Ein einzelner Node-Prozess nutzt nur einen CPU-Kern (sein JS läuft auf einem Thread). Um alle Kerne einer Maschine zu nutzen, führen Sie mehrere Node-Prozesse aus — über das cluster-Modul, einen Process Manager wie PM2 oder Container-Orchestrierung — und verteilen Sie eingehende Anfragen auf sie.
A server with 8 CPU cores running ONE Node process → uses ~1 core, wastes 7.
Need multiple processes to utilize all cores and handle more concurrent load.
import cluster from "cluster";
import { cpus } from "os";
import http from "http";
if (cluster.isPrimary) {
const numCPUs = cpus().length;
for (let i = 0; i < numCPUs; i++) {
cluster.fork(); // spawn one worker process per CPU core
}
cluster.on("exit", (worker) => {
console.log(`worker ${worker.process.pid} died — restarting`);
cluster.fork(); // restart a crashed worker (resilience)
});
} else {
// each worker runs the actual server; the OS load-balances connections across them
http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}
Der primäre Prozess forkt einen Worker pro Kern; alle Worker teilen sich denselben Port, und eingehende Verbindungen werden unter ihnen verteilt — was den Durchsatz vervielfacht. Abgestürzte Worker können automatisch neu gestartet werden, um Ausfallsicherheit zu gewährleisten.
pm2 start app.js -i max # run one instance per CPU core, with auto-restart & monitoring
Produktions-Apps verwenden normalerweise PM2 (oder ähnliches), anstatt Cluster-Code von Hand zu schreiben — es kümmert sich um Forking, Load Balancing, Reloads ohne Ausfallzeit, Monitoring und Neustarts.
Run ONE Node process per container, and run MANY containers (Kubernetes, ECS),
with a load balancer in front. This is the modern cloud approach — simpler
per-process model, scaling handled by the orchestrator across machines.
Multiple processes don't share memory. So:
⚠️ Don't store sessions/state in process memory → use Redis/a shared store
⚠️ In-memory caches aren't shared across workers → use Redis for shared cache
⚠️ WebSocket connections live on one worker → use a Redis adapter to coordinate
Damit die Multi-Prozess-Skalierung funktioniert, muss Ihre App zustandslos sein — jeder gemeinsame Zustand (Sessions, Cache, Echtzeit-Koordination) muss in einem externen Speicher wie Redis leben, nicht im Prozessspeicher.
Die Nutzung aller CPU-Kerne ist wesentlich, um die volle Leistung eines Node-Servers zu erreichen — ein einzelner Prozess lässt die meisten Kerne einer Multi-Core-Maschine untätig.
Die Optionen zu kennen (cluster-Modul, PM2-Cluster-Modus oder ein Prozess pro Container mit Orchestrierung) und, entscheidend, die Anforderung der Zustandslosigkeit (extern von Redis gestützte Sessions/Cache/Echtzeit, da Prozesse keinen Speicher teilen) ist grundlegend für die Skalierung von Node in der Produktion.
Diese horizontale Skalierung in Kombination mit Zustandslosigkeit ist die Art, wie Node-Apps hohe Datenmengen zuverlässig bewältigen.