Bird
Raised Fist0
Node.jsframework~8 mins

Worker pool pattern in Node.js - Performance & Optimization

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Performance: Worker pool pattern
HIGH IMPACT
This pattern affects how efficiently CPU-intensive tasks are handled without blocking the main event loop, improving responsiveness and throughput.
Handling multiple CPU-heavy tasks in a Node.js server
Node.js
const http = require('http');
const { Worker } = require('worker_threads');

function runHeavyTask() {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./heavyTask.js');
    worker.on('message', resolve);
    worker.on('error', reject);
  });
}

http.createServer(async (req, res) => {
  const result = await runHeavyTask();
  res.end(`Result: ${result}`);
}).listen(3000);
Heavy tasks run in worker threads, freeing the main thread to handle other requests and inputs smoothly.
📈 Performance GainMain thread remains responsive; INP improves significantly; throughput increases under load.
Handling multiple CPU-heavy tasks in a Node.js server
Node.js
const http = require('http');
http.createServer((req, res) => {
  // Heavy computation directly on main thread
  let result = 0;
  for (let i = 0; i < 1e9; i++) {
    result += i;
  }
  res.end(`Result: ${result}`);
}).listen(3000);
Heavy computation blocks the main event loop, causing slow response times and poor input responsiveness.
📉 Performance CostBlocks main thread for hundreds of milliseconds per request, causing high INP and poor user experience.
Performance Comparison
PatternCPU UsageMemory UsageMain Thread BlockingVerdict
Heavy tasks on main threadHigh CPU on main threadLow memoryBlocks main thread causing high INP[X] Bad
Unlimited workers for each taskHigh CPU across many threadsHigh memory usageLess main thread blocking but high overhead[!] OK
Worker pool with limited threadsBalanced CPU across workersControlled memory usageNo main thread blocking, smooth responsiveness[OK] Good
Rendering Pipeline
In Node.js, the worker pool pattern moves CPU-intensive tasks off the main event loop thread to worker threads, preventing blocking. This keeps the event loop free to handle I/O and user interactions smoothly.
Event Loop
Thread Pool
Task Scheduling
⚠️ BottleneckMain thread blocking due to synchronous heavy computation
Core Web Vital Affected
INP
This pattern affects how efficiently CPU-intensive tasks are handled without blocking the main event loop, improving responsiveness and throughput.
Optimization Tips
1Offload CPU-heavy tasks to worker threads to keep the main event loop free.
2Limit the number of worker threads with a pool to avoid resource exhaustion.
3Reuse workers to reduce thread creation overhead and improve throughput.
Performance Quiz - 3 Questions
Test your performance knowledge
What is the main performance benefit of using a worker pool in Node.js?
AIt decreases memory usage by avoiding caching.
BIt prevents blocking the main event loop by offloading heavy tasks.
CIt reduces network latency for HTTP requests.
DIt speeds up database queries automatically.
DevTools: Performance
How to check: Record a CPU profile while running heavy tasks. Look for long main thread tasks and thread activity.
What to look for: Long blocking tasks on main thread indicate poor pattern; balanced CPU usage across worker threads and short main thread tasks indicate good pattern.

Practice

(1/5)
1. What is the main purpose of using the worker pool pattern in Node.js?
easy
A. To increase the memory usage by creating many workers
B. To avoid using any background threads or workers
C. To slow down the program by running tasks one after another
D. To run multiple tasks concurrently using a fixed number of workers

Solution

  1. Step 1: Understand the worker pool pattern concept

    The worker pool pattern uses a limited number of workers to handle many tasks efficiently without creating too many threads.
  2. Step 2: Identify the main goal in Node.js context

    It allows running tasks concurrently but limits the number of workers to keep resource use balanced and improve speed.
  3. Final Answer:

    To run multiple tasks concurrently using a fixed number of workers -> Option D
  4. Quick Check:

    Worker pool = fixed workers + concurrent tasks [OK]
Hint: Worker pool means fixed workers handle many tasks concurrently [OK]
Common Mistakes:
  • Thinking worker pool creates unlimited workers
  • Believing it slows down the program
  • Confusing it with single-threaded execution
2. Which of the following is the correct way to create a worker pool using Node.js worker_threads module?
easy
A. const { Worker } = require('worker_threads'); const pool = new WorkerPool(4);
B. const pool = new WorkerPool(4); const { Worker } = require('worker_threads');
C. const { Worker } = require('worker_threads'); const pool = WorkerPool(4);
D. const pool = new Worker('worker.js', 4);

Solution

  1. Step 1: Import Worker correctly from worker_threads

    The correct import is: const { Worker } = require('worker_threads');
  2. Step 2: Create a worker pool instance properly

    Assuming a WorkerPool class exists, it should be instantiated with new WorkerPool(4); to create 4 workers.
  3. Final Answer:

    const { Worker } = require('worker_threads'); const pool = new WorkerPool(4); -> Option A
  4. Quick Check:

    Correct import + new instance = const { Worker } = require('worker_threads'); const pool = new WorkerPool(4); [OK]
Hint: Import Worker first, then create pool with new keyword [OK]
Common Mistakes:
  • Calling WorkerPool without new keyword
  • Wrong order of import and instantiation
  • Using Worker constructor incorrectly
3. Given this simplified worker pool code snippet, what will be logged to the console?
const { Worker } = require('worker_threads');

class WorkerPool {
  constructor(size) {
    this.workers = Array(size).fill(null).map(() => new Worker('./worker.js'));
  }
  runTask(task) {
    return new Promise((resolve) => {
      const worker = this.workers.pop();
      worker.once('message', (result) => {
        this.workers.push(worker);
        resolve(result);
      });
      worker.postMessage(task);
    });
  }
}

const pool = new WorkerPool(2);
pool.runTask('task1').then(console.log);
pool.runTask('task2').then(console.log);
medium
A. Runs tasks sequentially, logs task1 then task2
B. Outputs results of task1 and task2 as they complete, order not guaranteed
C. Only task1 result is logged, task2 is ignored
D. Throws an error because workers array is empty after first pop

Solution

  1. Step 1: Understand worker allocation and reuse

    The pool starts with 2 workers. Each runTask pops a worker, uses it, then pushes it back after message received.
  2. Step 2: Analyze concurrency and output order

    Both tasks run concurrently on separate workers. Results log as tasks complete, order may vary.
  3. Final Answer:

    Outputs results of task1 and task2 as they complete, order not guaranteed -> Option B
  4. Quick Check:

    Workers reused, tasks run concurrently [OK]
Hint: Workers pop and push back, tasks run in parallel [OK]
Common Mistakes:
  • Assuming workers array empties causing error
  • Thinking tasks run one after another
  • Believing only first task logs
4. Identify the bug in this worker pool code snippet and choose the correct fix:
class WorkerPool {
  constructor(size) {
    this.workers = [];
    for (let i = 0; i < size; i++) {
      this.workers.push(new Worker('./worker.js'));
    }
  }

  runTask(task) {
    if (this.workers.length === 0) {
      throw new Error('No workers available');
    }
    const worker = this.workers.pop();
    worker.once('message', (result) => {
      resolve(result);
      this.workers.push(worker);
    });
    worker.postMessage(task);
  }
}
medium
A. Replace pop() with shift() to get workers in order
B. Remove the check for empty workers array
C. Add a Promise wrapper around runTask and return it
D. Call worker.terminate() after task completes

Solution

  1. Step 1: Check runTask return and resolve usage

    runTask uses resolve inside callback but does not return a Promise or define resolve, causing error.
  2. Step 2: Fix by wrapping runTask in a Promise and returning it

    Wrap the logic inside return new Promise((resolve) => { ... }) so resolve is defined and caller can await result.
  3. Final Answer:

    Add a Promise wrapper around runTask and return it -> Option C
  4. Quick Check:

    runTask must return Promise with resolve [OK]
Hint: runTask uses resolve but lacks Promise wrapper [OK]
Common Mistakes:
  • Ignoring missing Promise causes runtime error
  • Removing worker availability check breaks logic
  • Terminating worker too early stops reuse
5. You want to process 10 CPU-heavy tasks using a worker pool of size 3. Which approach best ensures all tasks run efficiently without overloading the system?
hard
A. Create 3 workers, queue tasks, assign next task when a worker finishes
B. Create 10 workers, one per task, and run all at once
C. Run all tasks in the main thread sequentially without workers
D. Create 3 workers but assign all tasks to the first worker only

Solution

  1. Step 1: Understand resource limits and worker pool size

    Creating too many workers (10) can overload CPU and memory. Using 3 workers limits resource use.
  2. Step 2: Use a task queue to assign tasks as workers become free

    Queue tasks and assign next task to a worker when it finishes ensures all tasks run efficiently without overload.
  3. Final Answer:

    Create 3 workers, queue tasks, assign next task when a worker finishes -> Option A
  4. Quick Check:

    Fixed workers + queued tasks = efficient processing [OK]
Hint: Use fixed workers and queue tasks for efficiency [OK]
Common Mistakes:
  • Creating too many workers causing overload
  • Running tasks sequentially wasting concurrency
  • Assigning all tasks to one worker blocking others