... which, again, shows just how much power you can get out of a 10 year old server if you're not being a sucker for the "latest and greatest" resume-driven-development crap.

Just look at New Reddit, it's an insane GraphQL abomination.

Here goes all your software engineering classes. So bare it's hilarious

It's not a special case at all. 20 years ago this was standard architecture (hell, HN still caches static versions of pages for logged-out users).

No, what changed is the industry devolved into over-reliance on mountains of 'frameworks' and other garbage that no one person fully understands how it all works.

Things have gotten worse, not better.

I wouldn't call that a special case, just using a good tool for the job.

I worked at at company near the top of https://en.wikipedia.org/wiki/List_of_the_largest_software_c... for a while. It was extremely common that web services only used about 1/20th of a CPU core's timeshare. These were dynamic web services/APIs. (We did have to allocate more CPU than that in practice to improve I/O latency, but that was to let the CPU idle to be ready to quickly react to incoming network traffic.)

This was many years ago on hardware several times slower than the current generation of servers.

Yo dawg, I hear you want to cache your cache of shards.

Negotiating TLS handshakes is one way. But I'd imagine the rest is largely IO-bound like you said.

It still puts into perspective what a big pile of dogshit consumer software has become that stuff like this comes as a surprise. Also, the last time I checked, Let's Encrypt also ran on a single system. As did the Diablo 2 server (I love reading about these anecdotes.)

For every incremental change in HW performance, there is an order-of-magnitude regression in SW performance.

Servers can also serve small text files out of memory incredibly fast.

If nothing else, handling interrupts from the NIC to pull packets out of its receive buffer, though that should be usually be isolated to a couple of cores.

Also, re: I/O, the CPU usually also has to handle interrupts there, as well as whatever the application might be doing either that I/O.

NodeJS apps usually use multiple processes, since JS event loop is limited to a single core. However, this means that you cannot share data and connection pools between them.

> I think NodeJS apps typically rely on JavaScript event-loop instead of starting new processes all the time.

> Spawning new processes for every user is possible but would probabaly be less scalable than even thread-switching.

I’d just like to note/clarify that there is, in fact, multi-threading happening under the hood when running Node.js. libuv, the underlying library used for creating and managing the event loops, also creates and maintains thread pools that are used for some concurrent and parallelizable tasks. The fact that JavaScript (V8 in the case of Node.js) and the main event loop are single-threaded doesn’t mean that multi-threading isn’t involved. This is a common source of confusion.

The update appears to have come with unlimited or much higher page size. I don't think anyone has found a thread that is still split into multiple pages.