child_process and scaling

76 views
Skip to first unread message

Ω Alisson

unread,
May 19, 2016, 5:51:46 PM5/19/16
to nodejs
I need to develop a service where the user sends an array of values, I generate a chart with d3.js and convert it to png with a child_process calling imagemagick to send it back to the user. Are there any caveats for child_process when scaling for thousands of requests?

Zlatko

unread,
May 20, 2016, 4:42:48 PM5/20/16
to nodejs
You have multiple things there. Thousands requests (per second, I assume) is a lot even without spawning a child shell. Thousands of spawned shells, even without image magick, can bring a busy system down. But then again, you will know best with a test. Try it and see if and where you get stuck.

Even if the system itself handles it, depending on how fast you get to your saturation limits, your response time may get increasingly longer. If that's acceptable and you know there will be downtimes when the jobs can catch up, you might do well with this.

The bigger problem I see there is that you cannot scale horizontally there. You wanna be able to send those convert jobs to other machines as well, probably. And for that, a simple child_process won't do, it would be better if you had some sort of a job queue (MQ, redis pubsub, something of the sort depending if you can allow failures and lost jobs). Then your service that listens for reqs only shoots them to the queue, and listens for a matching response on the response queue. And your actual png generation service can listen on the other side and only take as many requests simultaneously as it makes sense - e.g. maybe per num of CPUs or similar, test there and see what makes sense. And when you have a lot of work, just spawn another png generator on a new machine and you're good, no blocking.

The best thing to do is simply measure. Try to run several processes at once and shoot a thousand requests, see how long it takes for all of them to finish. Thn try to fire 10 waves of 1k reqs, each wave 2 seconds apart, and see how that goes. (Of course, adjust the numbers to your environment.).

Lastly, from my personal experience, these kinds of things regularly grow out of hand and original specs, and it's better to just do job queues from the get-go.

Hope that helps.

Zlatko

Ω Alisson

unread,
May 21, 2016, 8:07:47 AM5/21/16
to nodejs
Interesting. I wonder if it is better to use phantomjs for the PNG rendering. Although it is slower, I don't need child_process

--
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/09ff5e6e-f2fe-45d7-bb57-488230ee78d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Zlatko Đurić

unread,
May 22, 2016, 12:58:18 AM5/22/16
to nod...@googlegroups.com
You should try it. But the bottom line is, in a thousand-reqs-per-sec scenario, you'll almost always hit a bottleneck and need to scale the processing job over multiple machines. So it's a tradeoff - how important is it to you to finish every request, how fast you want results, is the 1k/sec throughput constant or peak... your imagemagick (or phantom binary, whatever you use) can only run so many instances on a single machine. 

So again - test your load such as it is. If you already have a sample JSON, write a node script to make a png out of it - parsing json and calling imagemagick should not take very much time. Then run the script 1k times in a row and see how fast it goes. Then run it in thousand parallel shells and see if that goes well, too. 

testing, testing, testing. Hope I'm not too boring with it.


You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/1Oi4uzV2TGw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

To post to this group, send email to nod...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Zlatko

Matt

unread,
May 26, 2016, 3:04:24 PM5/26/16
to nod...@googlegroups.com
Check out node-canvas for the rendering, then you won't need any child processes.


Ω Alisson

unread,
May 26, 2016, 8:42:07 PM5/26/16
to nod...@googlegroups.com

That's actually a great idea!


Reply all
Reply to author
Forward
0 new messages