149

If I understand correctly Node JS is non blocking...so instead of waiting for a response from a database or other process it moved on to something else and checks back later.

Also it is single threaded.

So does all this mean that a given Node JS process can fully and efficiently utilize a single CPU core but it will not use any other core on the machine, as in, it will never use more than one at a time.

This of course means that the other CPUs can still be used by other processes for things like SQL database or other intentionally separated CPU heavy subroutines as long as they are a separate process.

Also in the event that the Node JS process has an endless loop or long running function, that process is no longer useful in any way until the endless loop or long running function is stopped (or whole process killed).

Is all this right? Am I correct in my understanding?

700 Software
  • 85,281
  • 83
  • 234
  • 341
  • 3
    "Node" is _not_ single threaded. Only the JS/V8 engine runs in a single thread. The libuv part of NodeJS is multi-threaded. See [Is NodeJS really Single-Threaded?](http://stackoverflow.com/questions/7018093/is-nodejs-really-single-threaded) – RaelB Sep 20 '16 at 08:46
  • 1
    Hooking http://stackoverflow.com/q/17959663/632951 – Pacerier Feb 19 '17 at 18:53

5 Answers5

90

Pretty much correct, yes. The node.js server has an internal thread pool so it can perform blocking operations and notify the main thread with a callback or event when things complete.

So I imagine that it will make limited use of another core for the thread pool, for example if you do a non-blocking file system read this is likely implemented by telling a thread from the thread pool to perform a read and set a callback when it's done which means that the read could be happening on a different thread/core while the main node.js program is doing something else.

But from a node.js point of view, it's entirely single threaded and won't directly use more than one core.

skippy
  • 257
  • 3
  • 11
jcoder
  • 29,554
  • 19
  • 87
  • 130
  • 2
    I'm still new to Node.js and appreciate the discussion here. I just wanted to point out that making assumptions that non-blocking calls are backed by threaded blocking calls is probably not wise (not that @jcoder suggested to architect code around these assumptions). In this case, even if IO is handled on a separate thread with a blocking call, that thread will basically wait on the IO anyway, so it won't be making use of other cores/CPUs. Code to the strength of the tools you're using and don't worry too much about the low level details (until they become a problem). – wbyoung Mar 05 '14 at 20:05
  • so we can do other proses using callback like javascript code on frontend – yussan May 27 '16 at 03:51
37

Yes, I'd say that your understanding is entirely correct. This article (archived) explains the rationale behind this design quite well. This is probably the most important paragraph:

Apache is multithreaded: it spawns a thread per request (or process, it depends on the conf). You can see how that overhead eats up memory as the number of concurrent connections increases and more threads are needed to serve multiple simulataneous clients. Nginx and Node.js are not multithreaded, because threads and processes carry a heavy memory cost. They are single-threaded, but event-based. This eliminates the overhead created by thousands of threads/processes by handling many connections in a single thread.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
  • The article is false. Although a multithreaded apache mpm exists, it is incompatible with practically all everyday used configurations. Apache is multiprocess, and not multithreaded until now, and will be, probably forever. I find it catastrophal, manipulating the proper meanings of the terminology is only a nice try to hide the problem, instead solving it. – peterh Apr 13 '17 at 21:55
  • 1
    @peterh You are not making sense. The article is completely correct, stating that apache is multiprocess or multithreaded depending on config. The multiproces case is even worse in regard to handling many connections, which is the only reason Apache is mentioned in the first place. Additionally, the very commonly used PHP module is multithreaded all by its own. And finally, while I'm not an apache expert, my impression from other articles is that the worker MPM is in fact very commonly used. – Michael Borgwardt Apr 17 '17 at 13:22
  • @MichaelBorgwardt Yes, apache can be multithreaded and and also multiprocess, I didn't deny it. But php is incompatible with the multiprocess configuration, and if you would be an apache expert you would surely know it. The very commonly used php module is not multithreaded. Your information is false. I suggest to try a test configuration and you will see. It is a factual thing, not matter of debate, try it and you will see. – peterh Apr 21 '17 at 07:55
27

Even if this is an old thread, I thought, that I would share with an idea, how to utilize more that one core in Node.JS app. As Nuray Altin have mentioned - JXcore can do that.

Simple example:

var method = function () {
    console.log("this is message from thread no", process.threadId);
};

jxcore.tasks.runOnThread(0, method);
jxcore.tasks.runOnThread(1, method);

// this is message from thread no 1
// this is message from thread no 0

By default there are two threads (you can change it with jxcore.tasks.setThreadCount())

Of course there is much more that you can do with tasks. The docs are here.

Few articles on that subject:

infografnet
  • 3,749
  • 1
  • 35
  • 35
13

Since this question asked almost 2 years ago. Things are getting different or there are alternative approaches to multithreading problem on Node.JS

According to below blog post, using the incoming 'task' extension, some can benefit from other available cores directly.

http://oguzbastemur.blogspot.com/2013/12/multithread-nodejs.html

Nuray Altin
  • 1,294
  • 12
  • 19
2

Node.js is a single-threaded application, but it can support concurrency via the concept of event and callbacks. Here is video by Philip Roberts which explains how the event-loops works in javascript.

Click here to see the video

(Instead of WebAPIs there are C++ APIs in Node.js)

Saurabh Lende
  • 953
  • 2
  • 13
  • 19