Steht zwischen Client und Spielserver ein Zwischenserver, kommt bei jeder Station Verarbeitungszeit hinzu, und dieser Server wird zum Single Point of Failure.
Warum Aufbau Client ↔ Gateway ↔ Spielserver → Folge Zusätzliche Verarbeitung und Wartezeit im Zwischenserver, bei Überlast sind alle betroffen → Auf dem Bildschirm Höherer Ping für alle, fällt das Gateway aus, Verbindungsabbruch für alle Spieler, die darüber laufen
Server: Gateways so auslegen, dass sich weitere Maschinen hinzufügen lassen, Session-Wiederaufnahme vorsehen, damit der Charakter nahtlos weiterläuft, wenn er sich nach dem Ausfall eines Gateways über ein anderes Gateway neu verbindet. Client: bei abgebrochener Gateway-Verbindung automatisch neu verbinden.
Aufgaben Infrastrukturteam
Gateways horizontal skalieren (weitere Maschinen hinzufügen), CPU, Verbindungszahl und Verarbeitungslatenz pro Gateway überwachen.
Größenordnungen
Im selben Rechenzentrum kostet jede Station normalerweise unter 1 ms. Ist das Gateway überlastet, steigt das auf Werte im zwei- bis dreistelligen Millisekundenbereich.
Im Graphen
Steigt mit Spielerzahl und Last · Verarbeitungslatenz des Gateways, CPU und Verbindungszahl des Gateways
Wo nachsehen
CPU und Verbindungszahl des Gateways sowie Recv-Q der Gateway-Sockets (ss, netstat) prüfen, Latenz vor und hinter dem Gateway vergleichen. Bei HTTP- oder gRPC-Aufrufen über ein Service-Mesh die Istio-Standardmetrik istio_request_duration_milliseconds getrennt nach Sender (reporter=source) und Empfänger (reporter=destination) vergleichen
Spricht dafür
Verarbeitungszeit im Spielserver unverändert, nur die Latenz im Gateway-Abschnitt steigt, und zur selben Zeit ist die Gateway-CPU ausgelastet oder die Recv-Q staut sich
Spricht dagegen
Wege ohne Gateway (Direktverbindung, anderes Gateway) genauso langsam: eher Leitung oder Spielserver
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Mit einem Service-Mesh (etwa Istio) kommt der Sidecar-Proxy (Envoy), der neben jedem Server läuft, als weitere Station hinzu. Anfragen zwischen Diensten durchlaufen nacheinander den Sidecar des Senders und den Sidecar des Empfängers. Je mehr Funktionen der Proxy übernimmt, etwa das Sammeln von Logs und Metriken, desto länger werden Verarbeitungs- und Wartezeit.
Performance and ScalabilityIstio Im Sidecar-Modus durchlaufen Anfragen nacheinander den Sidecar-Proxy des Senders und den des Empfängers. Mit jeder zusätzlichen Funktion wird der Verarbeitungspfad im Proxy länger, und das Sammeln von Telemetrie erhöht die Wartezeit der nächsten Anfrage
What is EnvoyEnvoy Envoy läuft als eigener Prozess neben jedem Anwendungsserver, die App kommuniziert über den Envoy auf localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (Verteilung der Bearbeitungszeit von HTTP- und gRPC-Anfragen), das Label reporter unterscheidet den Proxy des Senders (source) und des Empfängers (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: Anzahl der Bytes auf einem verbundenen Socket, die das Anwenderprogramm noch nicht abgeholt hat
Verwandte Ursachen
Gleiche Schicht: L13 Serverarchitektur und Betrieb