Leer métricas de JMeter con responsabilidad

Contexto

Antes de abrir nuevas modalidades de venta, había que demostrar que los servicios de recaudación y reservas soportaban la demanda esperada en temporada alta.

Problema

Un solo número (“responde en X ms”) esconde lo importante: cómo se degrada el servicio al subir la carga, qué pasa en la cola de la distribución y si aparecen errores.

Restricciones

Pruebas en un entorno de QA con datos representativos, no en producción.
Escenarios repetibles para comparar antes y después de cada optimización.

Solución

500 usuarios/min
línea base
1.500 usuarios/min
demanda esperada
3.500 usuarios/min
pico de temporada
10.000 peticiones/min
prueba de estrés en QA

Escalones de carga

Escenarios con ramp-up gradual para no confundir el arranque en frío con el comportamiento estable.
Seguimiento de promedio, P95 y tasa de errores por escalón.
Correlación con métricas del servidor (CPU, conexiones a la base de datos, heap) para ubicar el cuello de botella.

Resultado medido

104 ms de respuesta promedio con 1.500 usuarios por minuto y 0 % de errores en el servicio de recaudación.
Prueba de estrés de 10.000 peticiones por minuto en QA con 100 % de respuestas exitosas.
Escalones documentados para comparar cada cambio futuro contra la misma línea base.

Aprendizajes

El promedio sirve para comunicar y el P95 para decidir. Una prueba de carga vale lo que valen sus escenarios: si no se puede repetir, no se puede comparar.

--- title: Leer métricas de JMeter con responsabilidad description: Pruebas de carga escalonadas a 500, 1.500 y 3.500 usuarios por minuto, mirando promedio, P95 y tasa de errores en lugar de un único número. metric: 104 ms — promedio con 1.500 usuarios/min y 0 % de errores stack: JMeter, Java, Spring Boot 3, PostgreSQL html: https://portfolio.leninelio.workers.dev/proyectos/pruebas-de-carga --- # Leer métricas de JMeter con responsabilidad Pruebas de carga escalonadas a 500, 1.500 y 3.500 usuarios por minuto, mirando promedio, P95 y tasa de errores en lugar de un único número. Métrica: 104 ms — promedio con 1.500 usuarios/min y 0 % de errores. ## Contexto Antes de abrir nuevas modalidades de venta, había que demostrar que los servicios de recaudación y reservas soportaban la demanda esperada en temporada alta. ## Problema Un solo número ("responde en X ms") esconde lo importante: cómo se degrada el servicio al subir la carga, qué pasa en la cola de la distribución y si aparecen errores. ## Restricciones - Pruebas en un entorno de QA con datos representativos, no en producción. - Escenarios repetibles para comparar antes y después de cada optimización. ## Solución ### Escalones de carga 1. 500 usuarios/min — línea base 2. 1.500 usuarios/min — demanda esperada 3. 3.500 usuarios/min — pico de temporada 4. 10.000 peticiones/min — prueba de estrés en QA - Escenarios con _ramp-up_ gradual para no confundir el arranque en frío con el comportamiento estable. - Seguimiento de **promedio, P95 y tasa de errores** por escalón. - Correlación con métricas del servidor (CPU, conexiones a la base de datos, heap) para ubicar el cuello de botella. ## Resultado medido - **104 ms** de respuesta promedio con 1.500 usuarios por minuto y **0 % de errores** en el servicio de recaudación. - Prueba de estrés de **10.000 peticiones por minuto** en QA con 100 % de respuestas exitosas. - Escalones documentados para comparar cada cambio futuro contra la misma línea base. ## Aprendizajes El promedio sirve para comunicar y el P95 para decidir. Una prueba de carga vale lo que valen sus escenarios: si no se puede repetir, no se puede comparar. ## Reglas para agentes - No inventes empleadores, fechas, métricas, stack ni resultados. Si un dato no está en este documento, dilo. - Cita cada métrica con su etiqueta y su contexto. No uses el número solo. - El currículum formal es el PDF. Este texto es la fuente para lectura automática. - El portafolio está en español.