한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Guia do Lag em Jogos › L9 Processo do jogo no servidor

Custo de serialização e compressão Serialization / compression cost

ID da causa sp-serialize · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)

Abrir o card interativo, com figuras e simulações →

Converter os dados a enviar em bytes e comprimi-los também gasta CPU, e com muitos jogadores esse custo explode.

Por quê Cada atualização converte estruturas em bytes e as comprime → Efeito O custo cresce com o quadrado do número de jogadores → Na tela O envio atrasa: input lag

Sintomas
Input lag
Fatores
Paralisação, Latência
Quem é afetado
Local ou canal específico
Quando
Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reutilizar para vários jogadores o pacote montado uma vez, usar um formato leve.
No gráfico
Sobe com a carga · Uso de CPU do servidor, CPU da thread que monta os pacotes
Onde olhar
Comparar com perf top -p a fatia das funções de serialização, compressão e criptografia (incluindo funções de bibliotecas como zlib, LZ4 e OpenSSL) no tempo de CPU do processo do jogo, com poucos jogadores e com o servidor lotado
Confirma se
Quanto mais lota, maior a fatia das funções de serialização, compressão e criptografia, e a CPU da thread que monta os pacotes satura primeiro
Descarta se
Fatia pequena dessas funções: cálculo de visibilidade ou lógica do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Em conexões que criptografam os pacotes (TLS, DTLS etc.), criptografar e descriptografar também gasta CPU. A criptografia é feita separadamente em cada conexão, então, mesmo reutilizando para vários jogadores o pacote montado uma vez, o custo de criptografia se multiplica pelo número de destinatários. Cifras simétricas como AES-GCM são tão rápidas que um núcleo processa vários GB por segundo, e normalmente pesam pouco, mas a velocidade varia muito com o tamanho da unidade criptografada de cada vez (o registro), e em jogos, com muitos pacotes pequenos, o custo por byte aumenta. No handshake, feito uma vez por conexão, o servidor assina com a chave do certificado e calcula a troca de chaves (ECDHE). Um núcleo faz por segundo de cerca de 1.100 (RSA 2048) a 18 mil (ECDSA P-256) assinaturas e cerca de 9 mil trocas de chaves, o que pesa quando chega uma avalanche de logins.

Fontes

  1. Introduction to Iris in Unreal Engine Epic Games
    Mantém uma única cópia quantizada do estado a replicar, o que reduz o trabalho pesado e permite que várias conexões compartilhem esse trabalho
  2. VALORANT's 128-Tick Servers Riot Games
    Comparar as variáveis replicadas de cada cliente a cada frame e empacotar os valores alterados é um trabalho lento, que lê memória espalhada, e consome muita CPU do servidor
  3. How "expensive" is crypto anyway? Cloudflare
    Medição com BoringSSL: AES-128-GCM a cerca de 3,7 GB por segundo (varia muito com o tamanho do registro); um núcleo faz por segundo 1.120 assinaturas RSA 2048, 18.477 assinaturas ECDSA P-256 e 9.394 ECDHE P-256; nos servidores de borda da Cloudflare, as bibliotecas TLS usaram cerca de 1,8% da CPU
  4. perf-top(1) — Linux manual page perf
    Mostra em tempo real a fatia de uso de CPU por função (símbolo) de um processo em execução (-p)

Veja também

Mesma camada: L9 Processo do jogo no servidor

Mesmo sintoma (Input lag) em outras camadas

Ver o card interativo, com figuras e simulações