74

I don't understand several things about nodejs. Every information source says that node.js is more scalable than standard threaded web servers due to the lack of threads locking and context switching, but I wonder, if node.js doesn't use threads how does it handle concurrent requests in parallel? What does event I/O model means?

Your help is much appreciated. Thanks

Davita
  • 8,928
  • 14
  • 67
  • 119

4 Answers4

105

Node is completely event-driven. Basically the server consists of one thread processing one event after another.

A new request coming in is one kind of event. The server starts processing it and when there is a blocking IO operation, it does not wait until it completes and instead registers a callback function. The server then immediately starts to process another event (maybe another request). When the IO operation is finished, that is another kind of event, and the server will process it (i.e. continue working on the request) by executing the callback as soon as it has time.

So the server never needs to create additional threads or switch between threads, which means it has very little overhead. If you want to make full use of multiple hardware cores, you just start multiple instances of node.js

Update At the lowest level (C++ code, not Javascript), there actually are multiple threads in node.js: there is a pool of IO workers whose job it is to receive the IO interrupts and put the corresponding events into the queue to be processed by the main thread. This prevents the main thread from being interrupted.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
  • 2
    Thanks Michael. I understand that async IO operations are the nature of JS, but what I don't understand is, if node.js/JS is single threaded, how does it handle async operations. It can run async I/O operation in parallel with server side code, but how. – Davita Feb 29 '12 at 10:47
  • 3
    @Davita: I/O operations are not performed by the CPU. The server side code doesn't have to get involved until the external hardware has filled some buffer and tells the CPU about this via an interrupt mechanism. – Michael Borgwardt Feb 29 '12 at 10:58
  • 5
    @Davita there is a small writeup about node.js event loop here: http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/ – LoG Feb 29 '12 at 11:13
  • 1
    The Update portion is of great interest. I am also some what confused by the Single threaded-ness of node. My best understanding is the complexity of multi threaded programming is abstracted by node internals making life easier for the developers. – randomness Mar 06 '14 at 12:28
  • 1
    @randomness: basically, the complexity of multithreading is *avoided* by node's design. The IO workers are an implementation detail for performance reasons and are not relevant to the programming model of application code. – Michael Borgwardt Mar 06 '14 at 16:17
  • Similar approach as how [non-blocking IO](https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java)) works in Java. – Ozgur Vatansever May 19 '16 at 05:47
10

Although Question is already explained before a long time, I'm putting my thoughts on the same.

Node.js is single threaded JavaScript runtime environment. Basically it's creator Ryan Dahl concern was that parallel processing using multiple threads is not the right way or too complicated.

if Node.js doesn't use threads how does it handle concurrent requests in parallel

Ans: It's completely wrong sentence when you say it doesn't use threads, Node.js use threads but in a smart way. It uses single thread to serve all the HTTP requests & multiple threads in thread pool(in libuv) for handling any blocking operation

Libuv: A library to handle asynchronous I/O.

What does event I/O model means?

Ans: The right term is non-blocking I/O. It almost never blocks as Node.js official site says. When any request goes to node server it never queues the request. It take request and start executing if it's blocking operation then it's been sent to working threads area and registered a callback for the same as soon as code execution get finished, it trigger the same callback and goes to event queue and processed by event loop again after that create response and send to the respective client.

Useful link: click here

Alok Deshwal
  • 1,128
  • 9
  • 20
5

Node JS is a JavaScript runtime environment. Both browser and Node JS run on V8 JavaScript engine. Node JS uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node JS applications uses single threaded event loop architecture to handle concurrent clients. Actually its' main event loop is single threaded but most of the I/O works on separate threads, because the I/O APIs in Node JS are asynchronous/non-blocking by design, in order to accommodate the main event loop. Consider a scenario where we request a backend database for the details of user1 and user2 and then print them on the screen/console. The response to this request takes time, but both of the user data requests can be carried out independently and at the same time. When 100 people connect at once, rather than having different threads, Node will loop over those connections and fire off any events your code should know about. If a connection is new it will tell you .If a connection has sent you data, it will tell you .If the connection isn’t doing anything ,it will skip over it rather than taking up precision CPU time on it. Everything in Node is based on responding to these events. So we can see the result, the CPU stay focused on that one process and doesn’t have a bunch of threads for attention.There is no buffering in Node.JS application it simply output the data in chunks.

Mazumder Nazmul
  • 63
  • 1
  • 6
0

Though its been answered , i would like to just share my understandings in simple terms

Nodejs uses a library called Libuv , so this Libuv is written in C language which uses the concept of threads . These threads are called as workers and these workers take care of the multiple requests from client.

Parallel processing in nodejs is achieved with the help of 2 concepts

  1. Asynchronous
  2. Non blocking IO
Deepak Mukka
  • 358
  • 2
  • 6