:wtf: How can this be so wrong??? (AKA the Discopocalypse thread)
-
I haven't got time right now to explain why I made it, but it was a hack to get something working.
Someone between you and the open internet blacklisted github?
-
What could possibly go wrong?
Could you imagine what this would do to the server if t/1000 were still active?
-
He's lucky he didn't have an "e-mail on ANY notification" setting, because that would bankrupt Inedo.
-
*head explodes*
-
@JBert said:
What could possibly go wrong?
Could you imagine what this would do to the server if t/1000 were still active?
there was someone wanting to make a follow bot to like everything @sam posted.;
they asked me to write it, but i just poited them at giggityhub.com and told them they knew where the code was.
they then wandered off into the garden shed and i've heard a lot of odd noises coming from there int eh several hours since. I do hope they';re not being naughty in there....
-
Could you imagine what this would do to the server if t/1000 were still active?
:thatwasthejoke.avi.gif:
Admittedly, the entirety of meta.d is a joke but I picked that particular topic because I knew it would interest people here.
-
> a. Oh ... 3 people just liked the post I just made, better go back and refine it.
Discourse: fixing what isn't broken since 2013.
Dashit? "This post is great, and people are enjoying the content-- so I better go change it"
Perfect! Now, change.
-
-
To be entirely fair..... That's not totally insane for a normal forum, and might actually be useful
-
Dammit Discourse, why must you serve it with
Content-Disposition: attachment
?Here, download it: giggityhub.svg
-
Thanks! That's awesome!!! :-D
-
https://meta.discourse.org/t/load-times-of-thousands-of-milliseconds-1-3-in-sql/40653
INB4: 14vCPU and 48GB of RAM is not enough for the forum for the next 10 years. Please try 128vCPU and 960GB of RAM (because just under 1TB of RAM should be enough for anyone 10 years from now)
-
I had a thought this morning, while I was trying to find which post got a badge in my notifications this morning...
The side benefit of this change would definitely be that you'd be able to see which post just got the Passable Poster badger, since you'd have a like notification for it adjacent to the badger notification.
So then I was wondering... did stumble on the workaround on accident? Or is he implementing this so that would see it as bikeshedding, rather than a bug fix, and be more likely to approve it...
-
So, yeah, we ripped out the main underpinning of our entire forum, and performance increased by 5x on the "already working well" case and about the much on the "works like shit" cases.
But clearly, we never made a mistake when we picked Ember and wrote the original layout. We're just better at our knowledge domain now, so we can do things Bigger, Faster, Stronger (and only for a $6M rewrite!!!)
-
We didn’t want to sacrifice too much code quality
-
Traditionally the topic stream was not tested as well as the other parts of the site because its code was the oldest and weirdest.
Somebody care to explain to me why the "weirdest" part of code should not be tested? Like, is that a thing that other devs/companies do as well? Because it seems backwards to me...
Filed Under: @PJH can we update Discourse to latest like a week before we switch? I want to know if it actually improved :D
-
Considering how retarded Ruby multi-threading is, I'm guessing 14 cores is way overkill. Ruby's all blocking everything with its global lock anyway.
-
I'm still laughing at how they told us for months that Ember was going to be the key to fixing the front-end performance problems.
-
Well, yes. But do you expect Jeff to know that?
-
Well the guy trying to squeeze performance out of that server might need to know that. Depending on what's causing the slowdown.
It's even conceivable he'd get better performance with fewer cores. Less thread-juggling means less global locking.
-
@PJH can we update Discourse to latest like
a week beforeafter we switch? I want to know if it actually improved<post can be empty
-
@Kuro said:
@PJH can we update Discourse to latest like
a week beforeafter we switch? I want to know if it actually improved<post can be empty
PROPOSAL:
When the new forums go up, move the DysentryHose forums to bikeshed.thedailywtf.com.
Once moved, we all agree to not use the forum. Don't read, don't post, don't check stats, nothing.
Without being touched at all, I wonder how long it will take for the forum to crash itself.
-
Or we could just reopen the likes thread and have some fun.
-
Considering how retarded Ruby multi-threading is, I'm guessing 14 cores is way overkill. Ruby's all blocking everything with its global lock anyway.
I haven't delved into Discourse code/stack too much, but I doubt that's the case. Workers are likely processes not threads, and there shouldn't be anything shared between them. Normally that config would be fine, provided the database is not underprovisioned, but
It's even conceivable he'd get better performance with fewer cores. Less thread-juggling means less global locking.
Probably, but not because of locking. Wording of that post implies the database runs on the same server as the application (wouldn't be surprised since that's the default official crappy discocontainer config) — if so, then setting app workers to twice the cores means they compete with the database for CPU, which would easily account for inflated latency.
That thread is very in any case.
-
@Lorne_Kates said:
Without being touched at all, I wonder how long it will take for the forum to crash itself.
If Ruby crashes on a VM and nobody's connected to it, does it make an error?
-
@Lorne_Kates said:
Without being touched at all, I wonder how long it will take for the forum to crash itself.
If Ruby crashes on a VM and nobody's connected to it, does it make an error?
Since it's Ruby, I'll assume yes-- yes it makes an error. Always. Every second. Always bet on "Ruby has an error". You will come out on top.
-
Probably, but not because of locking.
Application level locking, not database. Which Ruby is famous for, because Multithreading Is Hard and locking is the easy (but not particularly useful) way to deal with that problem (Just make everything synchronized, we'll be fine!).
-
Which for a web application receiving many concurrent polling requests for updates is surely a good idea...
-
Application level locking, not database. Which Ruby is famous for, because Multithreading Is Hard and locking is the easy (but not particularly useful) way to deal with that problem (Just make everything synchronized, we'll be fine!).
GIL doesn't matter here, application workers are separate processes.
-
So, after skimming it, the solution was:
Rip out the overly bloated MVVM bolted onto our MVC out of the picture and write a custom renderer so our MVC can do its job properly and offload all that shit from the client.
And that helped performance? SHOCKING!
-
INB4: 14vCPU and 48GB of RAM is not enough for the forum for the next 10 years. Please try 128vCPU and 960GB of RAM
Even better:
Many slow cores aren't discourse type
Apparently, you need Discourse certified™ CPUs to run Dickhorse now.
-
GIL doesn't matter here, application workers are separate processes.
I've seen how Ruby does this sort of thing. It likes to “cache all the things” in the current process, and then it fires up lots of processes to avoid problems with locking (because threading is hard, genuinely hard) and recycles those processes fairly frequently to avoid problems with user identities. That these features don't fit together too well… well, I'm not sure that anyone's really compared notes between all the various Ruby gems and worked out what sorts of things should be actually not done.
Doing a good web application framework is rather hard, as there's a lot of places where the right thing isn't obvious at all.
-
And yet the programming language/web server Atwood had most experience with, C#/IIS, had probably the best implementation of threading possible including a non-locking global website-wide caching implementation.
But why would you write a product in that!? Ludicrous. You might accidentally touch a *shudders* graphical debugger or something.
-
It's true, guy might find higher performance out of a dual-core g3258 running 4ghz+.
I read this as
It's true, guy might find higher performance out of a
dual-core g3258ZX-80 running4ghz+phpBB.
-
I'm still laughing at how they told us for months that Ember was going to be the key to fixing the front-end performance problems.
It was always The Next Version™ of Ember. Did that ever get released?
-
I think several iterations, and they always kept harping on about the next one. It was the excuse that kept on giving.
-
Ultimately, you can't get VC funding for something in the C#/IIS stack -- too much enterprise and not enough hipster to have the UPSIDE!!! necessary to bait in the startup capital.
Which, of course, is the real in IT funding these days.
-
Also, people who have been infected by the "need all the gigahurts!!!" brain worm are my most favorite people to hate. We're sort of running into that internally where I work -- trying to standardize on new hardware for power users (graphics or software development), and at risk of having to leave the TPM chip on the cutting room floor to be able to afford an i7 CPU, because there's absolutely no way that an i5 might be able to get the job done.
Never mind that Gen 5 & 6 i5s are generally just i7s that didn't pass an upcheck for some of their "gigahurts", and had base clock turned into Turbo bays instead, with a little bit of the L3 cache disabled.
-
I think several iterations, and they always kept harping on about the next one. It was the excuse that kept on giving.
According to @eviltrout, the problem was that Ember 2.0 added the feature they needed to be faster, but ended up taking 2-5x as long to do anything. And the Ember devs kept promising to fix perf issues but bikeshedded on new features instead. Shedception?
-
Ah, so @wood is a uppity-up in the Ember development cabal. That explains the technology choice.
-
Did he even use VC funding for Discourse? I thought he was paying those guys out of his pocket until they got clients.
-
Survey says maybe?
-
What the fuck kind of business case did he make for that? Sheesh. There are some brain-dead dumbshits in Silicon Valley. So glad I'm in the sane Seattle IT industry.
-
For actual confidential data you really should be using vetted software like GPG
-----BEGIN PGP MESSAGE-----
Version: BCPG C# v1.6.1.0hQIMA18rR1bthz0jAQ//XMW0msbqsZPBrXoFMc1/LvDRCXuLSUWOZugyMjah7x1M
QLCaGDACryys7GLhoCoJ6kjrPdtZH2dTJ1ORFHugPkhzsgUx0cndnOw8FkzoLN5b
ydeO4cY7jjp7h2bPCTjMyijanUkPSaGU6RRNWeYrlYhBEYZYojtLh8hfutlabyd+
YC2bzBY8+h+mikuOinpVpRX+kj9Esie+g2zF3L+J7c0SnL/pTG0B5WKdUDrLVAr3
Q/vOQb7QF6Wb8hObyu9ZUuusP7bvnlQl9nVmxAOUy5TOYG5y+g/WqjVMiy83OhbF
YewTbUi7HkMisq/QbiruarRVizpECkUO+XevUr/5lsy1ao1GBz1rObf6GWygrZ6s
drkAUuq6U2K+H4k5QbFOinwwi195EFVyZKfSFSgKr1lbz5s6y6VoRa6ZuXW5DxSt
6HUuQtbc3WkQW9phRNbDWtohPrZDu4prz78Mv4GoZKfF1p5eMLHo+31HVig9NLIk
oraEYlQ4n/hPfjJZvn7UgoRIbI0fpwa4y3E3VphK/evAV5leIXrVai64TZSk74c1
z8pIfxJ0FyVGHUgy7Xx24a2z+Eq+JH9M11lC+bWxBP12VxkxM3oSS35+79kSrRyo
KC1X+/KaIWSx3H6SDpHY1EKiplWcnAOPATEzNfkxgYWJVM70uEmwEa37LsFJzs7J
TCR1W97WWo0GyNgC05e9oSPBz75+MJPF3tgyihYPiebxLD3iEMMUv/gF+0G00qg5
BGH7P29CKc8iVOCuCG5AXoDo4jxG6LLYrdu8BRk=
=jYQf
-----END PGP MESSAGE-----
-
It's a pass through proxy that I wrote a while ago, thought I'd put it to "good" use by making GiggityHub™ a reality for you
Remember it is a proxy, so if you login, your credentials will go via my server. I'm not doing any man in the middle bullshit, but I thought I'd give you full disclosure.
You could use a self-hosted gitlab for this
-
So, after skimming it, the solution was:
Rip out the overly bloated MVVM bolted onto our MVC out of the picture and write a custom renderer so our MVC can do its job properly and offload all that shit from the client.
And that helped performance? SHOCKING!
Shame a group of users hadn't told them to do that before...
-
To be fair, Discourse is a business success - they've got a lot of big names using it and frankly, they're probably raking in cash with those plans.
This is why we can't have nice things......
-
Shame a group of users hadn't told them to do that before...
Where do you think they got the idea from?
They can't respond to all of the feedback we gave them at once, otherwise they wouldn't have a 10 year plan.
-
To be fair, Discourse is a business success
Let's do some bar napkin finances!
https://www.discourse.org/faq/customers/ - Lists 27 customers we can reasonably assume are paying the $1K a month Discourse tithe. Let's be generous and round up to 50.
$600K annual gross revenue.
They are up to 9 FTE, let's say average cost of $80K per annum. $720K in employee costs.
That leaves a grand whopping -$120K in net revenue.
You really think the VCs that gave that starter money aren't riding him like a ?
-
That leaves a grand whopping -$120K in net revenue.
You forgot the huge-ass hardware cluster neccessary to even run their flagshit product.