Leistung und Skalierung

Am 27. Oktober 2026 verarbeitete ein einzelner Go-Server 10.000 authentifizierte WebSpace-WebSocket-Verbindungen und stellte alle 100.000 erwarteten Ereignisse zu. Bei gemischter SQLite3-Last wurden außerdem 1.000 Schreib- und 10.000 Lesevorgänge abgeschlossen, während 10.000 Verbindungen geöffnet blieben.

Die Validierungsergebnisse und Messdaten je Durchlauf (JSON) stehen zum Download bereit. Getestet wurde der eigene Echtzeitpfad von WebSpace, getrennt vom Workspace-Chat.

Testumgebung und Einstellungen

Ein eigener Entwicklungsbuild umging die Prüfung der Lizenzstufe. Authentifizierung, Berechtigungen und Origin-Prüfungen liefen über den regulären WebSpace-Pfad. Die Datenbanken lagen auf einem datenträgergestützten ext4-Dateisystem, nicht im RAM-Dateisystem tmpfs. Die Generatoren begrenzten weder die Leserate noch die Anzahl gleichzeitig ausstehender Schreibvorgänge.

Die HTTP-Limits wurden über requestsPerSecond und burst unter webspace.rateLimits.read, webspace.rateLimits.mutation und webspace.rateLimits.handshake konfiguriert und durch einen Neustart angewendet. Die Testwerte weichen von den Standardwerten ab. Echtzeit-Verbindungslimits verwalten Sie unter Dienste und Kapazität.

Verbindungen und Zustellung von 5.000 bis 10.000

Jede Verbindung empfing zehn Ereignisse. Jede Größenordnung wurde dreimal geprüft. In keinem Durchlauf fehlten Ereignisse oder wurden doppelt bzw. in einen falschen Raum zugestellt.

Die Zeiten sind Mediane aus drei Durchläufen. Die Verbindungszeit umfasst Generatorstart, schrittweisen Verbindungsaufbau, Authentifizierung und Abschluss der Abonnements. Zustell-p95 bezeichnet das 95. Perzentil der Zeit vom Senden bis zum Empfang eines Ereignisses; angegeben ist der Median der drei p95-Werte. Der September-Test maß die Zeit bis zum Empfang aller zehn Ereignisse je Verbindung. Die Latenzwerte sind daher nicht direkt vergleichbar.

1.000 SQLite3-Schreib- und 10.000 Lesevorgänge

Bei 10.000 geöffneten authentifizierten Verbindungen wurden 1.000 Zustandsänderungen an einer gemeinsamen Ressource zusammen mit 10.000 HTTP-Leseanfragen gestartet. Schreibvorgänge wurden je Datenbank über eine Warteschlange nacheinander ausgeführt.

Die Dauer reicht vom Start der Lese- und Schreibphase nach dem Verbindungsaufbau bis zu deren Abschluss. Die Einstellung 10.000 beschreibt die Anfragen der Clients. SQLite führte nicht 10.000 Abfragen gleichzeitig aus; der Lesepool war auf acht Verbindungen begrenzt.

Alle Leseanfragen erhielten HTTP 200. Es gab weder HTTP 429 noch Schreibfehler. Bei einer Lesekonkurrenz von 10.000 lag das Schreib-p95 bei 858 ms und das Lese-p95 bei etwa 2,88 s. Alle vier Testdatenbanken enthielten 1.000 eindeutige Aktionen, einen Ressourcenwert von 100.000→99.000, Version 1.000 und 1.000 Belohnungen. SQLite integrity_check lieferte jeweils ok.

Aktive Verbindungen, Räume und Wiederverbindung

Mit 10.000 Verbindungen wurden in zwölf Runden jeweils zehn Ereignisse gesendet, mit fünf Sekunden Pause zwischen den Runden. Alle 1.200.000 Zustellungen wurden in etwa 67,27 Sekunden abgeschlossen, ohne fehlende oder doppelte Ereignisse. Nach dem abrupten Schließen und erneuten Verbinden von 100 Verbindungen kamen auch alle 10.000 Folgeereignisse an.

Ein separater Test verteilte die Verbindungen auf 100 Räume mit je 100 Verbindungen. Alle 100.000 anfänglichen Ereignisse kamen an, keines im falschen Raum. Die Zustellung nach 20 Sekunden Leerlauf und nach dem erneuten Verbinden von 100 Verbindungen bestand ebenfalls den Test. Über alle 15 Testfälle lag der höchste beobachtete Server-RSS bei etwa 1,50 GiB. Nach Testende blieben keine Verbindungen offen.

Einfluss von Latenz und Speicherpfad

Im Test mit aktiven Verbindungen fiel die regelmäßige Token-Neuvalidierung des gesamten Abonnement-Namensraums mit Zustell-p95-Werten von etwa 1,91–2,31 Sekunden je Runde zusammen. Die 312 ms aus kurzen Zustelltests sind daher keine dauerhafte Latenzgarantie.

Ein früherer Test verwendete das freigegebene Windows-Dateisystem in WSL (9p). Nur 414 von 1.000 gleichzeitigen Schreibvorgängen wurden abgeschlossen; die übrigen überschritten das Fünf-Sekunden-Budget für Schreibwartezeit und Transaktion. Die oben gezeigten erfolgreichen Ergebnisse stammen von einem virtuellen WSL-ext4-Laufwerk auf derselben NVMe-SSD. Die Ergebnisse können je nach Art des Speicherzugriffs abweichen.

Mit dem Standard-Leselimit von 500 Anfragen/Sekunde pro IP und Burst 1.200 erhielten 37 Leseanfragen HTTP 429. Für die abschließenden Tests wurden die HTTP-Limits angehoben, statt die Generatoren zu verlangsamen.

Konfiguration nach Arbeitslast

Eine Warteschlange ordnet gleichzeitige Schreibvorgänge; der Durchsatz bleibt begrenzt. Die Verbindungszahl bezeichnet hier authentifizierte Sockets eines Kontos. Vollständige Abläufe von 10.000 verschiedenen Benutzern und lang andauernde Last wurden damit nicht validiert. Messen Sie zusätzlich mit TLS, Proxys, WAN und dem Lastprofil Ihrer Produktionsumgebung.

Unter Betrieb sehen Sie Anfragen, Fehler, Antwortzeiten und DB-Status. Einen vollständigen Benutzerablauf bietet das Beispiel Ein Echtzeit-Gomoku-Spiel erstellen.