Input lag: 76 causas e quem resolve

Também chamado de: delay nos comandos, resposta lenta, controle pesado

Abrir no catálogo de sintomas ilustrado →

Existe uma demora entre apertar o botão e ver o resultado. A imagem em si pode continuar fluida.

Você aperta o botão da skill e ela só sai 0,2–0,5 s depois. Ações que esperam confirmação, como pegar itens, conversar e trocar, ficam lentas.

O tempo de ida e volta (ping) está alto ou há fila acumulada em algum ponto. Verifique a distância, a fila do roteador, o Nagle (recurso do TCP que junta pacotes pequenos antes de enviar) e as filas do servidor. Se o ping está baixo e tudo continua lento, olhe para o seu PC (V-Sync, FPS baixo) ou para um design que espera a confirmação do servidor a cada ação (capítulo sobre modelos de sincronização).

Causas deste sintoma

L1 Processo do jogo no cliente

Carga de renderização com muitos personagens: Quando centenas de jogadores aparecem na mesma tela, como em guerras de castelo ou world bosses, o custo de desenhar tudo passa do que o aparelho aguenta. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Gargalo no processamento de pacotes na thread principal: Se o cliente processa só uma quantidade fixa de pacotes recebidos por frame, os pacotes que chegam em massa vão sendo empurrados para os frames seguintes. (Desenvolvimento do cliente (Equipe de desenvolvimento))
V-Sync e fila de renderização: O input lag aumenta enquanto alguns frames já desenhados pela GPU ficam em uma fila, esperando o ciclo do monitor para serem exibidos. (Desenvolvimento do cliente (Equipe de desenvolvimento))

L2 SO e dispositivo do cliente

Modo de economia de energia e thermal throttling: No modo bateria do notebook, no modo de economia de energia do celular ou com o aparelho quente, a CPU e a GPU ficam mais lentas. O sinal típico do aquecimento é o jogo começar bem e ficar lento só depois de um bom tempo. (Externo (Externo))
Outros apps do mesmo dispositivo consumindo largura de banda: Quando sincronização com a nuvem, downloads grandes ou patches de jogos rodam no mesmo PC, os pacotes do jogo esperam na fila. (Externo (Externo))
Latência da tela, do dispositivo de entrada e da geração de frames: Se o ping está normal, mas o controle parece pesado, o processamento de imagem da TV, o controle sem fio ou a geração de frames podem estar somando latência entre o comando e a tela. (Externo (Externo))

L3 Rede doméstica

Canal de Wi-Fi congestionado: Em lugares com dezenas de roteadores, como prédios de apartamentos, todos dividem o mesmo canal e esperam a vez de transmitir. (Externo (Externo))
Bufferbloat (fila do roteador): Quando alguém da família sobe um vídeo ou baixa um arquivo grande, a fila do roteador acumula centenas de ms de pacotes, e os pacotes do jogo esperam atrás deles. (Externo (Externo))
Atraso na transição de estado RRC (economia de energia do rádio móvel): Depois de um tempo sem comunicação, o celular coloca a conexão de rádio em estado de baixo consumo e, no pacote seguinte, demora para reativá-la. (Desenvolvimento do cliente (Equipe de desenvolvimento))

L4 Conexão de internet

Atraso de propagação (distância física): Mesmo a luz percorre só cerca de 200 mil km por segundo na fibra óptica. Um servidor distante é lento, por melhor que seja. (Infraestrutura de servidores (Equipe de infraestrutura))
Internet via satélite (órbita baixa ou geoestacionária): Na internet via satélite, o sinal precisa ir ao espaço e voltar. Com satélites geoestacionários, só a ida e volta já passa de 0,5 segundo. Satélites de órbita baixa como o Starlink costumam ser rápidos, mas no momento em que a rota é redistribuída a latência oscila e a conexão pode cair por um instante. (Externo (Externo))
Roteamento com desvio: Por causa dos contratos de interconexão entre operadoras, o tráfego até um servidor próximo pode dar uma volta longa. (Infraestrutura de rede (Equipe de infraestrutura))
Falha em cabo submarino ou link internacional: Quando um cabo submarino se rompe, o tráfego faz desvios longos por semanas (às vezes meses) até o reparo, e os links que sobram ficam congestionados. (Externo (Externo))
Limitação de velocidade e gerenciamento de tráfego da operadora: Quando a franquia de dados acaba, ou em planos que gerenciam certos tipos de tráfego, os pacotes são atrasados ou descartados. (Externo (Externo))
Tráfego via VPN ou redutor de ping: Com uma VPN ou um redutor de ping ligado, os pacotes passam pelos servidores intermediários (relays) dessa empresa. Se o relay estiver longe ou congestionado, a conexão pode até ficar mais lenta. (Externo (Externo))

L5 Equipamentos de rede do data center

Desvio pela proteção contra DDoS e falsos positivos: Quando o tráfego é desviado para um centro de scrubbing para barrar ataques, a rota fica mais longa, e às vezes jogadores legítimos são tomados por atacantes e bloqueados. (Infraestrutura de rede (Equipe de infraestrutura))
Saturação do link do data center: Quando distribuição de patches, envio de logs ou backups usam o mesmo link do jogo, o link lota. (Infraestrutura de rede (Equipe de infraestrutura))

L6 Placa de rede do servidor

Interrupções da NIC concentradas em um só núcleo: Se a NIC manda todas as interrupções de chegada de pacote para um único núcleo de CPU, esse núcleo vira gargalo. (Infraestrutura de servidores (Equipe de infraestrutura))
Coalescência de interrupções excessiva: Para poupar a CPU, a NIC junta pacotes e avisa uma vez só por lote. Os pacotes chegam atrasados pelo tempo gasto juntando. (Infraestrutura de servidores (Equipe de infraestrutura))
Saturação da largura de banda da NIC: Usar uma placa de 1 Gbps ou 10 Gbps no limite faz a fila de transmissão crescer até os pacotes serem descartados. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Atraso pela espera de agregação GRO/LRO: GRO e LRO são recursos que juntam vários pacotes em um só para reduzir a carga na CPU. Dependendo da configuração, um pacote pequeno do jogo pode esperar um pouco pelo próximo pacote para ser agrupado com ele. (Infraestrutura de servidores (Equipe de infraestrutura))

L7 SO do servidor (kernel)

Picos de latência pelo gerenciamento de energia do servidor (C-states e ajuste de frequência): Núcleos de CPU ociosos entram em estados profundos de economia de energia (C-states) e baixam a frequência para economizar eletricidade. Quando chega um pacote ou dispara um timer, o núcleo leva tempo para despertar e subir a frequência, e isso soma latência ao processamento de pacotes pequenos. (Infraestrutura de servidores (Equipe de infraestrutura))
Mudança de desempenho após atualização de SO, kernel, driver ou firmware: É quando o código do jogo continua o mesmo, mas o servidor fica lento depois de uma atualização de SO, kernel, driver ou firmware. A atualização pode mudar valores padrão, o escalonador, as mitigações de vulnerabilidades da CPU (mitigations) e o comportamento de drivers. (Infraestrutura de servidores (Equipe de infraestrutura))

L8 Sockets e protocolos

Algoritmo de Nagle + ACK atrasado: O algoritmo de Nagle, que junta pacotes pequenos antes de enviar, e o ACK atrasado, que demora para mandar o ACK, se combinam, e cada mensagem escrita em partes atrasa 40–200 ms. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Slow start após inatividade: Depois de um tempo ocioso, o TCP volta a reduzir a janela de congestionamento (quanto dá para enviar de uma vez) e, quando de repente precisa enviar muitos dados, divide o envio em várias rodadas. (Infraestrutura de servidores (Equipe de infraestrutura))
Queda brusca da taxa de envio pelo controle de congestionamento: O TCP trata a perda como sinal de congestionamento e reduz a taxa de envio em 30–50%. Ele reage do mesmo jeito à perda no Wi-Fi. (Infraestrutura de servidores (Equipe de infraestrutura))
Arquitetura de I/O bloqueante: Numa arquitetura em que a thread não pode fazer mais nada enquanto espera um socket, tudo fica mais lento à medida que entram mais jogadores. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L9 Processo do jogo no servidor

Estouro do tick: Quando o trabalho de um tick passa do orçamento, o intervalo entre ticks do servidor se alonga, e a área inteira fica lenta ou com engasgos. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Explosão de broadcast: Se o movimento de cada jogador é enviado a todos que o veem, o número de atualizações a enviar cresce com o quadrado do número de jogadores reunidos. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Sobrecarga de zona em thread única (hotspot): Numa arquitetura em que cada área fica com uma thread, quando todo mundo se junta num lugar, só aquele núcleo vai a 100%. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Contenção de lock: Quando várias threads esperam o mesmo lock para usar os mesmos dados, só uma roda por vez, por mais threads que se acrescentem. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Acúmulo na fila de mensagens: Quando os pedidos chegam mais rápido do que são processados e se acumulam na fila, os últimos da fila só são processados segundos depois ou são descartados. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Custo de serialização e compressão: Converter os dados a enviar em bytes e comprimi-los também gasta CPU, e com muitos jogadores esse custo explode. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Esgotamento do pool de threads: Quando todas as worker threads que processam tarefas ficam presas em trabalhos lentos, os pedidos novos ficam esperando indefinidamente. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Combate concentrado em um só alvo (world boss): Quando centenas de jogadores atacam o mesmo boss ao mesmo tempo, o cálculo daquele boss se concentra num só ponto, e as informações de cada golpe vão para todos que estão vendo. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Avalanche de spawns ao entrar em área lotada: Quando o jogador se teletransporta para uma cidade lotada, o servidor precisa enviar de uma vez a aparência, o equipamento e o estado das centenas de jogadores que acabaram de entrar no campo de visão. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Acúmulo de entidades (itens e invocações não removidos): Quando itens no chão, invocações e timers encerrados que deveriam sumir não são limpos e se acumulam, quanto mais tempo o servidor fica ligado, mais trabalho cada tick tem. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Mudança no padrão de tráfego após um patch: Quando novos conteúdos, efeitos e campos sincronizados aumentam o tamanho e a frequência dos pacotes, um servidor que ia bem passa a bater nos limites de MTU, largura de banda e número de pacotes depois do patch. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L11 Disco

Tempestade de fsync: Pedir que os dados sejam gravados “de verdade” no disco leva de 0,1 ms a dezenas de ms por chamada, conforme o disco, e, quando os pedidos se acumulam, a fila cresce. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Esgotamento dos créditos de burst do disco na nuvem: Alguns discos na nuvem e instâncias pequenas têm créditos de burst, que permitem passar do desempenho base por um tempo; quando o período de uso intenso se prolonga e os créditos acabam, a velocidade cai de repente. (Infraestrutura de servidores (Equipe de infraestrutura))
Limite de IOPS e saturação da fila: Quando as requisições passam do que o disco consegue atender em 1 segundo, a fila cresce e a latência dispara. (Infraestrutura de servidores (Equipe de infraestrutura))
Backup, compressão e varreduras: Quando backups de madrugada, compressão de logs e varreduras de segurança monopolizam o disco, as leituras e escritas do servidor do jogo ficam na fila. (Infraestrutura de servidores (Equipe de infraestrutura))
Latência de seek do HDD: No HDD, a cabeça de leitura precisa se mover sobre o prato (seek), então cada leitura ou escrita de dados espalhados leva perto de 10 ms. (Infraestrutura de servidores (Equipe de infraestrutura))

L12 Banco de dados

Query sem índice: Sem índice, para achar as linhas que atendem à condição é preciso ler a tabela inteira (full scan). (Desenvolvimento do servidor (Equipe de desenvolvimento))
Contenção de lock em hot row: Quando todos tentam alterar a mesma linha (baú da guilda, item popular na casa de leilões, contador global do servidor), só um de cada vez consegue o lock. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Deadlock no banco de dados: Quando duas transações (operações do BD processadas como um bloco único) esperam, cada uma, pela linha em que a outra pôs lock, o BD cancela uma delas à força. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Esgotamento do pool de conexões: O número de conexões abertas com o BD é fixo; quando queries lentas ocupam as conexões, as demais requisições esperam. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Checkpoint e flush de log: O BD grava periodicamente no disco, de uma vez, as alterações acumuladas na memória, e nesse momento as queries ficam lentas. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Cache frio (logo após reiniciar): Quando o BD reinicia, o cache em memória está vazio, e por um tempo todas as leituras vêm do disco. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Avalanche de logins e queries N+1: Se carregar um personagem exige dezenas de consultas separadas, dezenas de milhares de logins simultâneos viram milhões de queries. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Jobs em lote pesados: Rodar com o jogo no ar o cálculo de rankings, o envio de correio em massa ou a limpeza de dados antigos ocupa locks e disco. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Cache stampede: Quando o cache de dados populares expira todo ao mesmo tempo, milhares de requisições caem de uma vez no BD. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Transação aberta por muito tempo: Uma transação aberta por muito tempo continua segurando locks, e o BD não consegue limpar as versões antigas dos dados (purge), então tudo vai ficando mais lento. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Comandos lentos no Redis: O Redis processa um comando de cada vez, então um único comando lento bloqueia todas as requisições que vêm atrás. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Query lenta por mudança no plano de execução: O código continua igual, mas, se o BD muda a forma de executar a mesma query (plano de execução), uma query que levava 2 ms ontem passa a levar centenas de ms hoje. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Lock de alteração de schema (DDL) em produção: Adicionar uma coluna ou um índice a uma tabela com o jogo no ar exige um lock por um instante, e só esse lock pode deixar esperando todas as requisições que usam a tabela. (Infraestrutura de banco de dados (Equipe de infraestrutura))

L13 Arquitetura e operação de servidores

Tráfego via gateway ou proxy: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Falha em cascata: Quando um serviço fica lento, os servidores que o chamam ficam presos esperando a resposta, e até funções sem relação com ele param. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Deploy e reinício: Quando os servidores são reiniciados para uma atualização sem transferir as conexões, os jogadores daquele servidor são desconectados, e os salvamentos logo antes do desligamento e as reconexões chegam todos de uma vez. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Excesso de macros e bots: Bots mandam requisições com muito mais frequência que pessoas e consomem a capacidade de processamento do servidor. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Erro de matchmaking ou de atribuição de região: Quando o jogador é mandado para um servidor de uma região distante, mesmo havendo uma região próxima, só o ping dele fica sempre alto, ainda que a conexão esteja boa. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Design de sincronização

Feedback só depois da resposta do servidor (requisição-resposta): Ao apertar o botão, não há animação nem som até a resposta do servidor chegar. O ping vira o tempo de resposta. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Protocolo com muitas idas e voltas em sequência (chatty): Se uma única ação precisa de várias idas e voltas ao servidor, uma depois da outra, o ping é multiplicado por esse número. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Sem buffer de comandos para skills: Se a próxima skill só pode ser usada depois que o servidor confirma o fim da anterior, cada combo ganha um tempo de ida e volta no meio. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Janela de tempo curta consumida pelo ping: Quando o tempo para reagir é curto, como em esquiva, parry ou defesa, o ping consome esse tempo e surgem ataques impossíveis de evitar. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Lockstep esperando o jogador mais lento: Em uma arquitetura em que todos calculam juntos o mesmo turno, se o input de um jogador atrasa, todos esperam. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Espera dupla de tick: Se a requisição espera até o próximo tick para ser processada e o resultado também só sai no tick seguinte, o intervalo entre ticks se soma duas vezes. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Problemas que só afetam alguns

Tamanho do buffer de input por jogador: Se o servidor acumula um pouco os inputs de cada jogador e consome um por tick, os outros veem tudo suave, mas a ação do próprio jogador é confirmada no servidor mais tarde, na mesma medida. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Um membro da party com lag e a mecânica do boss: Em mecânicas de raid em que todos precisam reagir juntos em um momento definido, a reação atrasada de um jogador com lag vira falha da party inteira. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Personagem com dados grandes demais: Um personagem com milhares de itens ou mensagens no correio acumulados, ou com listas de amigos e bloqueados ou buffs fora do comum, tem várias vezes mais dados para carregar no login, salvar e enviar aos jogadores próximos. Fica lento só com esse personagem, seja qual for a conexão. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Orçamento de envio e prioridade por conexão: Se o servidor limita quanto envia por conexão e manda primeiro o que está mais perto, o lado com limite mais baixo recebe tarde, ou nunca recebe, os NPCs distantes. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Causas-raiz da retransmissão TCP

Descarte de pacotes no servidor receptor: O pacote chega ao servidor, mas é descartado porque o ring buffer da NIC (o buffer que guarda por um momento os pacotes que chegam) estourou ou porque o núcleo que faz o processamento de recepção no kernel está saturado. (Infraestrutura de servidores (Equipe de infraestrutura))
Retransmissão espúria por pico de latência: O pacote só chegou muito atrasado por um instante, sem se perder. Mesmo assim, se o atraso passa do RTO, quem envia considera o pacote perdido e retransmite. (Externo (Externo))
Retransmissão rápida espúria por pacotes fora de ordem: Quando a ordem dos pacotes muda ao passar por vários caminhos ou links agregados, quem recebe avisa com ACKs duplicados que “falta um pacote”, e quem envia reenvia um pacote que tinha chegado sem problema. (Infraestrutura de rede (Equipe de infraestrutura))
ACKs atrasados ou perdidos (upload saturado): Os dados chegaram bem, mas, se o ACK de “recebido” atrasa ou se perde na fila de upload lotada, quem envia considera o pacote perdido e retransmite. (Externo (Externo))
Configuração de RTO inadequada para o ambiente: Com o RTO mínimo baixo demais, qualquer pequeno atraso gera retransmissões espúrias; já o padrão (200 ms) é longo demais para um jogo, e cada perda deixa a conexão parada por muito tempo. (Infraestrutura de servidores (Equipe de infraestrutura))

Ver o catálogo de sintomas ilustrado