Node Cluster and context switching

189 views
Skip to first unread message

Ω Alisson

unread,
May 19, 2015, 12:04:26 AM5/19/15
to nod...@googlegroups.com
I see many articles saying to spawn workes equal to CPU cores, but what about context switching cost?

Ryan Graham

unread,
May 19, 2015, 12:54:00 AM5/19/15
to nod...@googlegroups.com
If there is a process per CPU core, and the same process always runs on the same core, the result is generally less context switching. But that effect is nothing compared to the reason for the 1 worker per core recommendation.

While node uses multiple threads behind the scenes, only one of those cores runs your JS. Since your request handling and any other logic you've written is generally written in JS it can easily become a bottleneck while your other cores that aren't running your JS are mostly idle.

~Ryan

On Mon, 18 May 2015 at 21:04 Ω Alisson <thelin...@gmail.com> wrote:
I see many articles saying to spawn workes equal to CPU cores, but what about context switching cost?

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CACZE8Y5RbgMebOSks7VsO4GNiRjGy%3DPhj1oJh1FzfRhiHdgo%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Ω Alisson

unread,
May 19, 2015, 10:31:04 AM5/19/15
to nod...@googlegroups.com
I know about the disadvantages of the single thread model, even thinking about delegating heavy stuff to Rust now that it is stable

johnny somethingerman

unread,
May 27, 2015, 7:51:51 AM5/27/15
to nod...@googlegroups.com
The context switching costs don't change just because you're using node.  The suggestion to spawn workers equal to the number of cores (really, it's #cores -1, so the spawning process can still run) comes from the assumption that there are no other processes demanding CPU time.

In some more reliable systems, care is taken to ensure there is enough cpu time available to non-workers which provide essential system services.  That way if any workers get out of hand, the system will still function at a minimum level.  The choice to implement something more complicated such as this is going to be based on the requirements of the system.  Since most systems won't have this kind of requirement, spawning a worker per core (- 1) is a decent default policy.

Ultimately context switching costs in a scenario where you are doing 1 to 1 node processes to core are pretty minimal as long as there are no other services running on the system which demand immediate cpu time or any long running computational load.  OS schedulers try to be smart about these issues, but not having enough RAM in a system where swapping is happening will make even trivial context switches (ie, allowing ssh to spawn a new user shell) bog down some running processes.

Hopefully this is what you were looking for?
Reply all
Reply to author
Forward
0 new messages