[ionrock]

While I don't know node.js very well and can't speak to the "shared memory server", I do think it is valid to point out that this sort of redesign to fit the platform is frustrating. I've hit similar situations in Python where an async i/o framework is used and at some point there becomes a CPU bound task. The application was redesigned and new microservices were started in order to cope and the architecture became convoluted. This sort of question always seems to always show up in Python where limitations of the GIL influences the design of the software, the libraries used and deployment. It seems node.js, not surprisingly, has the same problems.

As the above comment clearly points out, there are workarounds to make things work. Still, when I think about the amount of time and effort that goes into debugging systems when they hit limits like the author mentioned, I imagine most of the the benefits gained by using a language like Python or JavaScript go away.

[gaastonsr]

It's not a Node.js limitation either. The design was not thought out from the beginning.

It has happened to me before. I design something, then I run it in multiple CPUS and it doesn't make sense anymore...

Or realize that if try to scale the current design doesn't hold.

Node.js running in a single thread is a good thing if you know how to work with it. Or if you really need multiple threads, use another PL.

Or you could write it in C++ and bind it to Node.js. And run it as a background process. Or spin up a worker? there seems to be multiple solutions here...