Una herramienta de monitorización externa le informará de que el tiempo medio de respuesta de las 5 URL monitorizadas se ha duplicado en los últimos 30 minutos. El proyecto se ejecuta en un único servidor físico que no está bajo su gestión y se ejecuta en algún lugar de un centro de datos. Te conectas por SSH, inicias htop y ves que la carga de la CPU es del 95% y la memoria está desbordada desde hace tiempo.
Según git, sabes que hace una semana hicieron una migración de base de datos a una nueva estructura de tablas, y un compañero escribe en el chat que tuvo que ejecutar la migración durante la noche porque el recálculo de columnas e índices tardó unas 5 horas, durante las cuales casi toda la base de datos estaba bloqueada, y no funcionaban ni INSERT ni SELECT.
Así que los problemas de rendimiento probablemente se deban a índices mal diseñados, consultas SQL mal rediseñadas o grandes agrupaciones de conexiones. No hay tiempo para una reversión, hay 7 mil usuarios en el sitio según Google Analytics, y un corte de 5 horas significaría un riesgo reputacional para el cliente, y una pérdida de decenas a cientos de miles de coronas durante ese tiempo (es difícil de estimar, los proyeccionistas se inventan bastante). Se da cuenta de que probar sólo la funcionalidad en un entorno de prueba no es suficiente, y necesita implementar también una prueba de carga.
Como se trata de una importante tienda de comercio electrónico de su mayor cliente, y prevé que la situación puede empeorar, dispone de 30 segundos para tomar una decisión.
¿Cómo proceder?
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu:
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | es