0Pricing
Node.js Backend Development Bootcamp · Lekcja

Tworzenie wielokrotnego użytku puli workerów dla przepustowości

Projektuj pulę workerów opartą na kolejce zadań, która ponownie wykorzystuje wątki i maksymalizuje użycie CPU pod obciążeniem

Tworzenie wielokrotnego użytku puli workerów dla przepustowości to bezpłatna lekcja Node.js Backend Development Bootcamp na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Node.js Backend Development Bootcamp, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Node.js Backend Development Bootcamp zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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.

  • isMainThread is true in the parent, false inside the worker.
  • parentPort is 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 idle is 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 === 0

Quick 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_threads moves 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 error event 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.

Często zadawane pytania

Czy lekcja „Tworzenie wielokrotnego użytku puli workerów dla przepustowości” jest bezpłatna?

Tak — pełny tekst „Tworzenie wielokrotnego użytku puli workerów dla przepustowości” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Node.js Backend Development Bootcamp, przejdź na CoddyKit PRO. Kurs Node.js Backend Development Bootcamp zawiera 4 lekcji w sumie.

Co nauczysz się w „Tworzenie wielokrotnego użytku puli workerów dla przepustowości”?

Projektuj pulę workerów opartą na kolejce zadań, która ponownie wykorzystuje wątki i maksymalizuje użycie CPU pod obciążeniem Ćwiczysz Node.js Backend Development Bootcamp z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Node.js Backend Development Bootcamp?

Nie wymagamy żadnego doświadczenia. Node.js Backend Development Bootcamp w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Tworzenie wielokrotnego użytku puli workerów dla przepustowości”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Node.js Backend Development Bootcamp?

Tak. Każda lekcja Node.js Backend Development Bootcamp zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Dlaczego pętla zdarzeń zatrzymuje się przy pracy obciążającej CPU
  2. Uruchamianie wątków roboczych i przekazywanie komunikatów
  3. Współdzielenie pamięci za pomocą SharedArrayBuffer i Atomics
  4. Tworzenie wielokrotnego użytku puli workerów dla przepustowości
← Powrót do Node.js Backend Development Bootcamp