I was going to reply that this is pretty common for web apps, e.g. NodeJS or many Python applications also do not use multi-threading, instead just spawning separate processes that run in parallel. But apparently, HN ran as 1 process on 1 core on 1 machine (https://news.ycombinator.com/item?id=5229548) O_O
HN is not really that much of a workload. Links with text only comments, each link gets a few hundred comments at most, and commenting on stories ends after they are old enough.
Probably everything that's current fits easily in RAM and the older stories are candidates for serving from a static cache.
I wouldn't say this is an astounding technical achievement so much as demonstrating that simplicity can fall out of good taste and resisting groupthink around "best practices".
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 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.
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.