Question

This is the sort of the same question as before:

node.js child processes

I’m asking about whether or not I should use a child process per match for my node.js game.

But I realized that previously I neglected to include some very important details.

The game allows players to manipulate game rules in certain limited ways. However this can still lead to infinite loops / memory leaks / stalls and crashes.

Is 1 process per match a scalable / reasonable idea?

Answer 1

If any single game process can eat up all the memory or CPU, this isn’t scalable. If your server is an 8-core machine, eight games can take all of the CPU time, there’s nothing you can do, except for monitoring processes via top and killing them as needed – but that would make for a bumpy server.

Now, if you manage to prevent this stuff in the first place (sounds like a better idea to me), it is viable. Each process will take upwards of 30mb of memory, so you’ll need a beefy server for every couple hundreds. Look at http://site.nodester.com for an example, they seem to be running around 600 processes on a single machine. Their software stack is open source too: https://github.com/nodester/nodester

node v0.8 will bring Isolates (shared-nothing threads), which will probably use less resources than a child process.

A more “serious” solution to this would be using some kind of virtualization like OpenVZ that will allow you to set resource limits, then just keep a pool of virtual servers available, every game gets it’s own. It’s not as heavy as it looks, it’s ~18mb overhead per server and you can host hundreds per machine, although it’s a much more complex setup.