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.
Por quê Cada conexão espera a leitura e a escrita → Efeito O atraso de uma conexão se espalha para as outras conexões da mesma thread → Na tela Quanto mais jogadores simultâneos, mais tudo fica em câmera lenta e com input lag
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Migrar para I/O assíncrono baseado em epoll, IOCP ou io_uring.
No gráfico
Sobe com a carga · Tempo de resposta, número de threads
Onde olhar
Ver com pidstat -w -t o número de threads do servidor do jogo e as trocas de contexto voluntárias por thread (cswch/s, quantas vezes parou esperando um recurso), e comparar com o tempo de resposta conforme o número de jogadores simultâneos
Confirma se
Com mais jogadores simultâneos, o tempo de resposta sobe de forma íngreme, e a maioria das threads (que cresceram junto com o número de conexões) só tem trocas voluntárias e quase não usa CPU (esperando o socket)
Descarta se
Threads usando CPU sem parar, sem esperar: sobrecarga de cálculo (“Estouro do tick”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
epoll(7) — Linux manual pageLinux man-pages Notificação de eventos de I/O que escala para vigiar muitos fds de uma vez
I/O Completion PortsMicrosoft Modelo do Windows que processa muito I/O assíncrono com um pool de threads criado de antemão
pidstat(1) — Linux manual pagesysstat cswch/s do -w: trocas de contexto voluntárias, quando a thread para sozinha esperando um recurso; -t mostra por thread