Comparativas

Gatling vs JMeter: ¿pruebas como código o un plan en GUI?

8 min de lectura

Gatling y Apache JMeter son dos herramientas de pruebas de carga gratuitas y open source que funcionan sobre la JVM, y la elección depende sobre todo de cómo quiere construir las pruebas tu equipo. Elige Gatling si quieres las pruebas como código en Java, Kotlin, Scala, JavaScript o TypeScript, perfiles de inyección abiertos y un informe HTML después de cada ejecución. Elige JMeter si necesitas protocolos como JDBC, LDAP, FTP o correo sin añadir nada, prefieres montar las pruebas en una interfaz gráfica o ya tienes planes de prueba .jmx.

Los datos de esta comparativa Gatling vs JMeter vienen de la documentación y el repositorio de cada proyecto, comprobados el 9 de octubre de 2026.

GatlingApache JMeter
LicenciaApache 2.0; gRPC, MQTT y GraphQL con una licencia de componentes aparte (repositorio)Apache 2.0 (repositorio)
Entorno de ejecuciónJVM, OpenJDK LTS 11 a 25 (versión 3.16.0)JVM, Java 8 o posterior (versión 5.6.3)
Pruebas escritas comoCódigo en Java, Kotlin, Scala, JavaScript o TypeScriptPlanes de prueba montados en una interfaz gráfica y guardados en XML (.jmx)
Protocolos integradosHTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMSHTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, correo, TCP, comandos de shell, objetos Java
GrabadorProxy HTTP o conversor de archivos HARHTTP(S) Test Script Recorder (proxy)
Modelo de cargaPerfiles de inyección abiertos o cerradosThread Groups; un Open Model Thread Group experimental
EscaladoUna máquina; la ejecución distribuida requiere Gatling EnterpriseModo remoto integrado, un cliente que controla varios servidores
CI y ejecución sin interfazPlugins de Maven, Gradle, sbt y npm; una assertion fallida hace fallar la ejecuciónModo CLI (jmeter -n); plugins de terceros para Maven, Gradle y Jenkins
InformesInforme HTML después de cada ejecuciónPanel HTML; resultados en directo con un Backend Listener

¿Cuál es la diferencia entre Gatling y JMeter?

En Gatling una prueba es un programa dentro de un proyecto de build. En JMeter una prueba es un árbol de elementos que montas en una interfaz gráfica de escritorio y guardas como archivo XML, y de ahí salen casi todas las demás diferencias.

El README de Gatling llama simulaciones a las pruebas y las guarda en tu repositorio como el código de la aplicación, y se ejecutan con un plugin de Maven, Gradle, sbt o npm. El SDK de JavaScript y TypeScript se instala con npm y descarga su propio entorno GraalVM.

Un plan de JMeter tiene un Thread Group para los usuarios, samplers para las peticiones y assertions y listeners para los resultados. JMeter 5.6.3, la versión actual en la página de descarga, requiere Java 8 o posterior. El README de la rama de desarrollo de JMeter ya exige Java 17 (comprobado el 10 de octubre de 2026). Por dentro, JMeter ejecuta cada usuario virtual como un hilo de Java, mientras que el README de Gatling describe los usuarios virtuales como mensajes ligeros sobre un motor no bloqueante construido con Netty.

¿Cómo se escribe una prueba en cada herramienta?

En Gatling escribes una clase de simulación que define un escenario, un perfil de inyección y assertions. En JMeter añades un Thread Group y samplers en la interfaz gráfica, guardas el plan y luego lo ejecutas desde la línea de comandos.

Una simulación en Java basada en el tutorial de la primera simulación de Gatling: los usuarios nuevos llegan primero a razón de uno por segundo, suben a diez por segundo en un minuto y se mantienen así durante cinco minutos. La ejecución falla si el percentil 95 supera los 500 ms o si falla más del 1 % de las peticiones:

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Ejecútala con ./mvnw gatling:test; una simulación en JavaScript o TypeScript se ejecuta con npx gatling run.

En JMeter la misma prueba es un Thread Group con un sampler HTTP Request, y una Duration Assertion puede marcar como fallida cada respuesta lenta. La guía de inicio monta el plan en modo GUI y lo ejecuta en modo CLI, y -e -o añade el informe HTML:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Las dos herramientas pueden grabar un primer borrador desde el navegador. El Recorder de Gatling funciona como proxy HTTP o convierte un archivo HAR en una simulación, y el HTTP(S) Test Script Recorder de JMeter captura el tráfico del navegador en un plan (comprobado el 9 de octubre de 2026). La documentación de Gatling ya presenta este Recorder como legacy, y el más reciente Gatling Studio exige una cuenta de Enterprise para iniciar sesión (comprobado el 10 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

JMeter cubre más protocolos de serie. Gatling trae los principales protocolos web más JMS y deja casi todo lo demás a componentes aparte o a plugins de la comunidad.

El README de JMeter recoge todos los protocolos de la tabla anterior, correo incluido. JDBC y JMS necesitan los JAR del driver de tu base de datos o de tu proveedor JMS, y el Plugins Manager instala plugins de la comunidad desde la propia interfaz gráfica.

Según el README de Gatling, gRPC, MQTT y GraphQL son componentes aparte con la Gatling Enterprise Component License, limitados sin Enterprise a cinco usuarios simultáneos y pruebas de cinco minutos. Kafka, AMQP, SFTP, FTP y JDBC llegan con plugins de terceros para Gatling 3.13 que Gatling no mantiene (comprobado el 9 de octubre de 2026).

¿Cómo modelan la carga Gatling y JMeter?

Gatling te hace elegir entre un modelo abierto y uno cerrado en el propio script. El Thread Group clásico de JMeter es un grupo cerrado de usuarios, y la carga basada en llegadas necesita el más reciente Open Model Thread Group.

En Gatling, injectOpen recibe tasas de llegada como constantUsersPerSec y rampUsersPerSec, e injectClosed objetivos de concurrencia como constantConcurrentUsers. JMeter 5.5 añadió el Open Model Thread Group, que la referencia sigue marcando como experimental (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica por qué importa esa elección.

¿Cómo se reparte una prueba entre varias máquinas?

JMeter trae un modo distribuido integrado. La edición open source de Gatling genera carga desde una sola máquina, y su documentación pide una cuenta de Gatling Enterprise para la ejecución distribuida.

El modo de pruebas remotas de JMeter permite que un cliente controle cualquier número de servidores. Cada servidor ejecuta el plan completo, así que 1.000 hilos en seis servidores son 6.000 hilos. Todos los nodos deberían usar la misma versión de JMeter y de Java, RMI necesita un keystore salvo que desactives SSL, y los archivos de datos hay que copiarlos a cada servidor.

Hay una tercera vía para los planes de prueba de JMeter. LoadFocus, que publica este sitio, ejecuta tus planes de prueba de JMeter sin cambios desde 25 regiones cloud, sin servidores remotos que configurar. LoadFocus no ejecuta simulaciones de Gatling.

¿Cómo encajan en CI y qué informes obtienes?

Las dos se ejecutan sin interfaz. Las assertions de Gatling pueden hacer fallar el build directamente, mientras que las de JMeter marcan muestras sueltas y la integración con CI llega con bibliotecas de terceros.

Las assertions de Gatling se comprueban al terminar la ejecución, y una sola assertion fallida hace fallar la simulación y la tarea de build. El informe HTML muestra percentiles del tiempo de respuesta, usuarios iniciados por segundo, usuarios simultáneos y peticiones por segundo a lo largo del tiempo.

El modo CLI de JMeter no tiene criterios de aprobación, así que un objetivo incumplido solo hace fallar el build mediante las bibliotecas para Maven, Gradle y Jenkins que cita su README, o con una comprobación propia. El panel de JMeter añade una tabla APDEX, una tabla de estadísticas con tres percentiles configurables y resúmenes de errores, y un Backend Listener envía resultados en directo a InfluxDB o Graphite.

¿Cuál deberías elegir?

Elige Gatling si tu equipo escribe Java, Kotlin, Scala o TypeScript y quiere revisar las pruebas de carga como el resto de su código. Elige JMeter en su lugar si necesitas protocolos más allá de la web, si tus testers prefieren una interfaz gráfica o si ya tienes planes .jmx.

Gatling encaja con equipos que describen el tráfico como tasas de llegada y quieren las reglas de aprobado o fallo junto al escenario, con un informe legible sin configuración extra.

JMeter es la mejor opción para probar JDBC, LDAP, FTP o correo, para testers que refinan visualmente un flujo grabado y para ejecuciones distribuidas en tus propios servidores sin licencia comercial. Una empresa que ya usa JMeter conserva además sus planes, sus plugins y su experiencia.

FAQ

¿Gatling es más rápido que JMeter? No lo hemos medido nosotros, así que no vamos a nombrar un ganador. La comparación justa es el mismo escenario con las dos herramientas en tu propio hardware.

¿Gatling puede ejecutar archivos .jmx de JMeter? No directamente. Gatling ejecuta simulaciones escritas con sus SDK, así que un plan de JMeter hay que reescribirlo. El README de Gatling menciona extensiones de IA que convierten planes de prueba de JMeter, y requieren un token de API de Gatling Enterprise.

¿LoadFocus puede ejecutar pruebas de Gatling? No. LoadFocus ejecuta planes de prueba de JMeter y scripts de k6. Para repartir una simulación de Gatling entre varias máquinas, usa Gatling Enterprise.

Lecturas relacionadas


Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.

LoadFocus team
Escrito por el equipo de LoadFocus, las personas detrás de un servicio de pruebas de carga en la nube.