En un modelo en el que el hilo no puede hacer nada más mientras espera a un socket, todo se vuelve más lento a medida que aumentan los jugadores.
Por qué Se espera la lectura y la escritura conexión por conexión → Efecto El retraso de una conexión se contagia a las demás conexiones del mismo hilo → En pantalla Cuantos más jugadores conectados, más cámara lenta e input lag para todos
Cuando se junta mucha gente, Horas pico de la noche
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Pasar a E/S asíncrona basada en epoll, IOCP o io_uring.
En el gráfico
Sube con la carga · Tiempo de respuesta, número de hilos
Dónde mirar
Número de hilos del servidor del juego y cambios de contexto voluntarios por hilo (cswch/s, veces que se detuvo para esperar un recurso) con pidstat -w -t, comparados con el tiempo de respuesta según los jugadores conectados
Se confirma si
Al subir los jugadores conectados, el tiempo de respuesta se dispara, y la mayoría de los hilos, que crecen al ritmo de las conexiones, tienen muchos cambios voluntarios y apenas usan CPU (esperan al socket)
Se descarta si
Si los hilos usan CPU sin parar y sin esperas, es una sobrecarga de cálculo (“Tick que excede su presupuesto”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
epoll(7) — Linux manual pageLinux man-pages Notificación de eventos de E/S que escala para vigilar muchos fd a la vez
I/O Completion PortsMicrosoft Modelo de Windows que procesa mucha E/S asíncrona con un pool de hilos creado de antemano
pidstat(1) — Linux manual pagesysstat cswch/s de -w: cambios de contexto voluntarios (el hilo se detiene por sí mismo para esperar un recurso); con -t, por hilo