Как профилировать и оптимизировать производительность Node.js?

Question

Accepted Answer

Оптимизация производительности Node начинается с **измерения** для поиска реального узкого места — никогда не угадывайте. Вы профилируете использование CPU, event loop и память, а затем применяете целенаправленные исправления. Золотое правило: профилируй сначала, оптимизируй то, что действительно медленно.

## Инструменты профилирования

```bash
# CPU profiling — find which functions consume CPU time
node --prof app.js                    # generates a V8 profile log
node --prof-process isolate-*.log     # human-readable summary

# all-in-one diagnostics (flame graphs, event-loop, memory)
npx clinic doctor -- node app.js      # diagnoses the bottleneck type
npx clinic flame -- node app.js       # CPU flame graph (hot functions)

# the Chrome DevTools profiler
node --inspect app.js                 # then connect DevTools for CPU/memory profiles
```

Эти инструменты показывают, *куда* уходит время — графік пламени показывает, какие функции доминируют в CPU, так что вы оптимизируете нужную вещь.

## Проблема #1, специфичная для Node: заблокированный event loop

```js
// ❌ synchronous CPU-heavy work blocks ALL request handling
function handler(req, res) {
  const result = heavyComputation(); // freezes the event loop → every request stalls
  res.json(result);
}
```

Поскольку Node является однопоточным для JS, любая длительная синхронная операция блокирует всё. Контролируйте **event-loop lag** (например, `perf_hooks` `monitorEventLoopDelay`); растущее отставание означает, что что-то блокирует цикл. Исправьте, разгрузив работу CPU на **worker threads** или очередь.

## Почему это важно

```text
✓ Fix N+1 database queries — the most common real bottleneck (batch/join instead)
✓ Add caching (in-memory/Redis) for repeated expensive operations
✓ Add database indexes for slow queries
✓ Use streams for large data instead of buffering it all in memory
✓ Parallelize independent async ops with Promise.all (avoid await waterfalls)
✓ Offload CPU-bound work to worker threads (keep the event loop free)
✓ Use connection pooling for DB/HTTP
✓ Enable gzip/brotli compression for responses
```

## Часто это база данных, а не Node

```text
Many "Node is slow" problems are actually slow DB queries (N+1, missing indexes)
or external API latency — profiling reveals this so you fix the real cause.
```

## Бенчмарк для проверки

```bash
npx autocannon http://localhost:3000   # measure requests/sec, latency before & after
```

Измеряйте до и после каждого изменения, чтобы подтвердить, что оптимизация действительно помогла.

## Почему это важно

Работы по производительности эффективны только при **управлении измерением** — оптимизация неправильной вещи тратит усилия и добавляет сложность.

Знание того, как профилировать (clinic.js/flame graphs/DevTools для CPU, контроль event-loop lag, анализ heap), позволяет вам найти реальные узкие места, которые в Node часто являются заблокированным event loop (исправьте с помощью worker threads) или медленными запросами к базе данных (N+1, отсутствующие индексы — часто истинный виновник).

Вместе с кешированием, потоковой передачей, параллелизмом и пулингом — и проверкой с помощью нагрузочных тестов — эта дисциплина измерения-а-затем-исправления — это то, что превращает медленный сервис в быстрый, масштабируемый.