Child Processes Q&A

[00:00:00]
>> Kyle Simpson: All right, any questions about working with child processes?
>> Student: So in production how would you handle this? You would have some kind of load balancer or hit up another?
>> Kyle Simpson: This isn't about load balancing, this is load testing. We're trying to crash the server. And I'm just doing it in a really cheap way, with child processes.

[00:00:22]
If you were really trying to hammer it, you'd probably have some kind of automation of a bunch of virtual machines. And different hardware trying to hammer it with tens of thousands of requests at a time, or something like that. This is just to illustrating the idea that you might wanna spin up things.

[00:00:38]
Where I got my first exposure to child process management before wasn't really from a load testing perspective, but certainly from a testing at scale perspective. I worked for a game company and we had the game of Bingo. And so we had some basic logic that a player would take in terms of keeping track of the numbers were that were called or whether they called the bingo.

[00:01:05]
Or whether it was true or not or whatever. So I coded this basic logic and then I wrote a node thing that would basically hammer our server with like ten or 20,000. And I would do more than one player per child process, but I would hammer the server with as many players as I could spin it up to.

[00:01:27]
And I think I got it up to about 60,000 players hammering our production game server before it really started to have trouble keeping up or something like that. But I've actually used this in real world scenarios, to try to kind of at-scale be able to manage things. A single node process is limited by the synchrony of JavaScript that it can only do so many things at once.

[00:01:51]
So by spinning it up into, even if you weren't doing one request per child like we're doing here. If you did ten children but ten requests per child, that's gonna be more concurrent, more parallel than if you try to do all 100 of those in the same node process.

[00:02:08]
There are some benefits in terms of load testing, to being able to spin up child processes. In terms of production systems, I can't really come up with very many situations where a live production system would spawn off child processes. If I needed to do that I would delegate to somewhere lower in the stack below node, in sort of a, but it certainly helps for scripting and testing.

[00:02:34]
Yes?
>> Student2: I was just curious about like what's the mechanism that's actually causing it to fail? Is it that the CPU on the machine is just maxed out, or?
>> Kyle Simpson: In this particular case, it was most likely, I don't know exactly what this means, but it was most likely that the operating system refused to spin up another child process.

[00:02:55]
So it literally just failed to spin up another child process. I don't think it was the web server itself that crashed. I think it was the child process limitation. Which is why I said before, you wouldn't necessarily in a real load testing scenario, do like one per child process.

[00:03:12]
You would just kind of chunk them up, like do a hundred requests for children, and then do a couple hundred children with a hundred request in each, or something like that. That'd be better usage of your system resources. Yes?
>> Student3: When you said you might consider on a production situation delegating some of these tasks not to child processes but somewhere lower on the stack.

[00:03:38]
Can you speak a little more to what sort of alternatives you would consider like.
>> Kyle Simpson: Any other non JavaScript language-
>> Student3: Fair enough.
>> Kyle Simpson: Right, I don't know the go programming language but I know that it's famously good at threaded programming. And if I needed to do some massive parallel programming kind of thing rather than spending up node processes which are relatively kind of heavy.

[00:04:00]
I'd probably delegate to some highly optimized system like Scala or Gala, or something. And have it do a bunch of really efficient threaded programming.