1

Referring to the following discussion: How is Node.js inherently faster when it still relies on Threads internally?

After having gone through all responses, I still have basic questions: If a DB call is made, 'somebody' has to block for the call to return. It turns into a blocking call deep down. Somebody has to make a call to the DB. The 'somebody' has to be a thread. If there are 50 DB calls, though they appear to be non-blocking to the Javascript, deep down they have all blocked. If there are 50 calls, for them to be all fired together on the DB, they have to be each sent to the DB by a thread. This means there would be 50 threads that have sent the DB call and are waiting for their call to return. This is no different than having 50 threads like they do in Apache. Please rectify my understanding. What is Node.js doing cleverly and how to ensure that fewer threads than 50 run in this case?

Community
  • 1
  • 1
Yash
  • 946
  • 1
  • 13
  • 28

2 Answers2

1

You are... partially correct. If there are 50 concurrent DB calls, then that means 50 threads, each dedicated to a DB call (actually, the reality is that by default, node provides only 4 concurrent threads in its thread pool, if you want more you have to explicitly specify how many threads you're willing to allow node to spin up; see my answer here - any excess requests are queued).

What makes this more efficient than Apache is that each of those threads is dedicated to the smallest functional unit... it lives only for the life of that database call, and then it's relinquished (in this case, a new thread is created, up to the limit, and then that thread is put back into the pool). This is in dramatic opposition to Apache, which spins up a thread for each new request, and may have to service multiple database calls and other processing in between until that request is completed and can then be relinquished.

Ultimately, this results in each thread spending more of its time doing work or in the pool waiting for more work and less time being idle and unavailable.

Be aware that this is workload-dependent, there are workloads that work better in the Apache model, but in general, most web style workloads are more suited to the node model.

Community
  • 1
  • 1
Jason
  • 13,606
  • 2
  • 29
  • 40
0

The difference is that I believe in something like apache, those threads are going to be handled in the order they are received. So if thread one is waiting for 10TB of data and thread two is only waiting for 10KB of data, thread two has to wait until thread one is done even though it's work could be done far faster and return quicker. With node the idea is that each thread waiting for I/O is returned as soon as it is done. So depending on the I/O the same situation could allow thread two to return before thread one is done it's work. This is older but still an excellent write up I believe of threading in node. http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

ThrowsException
  • 2,586
  • 20
  • 37