Node JS single Threaded Vs MultiThreading (CPU Utilization : Any difference ? )

Question

I have started reading a lot about Node JS lately and one thing I am not able to clearly understand from differentiation perspective is what is the real difference between how I/O is handled by Asynchronous Vs Synchronous call.

As I understand, in a multi threaded synchronous environment , if I/O is started , the running thread is preempted and moves back to a waiting state.So essentially this is same as what happens with NodeJS asynchronous I/O call. In Node JS, when I/O is called, the I/O operation is moved out of current running thread and sent to event De-multiplexer for completion and notification. As soon as I/O is complete the callback method is pushed to event Queue for further processing.

So , the only difference I see is that in Node JS we are saving memory (due to multiple call stacks owned by each thread) and CPU ( saved because of no context switching). If I just consider that I have enough memory to buy , does saving of CPU due to context switching alone is making the huge performance difference?

If my above understanding is not correct, how does I/O handling is any different between a java thread Vs Node JS w.r.t to keeping the CPU busy and not wasting CPU cycles.Are we saving only context switching CPU cycles with Node JS or there is more to that?

Based on the responses , I would like to add another scenario:

Request A , Request B comes to J2ee server at the same time. Each request takes 10 ms to complete in this multi threaded environment.Out of 10 ms , 5 ms is spent in executing the code logic to compute some logic and 5 ms is spent in I/O for pulling a large dataset from a DBMS.The call to DBMS is the last line of the code after which the response should be sent to the client.

If same application converted to a node JS application, this is what might happen

1. Request A comes, 5 ms is used for processing the request.

2. DBMS call is hit from the code but it's non blocking.So a callback method is pushed to event Queue.

3. After 5 ms, Request B is served and again request B is pushed to event Queue for I/O completion.Request B takes 5 ms for processing.
4. Event Loop runs, pickups callback handler for request A, which then sends the response to client.So the response is sent after 10 ms because Req A and Req B both took 5 ms for synchronous code block processing.

Now where is the time saved in such a scenario?Apart from context switching and creating 2 threads. Req A & Req B both took 10 ms anyway with Node JS. ?

Answer 1

As I understand, in a multi threaded synchronous environment , if I/O is started , the running thread is preempted and moves back to a waiting state.So essentially this is same as what happens with NodeJS asynchronous I/O call.

Nope, in NodeJS an asynchronous I/O call is a non-blocking I/O. Which means that once the thread has made an I/O call it doesn't wait for the I/O to complete and move on to the next statement/task to execute.

Once the I/O completes it picks up the next task from event-loop-queue and eventually executes callback handler which was given to it while making the I/O call.

If I just consider that I have enough memory to buy , does saving of CPU due to context switching alone is making the huge performance difference?

Apart from this, saving is also coming from these two things

• Not-Having-To-Wait for the I/O to complete
• Not-Having-To-Make-Threads since threads are limited, so the system's capacity is not limited by how many threads it can make.

Apart from context switching and creating 2 threads. Req A & Req B both took 10 ms anyway with Node JS. ?

You are discounting one thing here - Thread is getting two request one after the other after a specific interval. So if one thread is going to take 10 seconds, then it will take a new thread to execute the second request. Extapolate this to thousands of requests and your OS having to make thousands of threads to deal with so many concurrent users. Refer to this analogy.