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.
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.