Для повышения производительности приложений на NodeJS во всех материалах рекомендуется использовать нодовский встроенный модуль cluster. Все статьи повторяют одно и то же, что и так написано в документации.
Вот официальный пример из доки:

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

const numCPUs = availableParallelism();

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

А теперь поделюсь своими исследованиями и расскажу, что не так в этом примере и как это можно улучшить.

Во-первых, некорректен нейминг переменной numCPUs. На моём компьютере, на котором тестировал производительность, стоит процессор Intel i7-13700, в нём всего 16 ядер. Сайт Intel так и пишет:

Обратите внимание: 16 ядер и 24 треда. И нода после вызова availableParallelism() возвращает число 24, а не 16. Так что это не ядра, а треды.

Во-вторых, большинство нодовских приложений - это обычные API. Какой-нибудь REST API, гоняющий туда-сюда JSON. А берётся этот JSON в большинстве случаев из базы данных вроде PostgreSQL. Многие сайты, описывающие работу с модулем cluster в качестве примера, почему-то возвращают моковые данные, захардкоженные прямо в коде, а в реальную базу данных не лезут. И потом делают нагрузочное тестирование по этим данным. Т.е. при таком подходе на каждом ядре сидит по процессу NodeJS и другие процессы не мешают их работе, не заставляют переключать на себя внимание ядра.

А теперь давайте проведём тест на реальной работе REST API. Это будет GET-запрос за сущностью по её id. Чтобы сформировать JSON этой сущности, нода совершает не один, а несколько сложных запросов в базу данных. Кэширование в глобальных переменных или в Redis не используется.

Для тестирования я использовал пакет bombardier, написанный на Golang.

go install github.com/codesenberg/bombardier@latest

Сначала провёл тест на Windows 10.
Запускаю:

bombardier http://127.0.0.1:7100/api/some/1101

Результат без cluster:

Bombarding http://127.0.0.1:7100/api/some/1101 for 10s using 125 connection(s)
[=================================================================================================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      2754.89    1413.90    5813.88
  Latency       45.31ms     1.95ms    72.43ms
  HTTP codes:
    1xx - 0, 2xx - 27625, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     9.99MB/s

Результат с cluster (все 24 потока):

Bombarding http://127.0.0.1:7100/api/some/1101 for 10s using 125 connection(s)
[=================================================================================================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      8424.89     801.49   15177.67
  Latency       14.84ms     1.69ms    72.64ms
  HTTP codes:
    1xx - 0, 2xx - 84224, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:    30.54MB/s

Разница по производительности почти в 3 раза.