[kompuuter]

> The fact that they were only getting 1k reqs/sec with Node gives me concern. It clearly shows something went wrong there very early on at a very fundamental level.

Because the program is performing CPU compute for each request. Node is single threaded.

It's a shame that the Node project killed off the multithreaded web workers pull request. It sorely needs that functionality. Pools of node processes are a poor substitute.

[ruffrey]

Looking at my Prometheus stats right now, I've got a Node TCP server doing 12k concurrent connections with 3-5% CPU and 130 MB memory. At least 4 DB queries are done per request, sometimes 10 queries. Raygun either has some nonobvious stuff going on, or Microsoft paid them to write PR fluff. After 6 years with Node it seems odd for their performance to be so bad. They should dive into more technical details to explain what specifically was made faster.

[uppity]

You've described a classic I/O bound server application (waiting on the database) that Node handles well. As soon as you introduce serious computations or server side rendering into the request handling performance would fall dramatically.

[zamalek]

And Raygun, according to what the website says it does, is doing a significant amount of work.

[allannienhuis]

Care to elaborate on why additional node processes are a poor substitute? They are really easy to reason about, and to manage. What are the downsides? Not trolling, really interested in hearing about pros/cons.

[markrendle]

One obvious thing is that multiple processes means no sharing of any kind of state or in-memory cache, so you immediately have to go to an external cache like Redis or whatever, with the additional maintenance and minor performance hit.