Nodejs eventloop request response architecture for sending multiple responses to multiple client`s requests

Viewed 228

I am learning a nodejs structure and came to the event loop and request-response architecture model. As per documentation and multiple articles.as event loop process non-blocking operation and delegate blocking operation to the internal thread pool and when the thread finish operation, they prepare a response in the callback and come to the main stack where the event loop process response and send back to the client. It indicates if we have tasks that require CPU instead of db or file (I/O) operation our code will be in a blocked state(as it will take time to resolve). If we wrap that heavy task in promise as we do in front-end javascript(the browser will take care of the executor function). Would it be a good practice or am I looking for the wrong solution? I know it is not an I/O operation. and one more doubt ,Main thread finish call back execution of I/O operation ,and send response to client ,does it not make process slow if there are multiple responses are prepared to send back to client as it block main thread?

3 Answers

Running code asynchronously (without worker threads) will not help gain performance, as it will be queued in the callback queue. The callback queue contains all of the callbacks waiting to be run, and they all run in a single thread. For most web applications, the bottleneck is not on the event loop, but if you have heavy CPU consuming tasks and would like to take advantage of all of the CPU cores, you should consider one of the following:

  • Run one Node.js instance per core, and set up a load balancer in from of them (keep in mind that the machine still needs some CPU for Node.js internal asynchronous functions, other software running on the same machine, and that context switching generates counterproductive overhead)
  • Use worker threads (available from v10.5.0) and use their messaging features in order to synchronize them

No, handling heavy CPU task in Promises doesn't help dealing with main thread block, neither in Node.js nor in browsers.

If we wrap that heavy task in promise as we do in front-end javascript (browser will take care of executor function)

Sorry but we don't "wrap that heavy task in Promises" neither in browsers, if you did it and you found browser HUD was not blocked, probably you did it with a not so heavy task.

The right tools to deal with heavy CPU task are:

Main thread finish call back execution of I/O operation ,and send response to client ,does it not make process slow if there are multiple responses are prepared to send back to client as it block main thread?

With large amount of concurrent requests/responses, yes, but we are speaking about a very very large amount of concurrent requests/responses.

If your application is single user, that is no multiple requests are coming then it's good to use promise/callback/async-await. This is because NodeJs will execute asynchronous operations in the background and you don't need to worry about concurrency because app is single user based.

If your application is multi user like a web app, then it's better to run separate process out of main running program (your application) that is to create a worker thread. This is because, if two different clients request a CPU intensive operation, than your main program will not hang and both the requests will be processed simultaneously. However it's little bit difficult to manage and will cost high CPU. Interesting part is that, in a book I studied that web server process creates a new thread for each new incoming request to create a new TCP socket. This socket is used to uniquely identify that request.

Related