Métricas de rendimiento de API: latencia, throughput y tasa de errores

¿Qué son las métricas de rendimiento de API?

Las métricas de rendimiento de una API miden lo rápido que responde, cuánto tráfico soporta y con qué frecuencia falla, con tráfico real o con una prueba. Las cuatro principales son latencia, throughput, tasa de errores y saturación. Los equipos las usan para fijar objetivos, encontrar cuellos de botella y decidir cuándo escalar.

Las cuatro señales de oro

El libro de SRE de Google nombra cuatro señales que cubren casi todo lo que hay que vigilar en un servicio (véase Monitoring Distributed Systems, en inglés). Los valores de ejemplo son solo ilustrativos.

Latencia: percentiles, no la media

La media esconde la cola lenta. El libro de SRE da el caso clásico: un servicio con 100 ms de latencia media a 1.000 peticiones por segundo puede tener fácilmente un 1 % de peticiones que tardan 5 segundos. Por eso conviene informar con percentiles; más en por qué los percentiles son más útiles que las medias (artículo en inglés).

Mide por separado la latencia de las peticiones correctas y de las fallidas. Un error rápido puede hacer que las cifras parezcan mejores que la experiencia real, y un error lento es peor que uno rápido. Lo básico, en latencia.

Throughput

El throughput (rendimiento o caudal) es el trabajo realizado por unidad de tiempo; en una API suele ser peticiones por segundo (RPS). Magnitudes relacionadas son los usuarios concurrentes (usuarios virtuales en una prueba) y el ancho de banda. Por sí solo dice poco: míralo junto con la latencia y los errores. El punto en que la latencia sube mientras el throughput deja de crecer es tu capacidad práctica; véase cómo se relacionan throughput y tiempo de respuesta (en inglés).

Tasa de errores

La proporción de peticiones que fallan. Sepárala por causa, porque cada una apunta a un sitio distinto:

• Respuestas 5xx: fallos del servidor, un problema tuyo.
• Respuestas 4xx: casi siempre errores del cliente (401, 404, 429), pero un salto repentino puede indicar una versión rota o una credencial caducada.
• Timeouts y errores de conexión: la petición nunca terminó.
• Contenido incorrecto con un 200: el libro de SRE también lo cuenta como error. Comprueba el cuerpo, no solo el código de estado.

Saturación

La saturación muestra lo cerca que está el sistema de su límite. Muchos sistemas se vuelven lentos mucho antes del 100 % de uso. Vigila CPU, memoria, E/S de disco, red, uso del pool de conexiones a la base de datos y longitud de las colas, y fija un objetivo de utilización. Un p99 que sube en una ventana corta suele ser la primera señal.

Otros tiempos útiles

• Tiempo hasta el primer byte: el tiempo de proceso del servidor antes de que empiece la respuesta, véase Time to First Byte (TTFB).
• Tiempo de DNS, conexión TCP y TLS: sobrecarga de red antes de que se ejecute tu código.
• Tiempo de descarga: tamaño de la respuesta y ancho de banda.
• Desglose por endpoint y región: una cifra global puede ocultar un endpoint o una región lentos.

SLI, SLO, SLA y presupuesto de errores

Los 43 minutos salen de una cuenta simple: el 0,1 % de un mes de 30 días (43.200 minutos). Más sobre contratos en gestión de SLA.

Un ejemplo resuelto

Imagina que haces una prueba de carga a un endpoint hipotético /orders con 50, 100 y 200 usuarios virtuales. Con 50 y 100 usuarios el p95 se mantiene en unos 180 ms y casi no hay errores. Con 200 usuarios el p95 salta a 900 ms y el 2 % de las peticiones agota el tiempo, mientras que el throughput apenas creció respecto a la prueba de 100 usuarios. El punto de inflexión está en torno a los 100 usuarios, esa es tu capacidad segura, y el pool de conexiones a la base de datos (una métrica de saturación) es lo primero que hay que revisar.

Cómo medir el rendimiento de una API

• Pruebas de carga: generan tráfico controlado antes de un release y permiten comparar ejecuciones. Véase pruebas de carga.
• Monitorización sintética de API: comprobaciones programadas contra producción que registran tiempo de respuesta, estado y cuerpo. Véase monitorización de API.
• APM y datos de usuarios reales: la instrumentación del servidor y los datos de campo muestran lo que vive el tráfico real. Véase monitorización del rendimiento de aplicaciones.

Ninguna fuente lo ve todo: las pruebas dan una baseline reproducible, la monitorización detecta regresiones en producción y el APM explica la causa.

Errores comunes

• Informar solo de medias. La cola lenta es lo que molesta a los usuarios.
• Medir solo en staging. Los datos, las cachés y la mezcla de tráfico son distintos en producción.
• Sin objetivos. Las métricas que nadie compara con un SLO se ignoran.
• Alertar por cada 5xx. Es mejor alertar por la tasa de errores en una ventana.
• Una sola cifra para todos los endpoints. Desglosa por endpoint y versión.
• Probar una sola vez. Vuelve a probar tras cambios importantes.

Mide el rendimiento de tu API con LoadFocus

Las pruebas de carga de LoadFocus ejecutan pruebas de JMeter, k6 y sin código desde 25 regiones en la nube e informan de tiempo de respuesta, latencia, throughput, errores y de los percentiles 50, 90 y 99, con umbrales de aprobado o suspenso para p95 o p99, tasa de errores y throughput. La monitorización de API comprueba tus endpoints según un calendario (cada 5 minutos en el plan gratuito) y puede dar una comprobación por fallida según estado, cuerpo, cabeceras o tiempo de respuesta. Para una visión más amplia, véase pruebas de API.

Preguntas frecuentes: métricas de rendimiento de API

¿Qué es una buena latencia para una API?

Depende del caso de uso y de lo que esperen los usuarios. Muchos equipos buscan un p95 de unos pocos cientos de milisegundos en endpoints interactivos, y menos en llamadas internas o en tiempo real. Fija el objetivo a partir de tus propios usuarios y mide p95 y p99, no la media.

¿Cómo encuentro el throughput máximo de una API?

Ejecuta una prueba de carga que suba el tráfico por pasos y observa la latencia y los errores. El punto en que la latencia sube o aparecen errores mientras el throughput deja de crecer es el máximo práctico.

¿Qué tasa de errores es aceptable?

No hay una cifra universal. Sale de tu SLO: un endpoint de pagos o de inicio de sesión necesita una tasa mucho más baja que uno no crítico. Defínela por endpoint y mídela en una ventana como 30 días.

¿Debo seguir el p95 o el p99?

Los dos. El p95 describe la calidad para la mayoría de usuarios y el p99 la experiencia de los menos afortunados. Con mucho tráfico, incluso el 1 % es mucha gente.

¿Qué es un presupuesto de errores?

La cantidad de fallo que tu SLO todavía permite. Con un 99,9 % de disponibilidad en 30 días son unos 43 minutos. Cuando el presupuesto casi se agota, los equipos suelen frenar los releases arriesgados y arreglar antes la fiabilidad.