Rendimiento del listado y del dashboard

El listado de incidentes es la consulta más usada y la que más crece. Sus índices se validaron con EXPLAIN sobre 100.000 incidentes generados por el seeder de volumen, en la misma base MySQL 8.4 del proyecto.

Cómo se mide

1. Cargar la base de pruebas con volumen (alrededor de un minuto, porque cada incidente trae su historial: unas 520.000 filas en incident_activities):

   docker compose -p trazo exec -e DB_DATABASE=trazo_test -e SEED_INCIDENTS=100000 app php artisan migrate:fresh --seed --force

2. Ejecutar el script de medición, que corre el listado real y pide el EXPLAIN del conteo y de la página:

   docker compose -p trazo exec -e DB_DATABASE=trazo_test app php artisan tinker --execute "require base_path('database/benchmarks/explain-incident-list.php');"

3. Para el dashboard, el script mide cada fuente de datos sin caché, para quien ve todo, un agente y un solicitante:

   docker compose -p trazo exec -e DB_DATABASE=trazo_test app php artisan tinker --execute "require base_path('database/benchmarks/explain-dashboard.php');"

Cada escenario se ejecuta tres veces y se reporta el mejor tiempo: en Docker sobre Windows una sola medición tiene mucho ruido (la misma consulta, con el mismo plan, puede tardar el triple de una vez a otra).

La suite de pruebas vuelve a crear esa base desde cero en su siguiente ejecución, así que no queda nada que limpiar.

Resultados (100.000 incidentes, caché caliente)

Cada listado hace dos consultas importantes: el conteo (para el total y las páginas) y la página (20 filas). Las demás son de catálogos y relaciones, y no crecen con el volumen.

Lista agrupada (ADR-0080). En lugar del conteo general hay un conteo por grupo, y la página sale de una consulta corta por cada grupo que la toca:

La primera versión ordenaba todo lo filtrado por grupo (ORDER BY CASE …) y tardaba de 130 a 300 ms sin filtros: el orden por una expresión obliga a MySQL a ordenar todas las filas. El conteo por prioridad se agrupa por estado y prioridad, y se suma en PHP: así lo cubre el índice dashboard_counts; agrupado solo por prioridad, MySQL elegía el índice de priority_id, que no tiene deleted_at, y leía cada fila (142 ms).

Todos los escenarios responden en menos de 100 ms con 100.000 incidentes.

Ajuste que salió de la medición

Los conteos también filtran por deleted_at (borrado lógico), y los índices de vencimiento no incluían esa columna. Por eso MySQL tenía que leer cada fila para comprobarla. La migración 2026_10_22_000014 reemplazó:

Los índices nuevos empiezan igual que los anteriores, así que los reemplazan sin perder ningún uso. Los resultados:

• El conteo de vencidos bajó de 27 ms a 3 ms.
• El del rango de vencimiento bajó de 18 ms a 10 ms.
• El conteo general ahora se resuelve solo con el índice.

Lo que no se cambió, y por qué

• El conteo del agente recorría la tabla. Su filtro (propios, asignados o sin asignar) abarca el 40 % de las filas. Desde los índices del dashboard (abajo), se resuelve solo con el índice.
• El orden por prioridad u estado ordena en memoria. Ordena por el nivel del catálogo (priorities.level), que vive en otra tabla. Copiar el nivel a incidents repetiría un dato, y la base de datos está normalizada. Con 17.000 filas filtradas, tarda 72 ms.
• Paginación por número de página. Pedir la página 4.000 de 5.000 es más lento que pedir la primera. Es lo que pide la prueba (page y per_page), y nadie recorre miles de páginas a mano: los filtros y la búsqueda acotan antes.

Las mejoras para un volumen mucho mayor (réplica de lectura, tabla resumen para los conteos y motor de búsqueda externo) están documentadas en ADR-0014.

Dashboard (100.000 incidentes, sin caché)

En uso real, cada fuente queda en caché hasta que cambia un incidente o pasan 60 segundos (ver Módulo Dashboard). Esta medición es el peor caso: la primera lectura después de un cambio.

Las tres últimas son del diseño centrado en el riesgo (ADR-0081), medidas en una corrida posterior con el mismo volumen; el pulso, el flujo y el balance reutilizan además el conteo por estado y prioridad y la tendencia.

Los datos de demostración reparten los incidentes en los últimos 60 días, así que con 100.000 hay unos 1.600 por día. Es mucho más que una mesa de ayuda normal, y sirve como peor caso:

• Todas las fuentes responden en menos de 100 ms, salvo la tendencia de 90 días (de 130 a 170 ms). Esa ventana abarca los 100.000 incidentes, y la consulta cuenta cada uno por hora. El tiempo depende de cuántos incidentes caen en la ventana, no del tamaño de la tabla.
• La tendencia queda en caché 60 segundos (o hasta el siguiente cambio), así que solo la paga la primera lectura.
• Si el volumen diario real se acercara a esa cifra, el paso siguiente es la tabla resumen por día ya prevista en ADR-0014: los días pasados no cambian y se contarían una sola vez.
• Para el solicitante, la base usa created_by y lee sus filas: son pocas.

Índices que salieron de la medición

La primera medición mostró tres consultas lentas:

• La carga por agente recorría la tabla entera (560 ms).
• El agente recorría la tabla en el conteo por estado y prioridad (260 ms): su visibilidad usa created_by y assigned_to, que no estaban en el índice.
• “Asignados a mí” (130 ms): MySQL recorría el índice de vencimientos completo, incluidos los cerrados, para no ordenar.

La migración 2026_10_23_000017 las resolvió:

Además, “asignados a mí” le indica a MySQL el índice dashboard_assignee (useIndex): ordenar los pendientes de una persona es mucho más barato que recorrer todos los vencimientos.

Efecto en el listado

Los índices nuevos empiezan igual que los anteriores, así que el listado no pierde ningún uso. Para compararlo se midió el listado con los índices anteriores y con los nuevos, seguidos y en las mismas condiciones (con la distribución de datos anterior, en la que el 60 % de los incidentes seguía pendiente):

Ese día la máquina estaba más cargada que en la primera medición del listado (arriba): el escenario más simple tardó 22 ms en lugar de 12 ms, sin cambios de código. Con esa carga, dos escenarios del listado superan los 100 ms con los índices anteriores y con los nuevos:

• El orden por prioridad, porque ordena en memoria (ver arriba).
• Los vencidos ordenados por vencimiento, porque MySQL recorre el índice de vencimientos desde los más antiguos, que en su mayoría están cerrados.

Quedan anotados como puntos a vigilar.

Revisión general (25 de octubre de 2026)

En la pasada de calidad (ADR-0060) se revisó todo lo construido después de estas mediciones.

Slow query log (más de 1 s), después de las corridas E2E y del escaneo activo de ZAP: ninguna consulta de la app. Las 32 anotadas son de las pruebas: borrar y truncar las tablas de trazo_test al empezar cada suite, y la inserción de 100.000 incidentes para medir la exportación.

Lista de eventos del sistema con 50.000 eventos (mejor de 3 intentos):

El EXPLAIN mostraba que MySQL empezaba por la tabla de tipos y ordenaba todo en una tabla temporal. Se cambió a LEFT JOIN (la clave foránea garantiza el tipo) y los filtros del tipo a una subconsulta: ahora empieza por los eventos. Sigue ordenando en memoria, pero con un volumen real mucho menor, porque los eventos se agrupan por huella y 50.000 serían 50.000 fallas distintas.

Exportación: 50.000 filas en 2,1 s con la memoria estable (Incidents).

Sin N+1 en ningún listado: incidentes, auditoría, dashboard, personas, roles y eventos del sistema tienen su prueba que compara las consultas con pocos y con muchos registros.

Front, sobre el build de producción:

• Carga inicial: unos 175 kB comprimidos.
  • JavaScript principal: 50 kB. Vue y Quasar: 27 kB. Estructura de la app: 38 kB. Mensajes y cliente HTTP: 22 kB.
  • CSS: 38 kB, casi todo de Quasar.
• Cada pantalla se descarga al entrar (entre 5 y 25 kB); el editor del dashboard (44 kB), solo al personalizar.
• Los tiempos del listado en celular incluyen la latencia del Docker local en Windows, de alrededor de 1 s por petición.

Dónde está en el código

• Consulta: EloquentIncidentList.php y IncidentFilters.php
• Migración: 2026_10_22_000014_extend_incident_due_indexes_with_deleted_at.php
• Scripts de medición: explain-incident-list.php y explain-dashboard.php
• Índices del dashboard: 2026_10_23_000017_add_dashboard_indexes_to_incidents.php y EloquentDashboardQueries.php
• Seeder de volumen: IncidentVolumeSeeder.php