Latencia, rendimiento y percentiles: la guía que zanja la discusión

Existe una frase que aparece en toda reunión técnica y que no significa nada: "el sistema está lento".

¿Lento para quién? ¿En qué momento? ¿Comparado con qué? Mientras esas preguntas no se respondan con números, la conversación es sobre sensaciones. Y las sensaciones no se optimizan.

Latencia no es rendimiento#

Latencia es cuánto tarda una petición. Medida en milisegundos. Es la experiencia de una persona.

Rendimiento es cuántas peticiones caben por segundo. Medido en QPS. Es la capacidad del sistema.

La analogía de la carretera funciona: la latencia es cuánto tarda tu coche de Madrid a Valencia, el rendimiento es cuántos coches pasan por el peaje por hora. Puedes duplicar el rendimiento construyendo más carriles, y tu viaje sigue durando exactamente lo mismo.

Por qué importa en la práctica: cuando alguien reporta lentitud, la primera pregunta es cuál de los dos cambió.

• Latencia subió, rendimiento igual → alguna dependencia se puso más lenta. Busca fuera de tu código.
• El rendimiento chocó contra un techo y la latencia se disparó con él → saturaste. Hay una cola creciendo en algún sitio: balanceador, pool de conexiones, ejecutor de tareas.

Son dos diagnósticos completamente distintos, y distinguirlos lleva treinta segundos si tienes los gráficos correctos.

La Ley de Little#

Existe una relación entre los dos que resuelve la mitad de las discusiones sobre dimensionamiento:

peticiones en curso = rendimiento × latencia

Cien peticiones por segundo, doscientos milisegundos cada una, da veinte peticiones vivas al mismo tiempo.

Ese número te dice cuántos hilos necesitas, cuántas conexiones de base de datos, cuánto de cualquier recurso que quede ocupado durante la petición. Es una multiplicación: no es modelado, no es adivinanza.

Y expone una trampa: si la latencia se duplica, el número de peticiones en curso se duplica, con el mismo tráfico. Por eso una dependencia lenta agota tu pool de hilos un día en el que el volumen no cambió nada.

La media miente. El percentil no.#

Si te digo que la latencia media de mi API es 100ms, no sabes casi nada.

Imagina diez peticiones: nueve tardaron 10ms y una tardó 900ms.

d = [10]*9 + [900]
media = sum(d) / len(d)   # 99.0  -> parece óptimo

La media da 99ms. Pero el 10% de los usuarios tuvo una experiencia horrible, y el panel está en verde.

El percentil resuelve eso. Ordenas todas las latencias, de la menor a la mayor, y miras dónde cae cada corte.

Amplificación de cola#

Ahora la parte que cambia el diseño de tu arquitectura.

Supón que tu página hace diez llamadas internas para montar la respuesta, y que cada servicio tiene un p99 de 1 segundo. ¿Cuál es la probabilidad de que la página entera se ponga lenta?

No es el 1%. Es la probabilidad de que al menos una de las diez caiga en la cola: aproximadamente el 10%.

Eso se llama amplificación de cola, y la consecuencia es dura: cuanto más partes el sistema en servicios, más el p99 individual de cada uno se convierte en el p90 del usuario final.

En arquitectura distribuida, el p99 de los componentes es un presupuesto colectivo, no una métrica individual. Cada servicio nuevo en el camino crítico consume parte de ese presupuesto.

Qué hacer con la cola#

Las causas típicas, y vale la pena cazar en este orden:

1. Pausa de GC: picos periódicos sin correlación con el tráfico.
2. Contención de locks: empeora con la concurrencia, no mejora con más CPU.
3. Caché fría: después de un deploy o de una expiración masiva.
4. Vecino ruidoso: otro proceso en la misma máquina.
5. Retransmisión de TCP: pérdida de paquete; TCP reduce la ventana y la latencia salta.
6. Cola: en cualquier punto del camino, y es la más común de las seis.

Y existe una técnica directa contra la cola, popularizada por Google, llamada hedging: si la petición no responde hasta el p95, disparas una segunda hacia otra réplica y usas la primera respuesta que llegue. Pagas un 5% de tráfico extra y cortas la cola de forma expresiva.

Cómo empezar hoy#

Tres medidas concretas, en orden:

1. Sustituye la media por el percentil en todos los paneles. Si tu sistema de métricas solo guarda la media, te está escondiendo el problema.
2. Mide p50, p95 y p99 por endpoint, no solo el agregado del servicio. El agregado esconde el endpoint malo detrás del endpoint popular y rápido.
3. Calcula las peticiones en curso con la Ley de Little y compáralas con el tamaño de tus pools. Mucho mayor de lo necesario significa contención pagada en balde; menor significa cola.

Hecho eso, "el sistema está lento" deja de ser una opinión y se convierte en una frase con número, endpoint y percentil.

Y ahí ya se puede arreglar.