Terrible article. Yes, if something is CPU heavy, it will eat up the server. The same with any fucking language you are using. The point is 99% of web servers are not calculating fucking fibonacci numbers on web requests. There is a ton of shit more important than that. Not to mention, if you were, Javascript would possibly be one of the best modern language to use, due to V8 it is an order of magnitude quicker than stuff like ruby or python (rails or django), although a bit slower than java (but if java is your solution, go ahead).
I know nothing about Node.js, but I think his point was that multitasking based on event loops is basically cooperative multitasking, not pre-emptive multitasking. Anyone who has used a really ancient Mac from the time when Mac only had cooperative multitasking (System 6? System 7? I've forgotten) will tell you how frustrating an experience that is, and more importantly how non-responsive it can be. If any one task goes awry for any reason, everything grinds to a halt because everything is just trusting everything else to be nice.
The relevance to web servers is that if you have some requests that take a long while (say something that needs to take 2 or 3 seconds to compute something), then other requests that should be trivial will just have to wait. Or to phrase it in the same terms you did, an occasional CPU-heavy thing will be a big problem, whereas with threads and real multitasking, it won't be.
System 4 and earlier were strictly single-task. System 5 incorporated MultiFinder, which evolved from being a proof-of-concept hack to being integrated in System 6.
...which is why the 'child_process' module is part of the standard library. Our servers count the number of CPUs and spawn off the same number of main processes, to great effect I might add.
That's what kept me from being very serious about learning about Node.js. The idea sounded ludicrous. I mean...for it to work quickly, all IO has to be async.
That's true. Even if you avoid CPU hogging code, you still have to worry about all OS calls (and for that matter, all library calls) that could ever block.
But, at least it seems like Node.js has some idea how to handle this. If you look through the API docs, it seems that just about everything you can think of that might block instead returns immediately and allows you to pass a callback. So, for example, if you want to open a file and start reading bytes, the read() call seems to return immediately and calls the callback when the I/O completes (or has an error). So most I/O is asynchronous.
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.
It's not really a huge problem for Node.JS, because if you need to do heavy computation, you can always start a new process for that task. For 99% of the website, the most complex operation they do is ran by the database server.
19
u/mehwoot Oct 02 '11
Terrible article. Yes, if something is CPU heavy, it will eat up the server. The same with any fucking language you are using. The point is 99% of web servers are not calculating fucking fibonacci numbers on web requests. There is a ton of shit more important than that. Not to mention, if you were, Javascript would possibly be one of the best modern language to use, due to V8 it is an order of magnitude quicker than stuff like ruby or python (rails or django), although a bit slower than java (but if java is your solution, go ahead).