5 ms·

> one effective way that we get high performance out of node.js is to avoid doing computation in node.js. And therein lies the problem with node. Its great for

by fein 11y ago

> one effective way that we get high performance out of node.js is to avoid doing computation in node.js. And therein lies the problem with node. Its great for rapid prototyping, but things fall apart pretty quickly with CPU laden tasks. That and the whole single threaded thing with node (technically JS) can be a wrecking ball when one task takes too long.

NathanKP 11y ago
I've done CPU laden tasks many times in Node. The key is how you break up the heavy task into pieces that can be distributed more evenly on the event loop instead of blocking it. For example processing a huge data stream is typically done by breaking it into chunks where each chunk can be processed in a few ms, rather than doing one giant blocking operation on the entire stream. Done properly this also leads to a low memory process that will grab data from an incoming socket stream, transform it, then push that data back out through an outgoing socket stream, only ever keeping a few MB of the stream in working memory at a time. Slap a cluster of these streaming processes together running on a single box to utilize all CPU cores and you can easily push many Mbps of IO through your server quickly and efficiently. Additionally even if you do have a heavy blocking system IO operation that you can't break up very well you can increase `UV_THREADPOOL_SIZE` when needed to reduce the impact of the blocking.
- SignMeTheHELLUp 11y ago
  But now you've just implemented thread context switching by pulling it's implementation details into your algorithm... Just use a language that supports threading if you have real work to do...
  - NathanKP 11y ago
    Sometimes it is more efficient to implement the context switching yourself. For extremely high performance server use cases such as realtime analytics, streaming video processing, high frequency trading, etc it isn't uncommon to have server code written in C/C++. It really depends on what your most important metric is. If the most important metric is speed then having more control over context switching is often better.
demmer 11y ago
(Disclosure: I’m the VP Eng at Jut) As Dave pointed out in the blog, we’ve definitely run into our fair share of challenges with the inherent limits of node.js. But on the whole, we’ve found it to strike a good balance between speed of development and performance. In addition to some of the techniques talked about in the post, we’ve also dropped down to C++ add-ons where we have really critical performance sections, and we do coarse-grained load balancing between multiple node processes to distribute computation on multiple cores. We also have a good bit of shared code between the browser and server (including the Juttle language compiler and runtime) that has been hugely beneficial for us. YMMV of course.
kaoD 11y ago
Same problem with hammers. They're great for nailing, but nearly useless when eating soup. What I'm trying to say is: use the right tool for the job. If your code is CPU intensive either don't use Node or use it exclusively for the IO-bound tasks and spawn jobs (or use a message queue, or whatever) for your CPU-bound needs.
richmarr 11y ago
There are two conflated points here. > ... things fall apart ... a wrecking ball... This one is FUD. I doubt there are many left on HN or anywhere else that hasn't heard this argument, and a similar proportion who don't know the solution (which is that you use clustering or worker processes for tasks the block the process more than your use case can absorb). > Its great for rapid prototyping... This one is true, it is great for rapid prototyping, but the implied point that it's not good for production apps is demonstrably false (as proven by the number of serious and respected companies happily using it in production). There's an argument to be made about node.js being a form of technical debt, and that's a reasonable point, but it also needs to be made in the context of the huge value of that technical debt. Update: I actually think Node.js is a contributor of technical debt but that it's worth the cost for the use cases I usually deal with (see point 7 on my post: https://medium.com/@richmarr/technical-debt-and-why-most-people-who-talk-about-it-are-just-plain-wrong-5c52b5d7121c https://medium.com/@richmarr/technical-debt-and-why-most-peo...)

by fein 11y ago

NathanKP 11y ago

I've done CPU laden tasks many times in Node. The key is how you break up the heavy task into pieces that can be distributed more evenly on the event loop instead of blocking it. For example processing a huge data stream is typically done by breaking it into chunks where each chunk can be processed in a few ms, rather than doing one giant blocking operation on the entire stream. Done properly this also leads to a low memory process that will grab data from an incoming socket stream, transform it, then push that data back out through an outgoing socket stream, only ever keeping a few MB of the stream in working memory at a time. Slap a cluster of these streaming processes together running on a single box to utilize all CPU cores and you can easily push many Mbps of IO through your server quickly and efficiently. Additionally even if you do have a heavy blocking system IO operation that you can't break up very well you can increase `UV_THREADPOOL_SIZE` when needed to reduce the impact of the blocking.

SignMeTheHELLUp 11y ago
But now you've just implemented thread context switching by pulling it's implementation details into your algorithm... Just use a language that supports threading if you have real work to do...
- NathanKP 11y ago
  Sometimes it is more efficient to implement the context switching yourself. For extremely high performance server use cases such as realtime analytics, streaming video processing, high frequency trading, etc it isn't uncommon to have server code written in C/C++. It really depends on what your most important metric is. If the most important metric is speed then having more control over context switching is often better.

demmer 11y ago

(Disclosure: I’m the VP Eng at Jut) As Dave pointed out in the blog, we’ve definitely run into our fair share of challenges with the inherent limits of node.js. But on the whole, we’ve found it to strike a good balance between speed of development and performance. In addition to some of the techniques talked about in the post, we’ve also dropped down to C++ add-ons where we have really critical performance sections, and we do coarse-grained load balancing between multiple node processes to distribute computation on multiple cores. We also have a good bit of shared code between the browser and server (including the Juttle language compiler and runtime) that has been hugely beneficial for us. YMMV of course.

kaoD 11y ago

Same problem with hammers. They're great for nailing, but nearly useless when eating soup. What I'm trying to say is: use the right tool for the job. If your code is CPU intensive either don't use Node or use it exclusively for the IO-bound tasks and spawn jobs (or use a message queue, or whatever) for your CPU-bound needs.

richmarr 11y ago

There are two conflated points here. > ... things fall apart ... a wrecking ball... This one is FUD. I doubt there are many left on HN or anywhere else that hasn't heard this argument, and a similar proportion who don't know the solution (which is that you use clustering or worker processes for tasks the block the process more than your use case can absorb). > Its great for rapid prototyping... This one is true, it is great for rapid prototyping, but the implied point that it's not good for production apps is demonstrably false (as proven by the number of serious and respected companies happily using it in production). There's an argument to be made about node.js being a form of technical debt, and that's a reasonable point, but it also needs to be made in the context of the huge value of that technical debt. Update: I actually think Node.js is a contributor of technical debt but that it's worth the cost for the use cases I usually deal with (see point 7 on my post: https://medium.com/@richmarr/technical-debt-and-why-most-people-who-talk-about-it-are-just-plain-wrong-5c52b5d7121c https://medium.com/@richmarr/technical-debt-and-why-most-peo...)