`worker_threads` or the `threadpool`?

[AyushG3112]

Hi,

I'm trying to understand worker_threads module and I'm wondering which one of these is a better way to about calling crypto/fs etc APIs (which use the libuv threadpool and have a Sync variant)

Taking the crypto.pbkdf2 as an example, 2 options are:

Option 1: Normally calling crypto.pbkdf2() on the main thread
Option 2: Calling crypto.pbkdf2Sync() on a worker thread, thus preserving the libuv pool for other tasks

Could anyone point me out to which one is better, and why? If better is situational, I will appreciate some examples in which one might be better than the other. Thanks!

[addaleax]

tl;dr: crypto.pbkdf2(), not crypto.pbkdf2Sync() on a worker thread.

Option 1 is what we’d recommend. As you noted, the two can be quite similar, but, quoting the documentation:

Workers are useful for performing CPU-intensive JavaScript operations; do not use them for I/O, since Node.js’s built-in mechanisms for performing operations asynchronously already treat it more efficiently than Worker threads can.

This is definitely closer to the I/O use case, and you should expect the overhead of communicating between workers to be higher than the overhead of what Node.js does internally for the async method.

If you are worried about the libuv threadpool being occupied by tasks, you can currently modify it by adjusting the UV_THREADPOOL_SIZE environment variable; but also note that using more threads than CPU cores are available is likely going to impact performance in a negative way.

[AyushG3112]

@addaleax thanks for the answer. I understand what you mean, but, just for the sake of curiosity, are there any node APIs which can help us see the state of the thread pool(like how many processes are waiting to use the threadpool) so that we can optionally use Option 2 if needed?

[addaleax]

@AyushG3112 If you’re talking about the libuv thread pool, then, no. However, @davisjam is currently working on a large-scale refactor of the libuv thread pool, and this might be possible as part of that.

But generally: You should never need Option 2. If the libuv thread pool becomes less efficient than manually doing multithreading, it’s our job to improvie the libuv thread pool, not the users’ job to work around that.

[davisjam]

Hey @AyushG3112. Great question.

The work @addaleax referenced is Node.js #22631 , which goes with libuv #1726.

are there any node APIs which can help us see the state of the thread pool(like how many processes are waiting to use the threadpool) so that we can optionally use Option 2 if needed?

AFAIK this is not currently possible. It will become possible as part of my Node.js PR. If you have requests or suggestions about monitoring APIs, please comment on that PR.

I'm wondering which one of these is a better way to about calling crypto/fs etc APIs

Option 1: Normally calling crypto.pbkdf2() on the main thread
Option 2: Calling crypto.pbkdf2Sync() on a worker thread, thus preserving the libuv pool for other tasks

Could anyone point me out to which one is better, and why? If better is situational, I will appreciate some examples in which one might be better than the other.

Option 1 is preferable from an application writer's perspective.

However, it may not perform as well as Option 2 without my PR depending on your workload characteristics. I am working on metrics by which to make this decision as part of my Node.js PR.

The reason for the possibility of worse performance using Option 2 is that crypto is CPU-intensive and I/O (e.g. FS, DNS) is generally not. In the current Node.js architecture, asynchronous CPU and I/O APIs both route tasks to the same threadpool, and (with the exception of some throttling @addaleax added to DNS (libuv #1845)) will contend in non-optimal ways due to the differing characteristics of these tasks.

I am optimistic that my PR will cause Option 1 to be clearly preferable in the next few months.