En este post quiero contarte algunas conclusiones a las que llegamos comparando Gatling vs JMeter, en particular considerando el manejo de los hilos y conexiones, ya que hacen cosas muy diferentes, que pueden afectar nuestros resultados. Esto fue un descubrimiento encontrado al realizar una comparación de la performance de las dos herramientas que lo publicaré en unos días.
Manejo de conexiones en Gatling vs JMeter
La prueba realizada en cada herramienta es igual, y queríamos ver cómo escala cada una, o sea, cuál es el máximo número de usuarios virtuales que puedo ejecutar con cada herramienta. La prueba automatizada es muy simple, un solo request a un sitio estático, ejecutando por 5 minutos sin pausa, con 1 minuto de ramp-up, y con distintas cantidades de usuarios virtuales, ya que es la variable que queríamos analizar.
En una primera instancia con JMeter simulando 400 usuarios se observaron errores de conexión (Non HTTP response code: java.net.BindException). Estos errores son ocasionados por límites a nivel de sistema operativo. En particular estamos usando Windows, en donde las conexiones TCP/IP utilizan los puertos 1024-5000 de salida, por lo que de generarse muchas conexiones en poco tiempo, estos puertos se saturan. Para evitar este problema se debe incrementar la cantidad de puertos disponibles para conexiones siguiendo los pasos descritos en esta página.
En cambio, utilizando Gatling, logramos ejecutar pruebas con hasta 4.000 usuarios virtuales concurrentes sin llegar a este problema.
A modo de encontrarle una explicación a este suceso, por qué se da esta limitante en una herramienta y no en la otra, fue que investigamos un poco más al respecto, llegando a la hipótesis de que la explicación está en cómo manejan las conexiones estas herramientas:
- Gatling: Según lo que entiendo de lo que explican aquí, Gatling maneja un pool de conexiones por usuario virtual, pero lo importante es que en los pedidos secuenciales por defecto reutiliza las conexiones.
- JMeter: Según lo que discuten aquí, JMeter no lo hace. Además, la documentación de JMeter menciona: There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread.
Manejo de threads en Gatling vs JMeter
Relacionado a lo anterior, hay otro aspecto bien interesante que diferencia cómo funciona cada herramienta con respecto al manejo de los usuarios virtuales. En el caso de JMeter tienen procesos que hacen solicitudes sincrónicas, y Gatling maneja un proceso asíncrono a través del uso de handlers. Aquí explica las diferencias bastante claro. Ambos tienen la posibilidad de manejar un pool de conexiones por usuario, que en el caso de tener varios pedidos secundarios, que no sucede en nuestro experimento, se realizan en paralelo como suelen hacer los browsers. En Gatling esta es la configuración por defecto, con un máximo de 6 conexiones simultáneas, en JMeter hay que especificarlo.
Conclusión
Lo que observamos es que tanto Gatling como JMeter permiten simular la misma cantidad de usuarios virtuales concurrentes. La diferencia es que por el manejo de conexiones que hace JMeter es necesario ajustar el sistema operativo, pero eso se hace una vez, es simple y ya queda.
El manejo de hilos debería presentar ventajas (uso de menos memoria al menos) pero no está demostrado como algo completamente significativo.
Es importante ver que estos comportamientos son configurables (reuso de conexiones, threads por usuario virtual, etc.) pero para tocar esos valores hay que estar seguro de lo que implican, y ver cuál es el modelo que nos sirve para lo que queremos probar, ya que podemos variar mucho el comportamiento del servidor (por ejemplo, la cantidad de conexiones que necesite el servidor para responder la carga).
