It's correct that Node.js uses multiple threading strategies. The libuv thread pool size equals to the number of logical CPU cores.
But, Node.js has many different queues. When the thread pool exceeds, each additional IO tasks is appended to the queue (FiFO).
A slow Node.js app rarely has something to do with thread pool size. Most often our code is synchronous, and that is slowing down Node.js quite a lot.
You can find everywhere those setTimeout( {...}, 0) calls. A trick to speed up synchronous code execution. Oh well, that is not true, but the recognizable effect is a performance boot. All this setTimeout zero does, is to move our slow code to the end of the message queue, allows other code to execute before our slow code blocks everything else.