Cuando los equipos hablan de pruebas de rendimiento, la atención a menudo se dirige directamente al número: ¿cuántos usuarios puede soportar el sistema? Pero ese número, por sí solo, significa muy poco. Un sistema que “sobrevive” a 1.000 o incluso a 50.000 usuarios no te dice cuándo comenzaron a degradarse las prestaciones, cómo surgieron los errores ni si la aplicación se recuperó después de que la presión disminuyó.
Lo que importa tanto (y a menudo más) es cómo se aplica esa carga. La forma del tráfico que generas durante una prueba, conocida como la curva de carga, determina si te irás con un veredicto binario de aprobado/rehuso o con ideas técnicas reales. Una curva mal elegida solo te dirá “sí, el sitio se mantuvo activo” o “no, se cayó”. Una curva bien estructurada, en cambio, revela umbrales, cuellos de botella y resiliencia: dónde aparecen las primeras grietas, con qué rapidez se extienden y si el sistema se recupera una vez que la demanda disminuye.
Por eso la curva de carga es tan importante como el tamaño de la prueba. Una subida contundente hasta un número elevado puede parecer impresionante en un gráfico, pero oculta la historia detrás del resultado. Las curvas bien pensadas exponen el comportamiento real de tu aplicación bajo estrés, identifican debilidades antes que tus usuarios y ofrecen al equipo la información necesaria para reforzar el rendimiento donde más importa.
¿Qué es una curva de carga?
Una curva de carga es la progresión del tráfico a lo largo del tiempo. En lugar de centrarse en el número total de usuarios virtuales, piensa en ella como una gradación o cola que representa cómo las personas realmente llegan e interactúan con tu sistema. Los ingenieros de rendimiento suelen distinguir entre concurrencia (usuarios simultáneos) y rendimiento (transacciones por segundo), ya que ambos modelan el comportamiento del sistema de manera diferente.
- ¿Con qué rapidez aumentan los usuarios? Un goteo se siente distinto a una avalancha.
- ¿Llegan de forma constante o en ráfagas? Diferentes curvas exponen distintos riesgos.
- ¿Pausas en ciertos niveles para observar la estabilidad? Esos plateaus pueden revelar grietas sutiles.
- ¿Mantienes la carga máxima o liberas el tráfico tan rápido como lo aplicaste? La demanda real a menudo implica ambas cosas.
Este es el verdadero valor de modelar la curva: no se trata solo de alcanzar la carga máxima, sino de observar cómo se comporta el sistema en cada etapa.
La sola concurrencia no explica toda la historia. Dos pruebas que afirman “1.000 usuarios concurrentes” pueden parecer radicalmente diferentes. Una puede ser una rampa suave que solo te dice si el sitio aguantó al final. La otra puede ser una sucesión de escalones que revela exactamente dónde aumentó la latencia, dónde empezaron las tasas de error y en qué nivel se vino abajo tu infraestructura.
Curvas de carga comunes en las pruebas de rendimiento
Existen diferentes curvas de carga por una razón: cada una destapa un tipo distinto de debilidad. Vamos a repasar los modelos más utilizados.
Ramp-up lineal
La prueba más simple. Se añaden usuarios virtuales de forma constante hasta alcanzar el objetivo. Esta curva es fácil de configurar y útil para calentar el sistema, pero también es la menos informativa. Todo lo que aprendes es si el sistema soportó la carga completa. No ves cuándo empezaron a ir mal las cosas, solo si estaban mal al final.
Ramp por pasos (escalera)
Un enfoque más pensado. El tráfico aumenta por incrementos, con pausas en cada paso. Esos plateaus son ventanas de observación: los momentos en que la latencia, los errores y el uso de recursos se estabilizan para que puedas identificar con precisión cuándo empiezan a degradarse las prestaciones. ¿Aparecieron las grietas con 10 usuarios? ¿60? ¿90? La escalera expone umbrales que una subida lineal podría no mostrar.
Pico y mantenimiento
Aquí, el tráfico sube hasta un objetivo y se mantiene ahí. Se trata menos de encontrar el punto de caída y más de ver si tu sistema puede sostener la presión una vez que alcanza un estado estable. Esta curva es invaluable para comprobar el comportamiento de la escalabilidad automática, el ajuste de pools de conexiones o si los servicios aguas abajo pueden soportar estrés constante.
Pruebas de picos
No todas las fallas son quemaduras lentas. A veces, el tráfico llega de golpe. Una prueba de picos simula esos aumentos: lanzamiento de producto, una oferta del Black Friday o un momento viral en redes sociales. Descubres qué tan bien absorbe tu plataforma un impacto repentino y si se recupera con gracia una vez que pasa la avalancha.
Soak / Pruebas de resistencia
Las pruebas cortas se pierden los problemas que solo aparecen tras horas de carga. Una prueba de resistencia se ejecuta a intensidad moderada durante largos periodos. Así es como descubres fugas de memoria, agotamiento de recursos, latencia creciente e inestabilidad que se construye gradualmente. Para plataformas críticas financieras, SaaS o gubernamentales, las pruebas de resistencia a menudo revelan los fallos de fiabilidad más graves.
Por qué la curva más simple suele ser la peor
Es tentador empezar con una subida lineal suave. Luce ordenada, es fácil de configurar y produce un resultado redondo: el número máximo de usuarios que tu sistema soportó antes de fallar. Pero ordenado no equivale a útil.
El problema es que una rampa lineal empinada oculta detalles críticos. ¿Empezaron a decaer las prestaciones con 200 usuarios pero se colapsaron a 800? ¿La latencia fue aumentando paso a paso mucho antes de que aparecieran errores? Muchos equipos han aprendido por las malas que confiar solo en esta curva los deja ciegos ante las señales tempranas.
Si ejecutas una rampa contundente, no lo sabrás. Te quedarás con una respuesta binaria. Saberás si sobrevivió o se cayó, y tendrás poca información sobre por qué. Eso puede bastar para una demo rápida, pero es inútil para decisiones de ingeniería y peligroso en producción.
Cómo elegir la curva correcta según tus objetivos
No existe una curva que funcione mejor en todas las situaciones. La elección adecuada depende del tipo de fallos que quieras exponer y de los conocimientos que esperas obtener de la prueba. Emparejar la curva con el objetivo es lo que separa las pruebas de rendimiento útiles de los gráficos bonitos pero sin sentido.
Para el descubrimiento de capacidad, las rampas por pasos son las más reveladoras. Manteniendo cada plateau, puedes observar cómo se asientan las métricas e identificar el punto exacto en que los tiempos de respuesta empiezan a doblarse o las tasas de error empiezan a aumentar. Esa precisión facilita rastrear los problemas hasta componentes concretos —ya sea una base de datos saturada, una caché abrumada o pools de hilos agotados.
Al probar la resiliencia bajo estrés, las pruebas de picos y las de pico y mantenimiento son invaluables. Un pico repentino muestra si tu sistema puede manejar una oleada inesperada sin fallos en cascada. El pico y mantenimiento revela cómo se comporta el sistema una vez que alcanza una carga elevada y estable: ¿responden los auto-scalers a tiempo?, ¿se estabilizan las prestaciones?, ¿o la plataforma se derrumba lentamente?
Para la fiabilidad a largo plazo, nada supera a una prueba de resistencia. Problemas como fugas de memoria, acumulación de colas y la latencia creciente no salen en ejecuciones cortas. Mantener tráfico moderado durante horas o toda una jornada laboral muestra si tu sistema puede soportar el desgaste lento del uso real.
El principio es simple: elige la curva que se alinee con el riesgo que más necesitas entender. Todo lo demás produce datos que lucen impresionantes pero no ayudan realmente a mejorar la fiabilidad.
Consejos prácticos para diseñar curvas de carga
Elegir la curva correcta es solo la mitad del trabajo —la otra mitad es darle forma correctamente. Las pruebas mal diseñadas pueden hacer perder horas y ocultar umbrales, mientras que las bien diseñadas actúan como experimentos controlados que explican no solo si el sistema falla, sino cómo y por qué.
- La velocidad de subida importa. Demasiado agresiva y sobrepasarás el umbral de fallo sin capturarlo. Demasiado lenta y no alcanzarás una carga significativa dentro de la ventana. Los mejores diseños equilibran realismo y visibilidad.
- Deja que los pasos se estabilicen. Cuando pauses en cada nivel, da al sistema tiempo para calentar caches, disparar auto-scalers y dejar que los procesos de fondo se asienten. Si no, estarás midiendo caos, no comportamiento en estado estable.
- Mira más allá de los fallos totales. Las interrupciones son dramáticas, pero las métricas sutiles a menudo dicen más: aumento de p95/p99, porcentajes de error crecientes o CPU y memoria acercándose a la saturación. Son señales tempranas que permiten arreglar cuellos de botella antes de que los usuarios los noten.
- Manténlo simple. Más curvas no siempre son mejores. En la práctica, dos o tres modelos bien elegidos, como una rampa por pasos para umbrales y una prueba de resistencia para durabilidad, ofrecen la mayoría de las ideas accionables sin complicar en exceso la suite de pruebas.
Trata tus curvas de carga como experimentos: diseñadas con intención, ejecutadas con disciplina y observadas para señales que expliquen no solo si el sistema falla, sino cómo y por qué.
Escenarios de ejemplo
Comercio electrónico: tráfico de Black Friday
Las plataformas de venta viven o mueren por su rendimiento en eventos como el Black Friday. El tráfico no se construye lentamente: se dispara en el momento en que las ofertas se activan. Una prueba de picos muestra si el sitio puede sobrevivir a la avalancha, mientras que una de pico y mantenimiento valida si los flujos de pago se mantienen estables bajo alta demanda durante horas.
Plataformas SaaS: picos de incorporación
Cuando se lanza un nuevo producto o un cliente grande se incorpora, los servicios compartidos como la autenticación o las bases de datos pueden verse desbordados. Una rampa por pasos resalta el umbral de concurrencia donde estos servicios empiezan a degradarse, dando a los ingenieros evidencia para reforzar puntos débiles antes de que los clientes sufran problemas.
Sistemas financieros: horas de negociación
Las plataformas de trading y las apps financieras deben mantenerse estables durante largas sesiones. Una prueba de resistencia durante las horas del mercado revela fallos lentos como fugas de memoria, acumulación de colas y la latencia creciente que las pruebas cortas no detectan. Estos problemas pueden no provocar un fallo catastrófico, pero erosionan silenciosamente la fiabilidad.
Medios y entretenimiento: eventos de streaming en vivo
Las plataformas de streaming suelen experimentar una acumulación constante seguida de un pico brusco al inicio del evento. Una curva híbrida, como una rampa en escalera seguida de un pico, muestra si la infraestructura de vídeo puede manejar tanto el calentamiento como la aplastante afluencia de espectadores de última hora sin degradar la calidad del streaming.
Gobierno y servicios públicos: picos por fechas límite
Portales fiscales, sistemas de permisos y solicitudes de prestaciones a menudo enfrentan picos impulsados por plazos. Una rampa por pasos combinada con pico y mantenimiento revela si estos sistemas pueden gestionar días de aumento progresivo del tráfico y seguir siendo utilizables cuando la carga alcanza su máximo justo antes del cierre.
Conclusión
La forma de tu prueba es tan importante como su tamaño. Una curva mal diseñada puede darte un titular llamativo tipo “soportamos 10.000 usuarios”, pero no te mostrará dónde empezó a fallar realmente el sistema ni cómo se vio afectado el usuario.
Las buenas curvas de carga ofrecen más que presunción. Revelan umbrales, localizan cuellos de botella y muestran si el sistema puede recuperarse con gracia una vez que pasa el estrés. Por eso los ingenieros de rendimiento tratan el diseño de curvas como la preparación de un experimento, no como un adorno.
Así que no trates la curva como una ocurrencia tardía. Trátala como el instrumento de tu prueba. Elige las curvas deliberadamente, adáptalas a tus preguntas y obtendrás resultados que realmente mejoren el rendimiento en lugar de meros logros en un informe.