0

Given a scenario with a single node process connecting to a single mongodb server, is there a reason to use connection pooling over a single persistent connection?

From what I understand, connection pooling is done so as to not create new connections all the time as well as to spread out the load with multiple operations. But if a single persistent connection works, and node is a single-threaded runtime by design, whats the point in having the default (5 connection) pool?

There's no more processing that can be done since its single-threaded. And the logic in the mongodb driver is able to multiplex multiple ongoing database operations on a single connection so it can't be that.

There must be some case that I'm missing that would warrant the use of multiple connections in a single-threaded environment. Is there some node-specific networking logic that I'm unaware of? Does it help out the database if there are more connections?

Edit:

The "duplicate" Q/As do not answer my question. I'm all too aware of the nodejs event loop and the answers to the other only address how to set up pooling and advocate against remaking connections, which my question isn't about. My question is, put more simply: why is 5 connections better than 1?

kmdreko
  • 25,172
  • 5
  • 32
  • 61
  • Only the javascript code is single threaded. Network, disc or db calls may go the kernel or thread pool to execute – Sagar Chaudhary Aug 17 '19 at 08:34
  • @SagarChaudhary sure, but since the serialization and deserialization of the database traffic is done in javascript, the work done by the external network-management stack is fairly insignificant and doesn't benefit from segregating traffic into multiple connections – kmdreko Aug 17 '19 at 17:53

0 Answers0