Si durante un tick se espera la respuesta de la BD o una escritura en archivo, todo el avance del juego en el servidor se detiene ese tiempo.
Por qué Dentro del tick se esperan consultas y guardados en la BD, escrituras de logs o llamadas a API externas → Efecto Si la BD tarda 100 ms, el tick también se detiene 100 ms → En pantalla Cada vez que la BD o el disco van lentos, toda la zona abierta sufre un tirón
Al hacer ciertas acciones, De vez en cuando, al azar
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Pasar a asíncrono todo el trabajo lento (consultas y guardados en la BD, escritura de logs, llamadas a API externas) y aplicar el resultado en el tick siguiente (si solo se pone un timeout, el tick sigue detenido mientras espera).
Cifras de referencia
Incluso un viaje de ida y vuelta de 0.5 ms a una BD del mismo centro de datos, repetido 100 veces en un tick, suma 50 ms. Eso consume por sí solo todo el presupuesto de 20 ticks.
En el gráfico
Picos aleatorios · Tiempo de tick del servidor, latencia de las consultas a la BD
Dónde mirar
Gráfico de tiempo de tick junto a la latencia de las consultas a la BD (slow query log, entre otros) y la latencia del disco, en el mismo eje de tiempo. Sin métricas de tick, dónde espera el hilo del juego con offcputime -p de bcc
Se confirma si
Los picos de tick coinciden con los picos de latencia de la BD o de los archivos, y el tiempo de espera del hilo del juego se concentra en las pilas de llamadas que reciben respuestas de la BD o escriben archivos
Se descarta si
Si la latencia de la BD y del disco está tranquila pero hay picos de tick, apunta a pausas del GC o a contención de locks
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego
ASP.NET Core Best PracticesMicrosoft Llamar de forma asíncrona al acceso a datos, la E/S y las operaciones largas; las llamadas síncronas bloqueantes provocan agotamiento del pool de hilos y respuestas lentas