Avalancha de inicios de sesión y consultas N+1 Login storm, N+1 queries
ID de la causa db-login-storm · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si cargar un personaje requiere decenas de consultas separadas, decenas de miles de inicios de sesión simultáneos se convierten en millones de consultas.
Por qué Al cargar un personaje se consultan por separado los objetos, las habilidades y las misiones → Efecto Justo después del mantenimiento, los inicios de sesión simultáneos disparan el número de consultas → En pantalla Carga infinita al iniciar sesión, e incluso los guardados de quienes ya están jugando se retrasan
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Agrupar las consultas en una sola, usar una cola de inicio de sesión y caché, revisar cuántas consultas genera la carga diferida del ORM.
Tareas (Equipo de infraestructura)
Sacar y compartir el ranking de las consultas más llamadas, monitorear el número de consultas y de conexiones durante los inicios de sesión justo después del mantenimiento.
En el gráfico
Avalancha tras la apertura · Consultas por segundo de la BD, número de inicios de sesión
Dónde mirar
Superponer los inicios de sesión justo después del mantenimiento y las consultas por segundo de la BD (en MySQL, el incremento de Questions) y calcular las consultas por cada inicio de sesión. Las consultas más llamadas se sacan con COUNT_STAR de events_statements_summary_by_digest en MySQL y con calls de pg_stat_statements en PostgreSQL
Se confirma si
Cada inicio de sesión genera decenas de consultas, y las más frecuentes son consultas cortas con la misma forma que buscan por un único ID de personaje. Si las consultas por inicio de sesión aumentaron tras un parche, ese parche es el punto de partida
Se descarta si
Si hay pocas consultas por inicio de sesión pero cada una es lenta, apunta a caché fría (db-cold-cache) o a índices (db-no-index)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
La carga diferida (lazy loading) de un ORM (biblioteca que genera automáticamente las consultas a la BD) crea este tipo de consultas sin que los desarrolladores lo noten. En el servidor de desarrollo, con unos pocos personajes, no se nota; aparece por primera vez con los inicios de sesión simultáneos en producción.
Fuentes
Efficient Querying.NET La carga diferida de un ORM genera el problema N+1, que envía una consulta adicional por cada elemento y degrada mucho el rendimiento; se recomienda cargar todo de una vez (eager loading)