Typically, node.js applications run as a single process. A process can only run on a single CPU core at a time. There’s nothing more to gain if your machine only has a single core, but if it’s got a multi-core CPU, your node.js app is missing out on all the potential juice from the extra cores.
If your node.js application is a TCP / HTTP / HTTPS server that listens on a port, you can make use of node.js’ native cluster module to take advantage of multiple CPU cores for > 100% more processing power, depending on the CPU.
Clutch: a module for web server apps
We run many web servers written in node.js, many of them handling a large number of connections and requests, such as our API. To maximise the capacity offered by our servers, we’ve developed clutch. Clutch is a convenience wrapper around cluster which helps you achieve the benefits of cluster in your web server app with minimal effort. It handles spawning, monitoring and replacing worker processes, as well as graceful shutdowns. All you need to do is include it in your server, tell it how many workers you want to spawn (which can be as easy as os.cpus().length) and it will handle the clustering magic.
Multiple processes, multiple cores
When clustering, your app becomes a ‘master’ process which can spawn any number of worker processes. Incoming connections to the listen port are then efficiently load-balanced across these workers by the operating system. Since each worker is its own process, a multi-core CPU can run more than one concurrently. As a result, your server is able to process more requests than it could as a single process, as well as making use of previously un-tapped CPU capacity.
Multiple processes, more resilience
Running processes in a master / worker arrangement means the master process effectively becomes a watchdog and manager for its workers. If any workers crash, the remaining healthy workers will continue to accept connections while your master replaces the dead worker with a new one. While you should always work to fix any crashes, this improves the availability of your server when problems occur and is a convenient opportunity to implement logging and monitoring around application crashes. Of course, it is also advised that your master process itself is booted and supervised by a service such as upstart in Ubuntu, just in case that crashes too!
In cluster mode, processes listen out for system signals (SIGTERM, SIGINT, etc) that would otherwise terminate the process right away. Instead, these signals initiate the shutdown behaviour in clutch, where the master ensures all workers have exited before it quits itself.
A convenient feature of this is a controlled shutdown procedure before the process terminates. This gives you the opportunity to close off any open connections, finish pending work, and otherwise close off any activity that should complete before the process exits. Clutch implements a process shutDown event when it is ready to quit. Your application should listen for this event, run its shutdown procedure, and then call process.exit when it is ready to finish.