Un cuadro de mando lento: dónde medir antes de ampliar infraestructura

Cuando un informe tarda demasiado en abrirse, es fácil concluir que falta potencia. Sin embargo, el retraso puede estar en una consulta que multiplica filas, en un modelo que transporta columnas innecesarias o en una página que solicita demasiados gráficos a la vez. Comprar más capacidad sin localizar el cuello de botella puede encarecer el servicio y apenas cambiar la experiencia. La mejora empieza con una medición que reproduzca el trabajo real de quienes usan el cuadro de mando.

Define qué experiencia quieres mejorar

Distingue la apertura inicial, la aplicación de filtros, la navegación entre páginas y la actualización de los datos. Son tiempos diferentes y pueden tener causas distintas. Acuerda un objetivo de uso razonable para cada operación y mide varias ejecuciones. Incluye una sesión sin caché y otras en condiciones habituales. Si solo se prueba el informe recién abierto por su desarrollador, puede quedar fuera el escenario de un usuario remoto o de una mañana con varios equipos consultándolo simultáneamente.

Localiza en qué etapa se consume el tiempo

Recoge el tiempo de la consulta, el volumen transferido y el tiempo de representación. Revisa también si el origen está esperando bloqueos o si existe una carga simultánea que compite por recursos. Un gráfico aparentemente sencillo puede lanzar varias consultas o repetir cálculos que ya realiza otro elemento. Relacionar la medición con la acción del usuario permite decidir si conviene tocar la base de datos, el modelo analítico, la página o la planificación de las actualizaciones.

No pruebes únicamente un filtro cómodo. Una vista limitada a la última semana puede funcionar bien mientras la opción de todo el histórico tarda demasiado. Prepara un pequeño conjunto de escenarios: periodo corto, periodo largo, unidad pequeña, unidad grande y selección sin resultados. Esa batería ayuda a verificar que la mejora es consistente y evita optimizar un caso excepcional que apenas representa el uso cotidiano.

Lee el plan antes de añadir índices

PostgreSQL ofrece EXPLAIN para inspeccionar cómo planea ejecutar una consulta. Su variante con ANALYZE ejecuta realmente la operación y permite comparar estimaciones con resultados, por lo que exige precaución cuando hay escrituras o cargas costosas. Busca diferencias importantes entre filas esperadas y reales, uniones que amplifican conjuntos y trabajo repetido. Un índice puede ayudar, pero también consume espacio y añade coste de escritura. Debe responder a consultas concretas y comprobarse con datos representativos.

Reduce lo que el informe necesita mover

Selecciona solo las columnas necesarias, limita el periodo inicial y evalúa agregaciones cuando el usuario no necesita detalle transaccional. No es equivalente mostrar una tendencia mensual que transportar cada evento individual para agruparlo en el navegador. Conserva una vía de detalle para investigar casos, pero evita cargarla de entrada. Revisa además conversiones de tipos y relaciones ambiguas: un modelo más claro puede mejorar simultáneamente la corrección del cálculo y su rendimiento.

• Identifica los gráficos que más consultas o tiempo consumen.
• Retira campos sin uso y comprueba el tamaño del modelo.
• Ajusta filtros iniciales a la tarea más frecuente.
• Evita repetir el mismo cálculo en varios puntos de la página.
• Compara cualquier agregación con el resultado original antes de publicarla.

Separa frescura y velocidad

Un requisito de datos al minuto puede obligar a consultar el origen constantemente, aunque la decisión se tome una vez al día. Pregunta qué antigüedad máxima resulta aceptable y utiliza ese acuerdo para elegir actualización, caché o consulta directa. Si se reutiliza un resultado, comunica la hora a la que corresponde. La caché puede mejorar tiempos, pero no debería esconder que una fuente lleva horas sin actualizarse ni mezclar respuestas de usuarios con permisos distintos.

Comprueba el resultado y deja una referencia

Después de modificar una consulta o un modelo, compara cifras, filtros y permisos además del tiempo. Una optimización que elimina registros por accidente será rápida y equivocada. Guarda una referencia breve con escenario, volumen, configuración y tiempo observado. Si el informe vuelve a degradarse, esa información permite distinguir crecimiento natural, regresión o cambio de uso. Programa revisiones cuando aumente sustancialmente el volumen o aparezcan nuevas vistas; no hace falta convertir cada modificación visual en una campaña completa de rendimiento.

Ampliar recursos sigue siendo una decisión válida cuando las mediciones demuestran que la carga lo requiere. La diferencia es llegar a esa conclusión con un modelo razonable y consultas conocidas. Así puede estimarse qué mejora se espera y comprobarla después. El objetivo práctico es que el equipo consulte el informe mientras trabaja, sin exportar los datos a otras herramientas porque la espera interrumpe cada decisión.