ID da causa in-gateway · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando há um servidor intermediário entre o cliente e o servidor do jogo, cada passagem por ele soma tempo de processamento, e esse servidor vira um ponto único de falha.
Por quê Arquitetura cliente ↔ gateway ↔ servidor do jogo → Efeito Processamento e espera extras no servidor intermediário, e a sobrecarga dele afeta todos → Na tela Ping mais alto para todos e, se o gateway cair, desconexão de todos os jogadores que passam por ele
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: permitir aumentar o número de gateways, fazer o personagem continuar de onde estava ao reconectar por outro gateway quando um cair (reconexão de sessão). Cliente: reconectar automaticamente quando o gateway cair.
O que fazer (Equipe de infraestrutura)
Escalar os gateways horizontalmente (adicionar máquinas), monitorar CPU, número de conexões e latência de processamento de cada gateway.
Números de referência
Dentro do mesmo data center, cada passagem normalmente leva menos de 1 ms. Com o gateway sobrecarregado, sobe para dezenas ou centenas de ms.
No gráfico
Sobe com a carga · Latência de processamento do gateway, CPU e conexões do gateway
Onde olhar
CPU e número de conexões do gateway, Recv-Q dos sockets do gateway (ss, netstat) e diferença de latência antes e depois do gateway. Em chamadas HTTP ou gRPC que passam pela service mesh, comparar a métrica padrão do Istio istio_request_duration_milliseconds separando quem envia (reporter=source) e quem recebe (reporter=destination)
Confirma se
O tempo de processamento do servidor do jogo não muda, só a latência no trecho do gateway sobe, e nesse momento a CPU do gateway satura ou o Recv-Q acumula
Descarta se
Rotas que não passam pelo gateway (conexão direta, outro gateway) igualmente lentas: aponta para a conexão ou para o servidor do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com uma service mesh (Istio, por exemplo), o proxy sidecar (Envoy) que fica ao lado de cada servidor acrescenta mais uma etapa. As requisições entre serviços passam pelo sidecar de quem envia e depois pelo sidecar de quem recebe, e quanto mais funções o proxy ganha, como coleta de logs e métricas, mais crescem o tempo de processamento e o tempo de espera.
Performance and ScalabilityIstio No modo sidecar, a requisição passa pelo proxy sidecar de quem envia e depois pelo de quem recebe; quanto mais funções, mais longo o caminho de processamento dentro do proxy, e a coleta de telemetria aumenta a espera da requisição seguinte
What is EnvoyEnvoy O Envoy é um processo separado que roda ao lado de cada servidor de aplicação, e o app envia e recebe tudo pelo Envoy em localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (distribuição do tempo de processamento de requisições HTTP e gRPC); o label reporter distingue o proxy de quem envia (source) e o de quem recebe (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: número de bytes em um socket conectado que o programa do usuário ainda não leu
Veja também
Mesma camada: L13 Arquitetura e operação de servidores