Rendimiento y escalabilidad: latencia, rendimiento (throughput), percentiles y carga

Dos preguntas distintas: qué tan rápido y cuánto

El rendimiento es la cualidad que la gente menciona primero y especifica peor. Abarca dos preguntas distintas. La latencia pregunta cuánto tarda una unidad de trabajo: cuántos milisegundos pasan entre tocar 'Pagar' y ver 'Pago aceptado'. El rendimiento (throughput) pregunta cuánto trabajo completa el sistema por unidad de tiempo: 1200 pagos por segundo, 40 000 pedidos por hora. Ambos están relacionados, pero no son intercambiables. Un autobús que lleva a 50 personas de Londres a Oxford en 100 minutos tiene peor latencia y un throughput mucho mejor que un deportivo que lleva a dos personas en 60 minutos.

En el software, la misma tensión aparece en todas partes. Agrupar las escrituras en la base de datos mejora el throughput, pero hace que cada escritura individual espere a su lote. Añadir una caché mejora ambos para las lecturas repetidas, pero no hace nada por la primera. Por eso un buen requisito de rendimiento dice a qué pregunta se refiere y, normalmente, indica ambas cosas: 'con 1200 pagos por segundo (throughput), el 99% se completa en menos de 800 ms (latencia)'. ISO/IEC 25010 las clasifica dentro de la eficiencia de rendimiento como comportamiento temporal, utilización de recursos y capacidad (Sección 2.2).

Tiempo de respuesta = tiempo de servicio + tiempo de espera

Cuando mides la latencia desde el lado del cliente obtienes el tiempo de respuesta: todo lo que ocurrió entre el envío de la solicitud y la recepción de la respuesta. Conviene dividirlo en partes. El tiempo de servicio es el tiempo que un recurso dedica realmente a trabajar en tu solicitud: analizarla, ejecutar la consulta, generar el resultado. El tiempo de espera es el tiempo que tu solicitud pasa en una cola porque el recurso está ocupado con la de otro. A esto se suma el tiempo de transferencia por la red, en ambos sentidos.

La distinción importa porque las dos partes responden a remedios distintos. El tiempo de servicio baja cuando abaratas el propio trabajo: un índice mejor, una carga útil más pequeña, un algoritmo más rápido. El tiempo de espera baja cuando añades capacidad o reduces la carga, y a menudo es mucho mayor que el tiempo de servicio cuando un sistema está ocupado. Muchas investigaciones de 'base de datos lenta' terminan con el descubrimiento de que cada consulta tarda 5 ms, pero espera 300 ms a que quede libre una conexión del grupo (pool).

Percentiles: por qué las medias engañan

Los tiempos de respuesta nunca son un único número; forman una distribución, y casi siempre es asimétrica. La mayoría de las solicitudes son rápidas, y una minoría son lentas porque se topan con una caché fría, una pausa de recolección de basura, un bloqueo, un reintento o un vecino sobrecargado. La media aritmética mezcla los dos grupos en una cifra que no describe a nadie. Los profesionales usan percentiles en su lugar. El percentil 50 (p50, la mediana) es el valor que supera en rapidez la mitad de las solicitudes; p95 es el valor que supera el 95% de las solicitudes; p99 y p99.9 describen el 1% y el 0.1% más lentos.

El extremo lento de la distribución se llama cola (tail), e importa más de lo que parece. Los usuarios de la cola suelen ser tus mejores clientes: los de carritos más grandes, historiales más largos y más datos. Un usuario que carga 40 recursos para ver una página experimenta el más lento de esos 40, no la media. Y la probabilidad de que una página de 40 recursos se tope con al menos una solicitud de p99 es 1 − 0.99⁴⁰ ≈ 33%: un evento 'raro' del 1% afecta a un tercio de las visualizaciones de página.

# Why the mean misleads: 1,000 response times from one minute of traffic
import statistics

times_ms = [80] * 900 + [150] * 80 + [1200] * 15 + [4000] * 5

mean = statistics.mean(times_ms)
cuts = statistics.quantiles(times_ms, n=1000, method="inclusive")
p50, p95, p99, p999 = cuts[499], cuts[949], cuts[989], cuts[998]
print(f"mean {mean:.0f} ms, p50 {p50:.0f}, p95 {p95:.0f}, p99 {p99:.0f}, p99.9 {p999:.0f}")
# mean 122 ms, p50 80, p95 150, p99 1200, p99.9 4000

La latencia de cola a gran escala

La cola pasa a ser lo principal en los sistemas grandes que usan fan-out (abanico), en los que una solicitud de usuario se divide en muchas solicitudes paralelas a otros servidores y la respuesta debe esperar a todas ellas. Un buscador, un feed social o una página de recomendaciones pueden consultar decenas o cientos de shards de backend en cada consulta. Jeffrey Dean y Luiz André Barroso, de Google, lo analizaron en The Tail at Scale (Communications of the ACM, 2013).

Su ilustración es sencilla. Supón que cada servidor responde normalmente en 10 ms, pero tarda 1 segundo en una de cada 100 solicitudes. Una solicitud de usuario que espera a un solo servidor es lenta el 1% de las veces. Una solicitud de usuario que espera a 100 servidores así es lenta siempre que cualquiera de ellos lo sea: 1 − 0.99¹⁰⁰ ≈ 63% de las veces. Un evento raro en un servidor se convierte en el caso habitual para el usuario. Dean y Barroso aportan mediciones de un servicio de Google en el que la latencia del percentil 99 para una única solicitud hoja era de 10 ms, pero el percentil 99 de la espera de todas las solicitudes hoja era de 140 ms.

Como no se puede eliminar toda fuente de variabilidad (hardware compartido, trabajos en segundo plano, recolección de basura, colas de red), defienden diseños tolerantes a la cola, igual que los diseños tolerantes a fallos aceptan que el hardware falla. Sus técnicas incluyen las solicitudes de cobertura (hedged requests: enviar una segunda copia a otra réplica si la primera no ha respondido en, por ejemplo, el tiempo del percentil 95, y usar la que vuelva primero), las solicitudes vinculadas que se cancelan entre sí, particiones más finas que se pueden reequilibrar, excluir temporalmente las máquinas lentas y devolver un resultado suficientemente bueno cuando han respondido la mayoría de los shards, pero no todos. En una prueba de rendimiento que describen, enviar la solicitud de cobertura a los 10 ms redujo la latencia del percentil 99.9 de 1800 ms a 74 ms enviando solo alrededor de un 2% más de solicitudes.

La ley de Little: cuántas solicitudes hay en curso

La ley de Little, demostrada por John Little en 1961, es la fórmula individual más útil en la planificación de capacidad. Para cualquier sistema estable, el número medio de elementos dentro de él (L) es igual a la tasa media de llegada (λ, lambda) multiplicada por el tiempo medio que cada elemento pasa dentro (W): L = λ × W. Se cumple sea cual sea el patrón de llegada o el orden de servicio, siempre que el sistema sea estable (en promedio, salen tantos elementos como llegan) y uses unidades coherentes.

En el software, L es el número de solicitudes en curso a la vez (la concurrencia), λ es la tasa de solicitudes y W es el tiempo de respuesta. Si un servicio recibe 200 solicitudes por segundo y cada una pasa 0.25 segundos dentro, entonces en promedio hay 200 × 0.25 = 50 solicitudes en curso en cualquier momento. Ese número determina los grupos de hilos, los grupos de conexiones, la memoria y el número de licencias. La ley también funciona a la inversa: si puedes atender como máximo 50 solicitudes a la vez y cada una tarda 0.25 s, no puedes sostener más de 50 ÷ 0.25 = 200 solicitudes por segundo.

Utilización y colas: por qué los sistemas caen al abismo

La utilización (ρ, rho) es la fracción del tiempo en que un recurso está ocupado. Un servidor que recibe 40 solicitudes por segundo, cada una de las cuales necesita 20 ms de servicio, está ocupado 40 × 0.020 = 0.8 del tiempo: un 80% de utilización. La intuición sugiere que un recurso ocupado al 80% solo debería ser un poco más lento que uno ocupado al 50%. La teoría de colas dice lo contrario, porque las solicitudes no llegan de forma uniforme; se agrupan, y cuando se agrupan, las últimas esperan.

El modelo más sencillo es la cola M/M/1: llegadas aleatorias, tiempos de servicio aleatorios y un único servidor. Su tiempo de respuesta medio es W = S ÷ (1 − ρ), donde S es el tiempo de servicio medio. Con un 50% de utilización, W = 2S. Con un 80%, W = 5S. Con un 90%, W = 10S. Con un 99%, W = 100S. El denominador se acerca a cero a medida que la utilización se aproxima al 100%, así que el tiempo de respuesta crece sin límite. Los sistemas reales no son exactamente M/M/1, y los grupos con varios servidores se comportan mejor con la misma utilización, pero la forma es universal: plana, luego un codo y luego un abismo.

Las lecciones prácticas son directas. No planifiques ejecutar recursos críticos cerca del 100% de ocupación; deja margen para que las ráfagas no te empujen más allá del codo. Vigila la utilización y la longitud de la cola a la vez (el método USE de Brendan Gregg comprueba la utilización, la saturación y los errores de cada recurso). Y recuerda que el abismo hace peligrosos los cambios pequeños: con un 90% de utilización, un aumento del tráfico de solo un 6% aproximadamente te lleva al 95% y duplica el tiempo de respuesta medio. El Capítulo 9 trata las colas, el back pressure y la planificación de capacidad en Asincronía, colas y back pressure.

Escalabilidad: carga, elasticidad, escalado vertical y horizontal

La escalabilidad es la capacidad de manejar más carga añadiendo recursos, idealmente con una capacidad que crezca en proporción y sin rediseñar. Solo significa algo cuando dices qué es la 'carga'. Los parámetros de carga difieren entre sistemas: solicitudes por segundo para una API, conexiones simultáneas para un servicio de chat, la proporción entre lecturas y escrituras para una red social, el volumen de datos para una plataforma de analítica o el número de seguidores de la cuenta más seguida para un feed. Un escenario de escalabilidad nombra el parámetro de carga, el crecimiento y la respuesta que debe mantenerse: 'cuando los pedidos diarios crecen de 50 000 a 500 000, la latencia p95 del proceso de pago se mantiene por debajo de 1.5 s añadiendo instancias, con un costo por pedido no más de un 20% mayor'.

La elasticidad añade el factor tiempo: la capacidad de añadir y quitar capacidad automáticamente a medida que la carga sube y baja, de modo que un sitio de venta de entradas pueda crecer para una venta y reducirse después. Es una parte importante del argumento económico a favor de las plataformas en la nube. Hay dos formas básicas de añadir capacidad. El escalado vertical (scaling up) da a una máquina más CPU, más memoria o un almacenamiento más rápido; es sencillo, no requiere cambios en el software y choca con límites estrictos y precios crecientes. El escalado horizontal (scaling out) añade más máquinas y reparte el trabajo; no tiene un techo fijo, pero exige que el software esté diseñado para ello, con instancias sin estado, balanceo de carga y datos particionados. El Capítulo 9 trata las estrategias en detalle en Estrategias de escalado: vertical, horizontal y el cubo de escalado.

La ley de Amdahl: el límite del paralelismo

Añadir procesadores o nodos solo ayuda con el trabajo que se puede hacer en paralelo. La ley de Amdahl, del artículo de Gene Amdahl de 1967 sobre los límites de la computación paralela, recoge esta idea. Si una fracción s del trabajo es serie (debe hacerse paso a paso) y el resto, 1 − s, se puede repartir perfectamente entre N procesadores, la mejor aceleración posible es aceleración(N) = 1 ÷ (s + (1 − s) ÷ N). A medida que N crece sin límite, la aceleración se aproxima a 1 ÷ s. Con un 10% de trabajo serie, ningún número de procesadores puede hacer el trabajo más de diez veces más rápido.

La Ley de escalabilidad universal

La ley de Amdahl supone que los procesadores adicionales nunca empeoran las cosas; la aceleración simplemente se estanca. Los sistemas distribuidos reales a menudo sí empeoran: a partir de cierto punto, añadir nodos reduce el throughput. La Ley de escalabilidad universal (USL) de Neil Gunther lo modela con dos penalizaciones. La contención (α, alfa) es el costo de hacer cola por los recursos compartidos, el mismo efecto que la fracción serie de Amdahl. La coherencia (β, beta) es el costo de mantener los datos consistentes entre nodos: cada nodo debe intercambiar información con todos los demás, así que este costo crece aproximadamente con el cuadrado del número de nodos.

La capacidad relativa es C(N) = N ÷ (1 + α(N − 1) + βN(N − 1)). Con β = 0 se reduce a la ley de Amdahl. Con cualquier β mayor que cero, la capacidad alcanza un máximo en torno a N = √((1 − α) ÷ β) y luego cae. Para α = 0.03 y β = 0.002, el máximo está cerca de √(0.97 ÷ 0.002) ≈ 22 nodos, con una capacidad de unas 8.6 veces la de un nodo; con 32 nodos la capacidad ha vuelto a bajar a unas 8.2. Gunther describe el modelo en Guerrilla Capacity Planning (2007). Su valor práctico es que α y β se pueden ajustar a partir de un puñado de mediciones de pruebas de carga, lo que te permite predecir dónde dejará de compensar el escalado antes de comprar el hardware.

Tácticas de rendimiento: una visión general

Bass, Clements y Kazman agrupan las tácticas de rendimiento en dos familias. La primera es controlar la demanda de recursos: reducir cuánto trabajo llega o cuánto cuesta cada unidad. La segunda es gestionar los recursos: hacer que los recursos disponibles trabajen más o añadir más. La mayoría de los diseños reales combinan varias tácticas; cada una tiene también costos en otros ámbitos, y por eso son decisiones arquitectónicas.