Come profilare e ottimizzare le prestazioni di Node.js?

Question

Accepted Answer

L'ottimizzazione delle prestazioni di Node inizia con **la misurazione** per trovare il vero collo di bottiglia — non indovinare mai. Profilare l'utilizzo della CPU, l'event loop e la memoria, quindi applicare correzioni mirate. La regola d'oro: profila prima, ottimizza ciò che è veramente lento.

## Strumenti di profilazione

```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
```

Rivelano *dove* va il tempo — un flame graph mostra quali funzioni dominano la CPU, così ottimizzi la cosa giusta.

## Il problema #1 specifico di Node: event loop bloccato

```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);
}
```

Poiché Node è single-threaded per JS, qualsiasi operazione sincrona lunga blocca tutto. Monitora **event-loop lag** (ad es. `perf_hooks` `monitorEventLoopDelay`); il lag crescente significa che qualcosa sta bloccando il loop. Correggi scaricando il lavoro della CPU su **worker thread** o su una coda.

## Ottimizzazioni comuni (applica dopo che i punti di profilazione le indicano)

```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
```

## Spesso è il database, non 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.
```

## Benchmark per verificare

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

Misura prima e dopo ogni modifica in modo da confermare che l'ottimizzazione ha effettivamente aiutato.

## Perché è importante

Il lavoro di ottimizzazione delle prestazioni è efficace solo quando **guidato dalla misurazione** — ottimizzare la cosa sbagliata spreca sforzi e aggiunge complessità.

Sapere come profilare (clinic.js/flame graph/DevTools per la CPU, monitoraggio event-loop lag, analisi heap) ti consente di individuare i veri colli di bottiglia, che in Node sono spesso un event loop bloccato (correggi con worker thread) o query di database lente (N+1, indici mancanti — frequentemente il vero colpevole).

Combinato con caching, streaming, parallelismo e pooling — e verificato con test di carico — questa disciplina misura-quindi-correggi è ciò che trasforma un servizio lento in uno veloce e scalabile.