Ficha del soak — 2026-10-10
| Campo | Valor |
|---|---|
| Entorno | Producción tratada como staging (decisión de [dato real omitido]): https://www.proyectonara.com → Vercel → nara-api en Render → Atlas nara |
| Versión | nara-api 861be00 (dep-db4u4v6k1f9s73drilsg); instancia 0.5c-512mb según la API de Render, Ohio |
| Autorización | pruebas/autorizaciones.md, fila Soak |
| Perfil | 20 usuarios simultáneos, rol clínico (TRL-QA-20261010-clin), GET /api/auth/me, /api/patients y /api/people en bucle; 5 min de subida + 4 h + 5 min de bajada |
| Periodo | 03:09 a 07:20 (hora de Bogotá); 08:09 a 12:20 UTC |
| Generador | Este portátil (k6 v2.2.0) |
| Intento 1 | Descartado: el script no conservaba las cookies entre iteraciones y todo daba 401 desde la 2.ª vuelta. Se corrigió noCookiesReset en k6_estres_soak.js (evidencia en intento1_401_cookies/) |
Resultado del lado del cliente (k6)
| Medida | Valor | Umbral | Estado |
|---|---|---|---|
| Peticiones | 35.858 (2,4/s) | — | — |
| Tasa de error | 0,003 % (1 de 35.858, /api/patients, estado 0) |
< 1 % | Pasa |
| p95 de la duración | 12,24 s | < 2 s | Falla |
| Mediana | 8,66 s | — | — |
| Degradación p95 (hora 2 contra hora 4) | +0,8 % | ≤ 10 % | Pasa |
| Datos recibidos | 10 GB (≈ 830 KB por iteración) | — | — |
Tabla hora por hora: soak_por_hora.md.
Lado del servidor (Render, servidor_cpu.json y servidor_memoria.json)
| Hora UTC | CPU media (máx) | Memoria media (máx) |
|---|---|---|
| 07 (línea base, sin carga) | 0,008 (0,010) | 403 MB (405 MB) |
| 08 (subida) | 0,096 (0,335) | 482 MB (513 MB) |
| 09 | 0,107 (0,134) | 508 MB (517 MB) |
| 10 | 0,107 (0,133) | 511 MB (520 MB) |
| 11 | 0,104 (0,135) | 514 MB (522 MB) |
| 12 | 0,093 (0,134) | 516 MB (523 MB) |
No hubo reinicios ni despliegues durante el periodo (render-nara.js eventos).
Lectura
- Estable, pero saturado desde el inicio. No hay degradación en el tiempo ni errores. Sin embargo, la latencia ya es de 8 a 12 s en la primera hora: la instancia queda topada en unos 0,1 de CPU todo el periodo.
- Memoria al límite. Pasó de 403 MB a 508–523 MB, alrededor del 97 % de 512 MiB, y subió unos 2–3 MB por hora entre la hora 2 y la 4. En 4 h no alcanza a demostrar una fuga, pero el margen para picos es casi nulo.
- Respuestas pesadas.
/api/patientsy/api/peopledevuelven la lista completa (≈ 830 KB por iteración, sin paginar). Es la causa más probable de la CPU y la memoria. - Limitaciones. Se midió un solo rol, en el plan vigente, con el generador en el mismo portátil. Durante los últimos minutos el portátil compiló el laboratorio, lo que pudo sumar algo de latencia del lado del cliente.