ID de la causa in-gateway · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Si se pone un servidor intermedio entre el cliente y el servidor del juego, cada paso por él suma tiempo de procesamiento y ese servidor se convierte en un punto único de fallo.
Por qué Arquitectura cliente ↔ gateway ↔ servidor del juego → Efecto El servidor intermedio añade procesamiento y espera; si se sobrecarga, afecta a todos → En pantalla El ping sube para todos; si el gateway falla, todos los jugadores que pasan por él sufren una desconexión
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: diseñar la arquitectura para poder tener varios gateways y para que, si uno se cae, el personaje siga tal cual al reconectarse por otro (reconexión de sesión). Cliente: reconectar automáticamente si se corta el gateway.
Tareas (Equipo de infraestructura)
Escalar los gateways horizontalmente (añadir más), monitorear la CPU, las conexiones y la latencia de procesamiento de cada gateway.
Cifras de referencia
Dentro del mismo centro de datos, cada paso suele costar menos de 1 ms. Si el gateway se sobrecarga, sube a decenas o cientos de ms.
En el gráfico
Sube con la carga · Latencia de procesamiento del gateway, CPU y conexiones del gateway
Dónde mirar
CPU y número de conexiones del gateway, Recv-Q de sus sockets (ss, netstat) y diferencia de latencia antes y después del gateway. Para llamadas HTTP o gRPC que pasan por la malla de servicios, comparar la métrica estándar de Istio istio_request_duration_milliseconds separada por emisor (reporter=source) y receptor (reporter=destination)
Se confirma si
El tiempo de procesamiento del servidor del juego no cambia, pero sube solo la latencia del tramo del gateway, y en ese momento la CPU del gateway está saturada o se acumula Recv-Q
Se descarta si
Si las rutas que no pasan por el gateway (conexión directa, otro gateway) van igual de lentas, apunta a la conexión o al servidor del juego
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Con una malla de servicios (service mesh), como Istio, el proxy sidecar (Envoy) que acompaña a cada servidor también suma un salto. Las solicitudes entre servicios pasan primero por el sidecar del emisor y después por el del receptor, y cuantas más funciones se añaden al proxy (recolección de logs y métricas, etc.), más crecen el tiempo de procesamiento y la espera.
Performance and ScalabilityIstio En modo sidecar, las solicitudes pasan sucesivamente por el proxy sidecar del emisor y por el del receptor; cuantas más funciones se añaden, más largo es el camino de procesamiento dentro del proxy, y la recolección de telemetría aumenta la espera de la siguiente solicitud
What is EnvoyEnvoy Envoy es un proceso aparte que corre junto a cada servidor de aplicaciones, y la aplicación envía y recibe a través del Envoy en localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (distribución del tiempo de procesamiento de solicitudes HTTP y gRPC); la etiqueta reporter distingue el proxy emisor (source) del receptor (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: en un socket conectado, bytes que el programa de usuario aún no ha recogido
Ver también
Misma capa: L13 Arquitectura y operación de servidores