Вынос CPU-работы: worker threads и пул libuv

Команда профилирует медленный эндпоинт ресайза картинок, находит CPU-тяжёлую работу и «чинит» её, подняв UV_THREADPOOL_SIZE с 4 до 32. Ничего не улучшается. Ресайз — это JavaScript, бегущий на потоке цикла, а пул libuv, который они только что увеличили, вообще не выполняет JavaScript — он выполняет нативный I/O. Они тюнили не тот пул. Node прячет два ресурса исполнения за единственным event loop, и знание, какая работа куда идёт, — это разница между фиксом и потерянной неделей.

Два пула, две задачи

За единственным циклом — два разных источника параллелизма, и они служат противоположным видам работы:

• Пул потоков libuv — небольшой пул (по умолчанию 4 потока, настраивается до 1024 через UV_THREADPOOL_SIZE), выполняющий нативные операции без асинхронного примитива ОС: вызовы файловой системы, DNS-резолвинг (dns.lookup) и асинхронные функции crypto/zlib. Он не выполняет твой JavaScript. Когда ты вызываешь fs.promises.readFile, libuv делает блокирующее чтение на потоке пула и постит результат обратно в цикл. Поэтому асинхронный bcrypt не замораживает цикл — хеширование бежит на потоке libuv.
• Worker threads (worker_threads) — реальные, отдельные изоляты V8 со своим event loop, дающие истинный многоядерный параллелизм для твоего CPU-bound JavaScript. Сюда относятся ресайз картинок, парсинг больших полезных нагрузок, сжатие и любые тяжёлые вычисления.

Баг с ресайзом теперь очевиден: ресайз — это JS, поэтому ему нужен worker thread, а не больший пул libuv. Увеличение libuv помогает, только когда упёрся в пропускную способность fs/dns/crypto — и даже тогда больше потоков пула, чем ядер CPU, в основном добавляет конкуренцию.

Цена воркера: перемещение данных

Worker threads не бесплатны, и счёт в основном за передачу данных. По умолчанию всё, что ты postMessage воркеру, глубоко копируется алгоритмом structured-clone — для большого буфера эта копия — реальная работа (копия многомегабайтного ArrayBuffer замерялась около 268 мс против примерно 29 мс при передаче). Два обходных пути важны:

• Transferables — передай ArrayBuffer в transferList, и владение перемещается воркеру без копии (отправитель больше не может им пользоваться). Почти нулевая цена передачи.
• SharedArrayBuffer — разделяемая память, которую видят оба потока сразу, с Atomics для безопасной координации. Без копии, без передачи владения; правильный инструмент, когда обеим сторонам нужны одни байты.

Поэтому старший расчёт для выноса такой: работа должна быть достаточно CPU-тяжёлой, чтобы затмить цену передачи сообщений. Вынос вычисления на 2 мс воркеру может оказаться медленнее, чем просто выполнить его, как только заплатишь за клон и круговой рейс.

Когда не выносить: нарезай вместо этого

Не каждое долгое вычисление требует потока. Если работу можно разбить на мелкие куски, ты можешь выполнить кусок, затем setImmediate (или await разрешённого промиса), чтобы уступить цикл, затем выполнить следующий кусок — давая I/O-колбэкам вклиниваться между кусками. Это держит всё на потоке цикла без цены передачи, меняя общую пропускную способность (работа теперь конкурирует с запросами) на отзывчивый цикл. Нарезка подходит работе, которая длинная, но прерываемая (итерация большого массива, постраничное вычисление). Worker threads подходят работе монолитной и тяжёлой (один ресайз, операция crypto) или той, что ты искренне хочешь гонять параллельно на другом ядре.

И иногда правильный ответ — ни то ни другое: если CPU — узкое место по всему сервису, горизонтальное масштабирование — больше процессов (cluster) или больше машин — это рычаг, потому что один процесс Node маппится на один цикл, а CPU-bound пропускная способность фундаментально проблема числа ядер.