Why in node.js do you have a number of workers equal to cpu cores when there's a master worker too?

Question

Sorry I don't think the title to the question is particularly great, I struggled to create a suitable one for the multiple questions I have.

I understand that having one node process per cpu core is the best way to fully utilise a multi-core cpu when using node.js. I now understand after researching that running more than one per core is inefficient due to the fact that the cpu has to do context switching between the multiple processes. How come then whenever I see code posted on how to use the in-built cluster module in node.js, the master worker creates a number of workers equal to the number of cores, because that would mean you would have 9 processes on an 8 core machine (1 master process and 8 worker processes)? Is this because the master process usually is there just to restart worker processes if they crash or end and therefore does so little it doesnt matter that it shares a cpu core with another node process?

Would it be okay then if I ran a locally hosted webpage on the master node process that is a control panel for the server? Would it be better to run this webpage on a separate worker and leave the master process to handle respawning workers only? Or should I have 7 workers instead of 8 so the master worker has a whole cpu core to itself?

Answer 1

In the cluster module, there are two methods of distribution for incoming connections. In the round-robin approach (which is the default on all platforms except Windows), the master process receives the incoming connection and then distributes it to a worker processes. It is assumed that most of the time the work to accept the connection and distribute it is much smaller than the work that the actual worker process is doing. So, if you had 8 cores and had 1 master and 7 workers, then much of the time the 1 master process would be sitting idle and thus one core would be sitting idle. So, you can get more out of the CPU by actually using the 1 master and 8 workers and let the OS do process switching when all workers are busy and a new incoming connection happens. The theory is that this gets better utilization than letting one core go idle most of the time.

In the other scheduling algorithm that the cluster module uses where each child process listens directly for incoming connections, the master process has even less to do so again, it makes sense to create as many workers as there are cores.