Wie viele gleichzeitige Nutzer schafft ein VPS? Die Rechnung

Von Nutzern zu Anfragen

„Gleichzeitige Nutzer“ bezeichnet je nachdem, wer spricht, drei verschiedene Größen:

• Die registrierten Konten: sie kosten den Server nichts, solange sie sich nicht anmelden.
• Die gleichzeitig aktiven Nutzer: Personen, die navigieren, lesen, ein Formular ausfüllen. Jede sendet von Zeit zu Zeit eine Anfrage, typischerweise alle 10 bis 30 Sekunden, in einer modernen Anwendung dazu einige API-Aufrufe pro Ansicht.
• Die laufenden Anfragen: die, die der Server in einem bestimmten Moment berechnet. Das ist die einzige Größe, die Prozessor und Arbeitsspeicher verbraucht.

Von der einen zur anderen kommt man mit dem Gesetz von Little: die Zahl der laufenden Anfragen ist gleich dem Durchsatz, in Anfragen pro Sekunde, multipliziert mit der mittleren Dauer einer Anfrage.

Beispiel. 600 gleichzeitig aktive Nutzer, die jeweils alle 20 Sekunden eine Anfrage auslösen, erzeugen 30 Anfragen pro Sekunde. Dauert jede Anfrage 100 ms, hat der Server im Mittel nur 3 laufende Anfragen. Die eigentliche Herausforderung liegt woanders: in den Spitzen und in den langsamen Anfragen.

Was eine vCPU trägt

Eine Anfrage belegt den Prozessor für die Dauer ihrer Berechnung: den Code ausführen, die Datenbank abfragen, die Antwort aufbauen. Eine vCPU verarbeitet daher höchstens 1.000 ÷ t Anfragen pro Sekunde, wobei t die Rechenzeit einer Anfrage in Millisekunden ist. Wartezeit (auf eine externe API, auf die Festplatte) belegt den Prozessor nicht, wohl aber einen Worker.

Mit diesen Größenordnungen belegen 30 API-Anfragen pro Sekunde mit 10 ms Rechenzeit 30 % einer einzigen vCPU. Dieselben 30 Anfragen pro Sekunde auf WordPress-Seiten ohne Cache verlangen 3 bis 9 vCPU. Genau dafür ist der Seiten-Cache da: er bringt eine Seite von der vierten Zeile der Tabelle in die zweite.

Was der Arbeitsspeicher trägt

Jede laufende Anfrage wird von einem Worker bearbeitet, und Worker belegen Arbeitsspeicher, ob sie arbeiten oder nicht. Oft ist es der Arbeitsspeicher, mehr als der Prozessor, der die Zahl parallel bearbeiteter Anfragen bestimmt:

• PHP-FPM: ein Prozess pro laufender Anfrage, jeweils 40 bis 80 MB. pm.max_children setzt die Obergrenze: 20 Prozesse belegen 800 MB bis 1,6 GB.
• Python (Gunicorn, Uvicorn): die Dokumentation von Gunicorn empfiehlt als Ausgangspunkt (2 × Anzahl der Kerne) + 1 Worker, mit jeweils 80 bis 200 MB. Ein asynchroner Worker hält viele Anfragen in Wartestellung, zum Preis eines einzigen Prozesses.
• Node.js: ein einziger Prozess hält Tausende wartender Verbindungen, nutzt aber nur einen Kern; der Cluster-Modus oder PM2 startet einen Prozess pro vCPU.
• Die Datenbank: PostgreSQL öffnet einen Prozess pro Verbindung und akzeptiert standardmäßig 100. Ab einigen Dutzend aktiven Verbindungen ist ein Connection Pooler wie PgBouncer die bessere Wahl als eine Erhöhung von max_connections.

Dauerhafte Verbindungen (WebSockets, Echtzeitbenachrichtigungen) zählen gesondert: ständig offen, belegen sie wenig Prozessorzeit und jeweils einige zehn Kilobyte Arbeitsspeicher. Ein Node.js-Server hält Tausende davon mit einigen hundert MB.

Die wahren Engpässe

In einer realen Anwendung stößt der Server selten dort an seine Grenze, wo man es erwartet. Die häufigsten Ursachen, in der Reihenfolge, in der Sie sie suchen sollten:

1. Eine langsame SQL-Abfrage: ein fehlender Index macht aus einer Abfrage von 2 ms eine von 2 Sekunden, die einen Worker und eine Verbindung festhält. pg_stat_statements bei PostgreSQL oder das Slow Query Log von MySQL zeigt sie an.
2. Kaskadierende Abfragen (das N+1-Problem): eine Seite, die pro angezeigter Zeile eine Abfrage startet, startet Hunderte davon.
3. Ein synchroner externer Aufruf: eine Zahlungs- oder KI-API, die in 3 Sekunden antwortet, blockiert einen synchronen Worker 3 Sekunden lang.
4. Aufwendige Verarbeitung in der Anfrage: E-Mail-Versand, Skalierung von Bildern, PDF-Erzeugung, die in eine Job-Queue gehören.
5. Fehlender Cache: Seiten, die für alle Besucher gleich sind, kommen aus einem Cache, statische Dateien direkt vom Webserver.

Überprüfen: der Lasttest

Die Größenordnungen liefern eine erste Größe; ein Lasttest liefert die tatsächliche. Das Prinzip: immer mehr Nutzer auf einer Kopie der Anwendung simulieren und den Moment festhalten, in dem die Antwortzeit sprunghaft ansteigt.

wrk -t2 -c50 -d30s --latency https://staging.ihre-website.com/

Für einen vollständigen Ablauf (Anmeldung, Navigation, Suche) beschreibt k6 ein Szenario in JavaScript und steigert die Last stufenweise:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://staging.ihre-website.com/');
  sleep(15);
}

• Testen Sie eine Kopie, nicht die Produktion, und informieren Sie Ihren Hoster, wenn der Test einen Server betrifft, den er betreibt.
• Starten Sie den Test von einer anderen Maschine als dem getesteten Server, sonst entzieht das Werkzeug ihm seine eigenen Ressourcen.
• Achten Sie auf das 95. Perzentil der Antwortzeit, nicht auf den Durchschnitt: das erleben Ihre am schlechtesten bedienten Nutzer.
• Beobachten Sie den Server während des Tests: htop für den Prozessor, free -h für den Arbeitsspeicher, die Logs für Fehler.

Wenn die Last wächst

Die Reihenfolge, die am wenigsten kostet und am meisten bringt:

1. Zwischenspeichern, was sich zwischenspeichern lässt (Seiten, Fragmente, Abfrageergebnisse), und langsame Abfragen korrigieren.
2. Die Zahl der Worker auf den verfügbaren Arbeitsspeicher und Prozessor abstimmen.
3. In die nächsthöhere Größe wechseln: mehr vCPU und Arbeitsspeicher, ohne etwas an der Anwendung zu ändern.
4. Die Datenbank auf einen eigenen Server legen.
5. Die Anwendung hinter einem Load Balancer auf mehrere Server verteilen.

Die ersten drei Schritte decken die große Mehrheit der Geschäftsanwendungen, Websites und APIs ab: mehrere hundert gleichzeitig aktive Nutzer finden auf einem einzigen, gut eingestellten Server Platz.