[vorpalhex]

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. By no means is Node the end-all be-all for performance by any measure, but you should definitely be getting much much higher throughput than 1k reqs/sec.

Simply booting up a single core http server should net you around 4-5k requests per second. Spin up an instance per core and you should be _at least_ in the 10k realm.

[coldtea]

>Simply booting up a single core http server should net you around 4-5k requests per second.

There's no such thing as "requests per second" generally. It's requests per second for a specific workload.

So, whether Node can do 4-5k rps with "hello world" doesn't matter much. It's the same engine that needs to also do the further processing for each fuller request.

[aliostad]

My understanding is that they hand just off the payload to another queueing mechanism. So it just returns ACK and done.

[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.

[always_good]

As the sibling comment points out, your middleware that has a 30k req/sec hello world may slow down to 500 req/sec on a production server once it's competing with everything else on the thread.