Serverkapazität

Aktualisiert am 30.05.2026 · nach dem Ausrollen der Korrekturen 6.61–6.64.

Das Wichtigste: Vorproduktion, kein Altlastenballast

Auf dem Produktivserver gibt es noch keine echten Nutzer. Alle Installationen sind Testinstallationen. Daraus folgt:

$MIN in version_check.php ist jetzt gleich $CURRENT (=6.66). Jede ältere Version wird zwangsweise auf die aktuelle gehoben.
„Natürliche Migration über den Update-Dialog“ ist eine Strategie für die Produktion. Vorerst heißt Ausrollen schlicht, ihn anzuheben: $MIN.
Rückwärtskompatibilitätsschichten „für den Fall eines alten Clients“ sind überflüssig — einen solchen Client gibt es nicht.

Schätzungen nach Lastbereichen

Publikum, MAU	Gleichzeitige WS (Spitze)	Zustand eines einzelnen VPS	Wichtigster Engpass
≤ 30k	≤ 3k	Zehnfache Reserve, im Leerlauf	In unserem Stack nichts
30k — 100k	3k — 10k	Der Zielbereich, komfortabel	Die CPU von Workerman bewältigt Pongs und Ereignisse mühelos. Die Datenbank arbeitet über Primärschlüssel. 500 MB–1 GB RAM für die Sockets.
100k — 200k	10k — 20k	Betrieb am Limit	Der einzelne Workerman-Prozess überhitzt in der Spitze. Taucht ein Fehler mit abbrechenden WebSockets auf, beginnt die Degradation.
> 200k	> 20k	Wir stoßen an die Decke	Phase C ist nötig (Workerman count=4 plus Redis pub/sub für gemeinsames `$hosts`/`$guests`).

Was in 6.61–6.64 behoben wurde

Metric	Vor den Korrekturen	Nach 6.64	Wo umgesetzt
`ble_token_renew` in der Warteschlange, solange der Besitzer offline ist	1300 in 4 h	1 (Dedup über UNIQUE INDEX)	Server — funktioniert mit jedem Client
HTTP-Wiederholungen bei Netzstörung	5 Schlüssel × 1/min = 7200 pro Tag	~50 pro Tag (30-Minuten-Backoff)	Client 6.64 — ein neues APK ist erforderlich
WebSocket-Neuverbindungen bei flatterndem Netz	~10/min (Wiederholung nach 1 s)	~1/min (60-s-Backoff)	Client 6.62+ — ein neues APK ist erforderlich
Datenbankabfragen bei hello während flatternder WebSockets	~50/s bei 10 000 Clients	~5/s	Server — das 5-Sekunden-Limit schützt vor jedem Client
Fehlgeschlagene Fire-Ereignisse in den Prefs des Gastes	60+ pro Tag je Gast mit abgelaufenem Token	0	Client 6.63
Recompose-Wellen bei guest_ok	bei jedem numbers_update	nur bei tatsächlicher Änderung	Client 6.64

Was sofort für alle Clients wirkt (serverseitige Korrekturen)

Die serverseitigen Schutzmechanismen stecken in der Verarbeitung eingehender Nachrichten — sie greifen unabhängig von der Client-Version.

Dedup per INSERT IGNORE in enqueueHostMsg — selbst wenn ein 6.55-Client 1300 identische Verlängerungen schickt, landet nur eine in der Warteschlange.
Ein 5-Sekunden-Limit für host_hello und guest_hello — selbst wenn ein 6.55-Client jede Sekunde neu verbindet, wird das zweite hello in Folge ohne Datenbankzugriff geschlossen.
Obergrenze pending_host_msgs = 500 je host_id — Absicherung gegen ein Anwachsen der Warteschlange, woher auch immer.
CDN-ready: $GLOBALS['apk_url'] in _config.php — der Umzug auf R2 oder ein CDN ist eine Zeile, ohne App-Release.

Was erst nach dem Client-Update wirkt

Der 60-Sekunden-WebSocket-Backoff zugunsten der Stabilität (6.62) senkt den Reconnect-Sturm des Clients um das Zehnfache.
Der exponentielle HTTP-Wiederholungs-Backoff, 30 s → 30 min (6.64), senkt die Wiederholungslast um das Dreißigfache.
Der Vergleich vor dem Hochzählen von overridesVersion (6.64) schont lokale CPU und Akku und verringert indirekt Doze-Neuverbindungen.
Die Gastoberfläche zeigt ein abgelaufenes Token als offline (6.63), fehlgeschlagene Ereignisse treten daher nicht mehr auf.

Entscheidung: angehoben $MIN = '6.66'. Jeder alte Client bekommt beim ersten versionCheck einen blockierenden Dialog „App aktualisieren“ (die Oberfläche existiert bereits, siehe App.kt:checkVersionAsync).

Workerman skalieren — wann es nötig wird

Derzeit count=1 — ein einziger PHP-Prozess hält ALLE WebSockets in den Arrays $hosts/$guests/$calls in-memory.

Die konkreten Schwellen:

10 000 gleichzeitige Verbindungen — komfortabel, mit Reserve.
15 000 gleichzeitig — stabil, doch in der Spitze sind Timeouts möglich.
20 000 gleichzeitig — der kritische Punkt. Ein Doze-Ausstieg bei 20 000 Clients ergibt eine Ereigniswarteschlange von rund 500 Sekunden: Timeouts und Sturm.

Was zu tun ist, wenn sich 15 000 nähern:

Redis auf dem VPS installieren (apt install redis-server).
Workerman count=4 (entsprechend der Kernanzahl des VPS).
Move $hosts/$guests/$calls in einen Redis-HASH mit TTL.
Pub/sub zwischen Workern: Kommt eine Nachricht bei W1 an, während der Empfänger auf W2 sitzt, wird sie über den Kanal weitergereicht.

Effect: lineare Skalierung bis 4×, die Decke steigt auf etwa 40 000–60 000 gleichzeitig.

Umzug auf ein CDN — wann es nötig wird

Heute wird das 22-MB-APK jedem Nutzer vom eigenen VPS ausgeliefert. Bei hunderttausend sind das 2,2 TB ausgehender Verkehr pro Release — die eigene Leitung schafft das womöglich nicht oder wird teuer.

In 6.64 vorbereitet:

$GLOBALS['apk_url'] in _config.php — eine einzige Wahrheitsquelle für die Adresse.
download.php und version_check.php lesen sie von dort.
Android prüft die APK-Signatur selbst, ein Austausch im CDN geht also nicht durch.

Wenn der Umzug nötig wird:

Ein Cloudflare-R2-Bucket → hochladen entrixy.apk.
Eigene Domain apk.entrixy.com über das Cloudflare-CDN.
In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
Im Deploy-Skript, nach assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

Beim heutigen Maßstab — Dutzende Testinstallationen — ist kein Umzug nötig.

Die Aufgabenliste: was jetzt auf dem Server und in der App liegt

Damit alle Korrekturen greifen:

Auf dem Server: sudo supervisorctl restart dialer-ws.
Jede Version unter 6.66 erhält beim nächsten Start einen verpflichtenden Update-Dialog.
Nach dem Ausrollen von 6.66 sinkt die Last aus Reconnect-Stürmen und Wiederholungen um eine Größenordnung.