Performance di Node.js: Event Loop, Clustering e Ottimizzazione nel 2026

L'ottimizzazione delle prestazioni di Node.js parte dalla comprensione dell'event loop — il meccanismo single-threaded che gestisce tutte le operazioni di I/O asincrone. Nei sistemi in produzione con Node.js 22 LTS o Node.js 24, una gestione inadeguata dell'event loop resta la causa principale di picchi di latenza, connessioni interrotte e guasti a cascata sotto carico.

Questa guida affronta i tre pilastri della performance di Node.js: i meccanismi interni dell'event loop, la scalabilità multi-core con cluster e worker threads, e i pattern di ottimizzazione collaudati nei sistemi ad alto throughput.

Come l'Event Loop di Node.js elabora le richieste

L'event loop non è una semplice coda. Opera attraverso sei fasi distinte, ciascuna responsabile di una specifica categoria di callback. La comprensione di questa architettura a fasi spiega perché determinati pattern causano latenza e altri no.

// Demonstrating phase execution order

const fs = require('fs');

// Phase 1: Timers — executes setTimeout/setInterval callbacks
setTimeout(() => console.log('1. Timer phase'), 0);

// Phase 4: Poll — executes I/O callbacks
fs.readFile(__filename, () => {
  console.log('2. Poll phase (I/O callback)');

  // Phase 5: Check — executes setImmediate callbacks
  setImmediate(() => console.log('3. Check phase (setImmediate)'));

  // Phase 1 again: Timer scheduled from within I/O
  setTimeout(() => console.log('4. Timer phase (from I/O)'), 0);
});

// Microtask — runs between every phase transition
Promise.resolve().then(() => console.log('Microtask: Promise'));
process.nextTick(() => console.log('Microtask: nextTick'));

L'ordine di output rivela la priorità delle fasi: nextTick viene eseguito prima delle promise, le promise prima dei timer, e setImmediate viene sempre attivato dopo i callback di I/O nella fase check. Questa sequenza è fondamentale nella progettazione di request handler sensibili alla latenza.

Rilevare il blocco dell'Event Loop in produzione

Un event loop bloccato si manifesta come latenza p99 in crescita, molto prima che i tempi di risposta medi mostrino degradazione. L'API integrata performance.eventLoopUtilization(), stabile da Node.js 16, fornisce il meccanismo di rilevamento più affidabile.

// Production-grade event loop monitoring

const { performance, monitorEventLoopDelay } = require('perf_hooks');

// High-resolution event loop delay histogram
const histogram = monitorEventLoopDelay({ resolution: 20 });
histogram.enable();

// Track utilization over intervals
let previous = performance.eventLoopUtilization();

setInterval(() => {
  const current = performance.eventLoopUtilization(previous);
  previous = performance.eventLoopUtilization();

  const metrics = {
    // Ratio of time the loop spent active vs idle (0-1)
    utilization: current.utilization.toFixed(3),
    // Delay percentiles in milliseconds
    p50: (histogram.percentile(50) / 1e6).toFixed(2),
    p99: (histogram.percentile(99) / 1e6).toFixed(2),
    max: (histogram.max / 1e6).toFixed(2),
  };

  // Alert when utilization exceeds 70% or p99 > 100ms
  if (current.utilization > 0.7 || histogram.percentile(99) > 100e6) {
    console.warn('EVENT_LOOP_SATURATED', metrics);
  }

  histogram.reset();
}, 5000);

Un utilizzo superiore a 0,7 (70%) indica che l'event loop trascorre più tempo nell'esecuzione di callback che in attesa di I/O. Oltre questa soglia, le connessioni in ingresso iniziano ad accodarsi e le latenze di coda crescono esponenzialmente.

Blocchi comuni dell'Event Loop e relative soluzioni

Tre pattern sono responsabili della maggior parte degli incidenti di blocco dell'event loop nelle applicazioni Node.js in produzione: operazioni JSON sincrone su payload di grandi dimensioni, calcoli CPU-intensive nei request handler e espressioni regolari non delimitate.

// Anti-patterns and their solutions

// PROBLEM: JSON.parse blocks on large payloads
const largePayload = Buffer.alloc(50 * 1024 * 1024); // 50MB
// JSON.parse(largePayload.toString()); // Blocks event loop 200-500ms

// SOLUTION: Stream-parse large JSON with a streaming parser
const { Transform } = require('stream');
const JSONStream = require('jsonstream2');

function processLargeJSON(readableStream) {
  return new Promise((resolve, reject) => {
    const results = [];
    readableStream
      .pipe(JSONStream.parse('items.*'))  // Stream-parse array items
      .on('data', (item) => results.push(item))
      .on('end', () => resolve(results))
      .on('error', reject);
  });
}

// PROBLEM: Synchronous crypto in request path
// const hash = crypto.pbkdf2Sync(password, salt, 100000, 64, 'sha512');

// SOLUTION: Use async variant
const crypto = require('crypto');
async function hashPassword(password, salt) {
  return new Promise((resolve, reject) => {
    crypto.pbkdf2(password, salt, 100000, 64, 'sha512', (err, key) => {
      if (err) reject(err);
      else resolve(key.toString('hex'));
    });
  });
}

La variante asincrona di pbkdf2 delega il lavoro CPU al thread pool di libuv, mantenendo l'event loop libero per elaborare altre richieste. Questa singola modifica ha ridotto la latenza p99 da 900 ms a 120 ms in un incidente di produzione documentato nel settore fintech.

Scalare Node.js su più core CPU con il modulo Cluster

Un singolo processo Node.js utilizza un solo core CPU. Su un server di produzione a 16 core, il 93% della capacità di calcolo disponibile rimane inutilizzata. Il modulo integrato cluster genera processi worker che condividono una singola porta, distribuendo le connessioni in ingresso su tutti i core.

// Production clustering with graceful shutdown

const cluster = require('cluster');
const os = require('os');
const process = require('process');

const WORKER_COUNT = parseInt(process.env.WORKERS) || os.cpus().length;

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} starting ${WORKER_COUNT} workers`);

  // Fork workers for each CPU core
  for (let i = 0; i < WORKER_COUNT; i++) {
    cluster.fork();
  }

  // Restart crashed workers automatically
  cluster.on('exit', (worker, code, signal) => {
    if (!worker.exitedAfterDisconnect) {
      console.error(`Worker ${worker.process.pid} died (${signal || code}). Restarting...`);
      cluster.fork();
    }
  });

  // Graceful shutdown on SIGTERM
  process.on('SIGTERM', () => {
    console.log('Primary received SIGTERM. Shutting down workers...');
    for (const id in cluster.workers) {
      cluster.workers[id].disconnect();
    }
  });
} else {
  // Worker process — start the actual HTTP server
  const http = require('http');
  const server = http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Handled by worker ${process.pid}\n`);
  });

  server.listen(3000, () => {
    console.log(`Worker ${process.pid} listening on port 3000`);
  });

  // Graceful shutdown for individual worker
  process.on('SIGTERM', () => {
    server.close(() => process.exit(0));
  });
}

Ogni worker opera nel proprio V8 isolate con memoria separata. I worker non condividono lo stato — dati di sessione, cache e stato applicativo devono risiedere in uno store esterno come Redis o PostgreSQL. Questo isolamento garantisce anche tolleranza ai guasti: un crash in un worker non influisce sugli altri.

Worker Threads per attività CPU-intensive

Il modulo cluster duplica l'intero processo. I worker threads, introdotti in Node.js 10 e stabili da Node.js 12, eseguono JavaScript in thread paralleli all'interno dello stesso processo. Condividono la memoria tramite SharedArrayBuffer e trasferiscono dati mediante clonazione strutturata.

La distinzione è importante: i cluster servono per scalare server HTTP I/O-bound su più core, i worker threads per spostare operazioni CPU-bound lontano dall'event loop.

// Reusable worker thread pool for CPU tasks

const { Worker } = require('worker_threads');
const os = require('os');

class WorkerPool {
  constructor(workerScript, poolSize = os.cpus().length) {
    this.workers = [];
    this.queue = [];

    for (let i = 0; i < poolSize; i++) {
      this.workers.push({ busy: false, worker: new Worker(workerScript) });
    }
  }

  execute(taskData) {
    return new Promise((resolve, reject) => {
      const available = this.workers.find(w => !w.busy);

      if (available) {
        this._runTask(available, taskData, resolve, reject);
      } else {
        // Queue task until a worker is free
        this.queue.push({ taskData, resolve, reject });
      }
    });
  }

  _runTask(entry, taskData, resolve, reject) {
    entry.busy = true;
    entry.worker.postMessage(taskData);

    const onMessage = (result) => {
      entry.busy = false;
      cleanup();
      resolve(result);
      this._processQueue();
    };

    const onError = (err) => {
      entry.busy = false;
      cleanup();
      reject(err);
      this._processQueue();
    };

    const cleanup = () => {
      entry.worker.removeListener('message', onMessage);
      entry.worker.removeListener('error', onError);
    };

    entry.worker.on('message', onMessage);
    entry.worker.on('error', onError);
  }

  _processQueue() {
    if (this.queue.length === 0) return;
    const available = this.workers.find(w => !w.busy);
    if (available) {
      const { taskData, resolve, reject } = this.queue.shift();
      this._runTask(available, taskData, resolve, reject);
    }
  }
}

module.exports = { WorkerPool };

// Worker thread for CPU-intensive image processing

const { parentPort } = require('worker_threads');
const sharp = require('sharp');

parentPort.on('message', async ({ inputPath, width, height }) => {
  const result = await sharp(inputPath)
    .resize(width, height)
    .webp({ quality: 80 })
    .toBuffer();

  parentPort.postMessage({ size: result.length, buffer: result });
});

Un worker pool pre-avvia i thread all'avvio dell'applicazione e li riutilizza tra le richieste. Questo elimina l'overhead di 30-50 ms necessario per creare un nuovo worker thread per ogni richiesta. Per l'elaborazione di immagini, la generazione di PDF o la trasformazione di dati, questo pattern mantiene la latenza dell'event loop principale sotto i 5 ms anche sotto carico CPU sostenuto.

Ottimizzazione della memoria e tuning del Garbage Collector

V8 suddivide lo heap in young generation (oggetti a vita breve) e old generation (oggetti a vita lunga). La maggior parte dei problemi di performance deriva da allocazioni eccessive nella young generation, che provocano frequenti pause di minor GC, oppure da memory leak che fanno crescere la old generation fino a quando le pause di major GC causano picchi di latenza visibili.

// Patterns that reduce GC pressure

// ANTI-PATTERN: Creating objects in hot loops
function processItemsBad(items) {
  return items.map(item => ({
    id: item.id,
    name: item.name.trim(),
    score: calculateScore(item),  // New object per iteration
    metadata: { processed: true, timestamp: Date.now() }
  }));
}

// OPTIMIZED: Reuse buffers and minimize allocations
const reusableBuffer = Buffer.alloc(4096);

function processItemsGood(items, output) {
  // Reuse the output array instead of creating new one
  output.length = 0;
  for (let i = 0; i < items.length; i++) {
    // Mutate in place when safe to do so
    output.push(items[i].id);
  }
  return output;
}

// Monitor heap usage for leak detection
function checkMemory() {
  const used = process.memoryUsage();
  return {
    heapUsedMB: Math.round(used.heapUsed / 1024 / 1024),
    heapTotalMB: Math.round(used.heapTotal / 1024 / 1024),
    externalMB: Math.round(used.external / 1024 / 1024),
    rsssMB: Math.round(used.rss / 1024 / 1024),
  };
}

// V8 flags for production GC tuning
// node --max-old-space-size=4096 --max-semi-space-size=128 app.js
// --max-old-space-size: Set old generation limit (default ~1.7GB)
// --max-semi-space-size: Increase young generation (default 16MB)

L'aumento di --max-semi-space-size dal valore predefinito di 16 MB a 64-128 MB riduce la frequenza del minor GC per le applicazioni con alti tassi di allocazione. Si scambia memoria con una minore frequenza di pause GC — un compromesso vantaggioso su server con 8 GB+ di RAM.

Monitoraggio in produzione con OpenTelemetry in Node.js 24

OpenTelemetry si è affermato nel 2026 come framework di strumentazione standard per Node.js. Il runtime Node.js 24 include un supporto migliorato al profiling con dati di inline cache nei profili CPU, rendendo l'analisi delle prestazioni significativamente più accurata.

// OpenTelemetry setup for Node.js performance monitoring

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { PrometheusExporter } = require('@opentelemetry/exporter-prometheus');
const { PeriodicExportingMetricReader } = require('@opentelemetry/sdk-metrics');

const sdk = new NodeSDK({
  metricReader: new PrometheusExporter({ port: 9464 }),
  instrumentations: [
    getNodeAutoInstrumentations({
      // Instrument HTTP, Express, DNS, fs, and more
      '@opentelemetry/instrumentation-fs': { enabled: false }, // Too noisy
    }),
  ],
});

sdk.start();

// Custom event loop lag metric
const { metrics } = require('@opentelemetry/api');
const meter = metrics.getMeter('app');

const eventLoopLag = meter.createHistogram('nodejs.event_loop.lag', {
  description: 'Event loop lag in milliseconds',
  unit: 'ms',
});

// Report event loop lag every second
const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 10 });
h.enable();

setInterval(() => {
  eventLoopLag.record(h.percentile(99) / 1e6);
  h.reset();
}, 1000);

Questa configurazione esporta event loop lag, durata delle richieste HTTP e tempo di risoluzione DNS come metriche Prometheus. Impostare alert sull'event loop lag p99 > 100 ms permette di individuare il degrado prima che gli utenti se ne accorgano.

Scegliere tra Cluster, Worker Threads e scalabilità esterna

La strategia di scaling corretta dipende dal profilo del workload. Una matrice decisionale basata su pattern di produzione reali:

| Scenario | Strategia | Motivazione | |----------|-----------|-------------| | API HTTP, prevalentemente I/O | Modulo cluster (1 worker per core) | Massimizza il throughput delle connessioni | | Elaborazione immagini/video | Pool di worker thread (4-8 thread) | Mantiene l'event loop reattivo | | Pipeline dati CPU-heavy | Worker threads + SharedArrayBuffer | Condivisione dati zero-copy | | Microservizi su larga scala | Pod Kubernetes (container single-process) | L'orchestratore gestisce lo scaling | | Mix I/O + CPU | Cluster + worker pool per worker | Ogni worker delega il CPU ai thread |

Per i deployment containerizzati su Kubernetes, l'esecuzione di un singolo processo Node.js per container (senza clustering) è spesso più semplice e prevedibile. L'orchestratore si occupa della scalabilità orizzontale, degli health check e dei rolling restart. Il clustering aggiunge valore su bare metal o VM dove una singola macchina deve massimizzare l'utilizzo dei core.

Checklist pratica di ottimizzazione per la produzione

L'applicazione di queste tecniche in ordine di impatto — prima la salute dell'event loop, poi la scalabilità, infine il fine-tuning — produce miglioramenti misurabili con rischio minimo.

• Monitorare continuamente l'utilizzo dell'event loop con performance.eventLoopUtilization() — alert alla soglia del 70%
• Profilare prima di ottimizzare — utilizzare node --prof o trace OpenTelemetry per identificare i colli di bottiglia reali, non quelli presunti
• Spostare le operazioni sincrone dal thread principale — crypto.pbkdf2, JSON.parse su payload di grandi dimensioni e l'elaborazione immagini appartengono ai worker threads
• Impostare UV_THREADPOOL_SIZE in base al workload — il valore predefinito di 4 è troppo basso per applicazioni con I/O DNS o file intensivo, troppo alto nei setup clusterizzati
• Utilizzare lo streaming per dati di grandi dimensioni — JSONStream, csv-parser e stream.pipeline() di Node.js prevengono picchi di memoria con payload voluminosi
• Pre-riscaldare i worker pool all'avvio — evitare la latenza di cold start alle prime richieste verso endpoint CPU-intensive
• Configurare i flag V8 per lo heap in base al deployment — --max-old-space-size e --max-semi-space-size in base alla memoria disponibile e ai pattern di allocazione
• Implementare il graceful shutdown — drainare le connessioni su SIGTERM, chiudere i pool di database e consentire il completamento delle richieste in corso prima dell'uscita del processo

Conclusione

La performance di Node.js nel 2026 si fonda su tre principi fondamentali:

• L'event loop è il single point of failure per il throughput — il monitoraggio dell'utilizzo e l'eliminazione dei blocchi ha il massimo impatto sulla latenza
• Il clustering scala i workload I/O-bound su più core; i worker threads delegano le attività CPU-bound dall'event loop — l'uso combinato di entrambi garantisce il massimo utilizzo dell'hardware
• Il monitoraggio in produzione con OpenTelemetry e gli strumenti di profiling V8 trasformano le supposizioni in dati — impostare alert su event loop lag p99 e tasso di crescita dello heap
• Node.js 24 offre miglioramenti prestazionali con V8 12.4, HTTP/3 stabile via Undici 7 e un modello di permessi maturo — l'aggiornamento da Node.js 20 o versioni precedenti garantisce miglioramenti misurabili del throughput
• Iniziare con performance.eventLoopUtilization() su qualsiasi applicazione Node.js esistente — i risultati spesso rivelano la singola ottimizzazione a più alto impatto disponibile