3 ms·
> 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 l
by kompuuter 9y ago
> 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.
- allannienhuis 9y agoCare 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 9y agoOne 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.
- ruffrey 9y agoLooking 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 9y agoYou'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 9y agoAnd Raygun, according to what the website says it does, is doing a significant amount of work.