Becuse a core equals a process is a very old piece of information from the times when cpu’s were not fast enough to handle more than a thread that it id not appear to be blocking the whole cpu cycle.
current cpu architectures (for the past 10+ years) are perfectly capable of handling multiple threads from multiple processes. A cpu acts like a turn-gate and is intelligent enough to prioritize what comes in and what waits. And does that millions of times per second.
Think of your own computer. You have probably 4-8 cores. Now open up your task manager and count the actively running processes. It should be somewhere around 50-100.
Of course if one of those processes starts a job that actually holds the cpu or runs so many cycles that it does clog up a core’s overall processing ability, then yes a core to instance mapping starts making sense. But for most applications that we’ll be developing on meteor/node, it is not the case.
Therefore, given you actually do profile your real use case, you can go with far more instances than the number of cores you have available.
Also don’t take it from me. Phusion Passenger optimization guide provides a good non-technical explanation at https://www.phusionpassenger.com/documentation/ServerOptimizationGuide.html
Number of CPUs. True (hardware) concurrency cannot be higher than the number of CPUs. In theory, if all processes/threads on your system use the CPUs constantly, then:
- You can increase throughput up to NUMBER_OF_CPUS processes/threads.
- Increasing the number of processes/threads after that point will increase virtual (software) concurrency, but will not increase true (hardware) concurrency and will not increase maximum throughput.
Having more processes than CPUs may decrease total throughput a little thanks to context switching overhead, but the difference is not big because OSes are good at context switching these days.
On the other hand, if your CPUs are not used constantly, e.g. because they’re often blocked on I/O, then the above does not apply and increasing the number of processes/threads does increase concurrency and throughput, at least until the CPUs are saturated.
The key point is saturating your CPU’s and most Meteor applications will go nowhere near saturation given that especially the publications are crafted sparingly.
And mind you that phusion passenger is actually a process manager (not a web/app server) and they are all about orchestrating processes effectively. So their opinion on this matter should not be taken lightly.