Pruebas de carga con Gatling: la herramienta JVM a fondo

Gatling es una herramienta gratuita de pruebas de carga con licencia Apache 2.0, en la que cada prueba es una simulación escrita como código que se ejecuta en la JVM y deja un informe HTML al terminar. Las pruebas de carga con Gatling encajan con equipos de desarrollo que quieren las pruebas en el repositorio, modelos de carga abiertos o cerrados y aserciones que hagan fallar el build. A los equipos que quieren un editor gráfico de pruebas o muchos protocolos les sirve mejor JMeter, y a los que quieren un único binario sin JVM, k6.

No hemos ejecutado Gatling para este análisis. Los datos proceden de la documentación, el repositorio y las páginas de versiones de Gatling, comprobados el 9 de octubre de 2026, y las valoraciones son nuestras.

¿Quién desarrolla Gatling y sigue manteniéndose?

Gatling Corp, una empresa francesa, desarrolla Gatling y tiene sus derechos de autor. Se mantiene de forma activa, con tres versiones para la JVM en lo que va de 2026.

La página de licencias atribuye los derechos de autor a Gatling Corp. Maven Central recoge la 3.15.0 en febrero, la 3.15.1 en mayo y la 3.16.0 el 29 de septiembre de 2026, y el SDK de JavaScript llegó a la 3.16.1 el 6 de octubre. Las notas de la versión 3.16 añaden GraphQL y colas compartidas entre usuarios virtuales. El README presenta el repositorio como la Community Edition, de uso libre incluso comercial (comprobado el 9 de octubre de 2026).

¿Qué necesitas para ejecutar Gatling?

Una JVM de 64 bits para Java, Kotlin o Scala, o Node.js para JavaScript y TypeScript. En ambos casos, la simulación en sí se ejecuta en una JVM.

La página de instalación admite las versiones LTS de OpenJDK del 11 al 25 y excluye las JVM de 32 bits y OpenJ9. La CLI de JavaScript requiere Node.js 24 o posterior y descarga un paquete de ejecución de Gatling y, según el README de gatling-js, GraalVM (comprobado el 9 de octubre de 2026).

¿Cómo se estructura una simulación de Gatling?

Una simulación define escenarios, asigna a cada uno un perfil de inyección y les añade una configuración de protocolo, todo registrado en una sola llamada a setUp.

En la referencia de simulaciones, un escenario encadena peticiones con pausas, bucles y condiciones. Esta simulación en Java guarda el id de un producto obtenido en una búsqueda, hace una pausa de uno a tres segundos y abre el producto, mientras las llegadas suben a 20 usuarios por segundo y se mantienen diez minutos:

public class ShopSimulation extends Simulation {

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

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Los imports se omiten, y #{id} lee el valor guardado mediante el Expression Language de Gatling. Gatling vs k6 muestra una simulación en JavaScript.

¿Conviene inyectar usuarios con un modelo abierto o cerrado?

Abierto, para la mayoría de sitios web y API, donde siguen llegando usuarios nuevos por mucho que se ralentice el sistema. El cerrado encaja con sistemas que limitan la concurrencia, como una cola de venta de entradas.

La referencia de inyección divide la API: injectOpen recibe tasas de llegada como rampUsersPerSec, e injectClosed, objetivos de concurrencia como constantConcurrentUsers. La página sobre modelos de carga dice que la mayoría de los sitios web se comportan como sistemas abiertos y que un perfil no puede mezclar ambos (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica cómo elegir.

¿Cómo funcionan los checks, las aserciones y el informe?

Los checks verifican cada respuesta y pueden guardar valores de ella, mientras que las aserciones juzgan la ejecución completa cuando termina. Después, cada ejecución genera un informe HTML.

Sin un check de estado explícito, Gatling comprueba que cada respuesta HTTP sea 2XX o 304. Las aserciones evalúan tiempos de respuesta, número de peticiones o peticiones por segundo, de forma global o por petición, y una sola aserción fallida hace fallar la simulación. El informe HTML muestra rangos de tiempo de respuesta y percentiles, usuarios iniciados por segundo, usuarios concurrentes y peticiones por segundo; sus percentiles a lo largo del tiempo solo cuentan peticiones correctas (comprobado el 9 de octubre de 2026).

¿Cómo encaja Gatling en el build y la CI?

A través de su plugin para Maven, Gradle, sbt o npm, que funciona en cualquier sistema de CI. Una aserción fallida hace fallar el build.

El plugin de Maven vincula gatling:test a la fase integration-test, así que mvn verify lo ejecuta, y con CI=true deja de preguntar qué simulación lanzar (la ejecución falla entonces si el proyecto tiene más de una simulación y no se indica ninguna). El plugin de Gradle usa gatlingRun, y el plugin de sbt solo admite simulaciones en Scala. Las integraciones de CI ya hechas de Gatling, como su GitHub Action, lanzan ejecuciones en Gatling Enterprise (comprobado el 9 de octubre de 2026). Nuestra guía de GitHub Actions cubre la parte del workflow.

¿Qué protocolos admite Gatling?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS vienen sin límites. gRPC, MQTT y GraphQL son plugins aparte, limitados a 5 usuarios y 5 minutos fuera de Gatling Enterprise.

El README incluye los cinco primeros bajo Apache 2.0. Las páginas de configuración de gRPC, MQTT y GraphQL ponen cada plugin bajo la Gatling Enterprise Component License: sin límites en Gatling Enterprise, mientras que una prueba con la Community Edition se detiene a los 5 usuarios o los 5 minutos. Esa licencia concede un uso gratuito durante un año como máximo, solo para probar internamente tus propias aplicaciones web; termina en cuanto se alcanza un límite, y Gatling puede cambiar los límites. GraphQL requiere la 3.16.0 o posterior. Sus notas de versión y el README dicen que el SDK de JavaScript todavía no lo soporta, aunque la página de configuración ya muestra un paquete npm, así que compruébalo antes de planificar una prueba de GraphQL en JavaScript (comprobado el 9 de octubre de 2026). Nuestra guía sobre cómo hacer una prueba de carga a una API GraphQL sortea el límite con peticiones HTTP normales.

¿Qué añade Gatling Enterprise?

Gatling Enterprise es la edición comercial sobre el mismo motor. Genera carga desde infraestructura gestionada o privada, algo que la edición gratuita no hace.

Según el README, Enterprise ejecuta las pruebas en generadores de carga gestionados o en tus propias cuentas de AWS, Azure, GCP o Kubernetes, y añade paneles en directo, tendencias, equipos con SSO e integraciones de CI/CD. Las preguntas frecuentes indican que la Community Edition no admite pruebas distribuidas y que las simulaciones pasan a Enterprise sin cambios (comprobado el 9 de octubre de 2026).

LoadFocus, que publica este sitio, no ejecuta simulaciones de Gatling. Ejecuta planes de prueba de JMeter y scripts de k6 desde 25 regiones cloud, así que para Gatling el camino hacia más máquinas es Gatling Enterprise.

¿Qué hace bien Gatling y dónde están sus límites?

Destaca en pruebas como código revisable, en modelos de carga y en informes sin configuración. Se queda corto en protocolos más allá de la web y la mensajería, y al escalar gratis más allá de una máquina.

El README destaca su motor: no bloqueante, construido sobre Netty, donde cada usuario virtual es un mensaje ligero. Límites que la propia documentación reconoce (comprobado el 9 de octubre de 2026):

• Gatling no es un navegador: según la página del protocolo HTTP, no ejecuta JavaScript.
• El SDK de JavaScript no tiene JMS y no puede usar librerías de npm que necesiten binarios nativos o API propias de Node.js.
• La caché HTTP está activada por defecto, lo que puede reducir el número de peticiones.
• El formato de simulation.log no está documentado y puede cambiar en cualquier momento.

¿Cuándo elegir k6, JMeter o Locust en lugar de Gatling?

Elige otra herramienta cuando su lenguaje, sus protocolos o su forma gratuita de escalar encajen mejor con tu equipo.

Nuestro repaso de herramientas de pruebas de carga open source sitúa Gatling junto a otras cinco.

Elige k6 si quieres en la CI un único binario sin JVM, thresholds que puedan detener pronto una ejecución fallida o gRPC entre sus protocolos integrados (comprobado el 9 de octubre de 2026). Gatling vs k6 compara las dos.

Elige JMeter si tus testers crean las pruebas en una interfaz gráfica, o si necesitas JDBC, LDAP o FTP desde su núcleo (comprobado el 9 de octubre de 2026). LoadFocus ejecuta tus planes de prueba de JMeter desde 25 regiones cloud, y Gatling vs JMeter profundiza más.

Elige Locust si tu equipo escribe Python y quiere un modo distribuido en la herramienta gratuita (comprobado el 9 de octubre de 2026). Nuestro análisis de Locust lo cubre.

FAQ

¿Gatling es gratuito para uso comercial? Sí. La Community Edition tiene licencia Apache 2.0. Los plugins de gRPC, MQTT y GraphQL tienen su propia licencia y se detienen a los 5 usuarios y 5 minutos fuera de Gatling Enterprise.

¿Hace falta Java para usar Gatling? Para Java, Kotlin o Scala, sí: un OpenJDK LTS de 64 bits del 11 al 25. El SDK de JavaScript necesita Node.js 24 o posterior, y su CLI descarga por sí misma el entorno JVM.

¿Puede LoadFocus 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

• Gatling vs JMeter: ¿pruebas como código o un plan en GUI?
• Gatling vs k6: ¿simulaciones en la JVM o un binario Go?
• Herramientas de pruebas de carga open source: seis opciones
• Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?
• Pruebas de carga con NBomber: análisis del framework .NET

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