P50, P95 y P99: cómo interpretar percentiles de latencia sin que el promedio te engañe

100,000 solicitudes
P50 = 120 ms
P95 = 480 ms
P99 = 1.8 s

¿El sistema es rápido porque la mitad de las solicitudes termina en 120 milisegundos o es lento porque aproximadamente 1,000 solicitudes superan 1.8 segundos?

Las dos afirmaciones pueden ser ciertas.

Ese es el problema de interpretar la latencia con un único número. El promedio puede ocultar una cola severa. El P50 puede describir correctamente la experiencia central y, al mismo tiempo, ignorar miles de operaciones lentas. El P99 puede revelar un impacto material, pero también puede ser inestable, estar mal agregado o representar una población que mezcla operaciones incomparables.

La idea central de este artículo es simple:

Al terminar, podrás leer P50, P95 y P99 sin confundirlos con disponibilidad, convertir la cola en impacto aproximado, decidir qué percentil observar y detectar mediciones que parecen precisas pero no son comparables.

La latencia es una distribución, no un número

Cada solicitud completada produce una observación:

84 ms
91 ms
105 ms
118 ms
...
2,400 ms

El conjunto de observaciones de una operación, población y ventana forma una distribución. Esa distribución puede concentrarse alrededor de un rango estrecho o presentar una cola larga con solicitudes mucho más lentas que la mayoría.

En sistemas distribuidos, las distribuciones de latencia suelen ser asimétricas. La mayoría de las operaciones puede completarse cerca de un valor central mientras una fracción menor acumula espera en colas, contención, pausas del runtime, I/O, reintentos, bloqueos o dependencias lentas. Por eso, la media aritmética rara vez describe por sí sola la forma completa de la distribución.

OpenTelemetry modela los histogramas como una población de mediciones comprimida en conteos, suma, límites de buckets y una ventana temporal. Prometheus utiliza el mismo principio para calcular cuantiles a partir de histogramas agregables.

Un percentil resume una posición. Un histograma o mapa de calor muestra mejor la forma. Para operar un sistema conviene observar ambos: percentiles para seguir umbrales y distribución para entender qué cambió.

La explicación completa de colas, presupuestos y componentes que acumulan tiempo pertenece a la guía de latencia en sistemas distribuidos. Aquí el alcance es más específico: cómo leer la distribución sin atribuirle propiedades que no mide.

Qué significa realmente un percentil

El percentil Px es el valor por debajo o igual al cual se encuentra aproximadamente x % de las observaciones de la población y ventana medidas.

Si el dashboard muestra:

P95 = 480 ms

la interpretación operativa es:

• Aproximadamente 95 % de las observaciones terminó en 480 ms o menos.
• Aproximadamente 5 % tardó más de 480 ms.

No significa:

• Que el sistema tuvo 95 % de disponibilidad.
• Que 95 % de las solicitudes fue exitoso.
• Que 95 % tardó exactamente 480 ms.
• Que el 5 % restante fue apenas más lento.
• Que ese valor sirve para cualquier endpoint, región o ventana.

Disponibilidad y latencia son indicadores distintos. Una solicitud puede responder con éxito y hacerlo demasiado tarde. También puede fallar con rapidez. Google SRE separa explícitamente el SLI de disponibilidad —proporción de solicitudes exitosas— del SLI de latencia —proporción de solicitudes por debajo de un umbral—.

La palabra “aproximadamente” importa

En una población finita, el resultado exacto depende del estimador, la convención de ranking, la interpolación y, en plataformas de observabilidad, del esquema de buckets. Hyndman y Fan documentaron múltiples definiciones de cuantiles muestrales usadas por paquetes estadísticos.

En producción esto tiene dos consecuencias:

1. Dos herramientas pueden reportar valores ligeramente distintos sobre la misma muestra.
2. Un percentil calculado desde buckets es una estimación cuya precisión depende de sus límites.

La decisión correcta no es buscar una falsa exactitud decimal. Es verificar si las diferencias son materiales para el umbral operativo y si ambos datos fueron calculados con métodos comparables.

Cómo interpretar P50, P95, P99 y P99.9

P50: la experiencia central

P50 es la mediana. Divide las observaciones de forma que aproximadamente la mitad queda por debajo o igual al valor y la otra mitad por encima.

Responde a esta pregunta:

Es menos sensible que el promedio a valores extremos. Si una solicitud tarda 30 segundos, la mediana puede no moverse. Eso es útil para describir la experiencia típica, pero insuficiente para evaluar la cola.

Señal observable: P50 sube de manera sostenida en todos los segmentos.

Posibles interpretaciones:

• Aumento general de tiempo de procesamiento.
• Cambio de ruta o dependencia común.
• Saturación que ya afecta a la mayoría.
• Payloads más grandes o composición distinta del tráfico.

Riesgo de mala lectura: declarar saludable un servicio porque P50 permanece estable mientras P95 y P99 se degradan.

Validación: comparar P50 con throughput, saturación, errores y segmentación por operación. Si solo la cola cambia, la causa probablemente no afecta de forma uniforme a todas las solicitudes.

P95: la cola operativa frecuente

P95 deja aproximadamente 5 % de las observaciones por encima. En servicios con tráfico moderado o alto, ese 5 % puede representar un volumen significativo.

1,000,000 solicitudes por día
5 % por encima de P95
≈ 50,000 solicitudes

P95 responde a una pregunta distinta:

Suele ser útil en dashboards de operaciones interactivas porque es más sensible a degradaciones que P50 y menos volátil que percentiles más extremos. No es universalmente “el percentil correcto”. Su utilidad depende del volumen, la criticidad y la forma de la distribución.

P99: extremos que dejan de ser raros a escala

P99 deja aproximadamente 1 % de las observaciones por encima.

100,000 solicitudes
1 % por encima de P99
≈ 1,000 solicitudes

A bajo volumen, el P99 puede depender de muy pocas observaciones. A gran escala, ese mismo 1 % puede afectar a cientos de miles de operaciones.

P99 resulta especialmente útil cuando:

• La plataforma procesa alto volumen.
• La operación es sensible a retrasos.
• Una solicitud depende de múltiples llamadas.
• La cola puede activar timeouts o reintentos.
• Una degradación extrema consume recursos durante más tiempo.

Su trade-off es claro: ofrece mayor sensibilidad a la cola, pero necesita más muestra y suele presentar más variación en ventanas cortas.

P99.9: precisión extrema con costo y volatilidad

P99.9 deja aproximadamente 0.1 % por encima. En diez millones de operaciones, ese segmento equivale a unas diez mil observaciones. En una ventana con mil solicitudes, representa nominalmente una sola observación.

Puede ser relevante en plataformas de enorme volumen o en operaciones donde una cola muy extrema tiene consecuencias materiales. También exige:

• Más observaciones para obtener una señal estable.
• Mayor resolución del histograma.
• Mejor control de truncación y timeouts.
• Más cuidado con cardinalidad y costo de almacenamiento.
• Comparaciones consistentes entre herramientas.

Subir de P99 a P99.9 no convierte automáticamente la medición en más útil. Solo desplaza la pregunta hacia una región más extrema de la distribución.

El ejemplo de 100,000 solicitudes

Retomemos la ventana inicial:

Volumen = 100,000 solicitudes
P50 = 120 ms
P95 = 480 ms
P99 = 1.8 s

Una lectura válida es:

• Aproximadamente 50,000 solicitudes completaron en 120 ms o menos.
• Aproximadamente 95,000 completaron en 480 ms o menos.
• Aproximadamente 99,000 completaron en 1.8 s o menos.
• Aproximadamente 1,000 superaron 1.8 s.

Pero todavía faltan preguntas esenciales:

• ¿La ventana fue de un minuto, una hora o un día?
• ¿Las 100,000 solicitudes pertenecen al mismo endpoint?
• ¿Incluyen errores y timeouts?
• ¿La medición fue cliente o servidor?
• ¿Qué regiones, versiones y payloads se mezclaron?
• ¿Cuánto tardó el peor 1 %: 1.9 segundos o 30 segundos?
• ¿El percentil fue calculado desde eventos crudos, un summary o un histograma?

Los tres percentiles no permiten reconstruir la distribución completa. Dos sistemas pueden compartir P50, P95 y P99 y tener máximos, densidades intermedias y causas radicalmente diferentes.

Por qué el promedio puede engañar

Considera esta muestra:

99 solicitudes = 100 ms cada una
1 solicitud = 10,000 ms

El promedio es:

((99 × 100 ms) + 10,000 ms) / 100
= 19,900 ms / 100
= 199 ms

Un dashboard que solo muestra promedio = 199 ms pierde dos hechos importantes:

• La experiencia central estuvo cerca de 100 ms.
• Una solicitud tardó 10 segundos.

P50 sería 100 ms. El máximo sería 10,000 ms. El P99 dependería de la convención de cálculo y de la representación de la muestra.

El promedio no “miente” matemáticamente. Responde otra pregunta:

El error es usar esa respuesta para inferir la forma de una distribución asimétrica.

Promedio, mediana, máximo e histograma cumplen funciones distintas

La recomendación operativa no es reemplazar el promedio por un percentil. Es observar un conjunto mínimo que preserve centro, cola, volumen y distribución.

El volumen cambia el significado de la cola

El mismo “1 %” representa impactos radicalmente distintos según la cantidad de operaciones.

Un P99 de 1.8 segundos sin volumen no permite estimar cuántas operaciones estuvieron por encima. Tampoco permite saber cuántos usuarios únicos fueron afectados: un cliente puede generar múltiples solicitudes y aparecer repetidamente en la cola.

No confundas solicitudes con usuarios

Convertir percentiles en impacto de usuario requiere una dimensión adicional:

• Identidad o sesión, cuando la privacidad y cardinalidad lo permitan.
• Flujo funcional.
• Número de llamadas técnicas por acción.
• Reintentos transparentes.
• Operaciones asíncronas disparadas por una interacción.

Una acción de usuario puede generar diez llamadas. Un P99 por solicitud no equivale automáticamente a 1 % de usuarios afectados.

Fan-out: cuando el P99 de un backend llega al camino crítico

Una solicitud frontal puede consultar múltiples particiones o dependencias en paralelo y esperar la respuesta más lenta. En ese diseño, la probabilidad de encontrar al menos una llamada lenta aumenta con el fan-out.

Supongamos, solo para ilustrar el efecto, que:

• Cada llamada tiene 1 % de probabilidad de caer en su cola lenta.
• Las llamadas son independientes.
• Una operación frontal espera las 100 respuestas.

La probabilidad de que ninguna sea lenta es:

0.99^100 ≈ 36.6 %

La probabilidad de que al menos una sea lenta es:

1 - 0.99^100 ≈ 63.4 %

Una condición de cola que afecta a 1 % de las llamadas individuales puede aparecer en la mayoría de las operaciones agregadas con fan-out alto. La independencia rara vez es perfecta en sistemas reales, pero el cálculo muestra por qué la cola deja de ser rara cuando el camino crítico consulta muchos componentes. El trabajo de Dean y Barroso sobre The Tail at Scale describe cómo episodios poco frecuentes pueden dominar el rendimiento de servicios grandes.

Esta sección no reemplaza el análisis completo de latencia de cola. Su función es explicar por qué un percentil extremo de una dependencia puede transformarse en experiencia frecuente del frontend.

La ventana de medición decide qué incidente puedes ver

Todo percentil pertenece a una ventana. Un valor sin ventana está incompleto.

El ejemplo que una ventana larga puede ocultar

Supongamos una hora con tráfico estable:

• 55 minutos a P99 = 300 ms.
• 5 minutos a P99 = 8 s.

El P99 de toda la hora no tiene que mostrar 8 segundos. Dependerá del volumen de cada tramo y de la distribución conjunta. Si el incidente afectó menos de 1 % de todas las solicitudes de la hora, puede desaparecer del P99 horario aunque haya sido evidente durante cinco minutos.

Decisión operativa

Usa varias ventanas para preguntas distintas:

• Detección: ¿está ocurriendo una degradación ahora?
• Confirmación: ¿es sostenida o fue un punto aislado?
• Tendencia: ¿el comportamiento cambió frente al baseline?
• SLO: ¿cuánto presupuesto se consumió en el periodo objetivo?

No compares un P99 de cinco minutos con otro calculado sobre una hora y los presentes como si describieran la misma población.

La población y la segmentación deciden qué estás midiendo

Un percentil global puede mezclar distribuciones incompatibles:

• Endpoints de lectura y escritura.
• Regiones con distancias distintas.
• Versiones antes y después de un despliegue.
• Caché hit y caché miss.
• Payloads pequeños y grandes.
• Clientes internos y externos.
• Operaciones síncronas y batch.
• Respuestas exitosas, errores y timeouts.

Ejemplo: un endpoint rápido oculta otro lento

Supongamos:

GET /catalogo
900,000 solicitudes
P99 = 180 ms

POST /pedido
100,000 solicitudes
P99 = 2.4 s

Si se mezclan ambas operaciones, el endpoint de alto volumen puede dominar la distribución global. El percentil agregado no responde bien a ninguna de estas preguntas:

• ¿La lectura del catálogo está saludable?
• ¿La creación de pedidos cumple su objetivo?

Decisión

Segmenta por dimensiones que cambian la naturaleza de la operación, pero evita cardinalidad sin control. Una taxonomía inicial razonable puede incluir:

• Ruta normalizada o tipo de operación.
• Código de resultado agrupado.
• Región.
• Versión de despliegue.
• Clase de payload.
• Estado de caché, si es operacionalmente relevante.

No uses IDs de usuario, request IDs o URLs sin normalizar como labels de métricas. Esos identificadores pertenecen a logs o trazas, no a series de alta cardinalidad.

OpenTelemetry permite asociar atributos a los puntos de histograma; esa capacidad mejora el filtrado, pero cada combinación de atributos puede generar una serie distinta y aumentar el costo.

Cliente y servidor no observan la misma latencia

La latencia medida en el servidor suele comenzar después de que la solicitud llega y termina cuando la respuesta es emitida. La latencia del cliente puede incluir además:

• Resolución DNS.
• Establecimiento de conexión.
• TLS.
• Tránsito de red.
• Espera en proxies o gateways.
• Transferencia del cuerpo.
• Reintentos del cliente.
• Procesamiento local.

Google SRE señala que la latencia cliente suele ser más relevante para el usuario, aunque a veces solo está disponible la medición servidor.

Por eso, estos valores no son intercambiables:

P99 servidor = 400 ms
P99 cliente = 1.2 s

La diferencia no demuestra por sí sola que la red sea la causa. Puede incluir colas en capas intermedias, retry automático, handshake, streaming o instrumentación con límites distintos.

Decisión de medición

Define explícitamente:

• Punto de inicio.
• Punto de fin.
• Unidad.
• Inclusión de retries.
• Inclusión de timeouts.
• Tratamiento de cancelaciones.
• Segmentación por protocolo y ruta.

Solo después compara cliente y servidor mediante métricas, logs y trazas.

Cómo se calculan los percentiles en una plataforma de métricas

La interfaz puede mostrar P99 = 742 ms, pero ese valor puede provenir de mecanismos distintos.

Eventos crudos

El sistema conserva cada observación y ordena o estima directamente sobre los datos.

Ventaja: máxima flexibilidad analítica.

Costo: volumen de almacenamiento, transferencia y consulta.

No suele ser la estrategia principal para telemetría de alto volumen durante retenciones largas.

Summary con cuantiles precalculados

El proceso instrumentado calcula cuantiles en una ventana y exporta valores como P50, P95 o P99.

Ventaja: el cliente puede controlar el algoritmo y la precisión del cuantil.

Limitación: los cuantiles precalculados no son generalmente agregables entre instancias. OpenTelemetry mantiene Summary como tipo legado y no lo recomienda para aplicaciones nuevas porque sus cuantiles no siempre pueden combinarse de forma significativa.

Histograma clásico

Cada observación incrementa buckets acumulativos definidos por límites:

≤ 0.1 s
≤ 0.3 s
≤ 0.5 s
≤ 1.0 s
≤ 2.0 s
+Inf

El backend calcula el percentil interpolando dentro del bucket que contiene la posición buscada.

Ventaja: los buckets compatibles pueden agregarse entre instancias y dimensiones.

Trade-off: la precisión depende de la ubicación de los límites. Un bucket demasiado ancho alrededor del SLO produce una estimación poco útil.

Histograma exponencial o nativo

Utiliza buckets con resolución relativa y puede cubrir un rango dinámico amplio de manera más eficiente. OpenTelemetry define ExponentialHistogram como estable y Prometheus recomienda histogramas nativos cuando están disponibles y la resolución satisface el requisito de precisión.

Un ejemplo de PromQL

Para un histograma clásico:

histogram_quantile(
  0.99,
  sum by (le, route) (
    rate(http_server_request_duration_seconds_bucket[5m])
  )
)

Esta consulta:

1. Calcula la tasa de incremento de los buckets durante cinco minutos.
2. Agrega instancias conservando le y route.
3. Estima el P99 por ruta.

Es un ejemplo conceptual. Los nombres, labels y filtros deben adaptarse a la instrumentación real. También debe definirse si se incluyen errores, cancelaciones y rutas de bajo volumen.

El error de buckets es parte del diseño

Prometheus documenta que histogram_quantile() estima dentro del bucket. Si el percentil cae en un rango de 200 a 300 ms, el valor real podría estar en cualquier punto de ese intervalo según la distribución interna. La interpolación puede producir una cifra precisa en apariencia, pero su resolución real sigue limitada por el bucket.

Por eso los límites deben concentrarse alrededor de decisiones importantes:

• Umbral de SLO.
• Timeout de cliente.
• Límite de experiencia aceptable.
• Frontera donde comienza una degradación funcional.

No existe un esquema universal. Un endpoint que normalmente tarda 5 ms necesita buckets diferentes de una operación batch de varios minutos.

Por qué no debes promediar percentiles

Considera dos instancias:

Instancia A
100,000 solicitudes
P99 = 200 ms

Instancia B
1,000 solicitudes
P99 = 2,000 ms

El promedio simple de ambos P99 sería:

(200 + 2,000) / 2 = 1,100 ms

Ese resultado trata ambas instancias como si tuvieran el mismo peso y no conserva ninguna de las distribuciones originales. No es el P99 global.

Prometheus califica como estadísticamente inválido promediar cuantiles precalculados y recomienda agregar histogramas antes de calcular el cuantil.

# Incorrecto: promedio de P99 precalculados
avg(http_request_duration_seconds{quantile="0.99"})

# Correcto para histogramas clásicos compatibles
histogram_quantile(
  0.99,
  sum by (le) (
    rate(http_request_duration_seconds_bucket[5m])
  )
)

Para obtener un percentil global necesitas

• Observaciones subyacentes, o
• Histogramas agregables con semántica compatible, o
• Una estructura de sketch diseñada para merge, si la plataforma la soporta.

También deben coincidir:

• Unidad.
• Ventana.
• Límites de buckets o esquema compatible.
• Definición de población.
• Tratamiento de errores y timeouts.

Cómo relacionar percentiles con SLO

Un SLO debe especificar indicador, objetivo, población y ventana. La frase siguiente parece completa, pero aún necesita definición operativa:

99 % de las solicitudes debe completar en menos de 800 ms durante 30 días.

Faltan, como mínimo:

• Qué operaciones entran.
• Desde qué punto se mide.
• Qué respuestas se excluyen y por qué.
• Cómo se tratan timeouts y cancelaciones.
• Qué ventana exacta se evalúa.
• Qué fuente de telemetría es autoritativa.

SLO basado en eventos buenos

Una forma directamente agregable es clasificar cada solicitud:

Evento bueno: duración ≤ 800 ms
Evento malo: duración > 800 ms

El SLI es:

solicitudes_buenas / solicitudes_totales

El objetivo puede ser:

≥ 99 % durante 30 días

Google SRE recomienda para servicios request-driven definir la latencia como proporción de solicitudes más rápidas que un umbral, y muestra objetivos múltiples para capturar experiencia central y cola.

Ejemplo:

90 % de solicitudes < 300 ms
99 % de solicitudes < 800 ms

Esto evita que un único objetivo de cola permita una experiencia central mediocre o que un objetivo central ignore a la cola.

SLO expresado como percentil

La expresión:

P99 ≤ 800 ms durante la población completa de 30 días

puede ser aproximadamente equivalente a exigir que al menos 99 % de esas observaciones esté por debajo del umbral, siempre que la población, ventana, manejo de empates y método de cálculo sean los mismos.

Pero deja de ser equivalente cuando se cambia la agregación. Por ejemplo:

P99 de cada ventana de 5 minutos ≤ 800 ms

no es lo mismo que:

99 % de todas las solicitudes del mes ≤ 800 ms

El primer objetivo evalúa ventanas. El segundo evalúa eventos. Un minuto con bajo tráfico puede pesar igual que uno con alto tráfico si se cuentan ventanas, mientras que el SLO por eventos pondera cada solicitud.

Decisión recomendada

Para SLO y error budget, usa una proporción de eventos buenos cuando puedas medirla de manera consistente. Mantén P50, P95, P99 e histogramas en dashboards para entender la forma y localizar degradaciones.

El percentil es una vista de distribución. El SLO es un contrato cuantitativo sobre experiencia aceptable.

Cómo alertar sin convertir el P99 en ruido

Alertar cada vez que un punto de P99 cruza un umbral produce falsos positivos en servicios de poco tráfico y fatiga en servicios variables.

Antes de paginar, evalúa:

• Duración de la violación.
• Volumen mínimo de la ventana.
• Magnitud del exceso.
• Consumo de error budget.
• Afectación por operación o región.
• Correlación con errores, saturación o timeouts.
• Comparación con ventanas corta y larga.

Google SRE recomienda diseñar alertas sobre eventos significativos y consumo de error budget, evaluando precisión, recall, tiempo de detección y tiempo de reset.

Ejemplo defendible de alerta percentil

Condición A:
P99 > 800 ms durante 10 minutos

Condición B:
volumen > 10,000 solicitudes en la ventana

Condición C:
la degradación aparece en al menos dos evaluaciones consecutivas

No es una configuración universal. El volumen mínimo, la duración y el umbral deben derivarse de la carga, la criticidad y el tiempo de respuesta operativo.

Mejor aún: alerta por consumo del SLO

Si el SLO es 99 % ≤ 800 ms, cada solicitud por encima de 800 ms consume presupuesto. Una alerta de burn rate puede detectar si el presupuesto se está agotando demasiado rápido, en lugar de reaccionar a un P99 aislado.

Esto no elimina el dashboard de percentiles. Separa dos funciones:

• Paginación: proteger el objetivo y la experiencia.
• Diagnóstico: entender qué parte de la distribución cambió.

Qué hacer con servicios de bajo tráfico

Con 50 solicitudes en cinco minutos, P99 está determinado por el extremo de una muestra pequeña. En ese contexto:

• Amplía la ventana.
• Usa conteos absolutos de eventos lentos.
• Muestra el volumen junto al percentil.
• Evita paginar por una sola observación salvo que la operación sea crítica.
• Considera synthetic monitoring si necesitas una señal periódica estable.

No existe una cifra mágica de muestra. Con N observaciones, el número esperado por encima de P99 es 0.01 × N:

Tener cien observaciones no vuelve estable al P99; solo ubica nominalmente una observación en la cola superior. La precisión depende de la distribución, el estimador y el nivel de confianza requerido.

Coordinated omission: la prueba que omite el daño

Una prueba de carga puede reportar percentiles excelentes mientras el sistema estuvo incapaz de aceptar el ritmo planeado.

Ocurre cuando el generador trabaja en ciclo cerrado:

1. Envía una solicitud.
2. Espera su respuesta.
3. Solo entonces envía la siguiente.

Si el sistema se bloquea durante un segundo, el generador también deja de producir nuevas operaciones. Las solicitudes que deberían haber llegado durante la espera nunca existen en el dataset. La medición registra una respuesta lenta, pero omite la cola que habría acumulado un flujo externo independiente.

Ejemplo temporal

Objetivo de carga:

100 solicitudes por segundo
1 solicitud cada 10 ms

El sistema se detiene durante 1 segundo.

En un generador cerrado, podría ocurrir:

t = 0 ms     envía solicitud A
t = 1000 ms  recibe A
t = 1000 ms  envía solicitud B

Durante ese segundo no se registraron las aproximadamente 99 llegadas adicionales que el plan pretendía generar.

En un modelo abierto, las operaciones continúan programándose cada 10 ms. El resultado refleja acumulación, espera, rechazo o pérdida de capacidad.

HdrHistogram incorpora mecanismos para corregir datos por coordinated omission añadiendo valores estimados según el intervalo esperado entre muestras. Esa corrección puede ser útil, pero no reemplaza diseñar una prueba que mantenga el patrón de llegada previsto.

Decisión para pruebas de carga

• Define si modelas usuarios cerrados o llegadas externas abiertas.
• Mantén el ritmo planeado cuando el caso real lo exija.
• Registra throughput ofrecido y throughput completado.
• Incluye rechazos, timeouts y cancelaciones.
• Verifica si la herramienta corrige coordinated omission y cómo lo hace.
• No compares resultados de metodologías distintas como si fueran equivalentes.

Cuando una prueba “mejora” P99 al saturarse mientras cae el throughput, sospecha del modelo de carga antes de celebrar el resultado.

Cómo diagnosticar una degradación de percentiles

Un percentil alto es un síntoma. No identifica la causa.

1. Confirma que el dato es comparable

Verifica:

• Misma operación.
• Misma ventana.
• Misma población.
• Mismo punto de medición.
• Mismo método de histograma.
• Volumen suficiente.
• Sin cambios de unidad ni buckets.

Si la instrumentación cambió durante un despliegue, el salto puede ser telemetría y no comportamiento.

2. Determina qué parte de la distribución se movió

Estas son hipótesis, no causas. Sirven para decidir qué señal revisar después.

3. Segmenta antes de buscar una causa global

Corta la distribución por:

• Endpoint.
• Región.
• Versión.
• Tipo de respuesta.
• Caché hit/miss.
• Dependencia.
• Clase de payload.

Una degradación global puede ser la mezcla de una sola ruta lenta con tráfico creciente.

4. Correlaciona con las cuatro señales

Revisa:

• Latencia: qué percentiles y buckets cambiaron.
• Tráfico: volumen, composición y fan-out.
• Errores: timeouts, rechazos, cancelaciones y fallos.
• Saturación: CPU, memoria, pools, colas, conexiones e I/O.

Google SRE considera que un aumento de P99 en ventanas cortas puede ser una señal temprana de saturación, pero debe analizarse con el resto del sistema.

5. Usa exemplars o trazas para pasar de métrica a petición

Un histograma muestra que existen solicitudes lentas. Una traza distribuida permite localizar en qué tramo se acumuló el tiempo.

El flujo operativo es:

P99 aumenta
→ identificar bucket y segmento
→ seleccionar exemplar o trace ID
→ inspeccionar spans
→ correlacionar logs y recursos
→ formular causa comprobable

La metodología completa se desarrolla en la pieza especializada de investigación estructurada de incidentes.

6. Valida la corrección sobre la distribución completa

Después del cambio, no compruebes solo que P99 bajó. Valida:

• P50, P95 y P99.
• Volumen comparable.
• Tasa de error.
• Throughput.
• Saturación.
• Distribución por endpoint y región.
• Consumo de recursos.
• Ausencia de regresión en otra operación.

Una optimización puede reducir P99 descartando solicitudes, acortando un timeout o devolviendo fallback degradado. La latencia mejora, pero la calidad o disponibilidad empeora.

Errores frecuentes

Interpretar P99 sin volumen

Problema: no se sabe cuántas observaciones representa la cola.

Consecuencia: se minimiza o exagera el impacto.

Corrección: mostrar volumen total y conteo aproximado por encima del percentil.

Confundir P95 con disponibilidad

Problema: asumir que P95 implica 95 % de éxito.

Consecuencia: mezclar dos SLIs y ocultar respuestas rápidas fallidas o respuestas exitosas tardías.

Corrección: medir latencia y éxito por separado.

Mezclar endpoints

Problema: una ruta de alto volumen domina el percentil global.

Consecuencia: la operación crítica lenta queda oculta.

Corrección: segmentar por ruta normalizada o clase funcional.

Comparar ventanas distintas

Problema: contrastar P99 de cinco minutos con P99 diario.

Consecuencia: atribuir una diferencia a rendimiento cuando proviene de agregación.

Corrección: alinear ventana y población.

Promediar percentiles

Problema: calcular el promedio de P99 de instancias o regiones.

Consecuencia: obtener un número sin interpretación estadística válida.

Corrección: agregar histogramas o datos subyacentes antes del cuantil.

Usar muestras insuficientes

Problema: calcular P99 sobre pocas observaciones.

Consecuencia: alta volatilidad y alertas por un extremo aislado.

Corrección: mostrar N, ampliar ventana o usar conteo de eventos lentos.

Excluir errores y timeouts sin declararlo

Problema: medir solo solicitudes completadas con éxito.

Consecuencia: las peores operaciones desaparecen de la distribución.

Corrección: definir elegibilidad y representar timeouts como eventos malos o en una métrica complementaria.

Truncar la métrica en el timeout

Problema: registrar todas las operaciones canceladas como exactamente 1 segundo.

Consecuencia: crear un pico artificial y perder la duración real posterior.

Corrección: distinguir tiempo observado por el cliente, cancelación y trabajo residual del servidor.

Tratar percentiles cliente y servidor como equivalentes

Problema: comparar puntos de medición distintos.

Consecuencia: diagnosticar erróneamente red o aplicación.

Corrección: documentar el alcance de cada temporizador.

Comparar histogramas con buckets distintos

Problema: asumir que dos estimaciones tienen igual precisión.

Consecuencia: interpretar diferencias de instrumentación como cambios de rendimiento.

Corrección: revisar esquema, interpolación y resolución.

Ignorar coordinated omission

Problema: el generador deja de enviar durante respuestas lentas.

Consecuencia: percentiles artificialmente optimistas bajo saturación.

Corrección: usar un modelo de carga coherente con el patrón de llegada y validar throughput ofrecido.

Optimizar el percentil y empeorar el sistema

Problema: reducir P99 con timeouts demasiado agresivos, rechazo o fallback.

Consecuencia: mejora aparente de latencia con caída de éxito o calidad.

Corrección: validar conjuntamente latencia, disponibilidad, calidad y carga.

Los límites de espera y reintentos deben diseñarse como un sistema. La relación con el presupuesto temporal y la amplificación de carga se desarrolla en la pieza sobre timeouts correctamente configurados y las tormentas de reintentos.

El comportamiento del circuito ante dependencias lentas se desarrolla en fallos en cascada.

Checklist operativo

Antes de interpretar un percentil, responde:

• ¿Qué operación representa?
• ¿Qué población incluye?
• ¿Cuál es la ventana?
• ¿Cuántas observaciones contiene?
• ¿La medición es cliente, gateway o servidor?
• ¿Incluye respuestas fallidas?
• ¿Incluye timeouts y cancelaciones?
• ¿Las rutas están normalizadas?
• ¿Se segmentó por región, versión o clase de payload?
• ¿El dato proviene de eventos, summary o histograma?
• ¿Los buckets tienen resolución cerca del umbral?
• ¿Se agregaron distribuciones antes de calcular el percentil?
• ¿La comparación usa el mismo método y unidad?
• ¿Existe suficiente muestra para el percentil elegido?
• ¿El SLO está definido por eventos o por ventanas?
• ¿La alerta considera duración, volumen e impacto?
• ¿La prueba de carga evita coordinated omission?
• ¿La validación posterior revisa éxito, throughput y saturación?

Conclusión

P50, P95 y P99 no compiten entre sí. Cada uno observa una región distinta de la distribución.

P50 describe el centro. P95 muestra una cola frecuente. P99 revela extremos que pueden ser masivos a escala. Ninguno, por separado, define si el sistema está disponible, si cumple un SLO o si la experiencia es aceptable.

La lectura correcta exige cinco datos:

1. Percentil: qué posición se está observando.
2. Ventana: durante qué periodo.
3. Volumen: cuántas observaciones lo sostienen.
4. Población: qué operaciones, regiones y resultados se mezclaron.
5. Método: cómo se capturó, agregó y estimó la distribución.

La acción concreta es revisar cualquier dashboard que hoy muestre P95 o P99 aislados. Añade volumen, ventana, segmentación, umbral de SLO y acceso al histograma o heatmap. Después valida que los percentiles se calculen sobre distribuciones agregables y que errores, timeouts y pruebas de carga no estén eliminando precisamente las observaciones que necesitas ver.

Un percentil sin contexto es un número. Un percentil conectado a una decisión operativa es una señal.

Preguntas frecuentes

¿P95 significa que 95 % de las solicitudes tardó exactamente ese valor?

No. Significa que aproximadamente 95 % terminó en ese valor o menos dentro de la población y ventana medidas. Las solicitudes pueden distribuirse en muchos valores inferiores.

¿Qué es mejor: P95 o P99?

Ninguno es universalmente mejor. P95 suele ser más estable y muestra una cola frecuente. P99 observa una región más extrema y requiere más volumen. La elección depende de criticidad, tráfico, fan-out, umbral de experiencia y costo de falsos positivos.

¿Se pueden promediar percentiles?

En general, no. El promedio de percentiles calculados sobre grupos separados no produce el percentil global. Se necesitan observaciones subyacentes o histogramas y sketches agregables compatibles.

¿Qué diferencia existe entre promedio y P50?

El promedio divide la suma total de duraciones entre el número de observaciones. P50 es la mediana: el valor que divide aproximadamente la muestra en dos mitades. Los extremos pueden mover el promedio sin alterar P50.

¿Qué es coordinated omission?

Es una subestimación de la latencia que ocurre cuando el generador de carga deja de producir nuevas operaciones mientras espera una respuesta lenta. Las llegadas que debieron ocurrir durante la espera no se registran.

¿Cuántas solicitudes necesito para calcular P99?

No existe una cifra universal. Con cien observaciones solo se espera una en el 1 % superior, lo que produce una estimación muy sensible. La muestra necesaria depende de la distribución, la precisión requerida, la ventana, el estimador y el uso operativo. Siempre muestra el volumen junto al percentil.

¿P99 por debajo de 800 ms equivale a un SLO de 99 % bajo 800 ms?

Puede ser aproximadamente equivalente si se calcula sobre exactamente la misma población y ventana con una definición compatible. No es equivalente si se promedian percentiles, se evalúan ventanas separadas o se excluyen eventos de manera distinta. Para error budgets suele ser más claro contar eventos buenos y malos contra el umbral.

¿Un P99 menor siempre representa una mejora?

No. Puede bajar porque se redujo trabajo, porque se rechazaron solicitudes, porque aumentaron timeouts o porque cambió la población. Debe validarse junto con éxito, calidad, throughput, saturación y composición del tráfico.

Fuentes técnicas

• Prometheus — Histograms and summaries: prometheus.io/docs/practices/histograms
• OpenTelemetry — Metrics Data Model: opentelemetry.io/docs/specs/otel/metrics/data-model
• Google SRE — Monitoring Distributed Systems: sre.google/sre-book/monitoring-distributed-systems
• Google SRE — Service Level Objectives: sre.google/sre-book/service-level-objectives
• Google SRE Workbook — Implementing SLOs: sre.google/workbook/implementing-slos
• Google SRE Workbook — Alerting on SLOs: sre.google/workbook/alerting-on-slos
• Jeffrey Dean y Luiz André Barroso — The Tail at Scale: research.google/pubs/the-tail-at-scale
• HdrHistogram — IntCountsHistogram JavaDoc (coordinated omission): hdrhistogram.github.io/HdrHistogram/JavaDoc/org/HdrHistogram/IntCountsHistogram.html
• Rob J. Hyndman y Yanan Fan — Sample Quantiles in Statistical Packages: robjhyndman.com/publications/quantiles

Jorel del Portal

Ingeniero de sistemas especializado en arquitectura de software empresarial y plataformas de alta disponibilidad.

LinkedIn YouTube Tiktok Facebook Instagram X Threads Mi web