Gatling vs JMeter vs The Grinder: Comparación de herramientas de prueba de carga

Programación

1. Introducción

Elegir la herramienta adecuada para el trabajo puede resultar abrumador. En este tutorial, simplificaremos esto comparando tres herramientas de prueba de carga de aplicaciones web: Apache JMeter, Gatling y The Grinder, con una API REST simple.

2. Herramientas de prueba de carga

Primero, repasemos rápidamente algunos antecedentes de cada uno.

2.1. Gatling

Gatling es una herramienta de prueba de carga que crea scripts de prueba en Scala. La grabadora de Gatling genera los scripts de prueba de Scala, una característica clave para Gatling. Consulte nuestro tutorial Introducción a Gatling para obtener más información.

2.2. JMeter

JMeter es una herramienta de prueba de carga de Apache. Proporciona una interfaz gráfica de usuario agradable que usamos can para la configuración. Una característica única llamada controladores lógicos brinda una gran flexibilidad para configurar pruebas en la GUI.

Visite nuestro tutorial Introducción a JMeter para obtener capturas de pantalla y más explicaciones.

2.3. El molinillo

Y nuestra herramienta final, The Grinder, proporciona un motor de scripting más basado en programación que los otros dos y usa Jython. Sin embargo, The Grinder 3 tiene funcionalidad para grabar scripts.

Grinder también se diferencia de las otras dos herramientas al permitir procesos de consola y agente. Esta funcionalidad proporciona la capacidad de un proceso de agente para que las pruebas de carga se puedan escalar en varios servidores. Se anuncia específicamente como una herramienta de prueba de carga creada para que los desarrolladores encuentren puntos muertos y desaceleraciones.

3. Configuración del caso de prueba

A continuación, para nuestra prueba, necesitamos una API. Nuestra funcionalidad API incluye:

  • agregar / actualizar un registro de recompensas
  • ver uno / todos los registros de recompensas
  • vincular una transacción a un registro de recompensas del cliente
  • ver transacciones para un registro de recompensas del cliente

Nuestro escenario:

Una tienda está realizando una venta a nivel nacional con clientes nuevos y recurrentes que necesitan cuentas de recompensas para los clientes para ahorrar. La API de recompensas verifica la cuenta de recompensas del cliente por la identificación del cliente . Si no existe una cuenta de recompensas, agréguela y luego vincúlela a la transacción.

Después de esto, consultamos las transacciones.

3.1. Nuestra API REST

Veamos un resumen rápido de la API viendo algunos de los códigos auxiliares del método:

@PostMapping(path="/rewards/add") public @ResponseBody RewardsAccount addRewardsAcount(@RequestBody RewardsAccount body) @GetMapping(path="/rewards/find/{customerId}") public @ResponseBody Optional findCustomer(@PathVariable Integer customerId) @PostMapping(path="/transactions/add") public @ResponseBody Transaction addTransaction(@RequestBody Transaction transaction) @GetMapping(path="/transactions/findAll/{rewardId}") public @ResponseBody Iterable findTransactions(@PathVariable Integer rewardId)

Tenga en cuenta algunas de las relaciones, como la consulta de transacciones por el ID de recompensa y la obtención de la cuenta de recompensas por ID de cliente . Estas relaciones fuerzan algo de lógica y análisis de respuestas para la creación de nuestro escenario de prueba.

La aplicación bajo prueba también utiliza una base de datos H2 en memoria para la persistencia.

Afortunadamente, todas nuestras herramientas lo manejan bastante bien, algunas mejor que otras.

3.2. Nuestro plan de pruebas

A continuación, necesitamos scripts de prueba.

Para obtener una comparación justa, realizaremos los mismos pasos de automatización para cada herramienta:

  1. Genere ID de cuenta de cliente aleatorios
  2. Publica una transacción
  3. Analizar la respuesta para el ID de cliente aleatorio y el ID de transacción
  4. Consulta de una identificación de cuenta de recompensas de cliente con la identificación de cliente
  5. Analizar la respuesta para la identificación de la cuenta de recompensas
  6. Si no existe una identificación de cuenta de recompensas, agregue una con una publicación
  7. Publique la misma transacción inicial con la identificación de recompensas actualizada utilizando la identificación de la transacción
  8. Consultar todas las transacciones por ID de cuenta de recompensas

Echemos un vistazo más de cerca al Paso 4 para cada herramienta. Y asegúrese de consultar el ejemplo de los tres scripts completados.

3.3. Gatling

Para Gatling, la familiaridad con Scala agrega una ventaja para los desarrolladores, ya que la API de Gatling es sólida y contiene muchas características.

La API de Gatling adopta un enfoque de constructor DSL, como podemos ver en su paso 4:

.exec(http("get_reward") .get("/rewards/find/${custId}") .check(jsonPath("$.id").saveAs("rwdId")))

De particular interés es el soporte de Gatling para JSON Path cuando necesitamos leer y verificar una respuesta HTTP. Aquí, recogeremos la identificación de la recompensa y la guardaremos en el estado interno de Gatling.

Además, el lenguaje de expresión de Gatling facilita las cadenas de cuerpo de solicitudes dinámicas :

.body(StringBody( """{ "customerRewardsId":"${rwdId}", "customerId":"${custId}", "transactionDate":"${txtDate}" }""")).asJson)

Por último, nuestra configuración para esta comparación. Las 1000 ejecuciones configuradas como una repetición de todo el escenario, el método atOnceUsers establece los hilos / usuarios:

val scn = scenario("RewardsScenario") .repeat(1000) { ... } setUp( scn.inject(atOnceUsers(100)) ).protocols(httpProtocol)

Todo el script de Scala se puede ver en nuestro repositorio de Github.

3.4. JMeter

JMeter genera un archivo XML después de la configuración de la GUI. El archivo contiene objetos específicos de JMeter con propiedades establecidas y sus valores, por ejemplo:

Echa un vistazo a los atributos de nombre de prueba , se pueden etiquetar ya que los reconocemos que coinciden con los pasos lógicos anteriores. La capacidad de agregar hijos, variables y pasos de dependencia le da a JMeter la flexibilidad que proporciona la secuencia de comandos. Además, ¡incluso establecemos el alcance de nuestras variables!

Nuestra configuración para ejecuciones y usuarios en JMeter usa ThreadGroups :

100

View the entire jmx file as a reference. While possible, writing tests in XML as .jmx files do not make sense with a full-featured GUI.

3.5. The Grinder

Without the functional programming of Scala and GUI, our Jython script for The Grinder looks pretty basic. Add some system Java classes, and we have a lot fewer lines of code.

customerId = str(random.nextInt()); result = request1.POST("//localhost:8080/transactions/add", "{"'"customerRewardsId"'":null,"'"customerId"'":"+ customerId + ","'"transactionDate"'":null}") txnId = parseJsonString(result.getText(), "id")

However, fewer lines of test setup code are balanced by the need for more string maintenance code such as parsing JSON strings. Also, the HTTPRequest API is slim on functionality.

With The Grinder, we define threads, processes, and runs values in an external properties file:

grinder.threads = 100 grinder.processes = 1 grinder.runs = 1000

Our full Jython script for The Grinder will look like this.

4. Test Runs

4.1. Test Execution

All three tools recommend using the command line for large load tests.

To run the tests, we'll use Gatling open-source version 3.4.0 as a standalone tool, JMeter 5.3 and The Grinder version 3.

Gatling requires only that we have JAVA_HOME and GATLING_HOME set. To execute Gatling we use:

./gatling.sh

in the GATLING_HOME/bin directory.

JMeter needs a parameter to disable the GUI for the test as prompted when starting the GUI for configuration:

./jmeter.sh -n -t TestPlan.jmx -l log.jtl

Like Gatling, The Grinder requires that we set JAVA_HOME and GRINDERPATH. However, it needs a couple more properties, too:

export CLASSPATH=/home/lore/Documents/grinder-3/lib/grinder.jar:$CLASSPATH export GRINDERPROPERTIES=/home/lore/Documents/grinder-3/examples/grinder.properties

As mentioned above, we provide a grinder.properties file for additional configuration such as threads, runs, processes, and console hosts.

Finally, we bootstrap the console and agents with:

java -classpath $CLASSPATH net.grinder.Console
java -classpath $CLASSPATH net.grinder.Grinder $GRINDERPROPERTIES

4.2. Test Results

Each of the tests ran 1000 runs with 100 users/threads. Let's unpack some of the highlights:

Successful Requests Errors Total Test Time (s) Average Response Time (ms) Mean Throughput
Gatling 500000 Requests 0 218s 42 2283 req/s
JMeter 499997 Requests 0 237s 46 2101 req/s
The Grinder 499997 Requests 0 221s 43 2280 req/s

The results show the 3 tools have similar speed, with Gatling slightly edging out the other 2, based on the mean throughput.

Each tool also provides additional information in a friendlier user interface.

Gatling will generate an HTML report at the end of the run, which contains multiple graphs and statistics, for the total run as well as for each request. Here's a snippet of the test result report:

When using JMeter, we can open the GUI after the test run and generate an HTML report based on the log file where we saved the results:

The JMeter HTML report also contains a breakdown of the statistics per request.

Finally, The Grinder Console records statistics for each agent and run:

While The Grinder is high-speed, it comes at the cost of additional development time and less diversity of output data.

5. Summary

Now it's time to take an overall look at each of the load testing tools.

Gatling JMeter The Grinder
Project and Community 9 9 6
Performance 9 8 9
Scriptability/API 7 9 8
UI 9 8 6
Reports 9 7 6
Integration 7 9 7
Summary 8.3 8.3 7

Gatling:

  • Solid, polished load testing tool that outputs beautiful reports with Scala scripting
  • Open Source and Enterprise support levels for the product

JMeter:

  • Robust API (through GUI) for test script development with no coding required
  • Soporte de Apache Foundation y gran integración con Maven

El molinillo:

  • Herramienta de prueba de carga de rendimiento rápido para desarrolladores que utilizan Jython
  • La escalabilidad entre servidores proporciona aún más potencial para pruebas grandes

En pocas palabras, si la velocidad y la escalabilidad son una necesidad, utilice The Grinder.

Si los gráficos interactivos de gran apariencia ayudan a mostrar una ganancia de rendimiento para defender un cambio, entonces use Gatling.

JMeter es la herramienta para una lógica empresarial complicada o una capa de integración con muchos tipos de mensajes. Como parte de Apache Software Foundation, JMeter ofrece un producto maduro y una gran comunidad.

6. Conclusión

En conclusión, vemos que las herramientas tienen funcionalidades comparables en algunas áreas mientras brillan en otras. La herramienta adecuada para el trabajo adecuado es la sabiduría coloquial que funciona en el desarrollo de software.

Finalmente, la API y los scripts se pueden encontrar en Github.