Why do we need connection pool in node.js when node is single threaded?

Question

Node.js is single threaded. The Javascript V8 engine and some of the internal libraries are multi threaded. For I/O, node delegates I/O to OS which may be multi-threaded.

If my node.js application is connecting to redis or ,sql/mariadb server, I assume I should not need a connection pool for redis or mysql.

As a developer, I create 1 redis or mysql connection and reuse it to send/get data. When data arrives, node will invoke the callback to process the data.

I understand connection pooling with Java/.NET but they are multi-threaded and so connection pooling in Java/.NET has clear benefit.

My question is: Why do we need connection pool in node.js when node is single threaded? Is there any benefit of it? Will node not leverage the multi-threading features of underlying OS and javascript engine without the developer having to do it?

Thanks

Tibbetts

Answer 1

Node runs your code single threaded. However, Node.js actually has a thread pool at its disposal that your code does not have access to. The threading mechanisms are implemented with libuv. Take a look at libuv book its in-depth and explains the inner workings of libuv.

Basically, your code is run within the context of the Event Loop (single thread). Any asynchronous work is then offloaded to an available thread from the pool and the Event Loop will just poll until that asynchronous work is completed by one of the threads. Once done, the callback function registered by your async call is then invoked and will get worked on during the next I/O Callback Phase of the event loop. You can read more about the Event Loop and its phases in the Node.js docs.

One of the benefits of building an application with this Event Loop style, is the abstraction of critical section coding (mutexs, semaphores, etc.) that is normally associated with multi-threaded applications.

Burtie

Thank you for the comment and links. So is there any benefit of using redis connection pool or mysql connections pool since node will use its internal thread pool for I/O? – Tibbetts

Sure, those connection pools still allow you to have multiple connections that are shared and available instead of having the overhead of waiting for a new connection to be opened. This is an optimization when implemented correctly. – Burtie

@Tibbetts Also those thread pools from redis and mysql are still being run with libuv just like your code. So there isn't a separate pool created by those packages. Your code is implemented with those packages, your code is run single threaded, those pools just provide open connections just waiting for work. No need to wait for the connection to be opened. – Burtie

Thanks for explanation... what if we reuse the same single connection without closing it. The same 1 connections will be used for redis for every request. So we won't have the overhead of opening a new connection everytime. – Tibbetts

@Tibbetts Yeah that works but be mindful, that connections can only do so much work, both client and server side. Generally speaking, connection pools are seen as a performance optimization and they're easy to use since most DB Drivers/Packages abstract their implementation so you can just process the requests without managing the connections explicitly in your code. – Burtie

Please see this: #21976770 – Tibbetts

Thank you @peteb. I think you have answered it... let me do some research. Thanks everyone. Also see #21976770 – Tibbetts

Answer 2

You need connection pools because even a single thread can hold multiple "blocking" DB connections (assuming RDBMS here). Without a connection pool, your app will create each connection from scratch for every additional DB request, even in a async / non-blocking system like Node.

Example:

request 1 - insert user  -- wait for response (assume it's 5 secs)
request 2 - insert invoice - wait for response (assume it's 3 secs)
request 3 - insert another invoice

Notice that request 3 is processed right away, without waiting for request 1 and 2 to complete. Right here in this single thread, we've already used three resources to connect to the DB. Imagine having to create each one every time you need a DB operation. It's much faster to just grab one from a connection pool!

Jaddo