Then I went to a conference (devLink) in Chattanooga, TN last month. Patrick Chu, a Sencha engineer and trainer, gave a talk on Node.js. Other speakers also talked about Node.js, and it became clear to me. Node.js is not just about satisfying someone’s preference about what language they want to write their server code in. It is about a totally different kind of server software. Node.js NEVER BLOCKS ON I/O. From the ground up, it is written to use the CPU at full speed. When waiting on I/O is needed, a callback is required. System calls are only EVER called in their non-blocking forms. In design-pattern-terms, this creates a programming approach conforming to the Reactor Pattern. This makes it incredibly easy to write efficient, responsive, event-driven server software of all kinds (not just web/http serving software) that is TOTALLY DIFFERENT architecturally from PHP, Java, Python, Ruby, or any other languages that read and write files and network sockets and database handles. These languages either ignore processes and threads (leaving the intricacies of server development to the application programmer) or make them first class citizens of the language (creating complexity to account for the blocking nature of I/O).
Why do we create 30 to 100 Apache workers to keep a machine busy that has 8 cores? It’s because the whole architecture of Apache and any software similar to it (including all web servers I had ever seen) is trying to make up for the fact that each of the processes is regularly blocking on I/O. With Node.js, an 8 core machine can be fully utilized with 8 Node processes.
The imperative of scaling a system requires that we move beyond a single process. The Node community is addressing these issues with load balancing, inter-process communication, and central coordinating servers (e.g. redis). Thus, while Node.js moves beyond the single process, it easily moves beyond the single server.