Offloading CPU work: worker threads and the libuv pool

A team profiles a slow image-resize endpoint, finds the CPU-heavy work, and “fixes” it by bumping UV_THREADPOOL_SIZE from 4 to 32. Nothing improves. The resize is JavaScript running on the loop thread, and the libuv pool they just enlarged does not run JavaScript at all — it runs native I/O. They tuned the wrong pool. Node hides two execution resources behind the one event loop, and knowing which work goes to which is the difference between a fix and a week lost.

Two pools, two jobs

Behind the single loop there are two distinct sources of parallelism, and they serve opposite kinds of work:

• The libuv thread pool — a small pool (default 4 threads, configurable up to 1024 via UV_THREADPOOL_SIZE) that runs native operations that have no async OS primitive: file-system calls, DNS lookups (dns.lookup), and the async crypto/zlib functions. It does not run your JavaScript. When you call fs.promises.readFile, libuv does the blocking read on a pool thread and posts the result back to the loop. This is why async bcrypt does not freeze the loop — the hashing runs on a libuv thread.
• Worker threads (worker_threads) — real, separate V8 isolates with their own event loop, giving true multicore parallelism for your CPU-bound JavaScript. This is where image resizing, large-payload parsing, compression, or any heavy computation belongs.

The image-resize bug is now obvious: resizing is JS, so it needs a worker thread, not a bigger libuv pool. Enlarging libuv only helps when you are bottlenecked on fs/dns/crypto throughput — and even then, more pool threads than CPU cores mostly adds contention.

The cost of a worker: moving data

Worker threads are not free, and the bill is mostly data transfer. By default, anything you postMessage to a worker is deep-copied via the structured-clone algorithm — for a large buffer that copy is real work (a multi-MB ArrayBuffer copy was measured around 268 ms, versus about 29 ms when transferred). Two escape hatches matter:

• Transferables — pass an ArrayBuffer in the transferList and ownership moves to the worker with no copy (the sender can no longer use it). Near-zero transfer cost.
• SharedArrayBuffer — shared memory both threads see at once, with Atomics for safe coordination. No copy, no transfer of ownership; the right tool when both sides need the same bytes.

So the senior calculus for offloading is: the work must be CPU-heavy enough to dwarf the message-passing cost. Offloading a 2 ms computation to a worker can be slower than just running it, once you pay the clone and round-trip.

When not to offload: chunk instead

Not every long computation needs a thread. If the work can be partitioned into small pieces, you can run a chunk, then setImmediate (or await a resolved promise) to yield the loop, then run the next chunk — letting I/O callbacks interleave between pieces. This keeps everything on the loop thread with no transfer cost, trading total throughput (the work now competes with requests) for a responsive loop. Chunking suits work that is long but interruptible (iterating a big array, paginating a computation). Worker threads suit work that is monolithic and heavy (a single resize, a crypto operation) or that you genuinely want running in parallel on another core.

And sometimes the right answer is neither: if CPU is the bottleneck across the whole service, horizontal scale — more processes (cluster) or more machines — is the lever, because one Node process maps to one loop, and CPU-bound throughput is fundamentally a core-count problem.