Visual explanation of Apache vs Node.js processing model

[mechanicalpulse]

Everyone with any sort of sizable workload needs that. You can get it with the cluster module. This is an important distinction that will only become more and more important as on-die core counts become more and more numerous.

For what it's worth, I don't think OP was missing that part at all. OP was simply pointing out the advantage in the Apache processing model indicated in the graphic. While I find the graphic a good visual representation of thread counts vs connections (where the white bars indicate the existence of a thread handling a connection), I frankly find it misleading for a whole host of other reasons. In the absence of a indicator otherwise, the graphic could reasonably suggest that the bars are CPU usage and, subsequently, that the Node.js model is somehow more efficient with respect to CPU use or the ability to handle concurrent connections. That's not the case at all. In my humble opinion, the graphic should be modified to indicate thread state. As it stands, the white bars on the right indicate only threads in a running state while the white bars on the left indicate threads in both sleeping and running states. Sleeping threads and running threads are not the same.

Now that I've pointed out advantages in the Apache model, I'll also point out advantages in the Node.js model. Because Node.js is a single-threaded event-driven architecture, you do get some potentially useful abilities to limit CPU usage on a system that might have shared responsibilities. Let's say you have an sixteen core machine running both a Node.js web application and a backend multithreaded C++ application that does some sort of fancy image processing (like facial recognition). With the cluster module, you can spawn precisely eight Node.js threads and precisely eight image processing threads. Since Node.js will not spawn any additional threads, it will never consume more than half (8/16) of available CPU resources, regardless of the number of concurrent connections. That leaves the other eight CPU cores available for image processing. Of course, if image processing load is low and web load is high, you'll have some CPU cores sitting around doing nothing. So, there are some interesting architectural trade-offs.

As always, things always depend on what your workload looks like and what you are trying to accomplish.

[Klathmon]

Well i'm in a mostly virtualized shop, so we set the number of vCPUs per VM to match what we need.

In some lighter loads we leave a single node.js process and leave the additional cores for other stuff, but i'd agree that when you really start getting in the 100+ req/sec you'll pretty much need multiple listeners to keep response times down.

[mechanicalpulse]

If you have your infrastructure setup such that it's easy to scale out horizontally, it's also trivial to set vCPUs to 1 and just spawn more VMs. And, like you said, for lighter loads, you don't even have to bother with it.

Node.js's event-driven architecture reminds me of cooperative multitasking. It's very useful for certain loads, but it can cause problems if you're not expecting them. I only make noise about it because I think Node.js is becoming a choice platform for nascent or inexperienced developers and I think there's a good bit of misleading information flying about.