Pruebas de carga: qué son y por qué tu sistema debería hacerlas antes que el cliente

Cada sistema funciona bien con un solo usuario. El problema empieza con mil al mismo tiempo.

La mayoría de los equipos descubren el límite de su propio sistema de la peor manera posible: en producción, durante el pico, con el cliente mirando. La campaña explota, el artículo se vuelve viral, llega la fecha límite para los impuestos y lo que parecía sólido se derrumba porque nunca nadie midió cuánto podría durar.

Existen pruebas de carga para invertir este orden. En lugar de que el usuario encuentre el límite por accidente, usted lo encuentra a propósito, en un entorno controlado, antes de que duela.

¿Qué es realmente una prueba de carga?

Las pruebas de carga consisten en someter al sistema a un volumen cada vez mayor de solicitudes o usuarios simultáneos para medir cómo se comporta bajo demanda. La pregunta que responde no es “¿funciona?”, sino “¿funciona con cuántos?”.

Note la diferencia. Una prueba funcional verifica que la funcionalidad es correcta. Una prueba de carga comprueba que sigue siendo correcta y rápida cuando lo utilizan muchas personas al mismo tiempo. Son preguntas distintas, y la segunda sólo aparece a escala.

Simula una cantidad realista de usuarios que realizan acciones reales, inician sesión, buscan, compran y observan el tiempo de respuesta, la tasa de error y el uso de recursos a medida que aumenta la carga. El resultado es un retrato de cómo se degrada el sistema.

La diferencia entre carga, estrés y rendimiento.

Vale la pena separar términos que muchas veces se confunden, porque cada uno responde a una pregunta diferente.

Las pruebas de carga miden el comportamiento bajo la demanda esperada y creciente, cuántos usuarios simultáneos admite el sistema con una calidad aceptable. Las pruebas de estrés se exceden, a propósito, para ver cómo el sistema colapsa y se recupera. Las pruebas de rendimiento, en un sentido amplio, miden los tiempos de respuesta y la eficiencia, a menudo bajo cierta carga.

Cargo responde "¿puede aguantar como se esperaba?" El estrés responde "¿qué pasa en el extremo?". Mantenerlos separados en su cabeza evita conclusiones erróneas de una prueba incorrecta.

Por qué se trata de una decisión empresarial, no sólo técnica

Es tentador tratar la carga como un detalle de ingeniería. Es un error. El límite de capacidad de su sistema es el límite de cuántos clientes puede atender al mismo tiempo, y eso es puro negocio.

Imagine un servicio público de programación que abre vacantes en un día específico. Toda la población elegible llega dentro del mismo período de tiempo. Si nadie ha probado la carga, el sistema falla justo cuando más importa y la falla se convierte en noticia de primera plana. El costo no es técnico; goza de confianza institucional.

Lo mismo ocurre con una startup que prepara un lanzamiento. Invertir en medios para generar un aumento en el tráfico y tener el sitio web fuera de línea en el momento del pico es quemar dinero dos veces: los medios y la reputación.

Qué medir y qué esconden las métricas

Las métricas obvias son el tiempo de respuesta y la tasa de error. Importan, pero sólo cuentan una parte de la historia.

El clima promedio es engañoso. Un buen promedio puede ocultar una fracción de usuarios con una experiencia terrible. Es por eso que miro los percentiles, el momento en que el 5% o el 1% experimentan la peor experiencia, en lugar de los promedios. Ahí es donde reside la verdadera frustración.

Además, observe los recursos detrás: uso de CPU, memoria, conexiones bancarias, cola de solicitudes. A menudo, el cuello de botella no es el servidor de aplicaciones, sino la base de datos o un grupo de conexiones de tamaño deficiente. La prueba de carga no sólo muestra que se ha degradado; bien instrumentado, muestra dónde.

Los errores más comunes

El primer error es realizar pruebas en un entorno que no parece de producción. Ejecutar cargas en una máquina pequeña o con un banco vacío genera números hermosos e inútiles. El entorno de prueba debe ser representativo y los datos deben tener un volumen similar al real.

El segundo es simular usuarios irreales. Mil solicitudes idénticas en el mismo punto final no reflejan el comportamiento humano. Los usuarios reales navegan, piensan, repiten acciones, abandonan. Un escenario de carga útil reproduce este patrón, no un robot uniforme.

La tercera, y la más común, es realizar la prueba una vez, antes del lanzamiento, y nunca más. La capacidad no es estática. Cada nueva característica, cada nueva consulta al banco, puede cambiar el límite. Las pruebas de carga no recurrentes tienen una validez corta.

Cuándo empezar a preocuparse

No todos los sistemas necesitan pruebas de carga desde el primer día. Un producto interno utilizado por diez personas no justifica el esfuerzo. La pregunta correcta es sobre la exposición a picos.

Si su sistema tiene momentos predecibles de demanda concentrada, campañas, plazos, lanzamientos, estacionalidad o crecimiento rápido de la base, las pruebas de carga ya no son opcionales. Y el mejor momento para la primera medición es antes del primer gran pico, no después.

El cambio de mentalidad que propongo es simple: la capacidad es un requisito, no una sorpresa. Conocer el techo de su sistema es tan importante como saber si cumple lo que promete. Uno te dice que funciona; el otro te dice cuánto tiempo seguirá funcionando cuando llegue el éxito.

Si su organización tiene un evento pico en el horizonte y nadie sabe con certeza si el sistema podrá manejarlo, este es el tipo de riesgo que vale la pena abordar de antemano, no durante. Tengo otros textos en el blog sobre rendimiento, escalabilidad y confiabilidad que hablan de este.