처리량 향상을 위한 재사용 가능한 워커 풀 만들기
부하가 발생해도 CPU 활용률을 극대화하도록 스레드를 재활용하는 작업 큐 기반 워커 풀을 설계합니다.
처리량 향상을 위한 재사용 가능한 워커 풀 만들기은(는) CoddyKit의 무료 Node.js Backend Development Bootcamp 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Node.js Backend Development Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
Why a Worker Pool?
Node.js runs your JavaScript on a single event-loop thread. That is great for I/O, but a CPU-bound task (hashing, image resizing, parsing, compression) blocks the loop and stalls every other request.
The worker_threads module lets you run JavaScript on separate OS threads. But spawning a brand-new Worker for every task is wasteful: thread startup costs tens of milliseconds and memory.
- Goal: create a fixed set of long-lived workers once.
- Recycle them across many tasks via a queue.
- Maximize throughput by keeping every CPU core busy.
That recycled, queue-backed set of workers is a worker pool.
The Blocking Problem
Before building the pool, feel the pain. A synchronous CPU loop on the main thread freezes everything: timers, HTTP responses, even a simple setInterval heartbeat.
Run this and watch the heartbeat go silent while fib(42) burns the CPU.
function fib(n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2);
}
let ticks = 0;
const timer = setInterval(() => {
console.log('heartbeat', ++ticks);
if (ticks >= 3) clearInterval(timer);
}, 50);
console.log('start blocking work');
console.log('fib(38) =', fib(38)); // blocks the event loop
console.log('done blocking work');A Single Worker Thread
The fix is to move CPU work off the main thread. A worker can be defined in the same file using isMainThread to branch behavior.
isMainThreadistruein the parent,falseinside the worker.parentPortis the message channel back to the parent.new Worker(__filename)re-runs this file on a new thread.
This is one worker for one task. The pool will generalize it.
const { Worker, isMainThread, parentPort } = require('node:worker_threads');
if (isMainThread) {
const worker = new Worker(__filename);
worker.on('message', (result) => {
console.log('result =', result);
worker.terminate();
});
worker.postMessage(40);
} else {
parentPort.on('message', (n) => {
const fib = (x) => (x < 2 ? x : fib(x - 1) + fib(x - 2));
parentPort.postMessage(fib(n));
});
}Designing the Pool's Pieces
A reusable pool needs four moving parts that work together:
- Workers array — a fixed number of long-lived threads, usually
os.cpus().length. - Idle list — workers ready to accept a task right now.
- Task queue — pending tasks waiting for a free worker.
- Pending map — links each busy worker to the Promise it must resolve.
The core invariant: a queued task only runs when an idle worker exists; when a worker finishes, it pulls the next task or returns to the idle list.
The Worker Script (worker.js)
Keep the worker logic in its own file so the pool can spawn many copies of it. The worker listens for messages, computes, and posts a structured reply that distinguishes success from error.
Always wrap the work in try/catch so a thrown error becomes a message rather than a crashed thread.
// worker.js
const { parentPort } = require('node:worker_threads');
function heavyTask(n) {
const fib = (x) => (x < 2 ? x : fib(x - 1) + fib(x - 2));
return fib(n);
}
parentPort.on('message', ({ id, payload }) => {
try {
const result = heavyTask(payload);
parentPort.postMessage({ id, result });
} catch (err) {
parentPort.postMessage({ id, error: err.message });
}
});Pool Skeleton: Spawning Workers
The pool constructor spawns N workers up front and tracks which are idle. Each task carries a unique id so replies map back to the right Promise.
Note the _tagWorker helper attaches a per-worker message/error listener exactly once, not once per task.
const { Worker } = require('node:worker_threads');
const os = require('node:os');
class WorkerPool {
constructor(workerPath, size = os.cpus().length) {
this.workerPath = workerPath;
this.idle = [];
this.queue = [];
this.pending = new Map(); // id -> { resolve, reject }
this.nextId = 0;
for (let i = 0; i < size; i++) this._spawn();
}
_spawn() {
const worker = new Worker(this.workerPath);
worker.on('message', (msg) => this._onResult(worker, msg));
worker.on('error', (err) => this._onError(worker, err));
this.idle.push(worker);
}
}Submitting Tasks and the Queue
run() returns a Promise and pushes a task onto the queue, then calls _dispatch(). Dispatch pairs a queued task with an idle worker; if none is free, the task simply waits.
- If
idleis empty, the task stays queued — no work is lost. - When a worker frees up, it drains the next queued task automatically.
This back-pressure is what keeps the pool stable under bursty load.
run(payload) {
return new Promise((resolve, reject) => {
const id = this.nextId++;
this.pending.set(id, { resolve, reject });
this.queue.push({ id, payload });
this._dispatch();
});
}
_dispatch() {
if (this.queue.length === 0 || this.idle.length === 0) return;
const worker = this.idle.pop();
const task = this.queue.shift();
worker._currentId = task.id;
worker.postMessage(task);
}Recycling: Handling Results
This is the heart of recycling. When a worker posts a result, the pool resolves the matching Promise, returns the worker to the idle list, and immediately tries to dispatch the next queued task.
The same worker handles task after task — no respawn — which is exactly what maximizes throughput.
_onResult(worker, msg) {
const { id, result, error } = msg;
const job = this.pending.get(id);
this.pending.delete(id);
worker._currentId = null;
this.idle.push(worker); // recycle the worker
this._dispatch(); // pull the next queued task
if (!job) return;
if (error) job.reject(new Error(error));
else job.resolve(result);
}Recycling on Failure
A worker can crash (uncaught exception, OOM). If you only handle message, a dead worker silently shrinks your pool and its in-flight Promise hangs forever.
On error, reject the in-flight task and respawn a replacement so the pool keeps its size. This self-healing behavior is essential for long-running services.
_onError(worker, err) {
const id = worker._currentId;
if (id != null && this.pending.has(id)) {
this.pending.get(id).reject(err);
this.pending.delete(id);
}
// remove the dead worker, keep pool size constant
this.idle = this.idle.filter((w) => w !== worker);
worker.terminate();
this._spawn();
this._dispatch();
}
async destroy() {
await Promise.all(this.idle.map((w) => w.terminate()));
}A Complete, Runnable Pool
Putting it together in a single file using isMainThread branching so it runs standalone. The pool fans 8 tasks across the available cores and resolves each via a Promise.
Notice every task resolves even though there are fewer workers than tasks — the queue handles the overflow.
const { Worker, isMainThread, parentPort } = require('node:worker_threads');
const os = require('node:os');
if (!isMainThread) {
const fib = (x) => (x < 2 ? x : fib(x - 1) + fib(x - 2));
parentPort.on('message', ({ id, payload }) => {
parentPort.postMessage({ id, result: fib(payload) });
});
} else {
class Pool {
constructor(size) {
this.idle = []; this.queue = []; this.pending = new Map(); this.id = 0;
for (let i = 0; i < size; i++) this._spawn();
}
_spawn() {
const w = new Worker(__filename);
w.on('message', ({ id, result }) => {
this.pending.get(id).resolve(result);
this.pending.delete(id);
this.idle.push(w); this._dispatch();
});
this.idle.push(w);
}
_dispatch() {
if (!this.queue.length || !this.idle.length) return;
const w = this.idle.pop(); const t = this.queue.shift();
w.postMessage(t);
}
run(payload) {
return new Promise((resolve) => {
const id = this.id++;
this.pending.set(id, { resolve });
this.queue.push({ id, payload }); this._dispatch();
});
}
destroy() { this.idle.forEach((w) => w.terminate()); }
}
const pool = new Pool(Math.min(4, os.cpus().length));
const jobs = [30, 31, 32, 33, 30, 31, 32, 33];
Promise.all(jobs.map((n) => pool.run(n))).then((results) => {
console.log('results:', results);
pool.destroy();
});
}Sizing and Tuning for Throughput
Pool size is a real decision, not a guess:
- CPU-bound work: size = number of physical cores (
os.cpus().length). More threads than cores just adds context-switch overhead. - Mixed work: a few extra workers can hide occasional I/O waits, but measure first.
- Transfer cost: large payloads serialize via structured clone; for big buffers use
postMessage(buf, [buf])to transfer ownership and avoid copying.
Always benchmark with realistic load. Throughput, not thread count, is the metric that matters.
const buf = new Uint8Array(1024 * 1024).fill(7);
// Transfer the buffer instead of copying it (zero-copy handoff)
worker.postMessage({ id, payload: buf }, [buf.buffer]);
// After transfer, buf is detached in the sender: buf.byteLength === 0Quick Check
Test your understanding of the pool's recycling design.
Recap
You designed a reusable worker pool that turns CPU-bound work into parallel throughput:
- Why: CPU-bound tasks block Node's single event loop;
worker_threadsmoves them to OS threads. - Pieces: a fixed workers array, an idle list, a task queue, and a pending map keyed by task id.
- Recycling: finished workers return to the idle list and pull the next queued task — no per-task respawn.
- Resilience: handle the
errorevent to reject the in-flight task and respawn a replacement so pool size stays constant. - Tuning: size to physical cores for CPU work, and transfer large buffers instead of copying them.
The result is a self-healing, back-pressured pool that keeps every core busy under load.
자주 묻는 질문
“처리량 향상을 위한 재사용 가능한 워커 풀 만들기” 강의는 무료인가요?
네 — “처리량 향상을 위한 재사용 가능한 워커 풀 만들기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Node.js Backend Development Bootcamp 강의 전체를 잠금 해제할 수 있습니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.
“처리량 향상을 위한 재사용 가능한 워커 풀 만들기”에서 뭘 배우나요?
부하가 발생해도 CPU 활용률을 극대화하도록 스레드를 재활용하는 작업 큐 기반 워커 풀을 설계합니다. 브라우저에서 직접 실행하는 실습 코드로 Node.js Backend Development Bootcamp을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Node.js Backend Development Bootcamp을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Node.js Backend Development Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.
“처리량 향상을 위한 재사용 가능한 워커 풀 만들기” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Node.js Backend Development Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Node.js Backend Development Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- CPU 집약적 작업에서 이벤트 루프가 멈추는 이유
- 워커 스레드 생성 및 메시지 전달
- SharedArrayBuffer 및 Atomics를 활용한 메모리 공유
- 처리량 향상을 위한 재사용 가능한 워커 풀 만들기