Pruebas de carga: cómo interpretar p95, throughput y tasa de errores

Pruebas de carga: cómo interpretar p95, throughput y tasa de errores

Un reporte de pruebas de carga puede mostrar un tiempo promedio de respuesta aparentemente saludable mientras una parte relevante de los usuarios experimenta demoras o errores. Esta diferencia suele aparecer en sistemas de checkout, APIs de pago, plataformas SaaS y otros flujos críticos donde no basta con saber que “el promedio está bien”.

Para interpretar correctamente una prueba de carga es necesario analizar en conjunto la latencia por percentiles, el throughput, la concurrencia y la tasa de errores. También hay que relacionar esos datos con las métricas de la aplicación, la base de datos y la infraestructura. En este artículo veremos cómo hacerlo mediante un escenario hipotético con cifras expresamente ilustrativas, no comparables con benchmarks de mercado.

Qué información debería responder una prueba de carga

Una prueba de carga no debería limitarse a responder cuántas solicitudes por segundo soporta un servicio. El objetivo es entender cómo se comporta el sistema cuando aumenta la demanda y si ese comportamiento sigue siendo aceptable para los usuarios y para el negocio.

Un reporte útil debería permitir responder preguntas como:

• ¿Cuánto tarda una solicitud típica?
• ¿Qué experimentan los usuarios más lentos?
• ¿Cuántas operaciones procesa el sistema por unidad de tiempo?
• ¿En qué nivel de concurrencia comienzan a degradarse las respuestas?
• ¿Los errores aparecen de forma gradual o a partir de un umbral?
• ¿La causa está en la aplicación, la base de datos, una dependencia externa o la infraestructura?

Estas preguntas son más útiles que una conclusión binaria como “la prueba pasó” o “la prueba falló”. El resultado debe interpretarse contra objetivos explícitos: latencia máxima aceptable, volumen esperado, porcentaje de errores permitido y duración de la carga.

Cómo leer la latencia: promedio, mediana y percentiles

La latencia es el tiempo que transcurre desde que se inicia una solicitud hasta que se recibe su respuesta. Puede medirse en una API completa o en una operación específica, como crear una orden o confirmar un pago.

El promedio es fácil de entender, pero puede ocultar comportamientos importantes. Si la mayoría de las solicitudes responde rápido y unas pocas tardan mucho, el promedio puede no representar la experiencia de los usuarios afectados por esas demoras.

Mediana y percentiles

La mediana, también llamada p50, indica que la mitad de las solicitudes tardó menos o igual que ese valor y la otra mitad tardó más.

Los percentiles permiten observar distintos puntos de la distribución:

• p50: representa el punto central de las solicitudes.
• p90: muestra el tiempo que no supera el 90 % de las solicitudes; el 10 % restante tarda más.
• p95: muestra el tiempo que no supera el 95 % de las solicitudes; el 5 % restante tarda más.
• p99: ayuda a detectar una cola de latencia especialmente alta.

Por ejemplo, supongamos que una prueba hipotética sobre un checkout produce los siguientes resultados:

• Promedio: 420 ms.
• p50: 280 ms.
• p95: 1.400 ms.
• p99: 3.800 ms.

Estos valores son únicamente ilustrativos. El promedio podría parecer razonable, pero el p95 indica que una proporción de usuarios espera bastante más que el usuario representado por la media. El p99, además, sugiere una cola de solicitudes muy lentas que merece investigación.

El p95 no significa que cada usuario espere exactamente ese tiempo ni que el 95 % de las solicitudes tenga la misma duración. Significa que, dentro de la muestra observada, el 95 % de las solicitudes tardó como máximo ese valor y aproximadamente el 5 % tardó más.

Por qué observar la evolución de los percentiles

Un solo valor final puede ocultar el momento en que el sistema comenzó a degradarse. Conviene graficar p50, p95 y, cuando sea relevante, p99 a lo largo del tiempo y compararlos con la carga aplicada.

Si el p50 permanece estable pero el p95 aumenta progresivamente, puede existir saturación parcial, colas internas, contención de recursos o una dependencia que responde de forma irregular. Si aumentan simultáneamente el p50 y el p95, la degradación probablemente afecta a una parte más amplia del sistema.

Throughput, concurrencia y carga no significan lo mismo

Estos conceptos suelen aparecer juntos, pero describen dimensiones diferentes del comportamiento del sistema.

• Throughput: cantidad de operaciones procesadas por unidad de tiempo, por ejemplo solicitudes por segundo o órdenes por minuto.
• Concurrencia: cantidad de solicitudes o usuarios que están siendo atendidos al mismo tiempo.
• Carga: trabajo aplicado al sistema, que puede incluir usuarios virtuales, solicitudes, transacciones y su distribución en el tiempo.

Un sistema puede recibir muchas solicitudes por segundo con una concurrencia relativamente baja si responde rápidamente. También puede tener una concurrencia elevada y un throughput menor si las solicitudes permanecen mucho tiempo esperando.

Una aproximación útil para relacionar estas variables es la ley de Little:

concurrencia aproximada = throughput × latencia promedio

La relación ayuda a razonar sobre el comportamiento, pero no reemplaza la medición. En sistemas reales influyen los patrones de tráfico, las colas, los reintentos y la variabilidad de las respuestas.

Por ejemplo, en el checkout hipotético, el sistema podría procesar inicialmente 20 transacciones por segundo con 100 usuarios concurrentes. Al aumentar la carga a 40 transacciones por segundo, el throughput podría dejar de crecer mientras la latencia y la concurrencia aumentan. Esa señal indicaría que el sistema está acumulando trabajo pendiente en lugar de procesarlo con mayor capacidad.

Cómo detectar el punto de degradación

El punto de degradación es el nivel de carga a partir del cual aparecen cambios relevantes en latencia, errores o capacidad de procesamiento. No siempre coincide con una caída completa del servicio. Con frecuencia comienza antes, cuando el sistema sigue respondiendo, pero lo hace de manera menos predecible.

Una forma práctica de analizarlo es ejecutar varios escalones de carga y registrar los indicadores en cada uno:

• Carga inicial para establecer una línea base.
• Aumento gradual de usuarios o solicitudes.
• Periodo de estabilización en cada nivel.
• Observación de latencia, throughput, errores y recursos.
• Reducción de carga para comprobar si el sistema se recupera.

Imaginemos esta secuencia ilustrativa para una API de checkout:

• Con carga baja, el p95 permanece estable y no se observan errores relevantes.
• Al aumentar la concurrencia, el throughput crece de forma proporcional.
• En un nivel intermedio, el throughput deja de crecer y el p95 aumenta con rapidez.
• Con más carga, aparecen timeouts y respuestas de error.

La combinación de throughput estancado, latencia creciente y errores ascendentes suele indicar que se alcanzó o superó la capacidad efectiva de algún componente. El objetivo del análisis no es buscar un único número máximo, sino identificar qué cambia y por qué.

Errores que conviene diferenciar

La tasa de errores debe separarse por tipo. No es lo mismo una respuesta HTTP 400 causada por datos inválidos que un timeout provocado por saturación. También es diferente un error generado por la aplicación, una conexión rechazada o una respuesta fallida de un proveedor externo.

Al revisar el reporte, conviene clasificar al menos:

• Errores funcionales, como validaciones o reglas de negocio.
• Errores del servidor, como respuestas HTTP 5xx.
• Timeouts del cliente, gateway o servicio.
• Fallos de conexión o agotamiento de pools.
• Errores de dependencias externas.
• Reintentos que pueden multiplicar la carga real.

Una tasa de errores baja no implica necesariamente que el sistema sea saludable. Si los errores están concentrados en una operación crítica, como confirmar un pago, su impacto puede ser mayor que el de muchos errores distribuidos en operaciones secundarias.

Por qué hay que correlacionar el reporte con la observabilidad

Las métricas del generador de carga muestran lo que experimenta el cliente, pero normalmente no explican por sí solas la causa. Para diagnosticar es necesario correlacionarlas con métricas internas.

Métricas de la aplicación

• Tiempo de ejecución por endpoint y por operación interna.
• Uso y saturación de pools de conexiones o hilos.
• Colas internas y cantidad de solicitudes en espera.
• Frecuencia de pausas de garbage collection, cuando aplique.
• Reintentos, circuit breakers y fallos de dependencias.

Métricas de la base de datos

• Latencia de consultas.
• Consultas lentas y planes de ejecución.
• Conexiones activas y conexiones en espera.
• Bloqueos, contención y capacidad de lectura o escritura.
• Uso de CPU, memoria e I/O.

Métricas de infraestructura

• CPU, memoria y presión de almacenamiento.
• Red y límites de ancho de banda.
• Reinicios, escalamiento y distribución entre instancias.
• Colas de balanceadores o gateways.
• Señales de throttling o límites impuestos por la plataforma.

Por ejemplo, un aumento del p95 puede coincidir con un incremento en la latencia de consultas y en el uso del pool de conexiones de la base de datos. En ese caso, agregar instancias de la aplicación podría no resolver el problema y hasta aumentar la presión sobre la base de datos. La correlación evita aplicar optimizaciones basadas únicamente en síntomas.

Errores frecuentes al interpretar una prueba de carga

Concluir a partir del promedio

El promedio puede ocultar una cola de solicitudes lentas. Revisar p95 y p99 ayuda a entender qué ocurre con los usuarios más afectados, aunque siempre deben interpretarse junto con el tamaño y la calidad de la muestra.

Confundir más throughput con mejor resultado

Un aumento del throughput solo es positivo si la latencia, los errores y el consumo de recursos se mantienen dentro de los límites aceptables. Procesar más solicitudes a costa de timeouts o respuestas incorrectas no representa una mejora real.

Medir únicamente el endpoint aislado

Una API puede responder bien en una prueba independiente y degradarse dentro del flujo completo. El checkout, por ejemplo, puede involucrar inventario, cálculo de impuestos, pagos, persistencia y publicación de eventos. El patrón de carga debe representar, tanto como sea posible, las operaciones relevantes y sus proporciones.

Ignorar la duración de la prueba

Una prueba breve puede no revelar fugas de memoria, acumulación de conexiones, degradación progresiva o problemas asociados con tareas periódicas. La duración debe relacionarse con el riesgo que se quiere evaluar.

No validar la recuperación

Después de reducir la carga, conviene observar si la latencia y los errores vuelven a sus niveles anteriores. Una recuperación lenta puede revelar colas acumuladas, procesos pendientes o mecanismos de protección que no se restablecen correctamente.

Cómo convertir los resultados en decisiones técnicas

El reporte debería terminar en hipótesis verificables y acciones priorizadas, no solo en gráficos. Para cada señal relevante, conviene documentar:

• Qué métrica cambió y en qué nivel de carga.
• Qué operación o flujo fue afectado.
• Qué componente muestra una señal correlacionada.
• Qué hipótesis explica el comportamiento.
• Qué medición adicional puede confirmarla o descartarla.
• Qué riesgo existe si no se realiza ninguna modificación.

Si el p95 aumenta por consultas lentas, las acciones podrían centrarse en revisar índices, patrones de acceso, paginación o límites de concurrencia. Si el problema está en un proveedor externo, puede ser necesario analizar timeouts, reintentos, circuit breakers y estrategias de degradación controlada. Si la saturación está en la infraestructura, se deben revisar capacidad, escalamiento y límites operativos.

Ninguna de estas acciones debe asumirse como universal. Aumentar recursos puede ser apropiado cuando existe capacidad insuficiente, pero no corrige una consulta ineficiente ni un patrón de reintentos descontrolado. Del mismo modo, introducir caché puede reducir lecturas repetitivas, pero agrega requisitos de consistencia, invalidación y observabilidad.

Conclusión: interpretar la capacidad como un conjunto de señales

Una prueba de carga exitosa no se define únicamente por un promedio bajo ni por un throughput elevado. La evaluación debe considerar cómo evolucionan el p95 y otros percentiles, cuál es la capacidad efectiva, cuándo aparecen errores y qué componentes explican la degradación.

La decisión técnica debería basarse en la relación entre latencia, throughput, concurrencia, errores y recursos, comparada con los objetivos reales del producto. Solo así es posible distinguir entre un sistema que todavía tiene margen y otro que simplemente está acumulando solicitudes antes de fallar.

Antes de concluir que una prueba fue exitosa, revisa latencia, errores y capacidad en conjunto. Si necesitas validar el comportamiento de una API, un checkout o una plataforma completa, puedes solicitar a Mentores Tech una evaluación de performance basada en evidencia.