Ficha — 6.5 · Estrés MODO=estres

• ID de prueba: K6-ESTRES-01 (criterio 6.5)
• Fecha y hora: 2026-10-10, 18:25:38 a 18:45:43 UTC (13:25 a 13:45 Bogotá)
• Ejecutado por: subagente ejecutor-pruebas-trl (Claude Opus 5.5), k6 2.2.0, desde el portátil de [dato real omitido] (red doméstica, una IP)
• Entorno: https://www.proyectonara.com (Vercel nara-web dpl_xNipoZa2zjPMm81K74kDN14p33Jn, main en 3596eeb) → nara-api dcef48e (toda la prueba; /api/health antes, durante y después: dcef48e; sin despliegues en Render entre 18:21:36Z y el final) → Atlas nara. Render 1c-2g, una instancia (…-kf244) sin reinicios durante la prueba.
• Autorización: pruebas/autorizaciones.md, fila «Estrés».
• Procedimiento: script original sin cambios pruebas/scripts_ajustados/k6_estres_soak.js, MODO=estres, ROL=clinico, cuenta prueba.clinico (territorio «Prueba», 10 pacientes). Rutas: /api/auth/me, /api/patients, /api/people. Rampas lineales de 3 min a 50, 100, 200, 300 y 400 VUs y bajada a 0 en 5 min. Comando: k6 run --summary-export=resumen_estres.json --out csv=series_estres.csv.gz -e MODO=estres -e ROL=clinico -e BASE_URL=https://www.proyectonara.com k6_estres_soak.js (claves por entorno con _herramientas/k6_run.js). Sonda externa cada 5 s a la web y a la API directa (sonda_externa.csv, con parada automática si aparecía X-Vercel-Mitigated: no apareció).
• Resultado: Parcial. Hay punto de quiebre por latencia y gráficas, pero no se pudo identificar con evidencia qué componente cedió primero, y el pico de errores se atribuye al generador, no a la plataforma.

Resultados (tramos de 30 s, analisis_30s.txt; gráfica grafica_estres.svg)

• Punto de quiebre por latencia: entre 111 y 127 usuarios simultáneos (p95 supera 2 s en el tramo que llega a 127 VUs). Con este perfil ligero (3 rutas, sin /api/app-state).
• Errores: 0 % hasta 344 VUs. Entre 18:39:00 y 18:41:29Z, 5.623 fallos, todos sin respuesta HTTP: connectex: A connection attempt failed…, A socket operation was attempted to an unreachable network, An established connection was aborted by the software in your host machine (códigos k6 1213/1000), contra las IPs de Vercel (64.29.17.65 y 216.198.79.65). En los mismos minutos, la sonda a la API directa en Render también falló (10,7 s de espera y un fallo local en 3 ms), Render registró la caída de su tráfico (3.382 → 1.867 → 16 peticiones/min a las 18:41) sin ningún 5xx, 401 ni 403, y la misma instancia siguió viva (CPU 0,15→0,01, memoria estable en 643 MB). Dos proveedores distintos inalcanzables a la vez y el error «aborted by the software in your host machine» apuntan a la red o la pila TCP del generador (portátil en red doméstica), no a la plataforma. No se puede descartar del todo un bloqueo de red en Vercel (no hay acceso a sus registros de firewall: el MCP no estaba conectado).
• Throughput máximo observado en Render: ≈ 3.300–3.380 peticiones/min (≈ 55/s) desde 277 VUs: la latencia crece en proporción a los VUs mientras el throughput se queda plano.
• Recursos de Render (../5.5_capacidad/estres_*.json): CPU máx. 0,218 de 1 CPU; memoria de 371 a 658 MB de 2 GB, sin reinicio. Ni CPU ni memoria de Render están saturadas cuando la latencia ya supera 2 s.
• Qué cedió primero: la latencia, con CPU de Render al 15–22 %. El cuello está después de la CPU del gateway: muy probablemente la base (Atlas) o un límite de concurrencia del camino gateway → microservicio → base (pool de conexiones, cola del proxy). No identificado con evidencia: no hay métricas de Atlas ni trazas por componente.

Evidencia

resumen_estres.json, resumen_estres_2026-10-10T18-45-43-152Z.json, k6_estres.log (resumen al final; código de salida 0 porque el único umbral del modo estrés es errores < 50 %), series_estres.csv.gz, analisis_por_minuto.json, analisis_30s.txt, grafica_estres.svg, sonda_externa.csv, ../5.5_capacidad/estres_cpu.json, estres_memoria.json, estres_peticiones.json, ../6.6_recuperacion/recuperacion_2026-10-10T18-25-47-383Z.*.

Limitaciones

• Un solo generador en red doméstica: no sostuvo 361–400 conexiones; el tramo alto no es válido para la plataforma. Repetir desde un generador en la nube (o varios).
• Perfil de un solo rol con 3 rutas ligeras, cuenta con 10 pacientes: no representa la mezcla real (la carga 5.4 muestra que /api/app-state tarda ≈ 1,2 s).
• El script sube en rampas lineales, no en escalones planos de 3 min como describe la guía: el «escalón» es el VU máximo de cada tramo de 30 s.
• Sin métricas de Atlas, sin latencia del lado de Render (metricas latencia falla).

Saturación de throughput ≈ 55 req/s con CPU al 20 % (cuello no identificado); generador insuficiente para 400 VUs.