Kapazität, in der Produktion gemessen
20.000 Menschen. Keine abgebrochene Verbindung.
Jede Zahl auf dieser Seite stammt aus einem Lasttest gegen das echte pollslive.com - kein Staging-Klon, keine Hochrechnung in einer Tabelle. Unten stehen Methode, vollständige Ergebnisse und die Grenze, die wir nicht überschritten haben.
Zuletzt gemessen: 20. Juli 2026
Was wir gemessen haben
Vier Zahlen, jede aus einem benannten Lauf gegen die Produktion. Jede mit ihrer Einschränkung.
2,500
Menschen, die dieselbe Frage gleichzeitig beantworten
Alle 2.500 Antworten angenommen, keine verloren, bei dauerhaft 100 Antworten pro Sekunde.
2026-07-20
20 ms
mittlere Zeit bis zur Annahme einer Antwort
p95 77 ms, p99 104 ms, langsamste Einzelantwort 140 ms - im selben Raum mit 2.500 Personen.
2026-07-20
20,000
gleichzeitige Live-Teilnehmende
Alle 20.000 waren verbunden und erhielten die Status-Verteilung. Null Fehler, p99 Verbindungsaufbau 34 ms.
2026-07-11
8,000
Menschen, die Ergebnisse live mitverfolgen
Null Fehler. Ein späterer Lauf hielt 4.000 Zuschauende, während der Antwortsturm noch lief.
2026-07-11
Der Moment, auf den es wirklich ankommt
Niemand sorgt sich darum, ob Leute beitreten können. Man sorgt sich um die Sekunde, in der die Frage erscheint und der ganze Raum gleichzeitig antwortet. Das ist ein Stoß von Datenbankschreibvorgängen - und genau dort geben solche Werkzeuge auf. Also haben wir ihn bewusst erzeugt: echter Raum, echte Beitritte, echte Antworten über das echte Gateway.
| Raumgröße | Antwortrate | Angenommene Antworten | Fehlgeschlagen | Annahmezeit p50 / p95 / p99 |
|---|---|---|---|---|
| 300 | 25/Sek. | 300 | 0 | 17 / 31 / 46 ms |
| 1.500 | 50/Sek. | 1.500 | 0 | 16 / 35 / 66 ms |
| 2.500 | 100/Sek. | 2.500 | 0 | 20 / 77 / 104 ms |
Lesen Sie die letzte Spalte von oben nach unten. Der Raum wird achtmal so groß, die Antwortrate viermal so hoch - und der Median bewegt sich kaum. Genau darum geht es: Die Antwortzeit verschlechtert sich nicht, wenn der Raum wächst.
Warum es flach bleibt
Die Live-Auszählung wurde früher aus allen Antworten der Folie neu berechnet, sodass jede neue Antwort etwas mehr kostete als die vorherige - bei 200 Personen unproblematisch, bei 2.000 hässlich. Jetzt ist es ein inkrementeller Zähler, wodurch die Kosten einer Antwort unabhängig davon sind, wie viele vorher kamen.
Alle in den Raum bekommen
Bevor jemand antworten kann, muss er beitreten. Jede teilnehmende Person hält für die gesamte Sitzung eine offene WebSocket-Verbindung. Es geht also darum, wie viele Verbindungen eine Maschine trägt - und wie lange die langsamste Person auf den Einlass wartet.
| Teilnehmende | Verbunden | Fehlgeschlagen | Langsamster Verbindungsaufbau (p99) |
|---|---|---|---|
| 1.000 | 1.000 | 0 | 9 ms |
| 3.000 | 3.000 | 0 | 8 ms |
| 5.000 | 5.000 | 0 | 7 ms |
Der Juli-Lauf trieb diese Dimension auf 20.000 gleichzeitige Teilnehmende, ohne Fehler und mit p99 von 34 ms, auf derselben Hardware.
Wo Schluss ist
Eine Grenze zu veröffentlichen ist nützlicher, als sie zu verstecken - hier ist unsere. Schreibvorgänge sind die kritische Fläche: rund 100 Antworten pro Sekunde laufen plattformweit sauber, bei etwa 180 pro Sekunde gibt die Maschine auf. Der begrenzende Faktor ist die CPU eines geteilten Hosts mit 4 Kernen - nicht die Datenbank, deren Verbindungspool in keinem der beiden Läufe auch nur annähernd erschöpft war.
Daher kommen die Tarifgrenzen
Ein Raum mit N Personen, die innerhalb von rund zehn Sekunden antworten, erzeugt N/10 Schreibvorgänge pro Sekunde. Rechnet man von der Grenze zurück, ergeben sich die tatsächlich durchgesetzten Teilnehmergrenzen: 50 bei Free, 1.000 bei Pro, 1.500 bei Team, 2.500 mit einem Event Pass und 5.000 bei Enterprise. Sie sind weder willkürlich noch eine als Technik verkleidete Bezahlschranke.
Wir behaupten keine unbegrenzte Skalierung. Ist Ihr Raum größer als die Zahlen oben, sagen Sie es uns vor der Veranstaltung - wir antworten ehrlich mit Ja oder Nein.
Wie wir getestet haben
Gegen die echte Produktion
Kein Klon. Die Generatoren liefen gegen denselben Edge-Proxy, dieselben Container, dieselbe Datenbank und dasselbe Realtime-Gateway, die pollslive.com bedienen - außerhalb der Stoßzeiten und mit Not-Aus beim ersten 5xx oder fehlgeschlagenen Health Check.
Mit umgangenen Ratenbegrenzern
Jede synthetische Anfrage trug eine eigene gefälschte Client-IP, damit die Begrenzer pro IP die Kapazität nicht verdecken. Wir wollten den Server messen, nicht unsere eigene Eingangstür.
Und danach aufgeräumt
Jeder Lauf nutzte einen Wegwerf-Workspace, eine Wegwerf-Umfrage und eine Wegwerf-Sitzung, am Ende gelöscht und auf null Restzeilen geprüft. Die Produktion blieb grün, ebenso die fremde Website auf derselben Maschine.
Konservativ
Die Lastgeneratoren liefen auf derselben Maschine, die sie testeten, und verbrauchten etwa einen Kern davon. Reale Grenzen mit externen Clients liegen daher etwas höher als veröffentlicht.
Die Werkzeuge hinter diesen Zahlen
Alle vier liegen im Repository. Nichts davon wurde mit einem Skript gemessen, das Sie nicht lesen können.
scripts/load-test/answer-storm.mjslive answers through the gatewayscripts/load-test/realtime-load.mjsconcurrent WebSocket participantsscripts/load-test/sse-flood.mjsconcurrent live-results viewersscripts/load-test/vote-storm.mjsasync vote write throughput
Die vollständigen Berichte
Beide Berichte, einschließlich der fehlgeschlagenen Läufe und der noch offenen Engpässe, liegen versioniert beim Code.
- Kapazitäts- und Stresstest
docs/LOAD_TEST_CAPACITY_2026-07.md2026-07-11 - Regressionstest des Live-Pfads
docs/LOAD_TEST_REGRESSION_2026-07-20.md2026-07-20
Bringen Sie Ihren größten Raum mit
Kostenlos starten, ohne Karte, ohne Konto zum Erstellen. Wenn es 2.500 gleichzeitig antwortende Personen trägt, trägt es auch Ihre Betriebsversammlung.