Semillero/semillero-INVIMA
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
master
semillero-INVIMA/benchmarks/INFORME_RENDIMIENTO.md

8.3 KiB
Raw Permalink Blame History

Informe de rendimiento INVIMA

Generado: 2026-07-12T23:11:54.172Z

1. Infraestructura

Infraestructura minima de referencia declarada: 4 GB RAM, 2 vCPU compartidas, 80 GB de almacenamiento, 4 TB de transferencia mensual y red nominal de hasta 40 Gbps de entrada / 4 Gbps de salida. Las versiones reales del entorno se registran con npm run benchmark:resources en benchmarks/results/resource_snapshot.json.

2. Condiciones de prueba

El protocolo completo usa 5 repeticiones de calentamiento por consulta, 100 repeticiones medidas por cada una de las siete consultas y 100 solicitudes por cada nivel de concurrencia (1, 5, 10, 25, 50 usuarios virtuales). El calentamiento no se incluye en metricas.

3. Estado del servidor antes de iniciar

Ver benchmarks/results/resource_snapshot.json. Si el archivo no existe, ejecute npm run benchmark:resources.

4. Consultas evaluadas

ID Consulta Grupo Endpoint asociado
query_01 COUNT total de invima_api_catalog estructurada GET /api/invima/sync/stats
query_02 Catalogo general paginado LIMIT 25 estructurada GET /api/invima/catalogo?limit=25&offset=0
query_03 Conteo de dispositivos estructurada SQL directo de evaluacion
query_04 Conteo de dispositivos vigentes estructurada SQL directo de evaluacion
query_05 Filtro dispositivos vigentes LIMIT 25 estructurada GET /api/invima/catalogo?datasets=dispositivos&onlyVigentes=true&limit=25&offset=0
query_06 Busqueda textual real del backend para marcapasos LIMIT 25 busqueda_textual GET /api/invima/catalogo?q=marcapasos&limit=25&offset=0
query_07 Conteo de busqueda textual real para marcapasos busqueda_textual GET /api/invima/catalogo?q=marcapasos&limit=25&offset=0 ejecuta conteo interno

5. Metodologia

Cada ejecucion usa EXPLAIN (ANALYZE, BUFFERS, VERBOSE, FORMAT JSON), registra latencia total de la operacion SQL, tiempos de planeacion y ejecucion de PostgreSQL, filas estimadas y reales, buffers, estado de exito o fallo, CPU/memoria del proceso de benchmark y conexiones activas a PostgreSQL. Los campos de HTTP quedan como SQL_ONLY porque estas siete consultas fueron identificadas como mediciones SQL representativas; los endpoints asociados se documentan para trazabilidad.

6. Resultados por consulta - linea base

Consulta Grupo n Promedio ms p95 ms p99 ms CV Fallos Throughput/s Criterio
query_01 estructurada 100 180,8483 221,0414 224,5531 13,3858 % 0 5,5463 Cumple latencia estructurada
query_02 estructurada 100 0,7436 1,5573 1,7209 45,2219 % 0 465,1163 No cumple latencia estructurada
query_03 estructurada 100 62,1545 152,5783 160,9022 73,9718 % 0 16,0565 No cumple latencia estructurada
query_04 estructurada 100 336,9629 378,5169 440,6483 8,1322 % 0 2,9818 Cumple latencia estructurada
query_05 estructurada 100 358,2494 387,7051 400,0415 5,6379 % 0 2,8108 Cumple latencia estructurada
query_06 busqueda_textual 100 58,9326 63,0636 64,1303 6,0973 % 0 16,5673 Cumple latencia textual
query_07 busqueda_textual 100 55,7683 60,3065 61,3194 5,4861 % 0 17,4551 Cumple latencia textual

7. Resultados de concurrencia

Usuarios Consulta n Promedio ms p95 ms Fallos Throughput/s
1 query_01 15 162,091 188,2455 0 0,8095
1 query_02 15 8,1895 10,317 0 0,8091
1 query_03 14 85,0922 167,6209 0 0,8153
1 query_04 14 273,713 298,8697 0 0,8217
1 query_05 14 296,5542 324,1339 0 0,8164
1 query_06 14 41,1734 46,6509 0 0,8203
1 query_07 14 26,717 29,6636 0 0,8206
5 query_01 15 247,5794 358,828 0 2,9297
5 query_02 15 15,2027 24,1378 0 2,9143
5 query_03 14 69,9716 175,6754 0 2,8513
5 query_04 14 513,248 692,9919 0 2,8346
5 query_05 14 544,4535 885,0376 0 2,7978
5 query_06 14 60,2426 73,7649 0 2,7767
5 query_07 14 52,3304 66,0039 0 2,805
10 query_01 15 587,9522 997,1856 0 3,9093
10 query_02 15 19,77 27,073 0 3,874
10 query_03 14 65,1973 128,5397 0 3,8642
10 query_04 14 759,8982 1.173,3659 0 3,7645
10 query_05 14 764,3358 1.213,4999 0 3,7175
10 query_06 14 70,4471 91,1849 0 3,7665
10 query_07 14 60,9191 91,6887 0 3,876
25 query_01 15 897,0712 1.345,1214 0 4,7589
25 query_02 15 21,7858 79,3087 0 4,8765
25 query_03 14 119,665 388,4036 0 4,8276
25 query_04 14 1.634,4797 2.308,0738 0 4,8093
25 query_05 14 1.681,5317 2.426,8691 0 4,5692
25 query_06 14 87,642 133,2468 0 4,5767
25 query_07 14 88,2408 138,4633 0 4,5797
50 query_01 15 1.233,3936 1.800,638 0 5,6775
50 query_02 15 18,209 54,6435 0 6,1551
50 query_03 14 390,1372 1.213,9514 0 5,5031
50 query_04 14 1.919,628 2.568,4577 0 5,283
50 query_05 14 2.087,0267 2.686,7188 0 5,9473
50 query_06 14 118,3391 233,0683 0 6,4015
50 query_07 14 111,4119 327,4249 0 5,4117
1 agregado 100 126,797 294,5365 0 5,333
5 agregado 100 213,0518 590,6394 0 18,9861
10 agregado 100 332,07 950,6843 0 25,8264
25 agregado 100 643,4468 2.060,2028 0 31,5358
50 agregado 100 835,4564 2.308,4586 0 37,594

8. Recursos

Los resultados crudos incluyen CPU del proceso, memoria RSS, operaciones de lectura/escritura reportadas por Node.js y conexiones activas. Para CPU/RAM del servidor y PostgreSQL se debe complementar con herramientas del sistema operativo si se requiere granularidad por proceso.

9. EXPLAIN ANALYZE

Cada fila cruda conserva planeacion, ejecucion, filas estimadas/reales y buffers. Para conservar el plan JSON completo, use una corrida puntual con BENCHMARK_REPETITIONS=1 o exporte desde PostgreSQL si se requiere auditoria completa de planes.

10. Optimizaciones aplicadas

Las optimizaciones reversibles estan en benchmarks/migrations/optimization_up.sql y benchmarks/migrations/optimization_down.sql. Incluyen indices B-tree para orden/filtros frecuentes, indices GIN trigram para los campos usados por ILIKE '%marcapasos%', aumento de estadisticas por columna y ANALYZE.

11. Comparacion antes/despues

Consulta Grupo n Promedio ms p95 ms p99 ms CV Fallos Throughput/s Criterio
query_01 estructurada 100 189,6095 228,973 232,9723 12,2207 % 0 5,2851 Cumple latencia estructurada
query_02 estructurada 100 1,2464 2,0078 2,2535 39,9475 % 0 343,6426 No cumple latencia estructurada
query_03 estructurada 100 64,6984 158,8514 175,4067 71,8252 % 0 15,223 No cumple latencia estructurada
query_04 estructurada 100 339,9853 383,8868 438,182 7,1143 % 0 2,959 Cumple latencia estructurada
query_05 estructurada 100 360,2395 391 393,1633 5,3055 % 0 2,7926 Cumple latencia estructurada
query_06 busqueda_textual 100 61,0332 68,2614 75,1879 7,21 % 0 15,873 Cumple latencia textual
query_07 busqueda_textual 100 58,6218 65,3004 72,1182 6,7621 % 0 16,5893 Cumple latencia textual

12. Criterios cumplidos y no cumplidos

No se declara cumplimiento sin resultados crudos. Cuando existan CSV completos, esta seccion debe leerse junto con las columnas criterio, failure_rate_percent, latency_p95_ms y latency_p99_ms.

13. Limitaciones

  • Las siete consultas representan mediciones SQL; el tiempo HTTP real requiere ejecutar el backend, autenticar y medir endpoints con token.
  • La busqueda textual real combina FTS con varios ILIKE, lo cual puede ser costoso.
  • Ejecutar 1 200 operaciones completas puede tardar mucho si las busquedas textuales mantienen tiempos del orden de decenas de segundos.
  • EA, MSE, precision y exhaustividad no calculables por ausencia de un conjunto de referencia validado.

14. Recomendaciones

  • Ejecutar primero una prueba corta con BENCHMARK_REPETITIONS=1 BENCHMARK_CONCURRENCY_REQUESTS=7.
  • Ejecutar el protocolo completo en una ventana controlada.
  • Revisar planes de query_06 y query_07 antes y despues de los indices trigram.
  • Considerar una refactorizacion futura de busqueda textual para usar una columna tsvector persistida o una estrategia de union controlada, sin eliminar campos validos.