Node.js Cluster vs PM2 – analisi approfondita delle prestazioni e della gestione dei processi

Le moderne applicazioni Node.js devono gestire centinaia di migliaia di richieste con latenza minima. I due meccanismi di scaling più popolari sono il cluster integrato e il process manager PM2. In questo articolo scomponiamo il loro funzionamento, misuriamo l’impatto sulle prestazioni e descriviamo quando scegliere una soluzione rispetto all’altra.

Come funziona Node.js Cluster?

Il modulo cluster fa parte della libreria standard di Node.js. Crea un gruppo di processi worker che condividono la stessa porta TCP grazie al meccanismo master‑worker. Il master accetta le connessioni e le distribuisce in round‑robin o secondo l’algoritmo os.sched, a seconda della piattaforma.

Esempio di implementazione:

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} startuje`);
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} zmarł, restartuję`);
    cluster.fork();
  });
} else {
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('Hello from worker ' + process.pid);
  }).listen(3000);
}

Caratteristiche chiave:

• Nessuna dipendenza esterna – funziona dalla versione Node 0.8.
• Riavvio automatico del singolo processo in caso di errore.
• La condivisione della memoria non è possibile – ogni worker ha il proprio heap.

Cosa offre PM2?

PM2 è un process manager scritto in Node.js, disponibile come pacchetto npm. Oltre all’avvio semplice di più istanze, PM2 fornisce:

• Load balancing tramite il modulo integrato cluster_mode (basato sulla stessa API di cluster).
• Zero‑downtime reload (comando pm2 reload).
• Monitoraggio in tempo reale (PM2‑Monit, Keymetrics).
• Watchdog integrato, logrotate e supporto per systemd.

Configurazione di base nel file ecosystem.config.js:

module.exports = {
  apps: [{
    name: 'api',
    script: './src/server.js',
    instances: 'max', // utilizza tutti i core
    exec_mode: 'cluster',
    watch: false,
    env: { NODE_ENV: 'production' }
  }]
};

Dopo aver eseguito pm2 start ecosystem.config.js il manager si occupa di riavvio, scaling e reporting.

Prestazioni Cluster vs PM2 in produzione

In termini di throughput grezzo le differenze sono minime, poiché PM2 in modalità cluster utilizza esattamente lo stesso meccanismo di Node.js. I principali fattori che influenzano i risultati sono:

• Overhead di comunicazione con il master – PM2 aggiunge uno strato IPC per il monitoraggio, che nel peggiore dei casi aumenta l’uso CPU di ~2‑3% con QPS elevati.
• Strategia di riavvio – PM2 può eseguire un graceful reload senza perdita di connessioni, importante per la disponibilità continua.
• Gestione della memoria – PM2 permette di limitare automaticamente la memoria (max_memory_restart), riducendo il rischio di leak nei processi a lungo termine.

Nei test pratici (es. 100 000 richieste GET /api in 30 s) la differenza nel tempo medio di risposta è stata di 1‑2 ms a favore del puro cluster, ma PM2 ha garantito risultati più stabili in caso di crash casuali dei worker.

Quando usare Cluster e quando PM2?

Node.js Cluster è una buona scelta quando:

• Si necessita di un set di dipendenze minimo e si vuole controllare ogni dettaglio del codice master.
• L’applicazione è semplice e i processi non richiedono monitoraggio avanzato.
• L’ambiente di esecuzione non permette l’installazione di pacchetti aggiuntivi (es. container molto leggeri).

PM2 è indicato quando:

• Si richiede un deploy zero‑downtime e riavvio automatico al superamento del limite di memoria.
• Si vuole monitorare centralmente l’utilizzo delle risorse e avere accesso a una dashboard.
• Il progetto è distribuito e necessita di integrazione con un sistema init (systemd, upstart).

Checklist pratica di implementazione

• Verifica il numero di CPU disponibili (os.cpus().length) e imposta il numero di worker pari a questo valore o 'max' in PM2.
• Definisci un limite di memoria (max_memory_restart in PM2 o watchdog personalizzato in Cluster) – tipicamente 300 MiB per i processi API.
• Configura il logging – PM2 gestisce la rotazione, in Cluster devi reindirizzare manualmente stdout/stderr.
• Testa lo scenario di fallimento: termina un worker e verifica che master/PM2 lo ricrei automaticamente.
• Deploy zero‑downtime: in PM2 usa pm2 reload, nel puro Cluster implementa manualmente cluster.disconnect() e cluster.fork().

Tipiche trappole e compromessi

1. Utilizzare un processo per CPU – in alcuni casi è preferibile avere due worker per core, quando l'applicazione è I/O‑bound e non sfrutta al massimo la CPU. Tuttavia ciò aumenta l'overhead di memoria.

2. Assenza di limite di memoria – sia Cluster che PM2 per impostazione predefinita non riavviano il processo in caso di perdita di memoria. In PM2 è possibile impostare max_memory_restart, mentre in Cluster occorre monitorare process.memoryUsage() e forcare manualmente.

3. Log in modalità cluster – senza una raccolta centralizzata dei log (ad es. Winston + trasporto verso Elastic) è difficile analizzare i problemi in ambiente di produzione.

«La scelta tra Cluster e PM2 non è una questione di “meglio vs peggio”, ma di adattare lo strumento ai requisiti operativi e di team.»

Riepilogo e prossimi passi

Node.js Cluster e PM2 offrono una base di scalabilità simile, ma differiscono per le funzionalità operative. Se hai bisogno di controllo totale e di un overhead minimo, scegli il puro cluster. Quando invece desideri automazione, monitoraggio e deployment senza problemi, PM2 è la scelta naturale. In entrambi i casi è fondamentale gestire consapevolmente il numero di worker, i limiti di memoria e la strategia di riavvio.

Hai domande sull'implementazione della scalabilità nella tua infrastruttura? Contatta Coderia.it – ti aiuteremo a selezionare la soluzione ottimale e a realizzarne l'implementazione in sicurezza.