Node.js-Cluster vs PM2 – tiefgehende Analyse von Leistung und Prozessverwaltung

Moderne Node.js‑Anwendungen müssen Hunderttausende von Anfragen mit minimaler Latenz verarbeiten. Die beiden beliebtesten Skalierungsmechanismen sind das eingebaute cluster‑Modul und der Prozess‑Manager PM2. In diesem Artikel zerlegen wir ihr Funktionsprinzip, messen die Performance‑Auswirkungen und beschreiben, wann welche Lösung zu wählen ist.

Wie funktioniert Node.js Cluster?

Das Modul cluster ist Teil der Standard‑Bibliothek von Node.js. Es erstellt eine Gruppe von Worker‑Prozessen, die denselben TCP‑Port über den Master‑Worker‑Mechanismus teilen. Der Master nimmt Verbindungen entgegen und verteilt sie entweder round‑robin oder nach dem os.sched‑Algorithmus, je nach Plattform.

Beispiel‑Implementierung:

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

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

Wesentliche Merkmale:

• Keine externen Abhängigkeiten – funktioniert seit Node 0.8.
• Automatischer Neustart eines einzelnen Prozesses nach einem Ausfall.
• Speicher‑Sharing ist nicht möglich – jeder Worker hat seinen eigenen Heap.

Was bietet PM2?

PM2 ist ein in Node.js geschriebener Prozess‑Manager, verfügbar als npm‑Paket. Neben dem einfachen Starten mehrerer Instanzen bietet PM2:

• Load‑Balancing mittels des integrierten cluster_mode (basiert auf derselben API wie cluster).
• Zero‑Downtime‑Reload (Befehl pm2 reload).
• Echtzeit‑Monitoring (PM2‑Monit, Keymetrics).
• Eingebauten Watchdog, Logrotate und Unterstützung für systemd.

Grundkonfiguration in der Datei ecosystem.config.js:

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

Nach dem Aufruf von pm2 start ecosystem.config.js kümmert sich der Manager um Neustarts, Skalierung und Reporting.

Performance: Cluster vs. PM2 in der Produktion

Bezüglich reiner Durchsatz‑Zahlen sind die Unterschiede minimal, da PM2 im cluster-Modus exakt denselben Node.js‑Mechanismus nutzt. Die wichtigsten Einflussfaktoren sind:

• Overhead der Kommunikation mit dem Master – PM2 fügt eine IPC‑Schicht für das Monitoring hinzu, was im schlimmsten Fall die CPU‑Auslastung um ~2‑3 % bei hohem QPS erhöht.
• Restart‑Strategie – PM2 kann ein graceful reload ohne Verbindungsverlust durchführen, was für kontinuierliche Verfügbarkeit wichtig ist.
• Speicher‑Management – PM2 ermöglicht automatisches Memory‑Limiting (max_memory_restart), wodurch das Risiko von Speicher‑Leaks in langlebigen Prozessen reduziert wird.

In praktischen Tests (z. B. 100 000 GET‑/api‑Anfragen in 30 s) lag der Unterschied in der durchschnittlichen Antwortzeit bei 1‑2 ms zugunsten des reinen cluster, jedoch erzielte PM2 stabilere Ergebnisse bei zufälligen Worker‑Ausfällen.

Wann Cluster und wann PM2 einsetzen?

Node.js Cluster ist die richtige Wahl, wenn:

• Ein minimaler Stack an Abhängigkeiten benötigt wird und jede Detail‑Implementierung des Masters kontrolliert werden soll.
• Die Anwendung einfach ist und die Prozesse kein erweitertes Monitoring benötigen.
• Die Laufzeitumgebung keine zusätzlichen Pakete zulässt (z. B. sehr kleine Container).

PM2 ist sinnvoll, wenn:

• Zero‑Downtime‑Deploys und automatischer Neustart bei Erreichen von Speicher‑Limits gefordert werden.
• Ressourcennutzung zentral überwacht und ein Dashboard bereitgestellt werden soll.
• Das Projekt verteilt ist und eine Integration in ein Init‑System (systemd, upstart) nötig ist.

Praktische Checkliste für die Implementierung

• Ermitteln Sie die Anzahl verfügbarer CPUs (os.cpus().length) und setzen Sie die Worker‑Anzahl auf diesen Wert oder auf 'max' in PM2.
• Legen Sie ein Speicher‑Limit fest (max_memory_restart in PM2 oder einen eigenen Watchdog im Cluster) – typischerweise 300 MiB für API‑Prozesse.
• Konfigurieren Sie das Logging – PM2 übernimmt Rotation, im Cluster müssen Sie stdout/stderr selbst umleiten.
• Testen Sie das Fehlerszenario: Töten Sie einen Worker und prüfen Sie, ob Master/PM2 ihn automatisch neu startet.
• Zero‑Downtime‑Deployment: Verwenden Sie in PM2 pm2 reload, im reinen Cluster implementieren Sie manuell cluster.disconnect() und cluster.fork().

Typische Fallen und Kompromisse

1. Ein Prozess pro CPU verwenden – in manchen Fällen sind zwei Worker pro Kern besser, wenn die Anwendung I/O‑bound ist und die CPU nicht voll ausnutzt. Das erhöht jedoch den Speicher‑Overhead.

2. Kein Speicherlimit – sowohl Cluster als auch PM2 starten einen Prozess bei Speicherlecks standardmäßig nicht neu. In PM2 kann max_memory_restart gesetzt werden, im Cluster muss process.memoryUsage() überwacht und das Forken manuell durchgeführt werden.

3. Logs im Cluster‑Modus – ohne zentrales Log‑Collecting (z. B. Winston + Transport zu Elastic) ist die Analyse von Problemen in der Produktionsumgebung schwierig.

„Die Wahl zwischen Cluster und PM2 ist keine Frage von „besser vs. schlechter“, sondern die Anpassung des Werkzeugs an operative und teambezogene Anforderungen.“

Fazit und nächste Schritte

Node.js Cluster und PM2 bieten ein ähnliches Fundament für Skalierung, unterscheiden sich jedoch hinsichtlich operativer Funktionen. Wenn du volle Kontrolle und minimale Overhead benötigst, wähle reines cluster. Wenn dir Automatisierung, Monitoring und reibungslose Deployments wichtig sind, ist PM2 die natürliche Wahl. In beiden Fällen ist ein bewusstes Management der Worker‑Anzahl, Speicherlimits und Restart‑Strategie entscheidend.

Hast du Fragen zur Implementierung von Skalierung in deiner Infrastruktur? Kontaktiere Coderia.it – wir helfen dir, die optimale Lösung zu finden und sicher zu implementieren.