0

I've read several articles describing how the Node event loop works, and how asynchronous operations can be achieved from a single 'main' thread, but I'm unclear of one thing -

Does all asynchronous IO nodejs code use libuv under the hood? For example - connections to a DB through Sequelize/Tedious

The goal for my understanding, is to determine if increasing process.env.UV_THREADPOOL_SIZE will open a potential bottleneck with our DB connections. I've seen timeouts in the log, waiting for a DB connection, though the DB server has never shown any performance issues.

These are the articles I've been reading -

https://www.future-processing.pl/blog/on-problems-with-threads-in-node-js/ http://abdelraoof.com/blog/2015/10/28/understanding-nodejs-event-loop/ https://nodesource.com/blog/understanding-the-nodejs-event-loop/
When is the thread pool used?

Community
  • 1
  • 1
Jeremy
  • 2,970
  • 1
  • 26
  • 50
  • libuv is for asynchronous I/O. Not all asynchronous events, such as `setTimeout`, are performing I/O operations. But given the libuv was [originally developed for Node.js](https://github.com/libuv/libuv#overview) I'd say there's a good chance that all async I/O is handled with it. – Mike Cluck Jul 07 '16 at 20:13
  • Thanks for the comments. I've updated my question for clarity. – Jeremy Jul 07 '16 at 20:15

1 Answers1

1

All asynchronous operations do not use the libuv thread pool. They may all go through an interface in libuv, but not everything uses threads under the covers inside of libuv.

For example, timers don't use threads and networking calls don't use threads. They both use OS-level asynchronous features. It is my understanding that all major platforms do use thread pools for asynchronous disk I/O (though OS-level async disk I/O does exist in some platforms). Other async operations that may be implemented by a given library such as reading a temperature probe or something like that can all use their own methods (whatever they find most appropriate). It isn't dictated by libuv or node.js.

It would take examination of the code that implements your specific database to understand where your database bottleneck might be. It could be using threads or it could be limiting the number of simultaneous db connections too. It may have its own internal connection pool and that may need to be increased. Only examination of the specific code and how it handles the specific case you've observed would tell you for sure. There is no "generic" answer. It depends upon how the db interface to node.js is coded.

jfriend00
  • 683,504
  • 96
  • 985
  • 979