intive Argentina Blog

Testing distribuido con Jmeter y Taurus

En este artículo vamos a darle una vuelta de tuerca a algo que ya habíamos hecho antes. Basándonos en la app web de 3 endpoints del artículo anterior y en el script de JMeter que habíamos creado, vamos a ver la forma que tenemos de correr estos tests en varias máquinas a la vez y de luego tener un reporte consolidado de esas pruebas.

Un punto importante a tener en cuenta, es que se ejecuta todo el test en plan en todos los servers. Por ejemplo, si tenemos 3 servers donde van a correr las pruebas y queremos lograr 6000 threads concurrentes, en nuestro test vamos a poner solo 2000 threads, ya que esos 2000 se generarán en cada servidor.

Levantando JMeter en modo server

Una forma sencilla de comprobar que todo funcione más o menos bien, es probar JMeter en modo server en nuestro local. Para eso podemos usar la terminal y levantar el servidor con el siguiente comando: jmeter -s -Jserver.rmi.ssl.disable=true. A la property de “deshabilitar SSL para RMI” la estoy usando porque en mi local no tengo configurado SSL para RMI y porque, realmente, no lo estoy necesitando.

Aunque usar JMeter en modo distribuido es bastante straightforward, hay 3 requisitos básicos que debemos cumplir:

  1. Tener la misma versión de JMeter en todos los servidores.
  2. Tener la misma versión de Java en todos los servidores.
  3. Tener un keystore válido para permitir RMI sobre SSL (RMI: Remote Method Invocation). O deshabilitar SSL, como hicimos con el punto anterior.

Corriendo nuestros tests en el server remoto

Con eso levantado, podemos proceder a correr los tests indicando los servidores que queramos con el siguiente comando: jmeter -n -t jmeter.jmx -Rlocalhost -Jserver.rmi.ssl.disable=true. Nótese que estoy indicando un solo server remoto, que es simplemente localhost. Esto nos genera un output así:

Si tuviéramos más servidores solo necesitaríamos indicarlos separados por comas en el parámetro -R.

Ahora bien… Estos son solo 3 requests usando la máquina “remota”. El resto de las configuraciones que vimos en el artículo anterior son válidas: podemos pasar por parámetro la cantidad de threads, loops y tiempo de ramp up, que se transmitirán a todos los servers donde corramos los tests. Un punto importante a tener en cuenta es que, si nuestros tests necesitan leer archivos, por ejemplo de un CSV, esta forma de correr los tests no “reparte” estos archivos entre todos los servers.

Por ejemplo, podemos correr: jmeter -n -t jmeter.jmx -Gthreads=1000 -Grampup=33 -Rlocalhost -Jserver.rmi.ssl.disable=true, para indicarle que queremos 1000 threads con un ramp up de 33 segundos. Nótese que para pasar estas properties a los servidores remotos ya no usamos el parámetro -J, ahora usamos -G. Esto nos generaría un output parecido al siguiente:

Corriendo nuestros tests distribuidos con Taurus

Correr nuestros tests en modo distribuido usando Taurus es igual de simple a como lo hemos visto antes. Simplemente tenemos que agregar algunos parámetros a nuestro archivo de configuración, para poder indicarle a Taurus que queremos ejecutar el test en modo distribuido.

En mi caso, además, tuve que agregar el parámetro para deshabilitar el chequeo de SSL. Pero eso es un extra… De la misma forma que pasé ese parámetro también se pueden pasar todos los que se necesiten, para configurar su ejecución. Mi archivo test.yml me quedó de la siguiente forma:

Como pueden ver, se agregó una sección - distributed: donde solo indico localhost, pero podemos agregar todos los servidores que necesitemos, indicando sus direcciones ip una abajo de la otra y precedidas por un -.

Con esto ya estamos listos para correr nuestros tests en modo distribuido. Podemos hacerlo tanto en un server como en 10, sin demasiado problema. Un punto súper interesante es la posibilidad de usar nuestra máquina local y nuestras conexiones hogareñas para controlar infraestructura como la de Amazon para nuestros nodos. De esta forma, podemos generar carga que sería casi imposible de otra manera.

Monitoreando el estado de nuestros nodos

Cuando hacemos pruebas de stress, siempre corremos el riesgo de encontrarnos con que el cuello de botella son las mismas pruebas y no el software que estamos probando. Puede pasar, que no podamos llevar el software al límite porque nuestras pruebas y nuestra infra para correrlas no alcanzan para estresar la aplicación.

Por defecto, Taurus nos permite monitorear la máquina donde se está ejecutando. Esto nos sirve cuando no estamos trabajando con varios nodos y personalmente no me parece tan útil habiendo otras herramientas para monitorear el servidor donde está funcionando. Cuando tenemos las pruebas corriendo en varios servidores, se vuelve más interesante poder monitorear y visualizar el estado de todos estos en un solo lugar. Para hacerlo, necesitamos tener instalada una pequeña aplicación java en cada uno de los servidores: PerfMon Server Agent. Esta app nos expone un endpoint al cual podemos consultarle por los stats.

Simplemente lo descargamos y lo encendemos en cada uno de los nodos con el script startAgent.sh que trae el .zip. Luego, en nuestro archivo de configuración deberemos indicar que queremos recolectar estas métricas. Así que entramos en nuestro test.yml y agregamos algunas líneas. Nos debería quedar algo así:

Debemos agregar tantos server-agent como servidores tengamos… En mi caso, para escribir este artículo solo tengo uno en localhost. Entonces en address puse localhost:4444. Si se está corriendo en otra máquina deberíamos poner la ip y el puerto. Incluso podemos cambiar localhost por 127.0.0.1:4444.

Es importante definir las métricas que nos sirvan para entender qué es lo que pasa. Para determinadas pruebas, puede que necesiten medir el estado de las conexiones de red, por ejemplo. Con esta configuración, cuando corremos las pruebas, podemos ver un output así:

El tamaño vertical de la ventana puede ser una limitante de los datos que vemos. Si agregan la configuración y no ven la sección nueva, es probable que solo necesiten agrandar verticalmente la pantalla donde están viendo el output de Taurus.

Reporting

Obviamente podemos usar las mismas herramientas que vimos anteriormente para hacer nuestros reportes, siendo Blazemeter una de las mejores opciones. Con solo llamar a Taurus con el parámetro -report podríamos verlo en su interfaz. El tab engine health, aunque estemos monitoreando los servers, no va a funcionar ya que es funcionalidad específica para las corridas con la infra de ellos.

De todas formas, el reporte de Blazemeter es tan bueno como lo vimos antes, con todos las funcionalidades que nos gustan. Por ejemplo, el timeline report, que nos permite crear gráficos como el siguiente:

Esto es todo. Gracias por leer. Happy testing.

Fernando Lescano

Es uno de nuestros líderes técnicos y desarrollador full stack de intive – FDV desde marzo de 2015. En la empresa trabaja con tecnologías como Javascript (NodeJS, AngularJS, Mongodb, Jquery, etc.), Python (Django), Java y PHP e integra la brigada Frontend. Se define como “apasionado del desarrollo de software, pero con muchos otros intereses”. Desde diciembre de 2015 se ocupa del desarrollo y mantenimiento en Java y de nuevos componentes en JavaScript (AngularJS). Es Técnico Universitario en desarrollo de software y tecnologías de la información, graduado de la Universidad Provincial de Ezeiza.

Deja un comentario