Webserver-Kapazitätsrechner
Maximalen Durchsatz aus Worker-Anzahl und Antwortzeit berechnen.
Quick Presets
Durchsatz pro Worker
20.0 req/sec
Maximaler Durchsatz
40.0 req/sec
Skalierungsszenarien
| Worker-Anzahl | Maximaler Durchsatz | Status |
|---|---|---|
| 1 | 20.0 req/sec | — |
| 2 (current) | 40.0 req/sec | — |
| 4 | 80.0 req/sec | — |
| 8 | 160.0 req/sec | — |
Was ist ein Web-Kapazitaetsrechner?
Ein Web-Kapazitaetsrechner schaetzt die Serverkapazitaet fuer eine Website oder Webanwendung: wie viele gleichzeitige Nutzer der Server verarbeiten kann und wann Skalierung noetig wird.
Kapazitaetsplanung verhindert Ausfaelle bei Traffic-Spitzen und vermeidet gleichzeitig Ueberbereitstellung (zu viel Server = verschwendetes Geld). Ziel: genug Kapazitaet fuer Peak-Zeiten plus Sicherheitsmarge.
So verwenden Sie dieses Tool
Geben Sie erwartete Besucher/Tag, durchschnittliche Seitenaufrufe pro Besuch, durchschnittliche Seitengroesse und Peak-Faktor ein. Das Tool berechnet benoetigte Bandbreite, Requests/Sekunde und empfohlene Servergroesse.
Wichtige Metriken
- Requests per Second (RPS) — Anzahl HTTP-Anfragen pro Sekunde. Ein Seitenaufruf erzeugt typisch 20-100 Requests (HTML, CSS, JS, Bilder).
- Concurrent Users — gleichzeitig aktive Nutzer. Faustregel: ca. 10 % der stuendlichen Besucher sind gleichzeitig aktiv.
- Bandbreite — Datentransfer pro Zeiteinheit. Eine 2MB-Seite bei 100 Besuchern/Sekunde = 200 MB/s = 1,6 Gbit/s.
- Time to First Byte (TTFB) — Zeit bis der Server die erste Antwort sendet. Unter 200ms ist gut, ueber 600ms ist schlecht.
Skalierungsstrategien
Vertikal (groesskerer Server): schnell, aber begrenzt. Horizontal (mehr Server + Load Balancer): skaliert theoretisch unbegrenzt. CDN fuer statische Inhalte: entlastet den Ursprungsserver um 70-90 %. Caching (Redis, Varnish): reduziert Datenbankabfragen um 95 %+.
Rechenbeispiel
Ein Server bearbeitet Anfragen, die im Mittel je 50 ms dauern. Nach dem Little-Gesetz erledigt ein Worker 1 ÷ 0,05 = 20 Anfragen pro Sekunde. Acht Worker liefern bei Vollauslastung 160 Anfragen pro Sekunde. Um für Reserve unter 70 % Auslastung zu bleiben, plane etwa 112 Anfragen pro Sekunde, bevor du Kapazität hinzufügst.
Häufige Fehler
Ein häufiger Fehler ist, für 100 % Auslastung zu planen; Warteschlangen wachsen explosionsartig, wenn ein Server der Sättigung nahekommt, sodass die Latenz lange vor dem theoretischen Limit hochschnellt. Ein weiterer ist, die mittlere Antwortzeit zu nutzen und den langsamen Rand zu ignorieren — wenige sehr langsame Anfragen binden Worker und senken den echten Durchsatz. Lasttests mit unrealistischem, cachefreundlichem Verkehr überschätzen die Kapazität ebenfalls.
Haeufig gestellte Fragen
Wie viele Besucher kann ein einzelner Server verarbeiten?
Stark abhaengig von der Anwendung. Statische Seiten: 10.000+ RPS (Nginx). WordPress: 50-200 RPS ohne Cache, 1.000+ mit Cache. Node.js API: 1.000-10.000 RPS. Faustregel: mit CDN und Caching 10x mehr als ohne.
Was ist der Peak-Faktor?
Das Verhaeltnis von Spitzen-Traffic zum Durchschnitt. Typisch 2-5x fuer die meisten Websites. E-Commerce am Black Friday: 10-20x. Nachrichtenseiten bei Breaking News: 50-100x. Planen Sie immer fuer den Peak, nicht den Durchschnitt.
Warum sollte ich nicht für 100 % Serverauslastung planen?
Die Warteschlangentheorie zeigt, dass die Wartezeit stark steigt, wenn die Auslastung sich 100 % nähert; bei 90 % kann ein kleiner Verkehrsstoß große Latenzspitzen verursachen. Reserve zu lassen — oft mit Ziel 60 bis 70 % — fängt Stöße, Ausfallübernahmen und Verkehrswachstum ab und hält die Antwortzeiten stabil, statt unter Last zusammenzubrechen.