¿Buscas crear un plan de pruebas de rendimiento? Mira estas importantes consideraciones antes de decidir cómo simular la carga.

Este plan de pruebas 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.

¿Qué son las pruebas de performance?

Las pruebas de performance consisten en simular carga en el sistema bajo pruebas para analizar su desempeño durante la ejecución de la prueba, pudiendo encontrar cuellos de botella y oportunidades de mejora.

Recordemos que en la medida en que se detectan problemas de performance 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 las interrogantes de performance por las cuales nos indicaron hacer la prueba.

Primero, es necesario saber qué preguntas vamos a contestar con los resultados de las pruebas. A continuación, se resumen los ejemplos más comunes:

1. Prueba de estrés (stress testing)

¿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 (load test)

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 (endurance)

¿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. Prueba de peaks

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?

Preguntas frecuentes sobre las pruebas de rendimiento - Abstracta Chile

Otras consideraciones para diseñar una prueba de rendimiento

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 problemas o limitantes con las que me encuentre?

Pueden surgir preguntas como por ejemplo: ¿mi equipo está preparado para cuando algo así pase en producción o necesito aprender algo más?

Por otro lado, ¿qué disponibilidad de recursos físicos tengo disponibles o cuán difícil es conseguirlos? o ¿qué tan rápido damos soluciones a problemas de performance?

Con todo lo anterior 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, hacer estimaciones y averiguaciones de cuántos usuarios se esperan recibir.

Al momento de diseñar la prueba 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.).

Ahora bien, ¿cómo ejecutar ese escenario de carga? Veamos en las próximas líneas la mejor forma.

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

Algo que ya lo he repetido tantas veces 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, seguramente (por experiencia) aparezcan tantos problemas a la vez que no sabremos por dónde comenzar.

Y es precisamente 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 exponencial. Comenzando con una cantidad reducida de usuarios concurrentes, solucionando los problemas que se vayan identificando, y avanzando aumentando la concurrencia.

Ejemplo de prueba de carga

Consideremos como primer ejemplo que estamos haciendo una prueba de carga, donde el objetivo de la prueba 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).

  • Primera prueba: 1 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).
  • 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 la vamos a tener para completar la prueba en tiempo y 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), y 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, por Federico Toledo - Abstracta Chile

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. Esto 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 rampup 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 endurance

Para una prueba de endurance, diría de ejecutar una carga constante que esté entre el 50 y el 70% de la carga soportada por el sistema en condiciones aceptables. Podría servir una carga menor también, 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 prueba de peaks

Para una prueba de peaks como dijimos antes, la idea es ver qué pasa cuando hay un peak, qué tanto le cuesta al sistema recuperarse.

Si hay un peak entonces ¿el sistema me queda colgado? ¿a los 10 segundos se recupera? ¿a las dos horas se recupera?.

Para esto es necesario ya conocer cuál es el punto de quiebre del sistema, para poder preparar una prueba que esté por debajo de ese umbral. De esta 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 los 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 o rendimiento, por Federico Toledo - 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.

Es decir, así como se ejecutan tests de regresión, también considerar performance dentro de esas regresiones.

Artículo original tomado del blog de Federico Toledo.

Si necesitas ayuda para definir tu plan de pruebas de performance, no dudes en contactarnos. D.


Posts recomendados