Ficha del soak 2 — 1 hora, Render 1 CPU / 2 GB — 2026-10-10
| Campo | Valor |
|---|---|
| Objetivo | Medir la mejora de rendimiento con el nuevo cómputo de Render, con el mismo perfil del soak 1 |
| Entorno | Producción, que hace de staging: https://www.proyectonara.com → Vercel → nara-api en Render → Atlas nara |
| Versión | nara-api 00f1e6d (dep-db555k49v7es738ov8vg, incluye rc3) · nara-web main c2107c0 · Render plan 1c-2g (1 CPU / 2 GB) |
| Autorización | pruebas/autorizaciones.md, fila «Soak 2» |
| Perfil | Igual al soak 1: 20 usuarios simultáneos, rol clínico (TRL-QA-20261010-clin), GET /api/auth/me, /api/patients y /api/people en bucle |
| Duración | 1 h de meseta con 20 usuarios (más 5 min de subida). Programado a 1 h 50 min y detenido a mano al cumplir 1 h (11:13:11, hora de Bogotá), para comparar con el soak 1 |
| Periodo | 10:08:16 a 11:13:11 (hora de Bogotá); 15:08:16 a 16:13:11 UTC |
| Generador | Este portátil (k6 v2.2.0) |
| Cómo se calculó el resumen | Al detener el proceso, k6 no escribe resumen.json; todas las cifras salen de series.csv, que guarda cada medición en el momento |
Resultado del lado del cliente (k6, meseta de 1 h)
| Medida | Soak 2 (1 CPU / 2 GB, rc3) | Soak 1 (0,5 CPU / 512 MB) | Umbral | Estado del soak 2 |
|---|---|---|---|---|
| Peticiones | 36.159 en 1 h 5 min (≈ 9,3/s) | 35.858 en 4 h 10 min (≈ 2,4/s) | — | — |
| Tasa de error | 0 % (0 de 36.159) | 0,003 % | < 1 % | Pasa |
| p50 | 234 ms | 8.660 ms | — | — |
| p95 | 286 ms | 12.240 ms | < 2 s | Pasa |
| p99 | 402 ms | — | — | — |
| Máximo | 1.336 ms | 18.200 ms | — | — |
| Degradación del p95 (primer cuarto de hora contra el último) | +3,1 % (282 → 291 ms) | +0,8 % (hora 2 contra hora 4) | ≤ 10 % | Pasa |
Por cuarto de hora (meseta): p95 de 282, 291, 281 y 291 ms; p50 de 231, 235, 232 y 236 ms.
Lado del servidor (Render, servidor_cpu.json y servidor_memoria.json)
| Tramo (UTC) | CPU media (máx) | Memoria media (máx) |
|---|---|---|
| 15:00 (línea base y subida) | 0,035 (0,046) | 478 MB (553 MB) |
| 15:10 | 0,056 (0,071) | 538 MB (570 MB) |
| 15:20 | 0,054 (0,065) | 549 MB (569 MB) |
| 15:30 | 0,040 (0,044) | 466 MB (496 MB) |
| 15:40 | 0,037 (0,050) | 510 MB (521 MB) |
| 15:50 | 0,037 (0,046) | 526 MB (527 MB) |
| 16:00 | 0,037 (0,040) | 527 MB (528 MB) |
| 16:10 | 0,033 (0,040) | 526 MB (527 MB) |
La API de Render reporta 2 series de instancia en el periodo; la tabla usa la primera.
Lectura
- Mejora de rendimiento: con el mismo perfil, el p95 bajó de 12,2 s a 286 ms (≈ 43 veces menos) y el throughput se multiplicó por ≈ 3,9, porque cada usuario ya no espera respuestas de 8 a 12 s. Pasa el umbral de p95 < 2 s, que el soak 1 no cumplía.
- Holgura del servidor: la CPU usa entre el 3 % y el 6 % de 1 CPU (en el soak 1 estaba topada en ≈ 0,1). La memoria se estabiliza en ≈ 527 MB de 2 GB (26 %), sin tendencia creciente en la última media hora.
- Qué cambió entre los dos soaks: el plan de Render (0,5 CPU / 512 MB → 1 CPU / 2 GB) y el código (861be00 → 00f1e6d, con rc3). Las rutas medidas (
/api/patientsy/api/people) no cambiaron en rc3, así que la mejora se atribuye al cómputo. - Limitaciones: dura 1 h (la decisión vigente pide más de 3 h para el criterio 6.7, así que este soak es comparativo y no reemplaza esa regla); un solo rol; el generador es el mismo portátil; con menos de 2 horas completas no se puede hacer la comparación hora contra hora de
analizar-soak.js, por eso la degradación se mide por cuartos de hora.