Para alcanzar un buen nivel de rendimiento de un sistema, es vital que las pruebas comiencen en el inicio del desarrollo del software.

El plan de pruebas de performance detalla lo que se debe ejecutar en el tiempo que hemos asignado para la prueba. De tal forma que se puedan responder las preguntas sobre el rendimiento del sistema, después de haber ejecutado la menor cantidad de ejecuciones posibles.

En este post hablaremos sobre los tipos que existen y cómo diseñar un plan de pruebas de performance, antes de decidir cómo simular la carga.

¿Qué son las pruebas de performance?

Las pruebas de performance simulan la carga esperada del sistema en un entorno similar al de producción, pudiendo encontrar cuellos de botella y oportunidades de mejora.

Recordemos que en la medida en que se detectan problemas asociados al rendimiento lo antes posible, se logra un ahorro importante en el tiempo, dinero y dolores de cabeza.

¿Le interesa mejorar la performance de un sitio o sistema web pero no sabe por donde empezar? Llegó al lugar correcto, ¡continúe leyendo!

Definición de un plan de pruebas de performance

En primer lugar, al hablar de un plan de performance testing, no nos referimos propiamente al documento, sino a lo que se va a ejecutar en el tiempo que se tiene destinado a las pruebas.

De esta forma, se propone que con la menor cantidad de ejecuciones posibles, seamos capaces de responder los interrogantes de performance por los cuales nos indicaron hacer la prueba.

Primero, es necesario saber qué preguntas vamos a contestar con los resultados, de acuerdo a cada uno de los tipos de prueba de performance:

1. Prueba de estrés

¿Cuál es la cantidad máxima de usuarios concurrentes que soporta el sistema con una experiencia de usuario aceptable? O sea, ¿cuál es el punto de quiebre?

2. Prueba de carga

Dado el escenario actual de carga del sistema, ¿cómo se comportará la aplicación? ¿Qué oportunidades de mejora encuentro para ese escenario esperado?

3. Prueba de resistencia

¿Cómo funcionará el sistema luego de estar cierto tiempo ejecutando, digamos luego de estar un día entero en régimen? (En algunos casos esto implicó tomar acciones como la de reiniciar el servidor cada noche, hasta encontrar una solución definitiva a algún leak presente en el sistema).

4. Peak testing

Si mi sistema en régimen normal funciona adecuadamente y viene un peak de estrés (la casuística hace que en un mismo momento coincidan muchas más peticiones que lo normal, ante lo cual sé que los tiempos de respuesta quizá empeoran por debajo de lo aceptable), entonces ¿qué tan rápido se recupera el sistema?

Tipos de pruebas de performance más comunes

Otras consideraciones

En cualquier caso, hay otra pregunta que está siempre presente en toda prueba de performance: ¿cuáles son los cuellos de botella principales, y cómo soluciono los limitantes con los que me encuentre?

Incluso podríamos responder cosas como por ejemplo: ¿mi equipo está preparado para cuando algo así pase en producción o necesito aprender algo más? ¿Qué disponibilidad de recursos físicos tengo disponibles o cuán difícil es conseguirlos? ¿Qué tan rápido damos soluciones a problemas asociados al rendimiento?

Con estos interrogantes ya tenemos mucho para trabajar. Muchas veces es necesario revisar los access log del sistema para tener una idea de la cantidad de usuarios que se conectan a diario. O bien, tenemos que hacer estimaciones y averiguaciones de cuántos usuarios se esperan recibir.

Al momento de diseñar las pruebas de performance, todo lo anterior se refina mucho más, ya que es necesario indagar qué hacen cada uno de esos usuarios (qué casos de prueba, con qué datos, etc.)

En lo que me quiero centrar en este post es cómo ejecutar ese escenario de carga.

¿Con cuántos usuarios concurrentes ejecuto las pruebas de performance?

Algo que ya he repetido tantas veces y que ahora ya debe ser verdad: si diseñamos/definimos nuestro escenario de carga con una cantidad X de usuarios, no podemos comenzar ejecutando una prueba que simule los X usuarios concurrentes en un primer momento.

Si hacemos eso, por experiencia, es posible que aparezcan tantos problemas a la vez que no sabremos por dónde comenzar. De ahí es que surge la idea de aplicar una metodología iterativa incremental para un plan de pruebas de performance.

Iterativa porque se van ejecutando distintas iteraciones de prueba, de manera incremental. Comenzando con una cantidad reducida de usuarios concurrentes, solucionando los problemas que se vayan identificando, e ir avanzando mientras se aumenta la concurrencia.

Ejemplo de prueba de carga

Consideremos como primer ejemplo que estamos haciendo una prueba de carga, donde el objetivo es analizar si el sistema soporta 1.000 usuarios concurrentes (aclaración: no estoy teniendo en cuenta el tema de entorno de test, y qué tan similar es al de producción, y cómo definir el alcance en base a la diferencia de los ambientes).

  1. Primera prueba: Un usuario sin concurrencia (esto puede servir como baseline, para comparar luego, puede ser con 1, 5, 10 o más, pero tiene que ser algo sumamente reducido para lo esperado en el sistema).
  2. Segunda prueba: 200 usuarios concurrentes (o sea, el 20% de la carga esperada). Aquí ya se puede obtener muchísima información sobre qué tan difícil va a ser completar la prueba, tanto en tiempo como en forma.

Al ejecutar estas primeras pruebas vamos a resolver los problemas más “gruesos”: las configuraciones por defecto (pools de conexión o tamaño del heap de Java por ejemplo). También vamos a tener una idea de cómo escala el sistema, comparando los tiempos de respuesta con respecto al baseline.

Una vez que se termina el análisis y resolución de problemas, se vuelve a ejecutar esta prueba hasta que se obtengan tiempos aceptables.

Según qué tan ajustados sean esos resultados vamos a decidir si la tercera prueba será la del 40% (para seguir con incrementos de a 20) o si vamos con 50% de la carga (pensando en pasar luego al 75 y al 100), o si el sistema responde muy bien, quizá nos animemos a pasar directamente a más.

En cualquier caso, lo que queremos tener al final es una gráfica que nos muestre los tiempos de respuesta obtenidos con cada prueba (con cada porcentaje de la carga esperada), y así podremos ver cómo fue evolucionando el sistema gracias a nuestro trabajo.

Ejemplos de pruebas de carga o load test

En la anterior gráfica, vemos por ejemplo cómo se ejecutaron distintas pruebas incrementando de a 20% la carga.

Además, se puede observar fácilmente que se repitieron las pruebas hasta alcanzar el SLA esperado en cada caso, y recién al alcanzarlo, se pasó al siguiente escalón.

Ejemplo de prueba de estrés

Como segundo ejemplo, imaginemos que queremos encontrar el punto de quiebre del sistema con una prueba de estrés.

Para eso queremos ejecutar distintas pruebas, con distintas cantidades de usuarios, analizando si al aumentar la concurrencia sigue aumentando el throughput (si al aumentar la concurrencia no aumenta las transacciones por segundo, eso indica que llegamos al punto de quiebre, ya que se está saturando el sistema en algún punto, sin escalar).

Si comenzamos a ejecutar pruebas con números de usuarios al azar, va a ser un tiro al blanco de ojos cerrados y perderemos mucho tiempo. Por lo que la mejor estrategia es ejecutar una “prueba exploratoria de performance“. Esto con el fin de tener una primera idea de dónde está ese punto de quiebre.

Para ello, ejecutamos una prueba incremental de 0 a X, donde X es una cantidad de usuarios grande (digamos 1.000 para considerar una generadora de carga sola) y que creemos que el quiebre tiene que estar en ese rango.

Lo que se puede hacer en cualquier herramienta de simulación de carga para ejecutar esta prueba es establecer un ramp-up uniforme durante el tiempo de la prueba.

En otras palabras, si queremos que esa prueba dure una hora, configuramos para que la prueba comience con cero usuarios concurrentes, y al cabo de una hora tenga 1.000. De esta manera, vamos a poder tener una primera aproximación hacia cuando el throughput del sistema se degrada. Si observamos que es alrededor de los 650 usuarios, ahí podemos comenzar a refinar ejecutando pruebas puntuales.

Por ejemplo, podríamos ejecutar una prueba con 500, otra con 600, otra con 700. Si efectivamente la prueba de 700 usuarios tiene menos throughput que la de 600, hay que refinar y ejecutar una con 650, y así seguimos con el punto medio, hasta mejorar la precisión.

Ejemplo de prueba de resistencia

Para una prueba de resistencia, es aconsejable ejecutar una carga constante que esté entre el 50 y el 70% de la carga soportada por el sistema en condiciones aceptables. Si bien podría servir una carga menor, todo dependerá de qué tan complejo sea preparar los datos de prueba para poder ejecutar durante muchas horas.

Por lo general estas pruebas se ejecutan una vez terminadas las pruebas de estrés o carga que se hayan realizado, para intentar identificar otros tipos de problemas (memory leaks, conexiones colgadas, etc.).

Si se cuenta con tiempo, datos y lo que se necesite para esto, se podrían incrementar las cargas que se utilicen para las pruebas, ejecutándolas en forma prolongada.

Ejemplo de peak testing

Como dijimos antes, la idea es ver qué pasa cuando hay un peak y qué tanto le cuesta al sistema recuperarse. En este contexto, pueden surgir varios interrogantes, tales como: ¿Si hay un peak entonces el sistema me queda colgado? ¿A los 10 segundos se recupera, o a las dos horas?

Para esto, es necesario conocer de partida cuál es el punto de quiebre del sistema y así poder preparar una prueba que esté por debajo de ese umbral. De este modo generar un peak subiendo la carga por un período de un minuto por ejemplo, y luego bajarla.

El enfoque incremental que se puede aplicar aquí es en el peak en sí. Se podría comenzar experimentando con peaks pequeños (de corta duración o poca carga), y luego estudiar cómo reacciona el sistema ante peaks mayores.

En cualquier caso, esto es algo que se debe modelar en base a un estudio de comportamientos de los usuarios, especialmente en base a los access logs que se tengan a disposición.

¿Cómo ejecutar las pruebas de performance?

La forma de ejecutar pruebas de performance varía según el tipo de prueba. Es decir, depende de la pregunta a la que queremos encontrar respuesta.

En términos generales el enfoque de las pruebas persigue un mismo objetivo: reducir la cantidad de pruebas que ejecutamos, optimizando la relación costo-beneficio del testing.

Preguntas frecuentes sobre pruebas de performance - Abstracta Chile

Para esto, lo ideal es seguir un enfoque iterativo incremental (para pruebas de carga, endurance y peaks). Así como un enfoque iterativo de refinamiento (para pruebas de estrés).

Por último, tener en cuenta también que estos tests se deben repetir con liberaciones de nuevas versiones para evitar que se introduzcan “errores” o cambios que degraden la performance. O sea, así como se ejecutan tests de regresión, también considerar performance dentro de esas regresiones.

Si necesita ayuda para definir su plan de pruebas de performance, escríbanos o envíenos un mail a [email protected], y le contactaremos a la brevedad para conocer más sobre su proyecto.


Posts recomendados

Herramientas para pruebas de performance: ¿cómo prepararse para Black Friday?

Los 8 desperdicios de la metodología Scrum