Diseño de test de carga

A la hora de implementar nuestras pruebas de carga tendremos que tener en cuenta los entornos disponibles para el desarrollo y la diferente causística de cada uno de ellos.

• Entorno local: Las limitaciones las provee la máquina del desarrollador. El servidor Weblogic incluido no está configurado con los parámetros finales del resto de entornos. Los resultados de los test deben servir como guía para una primera optimización de código, pero se deben validar con el entorno de desarrollo. En este entorno tendremos control absoluto sobre la monitorización del servidor por lo que sabemos en todo momento los recursos que está consumiendo.

• Entorno de desarrollo: Un único servidor dispuesto por el departamento de sistemas con una asignación de recursos ajustada. Un resultado negativo de las pruebas de carga implicará revisar la aplicación e intentar mejorar el rendimiento. En aplicaciones de tamaño grande es posible aumentar la memoria de este entorno para que se acerque a la del entorno de test, pero por norma general no es necesario hacerlo.

• Entorno de preproducción: Cluster de dos servidores con una asignación de recursos estándar. La aplicación debería funcionar correctamente en este entorno sin problemas. Un resultado negativo de los test invalida el despliegue en producción de dicha aplicación. En este caso se deberá revisar el código fuente.

• Entorno de producción: Cluster de dos/cuatro servidores con la asignación de recursos validada en el entorno de test. Por defecto será la estándar salvo que, en aplicaciones de gran tamaño, se requiera ampliar para su correcto funcionamiento. Esta ampliación debe estar siempre justificada y tras haber realizado todas las optimizaciones posibles en el código de la aplicación.

Tras las propiedades y limitaciones de los diferentes entornos, debemos preparar un plan adaptado a cada uno de ellos para optimizar los datos que nos mostrará JMeter. En base a los resultados obtenidos también tendremos que interpretarlos según el entorno en el que lo hayamos ejecutado.

En este entorno las limitaciones las impone nuestro servidor y no existen daños colaterales por lo que podemos lanzar las pruebas más agresivas en este entorno sin causar problemas en otros desarrollos. También tenemos que tener en cuenta que las características de nuestra máquina limitarán los resultados de las pruebas.

El objetivo principal de esta fase es encontrar los límites de nuestro servidor local y detectar código mejorable en nuestra aplicación.

La primera etapa a realizar será intentar “tirar” el servidor. Una vez que tengamos los test de carga los ejecutaremos con un número elevado de conexiones e iremos repitiendo hasta que el servidor empiece a fallar. Esto nos dará una idea de cuantas conexiones concurrentes puede soportar el servidor.

Una vez alcanzado ese punto vemos si las conexiones soportadas son mayores de la media esperada en nuestra aplicación en un pico máximo, en caso afirmativo podemos seguir con el siguiente punto.

En la segunda etapa pondremos una carga media y dejaremos el test funcionando un largo periodo de tiempo. Con esta prueba comprobaremos si el servidor libera bien la memoria y se mantiene estable con una carga media estimada de usuarios accediendo a él.

La última fase a ejecutar sería crear ráfagas de tráfico. Para ello arrancaremos un test como el anterior con carga media y paralelamente lanzaremos otro test que simule picos de conexión. De esta manera podremos comprobar cómo el servidor asume y se recupera de ráfagas de tráfico.

Con estas tres medidas, y aunque el rendimiento de los test esté condicionado por nuestra máquina, podremos ya tener una idea aproximada de si nuestra aplicación requiere ajustes o no.

En este entorno las limitaciones ya son puestas por el departamento de sistemas y nos encontraremos ante una reserva de recursos asumible para aplicaciones medianas y pequeñas.

En este caso, no será necesario realizar la primera etapa que lanzamos en nuestro entorno local. Sólo la lanzaremos si nuestra aplicación recibe mucho tráfico en muy poco tiempo. En ese caso y con la monitorización del departamento de sistemas buscaremos el límite del servidor y ampliaremos recursos en caso de ser necesario y asegurarnos de que nuestra aplicación no tiene más optimizaciones que hacer.

Las dos fases siguientes, carga media y carga media con picos sí las tendremos que realizar. Monitorizaremos con la ayuda del departamento de sistemas el consumo de memoria, las consultas reales que se han hecho en el servidor y el tiempo de respuesta. En base a esto decidiremos si nuestra aplicación pasa los test de calidad o requiere ajustes.

Este entorno es una copia del entorno real que se espera en producción por lo que las limitaciones que se encuentren serán las reales y salvo para aplicaciones de gran carga, validadas por sistemas, o casos excepcionales, no se deberían ampliar los recursos.

En este caso el lanzamiento de test debe estar monitorizado, coordinado por el departamento de sistemas para evitar afectar colateralmente a otras aplicaciones.

Seguiremos el mismo protocolo utilizado en el entorno de desarrollo validando con ello que la aplicación no solo funciona correctamente en un nodo, sino que el cluster funciona correctamente manteniendo un tiempo de respuesta acorde a lo esperado.

Este es el entorno real donde las aplicaciones definitivamentne estarán desplegadas. Las pruebas realizadas simplemente deben validar las realizadas en el entorno de preproducción.

En este caso el lanzamiento de test debe estar monitorizado, coordinado y supervisado por el departamento de sistemas. NO se lanzará la primera etapa de test.

• Cuando lancemos los test en los entornos probablemente implicará modificaciones en base de datos. Es imprescindible limpiar los datos guardados en producción y, si se accede a servicios de terceros que almacenen información, no lanzar esos servicios o saber cómo deshacer los cambios realizados.

• A la hora de realizar las pruebas de test de carga contra un servidor, nuestra tarjeta de red será factor limitante por lo que es interesante realizar test de carga distribuidos los cuales podemos configurar en este enlace Test de carga distribuidos

• Nunca lanzar test de carga en producción si no han sido validado en preproducción.