1

Given that node.js is designed for server applications and can handle much more concurrent connections than other competing solutions, why is it ill-suited for server applications that involve heavy processing?

guagay_wk
  • 26,337
  • 54
  • 186
  • 295
  • Who's opinions on the topic have you been reading? – Pointy Jul 20 '15 at 01:48
  • Pointy: http://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js – guagay_wk Jul 20 '15 at 01:50
  • Why the requests to close this question? I believe it is important to know when and when not to use node.js. – guagay_wk Jul 20 '15 at 01:54
  • 2
    The question is not a bad one, but it's not the sort of thing that Stackoverflow is designed for. The answer is a matter of opinion, and this site is about finding help for specific, objective programming problems. There are other stackexchange sites that are oriented more directly at such discussions. – Pointy Jul 20 '15 at 02:05
  • 2
    For example, [here is a completely contrary viewpoint.](http://neilk.net/blog/2013/04/30/why-you-should-use-nodejs-for-CPU-bound-tasks/) – Pointy Jul 20 '15 at 02:06
  • 1
    *"why is it ill-suited for server applications that involve heavy processing"* - I'm not sure that you should start with the assumption that node.js is ill-suited for this purpose. Perhaps you should rephrase to "Is node.js ill-suited for this purpose?" – nnnnnn Jul 20 '15 at 02:19

3 Answers3

4

Short Answer: Because nodejs is single threaded, the same as javascript.

Brian McGinity
  • 5,777
  • 5
  • 36
  • 46
  • So, a heavy computational request would "hang" node.js? Is this interpretation correct? – guagay_wk Jul 20 '15 at 01:49
  • Plenty of people think Node is super-awesome for all sorts of server-side work, so I think it's hardly a settled matter. (Personally I don't argue with Node people :) – Pointy Jul 20 '15 at 01:50
  • Exactly, you want to keep your node processing as short as possible. Receive a request, process it, move on to the next. It might be possible to fork longer running processes. Personally I've never done it. I use node for web sockets and for me it's just a way to pass a message to someone's browser. – Brian McGinity Jul 20 '15 at 01:55
2

Because node.js is designed around using a single thread very efficiently. Its event based model dispatches code fragments when specific events occur. Those code fragments are supposed to execute very quickly and then return control to node.js, which then dispatches the next event.

If one of those code fragments performs a long running task, then no more events will be dispatched and the whole system appears to hang.

schtever
  • 3,210
  • 16
  • 25
  • 1
    Why can't node.js execute a portion of a long-running task, then skip to the next task and come back later to execute the remaining portion of the long-running task? This is quite standard behavior for operating systems. EDIT: On second thoughts, what I wrote above cannot be done because node.js is single-threaded? Correct? – guagay_wk Jul 20 '15 at 01:52
  • This isn't entirely true, you can fork worker processes for cpu bound work. – Brandon Smith Jul 20 '15 at 02:20
  • 1
    @BrandonSmith is correct. Node has facilities that allow you to delegate work to other processes and/or threads. The Cluster and Child Processes features are good examples. If you want to go under the covers, the built-in `libuv` has worker thread capabilities. It's then up to you to design how to put all this into play. But, the primary rule remains: never block the main thread. – schtever Jul 20 '15 at 02:29
1

Node js runs on a single thread while other popular server-side language runs on multiple thread. Therefore, heavy CPU operation would block the whole thread. For more detail, go to this page.

Community
  • 1
  • 1
Ken Kwok
  • 388
  • 3
  • 19