"Thread-based networking is relatively inefficient and very difficult to use. See: this and this.Node will show much better memory efficiency under high-loadsthan systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process—there are no locks. Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems."
So not to be a big hater or anything, but let's visit a few ideas:
* Thread-based networking is only relatively inefficient at solving the very specific task node.js is trying to solve.
* Thread based networking is indeed relatively difficult to use
* No locks. That means no concurrency. Obviously, because we're not threading.
Event driven programming is great. Seriously. It's been kicking ass and taking names since the 70's, if not before. But, it is not a panacea. Event driven systems are inherently queued. Why? Because they can only service one thing at a time. Therefore, if you get 10 requests really fast, 1 processes while the next 9 wait. That's not so awesome.
Server side operations are well known to take time to operate. They are also famous for spending a lot of time in blocking I/O operations such as SQL reads or net calls of their own. It really doesn't matter if your memory footprint of node.JS allows you to scale to 10 bazillion users if your queue servicing speed only lets you serve 10 requests per second. Threading shines for these types of operations.
"But wait, " you may say, "you implied earlier that node.js has a specific task it handles well"
Yes, I did. Let's talk about that
It is well known threading introduces both CPU and memory overhead. If your server processes are primarily CPU bound and/or execute *extremely* quickly (like less than 3ms per request) then node.js has some advantage. The fact that the 1000th user had to wait his turn in the queue isn't such a big deal if it only took 3000ms for his turn to come up. Yes, it's a big deal because 5000ms is an eternity when the request "actually" takes 3 ms to process, but at least you can comfortably service 1000 user requests "at once". I imagine a threaded system would not fair much better, but I have no metrics to back that up.
My own experience is server side requests are a mixed bag, some taking longer to operate than others, and oftentimes operating faster and faster as time goes on (memory and caching permitting).
The verdict is the Node.js seems to have something solid to offer, but is not automatically a good choice.
No comments:
Post a Comment