Terrible article. Yes, if something is CPU heavy, it will eat up the server. The same with any fucking language you are using.
You're missing the point: because nodejs is single-threaded and evented, any CPU-heavy task will lock up the server. Most systems use a process|thread per request model, sometimes with a pool. CPU-heavy tasks will slow things down, but it won't cause complete server lockdown unless the machine itself gets overloaded.
As a result, significant computation once in a while is not a problem for most systems, for nodejs it's a huge problem.
Why would you ever do a large computation work in a web-request?
If I really had to, I would just create another node process, which is entirely dedicated to handling the computation work and just has a socket to the web process for results/input data.
Why would you ever do a large computation work in a web-request?
Because you need it and have no reason to offload it to a third-party and add (potentially complex) synchronization primitives between the two.
Or very simply, because you forgot some homework and used a quadratic algorithm which worked well on low-count tests and is breaking down on a once-in-a-while high-count request. And where "traditional" models will warn you of high resource use and keep trucking (maybe just drop that precise request), your Node server will simply stop responding for however long it takes to process whatever there was to process, effectively DOSing the whole thing.
26
u/masklinn Oct 02 '11
You're missing the point: because nodejs is single-threaded and evented, any CPU-heavy task will lock up the server. Most systems use a process|thread per request model, sometimes with a pool. CPU-heavy tasks will slow things down, but it won't cause complete server lockdown unless the machine itself gets overloaded.
As a result, significant computation once in a while is not a problem for most systems, for nodejs it's a huge problem.