> In fact, I found it helpful. If your database is under load and is already running 4 heavy queries, not giving it any more jobs is actually a good thing.

Actually the threadpool shouldn't be a factor then, unless there are no nonblocking/async drivers for the database: internally, libuv uses its threadpool to asyncify operations for which no async/nonblocking version exists (Erlang does the same IIRC), for the most part it's filesystem operations, getaddrinfo and getnameinfo (I'm guessing it could include other stuff depending on what the underlying OS provides).

Socket or file IO should have native non-blocking APIs, so it does not need to use the threadpool.

On the other hand, not being able to hit the filesystem because you have those four queries running is... not so helpful.

In general, this looks like it could be a performance bottleneck for highly-concurrent applications.

I agree with this - the right place to restrict the number of concurrent database queries is the database, not the whole IO layer!

> If your database is under load and is already running 4 heavy queries, not giving it any more jobs is actually a good thing.

User-interfaces 101: don't sacrifice the latency of short-lived jobs for finishing lengthy jobs.

Also, let the OS figure it out. That's what it was made for.

There's a reason why queues are more performant than threads. See node.js and nginx for real-world examples.

The OS is dumb and does not understand the nature of load. If we applied your logic, everyone would still run Apache instead of nginx.

Your user-interfaces 101 fails flat on its face when you have hundreds of short-lived jobs that need to happen. Each one is insignificant on it's own, but if you overload the server will all of them at the same time just can starve system's RAM (forcing it to swap) or increase disk seeks by order of magnitude if short-lived jobs are asking for different data that is all over the place.

The only true answer here is: it depends.