Este año me tocó trabajar bastante con una nueva herramienta para pruebas de performance, la cual me está gustando cada día más. Se trata de Gatling y a esta altura la estoy considerando como mi herramienta predilecta, incluso más que JMeter. A mi forma de verlo, Gatling tool tiene bastantes ventajas sobre JMeter y sobre otras herramientas, es también una herramienta open-source, y quizá sobre todo, más developer-friendly 🙂 Hace unos meses ya había escrito un review sobre la herramienta aquí y ahora quiero ir agregando algunos comentarios en base a la experiencia de 6 meses trabajando a diario con Gatling.
Si bien es una herramienta bastante nueva (del 2012) en este último tiempo ha ganado cierta popularidad (350.000 descargas en estos casi 5 años, concentrando la mayor cantidad en el último año, con lo cual, parece que está ganando la atención de la comunidad).
Características principales de Gatling
- Herramienta de pruebas de performance.
- Gratis y opensource (desarrollada en Java / Scala).
- El lenguaje de scripting es Scala, con un DSL propio de la herramienta que realmente brinda mucha flexibilidad y facilidad para preparar las pruebas.
- Funciona con cualquier sistema operativo y cualquier browser.
- Soporta protocolos HTTP/S, JMS y JDBC.
- Reportes en HTML muy vistosos.
No permite distribuir carga entre distintas máquinas, pero se pueden ejecutar sus pruebas en distintos Cloud de pruebas. Se puede escalar usando https://flood.io/ o Taurus con BlazeMeter, que brinda muchas más facilidades para la integración continua.
Con lo cual es una herramienta muy buena cuando:
- Se necesita ejecutar menos de 600 usuarios concurrentes. Esto es solo un número de referencia, depende de qué tanto procesamiento tenga el script de simulación, pero si se necesita generar más entonces habrá que pagar una herramienta en el Cloud. Un colega me comentó que llegó a ejecutar 4.000 usuarios concurrentes con un script simple desde una sola máquina. En estos días estamos haciendo un benchmark entre Gatling y JMeter en Abstracta, pronto lo compartiré acá.
- Quiero aprender de pruebas de performance (es muy simple para comenzar y el código queda legible). Hace muy poco hice un workshop aquí en la oficina, y creo que en 2 o 3 horas que estuvimos reunidos, los participantes pudieron entender el funcionamiento básico de la herramienta. Aquí les compartí las ppts y algunas fotos de ese meetup, que pueden servir como guía para iniciarse con la herramienta.
- Me interesa mantener el código de pruebas (el lenguaje Scala y el DSL de Gatling están bastante enfocados en facilitar la mantenibilidad de las pruebas, con lo cual es ideal para enfoques de integración continua).
Esta herramienta permite realizar simulación de carga de usuarios concurrentes contra un sistema, a través de los protocolos HTTP/S, JMS o JDBC. El escenario más típico de uso es el de simular usuarios de un sistema web para poder analizar los cuellos de botella y optimizar el sistema, con lo cual la mayoría de las veces lo que vamos a utilizar es HTTP y HTTPS. Muy pocas veces (menos del 10% de los proyectos) me ha tocado automatizar un protocolo diferente, así que estamos cubiertos para la mayoría de los casos.
Gatling es una herramienta gratuita y opensource. Funciona sobre Java, con lo cual está apta para todos los Sistemas Operativos. Es necesario tener la JDK8 (no es suficiente con el runtime, hace falta el kit de desarrollo).
La herramienta tiene dos ejecutables: uno para grabar las pruebas y otro para ejecutarlas. Las pruebas grabadas quedan en un lenguaje llamado Scala, el cual es muy limpio y fácil de leer incluso si es la primera vez que lo miras. El resultado de la ejecución queda en un reporte HTML muy colorido y bien prolijo.
Los scripts cuentan con los aspectos fundamentales para la correcta simulación de usuarios, que a mi consideración son:
- Manejo del protocolo (desde las invocaciones y respuestas, hasta el manejo de headers, cookies, etc).
- Manejo de strings, facilidades para parsear, expresiones regulares, e incluso, localización de elementos por xpath, json path, css y más.
- Validaciones, ya que necesitamos verificar que las respuestas sean correctas.
- Parametrización desde distintas fuentes de datos (aquí le veo un punto muy fuerte a la herramienta, ya que brinda varias alternativas y muy fáciles de usar con un objeto llamado Feeder).
- Manejo de variables dinámicas, conocido como correlación de variables.
- Manejo de distintos scopes para las variables (a nivel de hilos, prueba, etc.).
- Modularización (facilitando la mantenibilidad y legibilidad de los scripts). Incluso, se puede seguir un esquema similar al de Page Objects para Selenium.
- Manejo de esperas (para simular los think times).
- Gestión de métricas (tiempos de respuesta, tanto individuales como agrupados, transacciones por segundo, cantidad de usuarios concurrentes, errores, cantidad de datos transferidos, etc.). Incluso muestra una gráfica con distintos percentiles (50, 90, 95, etc.) que es sumamente útil para el análisis del total de los resultados.
- Manejo de errores y excepciones.
- Control de flujo (loops, if-then-else).
¿Qué otra cosa consideras al momento de evaluar el lenguaje de scripting de una herramienta de simulación de carga o estrés? ¡Si me faltó alguna la puedo agregar!
En cuanto a los reportes, realmente están vistosos y muy completos, destacando que:
- Es un HTML con facilidad de navegación, con un índice y ordenado.
- Muestra gráficamente la información agrupada y muy bien procesada y vinculada.
- Incluye gráfico de cantidad de usuarios virtuales durante la prueba.
- Se puede hacer zoom en los gráficos para focalizar y analizar en detalle en determinados puntos.
- Grafica los requests/second y los responses/second, Incluso comparando con la cantidad de usuarios activos.
- Se puede ver el detalle para cada “request” como para refinar el análisis.
- Separa los tiempos de respuesta de las que dieron OK de las que fallaron.
- Maneja el concepto de percentiles.
- Hay un log con los errores obtenidos.
¿Qué otra cosa consideras al momento de evaluar los reportes de una herramienta de simulación de carga o estrés?
Seguiré compartiendo más experiencias con Gatling, cualquier consulta estoy a las órdenes en lo que pueda ayudar.
Hola Federico,
cómo estas?, te escuché en el último webinar del isqi, sobre performance testing, me sirvió mucho. Tengo un nuevo proyecto, ojala me puedas ayudar o indicarme con quien puedo consultar, necesito probar un IVR, es un aplicativo de call center o contact center, y mi cliente tiene la necesidad de probar el IVR. es decir necesito realizar llamadas en concurrencia. Me comentaron que necesito tener un sw de telefono virtual, acompañado de una tool de performance que puede ser jmeter, para comunicarse con el ivr. A ver si me orientas y me das algunos nombres porfavor!!! :D, Si tienes una experiencia previa me cuentas, muchas gracias! espero tu rpta.
Hola Sonia. Gracias por el feedback!
Alguna vez algún integrante del equipo participó de una prueba de este estilo, pero no tengo muchos detalles.
Sé que el protocolo que simuló era SIPP, y que para eso se implementaron cosas específicas para soportarlo, y creo que se utilizó JMeter.
Buscaría si hay herramientas para el protocolo que utilizan ustedes, que probablemente sea el mismo.
Voy a ver si consigo que alguien de ese proyecto comente su experiencia.
Saludos
Hola!
Hace ya un tiempo hicimos algunos proyectos de performance utilizando la herramienta SIPP (http://sipp.sourceforge.net/) para generar pruebas de carga para el protocolo SIP. Es un protocolo bastante sencillo por lo que estimo se podría utilizar algún plugin de JMeter
Enviar tonos o audio es sencillo, medir los tiempos también. Lo que ya es mas complejo es reconocer el audio que viene desde el IVR