Como lo expliqué en un post anterior, vamos a querer incluir pruebas de performance en nuestro pipeline de Integración Continua para detectar problemas de performance lo antes posible, logrando así ahorrar tiempo, dinero y dolores de cabeza. Sería muy bueno poder atrapar los problemas en el momento preciso en que se insertan en el sistema, ya sea una línea de código o una configuración en el ambiente. Para esto es que la propuesta es ejecutar pruebas en cada nueva versión de nuestra aplicación que permita verificar si los últimos cambios generan degradaciones sobre la performance de nuestro sistema. En este post quiero compartir cómo hacerlo con Taurus y Jenkins, pero puede ser extrapolado a cualquier otra herramienta de Integración Continua. Entonces, lo que vamos a usar es:
- Jenkins como agente de integración continua.
- Taurus para ejecutar pruebas de performance (puede ejecutar pruebas ya preparadas en JMeter, Gatling, o alguna de las tantas herramientas opensource que soporta).
- Un plus opcional: Blazemeter para los reportes.
También podés ver este manual en el sitio de Taurus o este post en el blog de BlazeMeter que es el artículo original que escribimos (ambos en inglés).
Sobre Taurus
Cuando hablamos de pruebas de performance, JMeter es de las mejores herramientas, pero es bastante compleja para mantener los scripts en la estrategia de trabajo sugerida en este post. Taurus en cambio nos permite hacer pruebas simples de manera muy simple, además de unas cuantas ventajas más. Es open source y brinda una capa de abstracción sobre JMeter (y otro tanto de herramientas similares) con scripts simples, en texto plano en formato yaml, donde uno puede separar el script (el flujo del usuario sobre el sistema) del criterio de aceptación o del escenario de pruebas. Todos estos aspectos simplifican el enfoque al querer ejecutar esto desde Jenkins.
Entonces, uno define un script en un formato simple, en texto, y luego Taurus usa la herramienta open source a elección para ejecutar (hay 10 opciones más o menos, entre ellas: JMeter, Gatling, Locust, Grinder). Si uno no se preocupa por qué herramienta se usa, Taurus por defecto usa JMeter, pero al fin de cuentas ni nos interesa, ya que Taurus se encarga de descargarla, hacerla funcionar, generar el script y ponerlo a ejecutar, y por último, tomar los resultados de ejecución.
En Taurus cada ejecución tiene un estado de pass/fail y eso se define en base a un criterio de aceptación. El siguiente código muestra un ejemplo de criterios de aceptación, basado en el promedio de tiempos de respuesta y en el porcentaje de fallas, donde se plantea también parar la prueba o continuarla de acuerdo a cómo se vayan evaluando estos criterios.
Razones por las que me gusta Taurus
- Muy fácil de instalar.
- Permite ejecutar pruebas existentes en más de 10 herramientas (JMeter y Gatling incluídas, así que yo ya estoy cubierto).
- Se puede separar el criterio de aceptación del resto de las configuraciones del test. Incluso, se puede separar la carga a ejecutar del flujo, pudiendo así ejecutar el mismo flujo con distintas cargas y distintos criterios de aceptación. Esto es particularmente conveniente cuando queremos ejecutar la misma prueba en distintos ambientes.
- Reportes en tiempo real (esto es una limitante de Gatling y en JMeter generalmente no se usan listeners durante la ejecución porque son muy pesados, siendo Taurus una alternativa más liviana).
- Facilidad para integrar en Jenkins para Continuous Integration.
- Varios formatos de salida para los reportes.
- Ejecución independiente de la plataforma, ya que depende solo de Python y Java, que ejecutan sobre diversos sistemas operativos.
- Código simple, con lo cual es simple para versionar en algo como Git.
Configuración de Pruebas de Performance en CI
Estos son los pasos que seguimos para configurar la ejecución de pruebas con Taurus en el pipeline:
- Instalar Taurus. http://gettaurus.org/docs/Installation/ (básicamente, ejecutar pip install -upgrade bzt).
- Instalar plugin para visualizar resultados en Jenkins. Para esto ir al plugin manager de Jenkins, buscar “performance plugin” e instalar.
- Crear archivos yml de configuración para cada ambiente y para cada prueba.
- Ejecutar el test por línea de comandos. Esto es muy simple incluso si ya se tiene una prueba preparada con JMeter, por ejemplo: bzt SmokeTest.yml
- Configurar un job en Jenkins para ejecutar el test en cada build.
Para el último paso, hay que ir en Jenkins a la opción de crear un “New Item” (Job), ponerle un nombre y elegir “Freestyle Project” y guardar. En la pestaña “General” de la configuración del job, habilitar “This project is parameterized” para poder pasarle los siguientes parámetros con la opción “String Parameters”:
- Concurrency
- Hold For
- Iterations
- Ramp Up
En la sección “Build Triggers”, una opción es marcar “Build after other projects are built” si se quiere disparar después del pipeline que ya se tiene en funcionamiento (quizá luego de terminar las pruebas funcionales, eso es a gusto del consumidor). Por último, en la sección “Build”, elegir “Execute shell” y agregar el siguiente comando:
En este caso estoy usando un archivo JMeter que ya tenía, pero es muy fácil crear un script Taurus desde cero (ver manual).
Al ejecutar Taurus:
- Va a sobreescribir la configuración del script JMeter.
- Va a ejecutar JMeter con el modo consola (sin interfaz gráfica).
- Va a enviar datos de los resultados a Blazemeter en tiempo real, entonces tendremos un reporte web que podemos compartir y así ir viendo cómo va evolucionando cada prueba.
En el Job de Jenkins luego hay que agregar un post-build action del tipo “Publish Performance Test Result Report”. Add -> New Report -> Taurus. Siguiendo el ejemplo, habría que configurar “taurus final stats xml” con el nombre del archivo de salida “report.xml”.
Reporting con BlazeMeter
Para visualizar los resultados en Blazemeter no hace falta tener una cuenta, pero si tenemos una, nos quedarán almacenados todos los resultados asociados a esa cuenta. Para esto es necesario configurar la pruena con el API Key del usuario, que se encuentra en la configuración de la cuenta. La ventaja principal de asociar a la cuenta es que se pueden comparar resultados y analizar tendencias de manera automática.
Cerrando
Este enfoque como ya comentamos tiene grandes ventajas, pudiendo detectar degradaciones de performance lo antes posible. Todo lo logramos sin costo, y sin ser por BlazeMeter, en base a herramientas open source.
La implementación de las pruebas son simples, entonces es fácil de entender y de mantener por cualquier integrante del equipo.
Todo esto hace que este enfoque sea muy bueno para equipos que trabajan con metodologías ágiles.
Gracias Alexis Álvarez (de Abstracta) por la ayuda a escribir el post compartiendo tus análisis de como lograrlo. Esto surgió del trabajo en un proyecto, un poco más de un año atrás.
One thought on “Cómo usar Taurus y Jenkins para pruebas de performance en Integración Continua”