Event loop Node.js: фазы, nextTick и задержка цикла

Ваш Node-сервис отлично обрабатывает 1000 запросов в секунду на стейджинге. В продакшене иногда выдаёт хвостовую задержку 500 мс. DevTools бесполезен — у Node нет кадров, нет INP. Нужен эквивалентный диагностический инструмент для headless-цикла: задержка event loop.

Цикл libuv Node: шесть фаз

Управляемый libuv цикл Node проходит шесть фаз за итерацию:

Между каждой фазой дренируются две очереди: очередь process.nextTick (специфичная для Node, срабатывает до микрозадач) и стандартная очередь микрозадач (Promise.then, queueMicrotask).

process.nextTick — колбэк с наивысшим приоритетом в Node

process.nextTick — колбэк с наивысшим приоритетом кроме синхронного кода. Срабатывает до микрозадач — до Promise.then. Неправильное использование вызывает тот же паттерн голодания, что и неуправляемые микрозадачи в браузере, но на один уровень приоритета выше:

function tick() {
  process.nextTick(tick); // голодание на уровне nextTick
}
tick(); // колбэки I/O, setImmediate, таймеры никогда не запустятся

Если нужно «запустить после этого синхронного блока», в Node предпочтительнее queueMicrotask или Promise.resolve().then — они имеют правильный приоритет относительно I/O.

setImmediate vs setTimeout(0) в Node

Несмотря на имена, setImmediate не запускается немедленно, а setTimeout(0) — не с нулевой задержкой.

• setImmediate запускается в фазе check (после I/O текущей итерации).
• setTimeout(0) запускается в фазе timers следующей итерации.

Внутри I/O-колбэка (чтение файла, чтение сокета) setImmediate всегда выигрывает — он срабатывает в фазе check текущей итерации до фазы timers следующей итерации. Вне I/O-колбэков порядок недетерминирован по спецификации. Код, полагающийся на порядок между этими двумя, хрупок; если нужен гарантированный порядок — используйте queueMicrotask (всегда раньше обоих) или явные зависимости.

Почему блокировка цикла Node важна

У Node нет концепции кадров или ввода — но он однопоточный, как браузер. JSON.parse на 500 мс в обработчике запроса блокирует каждый другой запрос на том же процессе на 500 мс. Нет защитного барьера рендеринга. Решения:

• Перенести работу, зависящую от CPU, в Worker thread (node:worker_threads).
• Делать обработчики запросов async-first.
• Использовать стриминговые парсеры (JSONStream, oboe.js) для больших тел.

Та же дисциплина «более короткие задачи», которая лечит INP браузера, лечит хвостовую задержку Node.

Измерение задержки event loop в Node

У браузера есть INP и LoAF. У Node есть задержка event loop — эквивалентный диагностический инструмент для headless-цикла. Идея: запланировать таймер на T мс и измерить, насколько поздно он фактически сработал; превышение над T — это время, когда цикл был заблокирован синхронной работой.

perf_hooks.monitorEventLoopDelay() даёт гистограмму этой задержки с перцентилями. Здоровый процесс держит задержку p99 в однозначных мс; p99 в сотнях мс означает, что какой-то обработчик регулярно монополизирует поток, и каждый запрос, попадающий в это окно, получает хвостовую задержку.

const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 10 });
h.enable();
// … позже:
console.log(`p99 задержка: ${h.percentile(99)}мс`);

Это то же измерение, что INP в браузере — «как долго одна задача держала единственный поток выполнения» — только выраженное как задержка, а не задержка взаимодействия.