Cómo realizar pruebas distribuidas en JMeter

Si tiene un sitio de comercio electrónico (o cualquier sitio para el caso), no es raro que espere un mayor nivel de tráfico en ciertos días, como el Viernes Negro, por ejemplo. En momentos como estos, necesitamos llevar nuestras pruebas de carga al siguiente nivel y simular un mayor número de usuarios simultáneos. Si estamos ejecutando nuestras pruebas de carga localmente con Apache JMeter™, hay ciertas limitaciones en el número de usuarios que puede ejecutar, incluso si su computadora tiene suficiente CPU y memoria.

¿Cómo podemos crear un escenario con más de 800 usuarios simultáneos utilizando JMeter? Una de las respuestas es ejecutar JMeter en modo distribuido. Para aquellos de ustedes que nunca han oído hablar de él, aquí hay una breve explicación.

Cuando hablamos de distribuir JMeter, nos referimos a una arquitectura Maestro-Esclavo donde JMeter usa Java RMI para interactuar con objetos en una red distribuida. Puedes ver esto en la imagen de abajo.

Las pruebas distribuidas permiten tener un JMeter local (maestro) que maneja la ejecución de la prueba, junto con varias instancias JMeter remotas (esclavos) que enviarán la solicitud a nuestro servidor de destino.

Pero antes de poder ejecutar JMeter de forma distribuida, hay un par de pasos simples que debe realizar.

En primer lugar, necesitamos tener varios ordenadores.

Entonces necesitamos que el servidor JMeter se ejecute en cada sistema esclavo que tengamos. Para ello, tenemos que ejecutar el servidor jmeter.bat (jmeter-servidor para usuarios Unix) que se encuentra en el jmeter/bin. Una vez que lo ejecutemos deberíamos ver algo como esto:

Luego, a través de la misma ruta, pero en el sistema maestro, localice el jmeter.propiedades fil. Edite este archivo y agregue las direcciones IP de todos los sistemas esclavos que deberían estar involucrados en la propiedad remote_hosts. Asegúrese de que los sistemas maestro y esclavo estén ubicados en la misma subred.

Es muy importante recordar que todos los valores deben estar separados por comas (en este ejemplo estamos usando un solo sistema esclavo, solo para mantenerlo simple).

Una vez que se hayan completado todos estos pasos, podemos iniciar JMeter y ejecutar las pruebas que necesitamos. En este caso, vamos a ejecutar JMeter usando el Modo GUI, para que podamos tener una mejor idea de cómo funciona. Sin embargo, se recomienda encarecidamente el modo sin interfaz gráfica de usuario para fines de prueba.

El número de usuarios, la rampa ascendente y las iteraciones deben configurarse en el Grupo de subprocesos de sistemas maestros como de costumbre. Al ejecutar la prueba, estas condiciones se replicarán en cada sistema esclavo.

Después de iniciar JMeter y cargar nuestra prueba, tenemos dos opciones. Una, configurada a través del sistema maestro, es a través de Run – > Inicio remoto y luego seleccionar el sistema esclavo donde queremos ejecutar. El segundo, también configurado a través del sistema maestro, es Run->Remote Start All para iniciar la prueba en todos los sistemas esclavos disponibles.

(Como configuramos un solo sistema esclavo, no hay diferencia entre las dos opciones en este ejemplo).

Aquí tenemos un escenario simple donde podemos buscar y ver un artículo en un sitio de comercio electrónico:

Como puede ver, hemos agregado un listener de Árbol de resultados de vista para que podamos verificar si la prueba se ejecutó correctamente o no. Cuando ejecutamos una prueba de forma remota, vamos a poder ver localmente el resultado de la prueba en el oyente del árbol de resultados de la vista, como ya mencioné, pero en los sistemas esclavos, solo podemos observar la hora de inicio y la hora de finalización de la prueba.

Localmente:

De Forma Remota:

Entre bastidores, cada sistema esclavo ejecuta las pruebas de carga con las condiciones que establecemos en el sistema maestro. De esta manera, estamos logrando un mayor número de usuarios simultáneos y, por lo tanto, una mayor carga para nuestro servidor de destino.

Por lo tanto, si realmente queremos distribuir la carga, tenemos que hacerlo manualmente. Por ejemplo: si queremos llegar a 10.000 usuarios simultáneos y tenemos 10 sistemas esclavos, nuestro plan de pruebas debe tener 1.000 usuarios, por lo que terminamos teniendo un total de 10.000.

Otra cosa interesante que podemos hacer es agregar lógica a nuestra prueba agregando un controlador If. El Controlador If nos permite elegir un flujo en particular que queremos ejecutar, dependiendo del sistema que esté ejecutando la prueba. Ao, diferentes sistemas esclavos estarían ejecutando diferentes partes de la prueba.

Por ejemplo, si añadimos un parámetro al ejecutar el jmeter-server en los sistemas esclavos (./ jmeter-server-Jparam=1) podemos colocar una condición como ${__JavaScript (par{param}==1)} dentro del Controlador If, para que podamos ejecutar peticiones particulares dependiendo del sistema esclavo.

¡Eso es todo! Hemos ejecutado con éxito una prueba sobre un sistema distribuido JMeter. Esto puede no parecer muy complejo porque elegimos usar un solo sistema esclavo. Pero si necesita simular 25,000 usuarios simultáneos, el costo de mantener todos estos sistemas es enorme. Puede haber una posible solución para los problemas de mantenimiento y es montar toda la arquitectura que hemos visto sobre contenedores Docker (puede ver un ejemplo aquí).

Sin embargo, esto no será lo suficientemente bueno si nuestro objetivo es ejecutar pruebas de carga periódicamente. Hemos montado toda la arquitectura distribuida en un solo ordenador, por lo que estamos consumiendo una cantidad considerable de recursos. El concepto de distribuir JMeter sobre Docker tiene más sentido si tenemos la posibilidad de aumentar el número de contenedores bajo demanda, como en un servicio de computación en la nube.

Otra dificultad al ejecutar JMeter en modo distribuido es cómo manejar archivos CSV cuando tiene datos parametrizados en sus pruebas. Esto se debe a que necesitamos tener archivos separados, y si tenemos que actualizarlos tenemos que ir a cada sistema esclavo y hacer las modificaciones.

Para resolver todas estas limitaciones e inconvenientes, podemos usar BlazeMeter, que nos proporciona una manera fácil de manejar nuestras pruebas de carga. Todo lo que necesitamos hacer es subir nuestro archivo JMX a BlazeMeter. También podemos cargar un archivo CSV consolidado con todos los datos necesarios y BlazeMeter se encargará de dividirlo, dependiendo de la cantidad de motores que tengamos configurados.

En BlazeMeter podemos establecer la cantidad de usuarios o la combinación de motores (sistemas esclavos) e hilos que queremos aplicar a nuestras pruebas. También podemos configurar valores adicionales como ubicaciones múltiples.

los resultados de la Prueba:

Eso es todo! Ahora que ha visto algunas soluciones para ejecutar pruebas de carga a gran escala, mi recomendación para usted es crear su propia experiencia y tomar una decisión sobre qué opción le proporciona mayores beneficios.

Obtenga más información sobre cómo usar JMeter en nuestra academia JMeter gratuita.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.