Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?

Gatling y Locust son dos herramientas open source gratuitas que guardan las pruebas de carga como código en tu repositorio. Elige Gatling si tu equipo trabaja en la JVM o si quieres perfiles de inyección abiertos y cerrados, aserciones y un informe HTML en un solo paquete. Elige Locust si tu equipo escribe Python, valora una interfaz web para iniciar y seguir una ejecución, y necesita el modo distribuido sin una edición comercial.

Los datos de esta comparación Gatling vs Locust salen de la documentación y del repositorio de cada proyecto, comprobados el 13 de octubre de 2026.

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

Gatling ejecuta simulaciones en la JVM y Locust ejecuta programas de Python normales. Gatling trae de serie un modelo de carga y un informe, y en Locust escribes tú mismo la lógica de la prueba.

El README de Gatling describe un motor no bloqueante construido sobre Netty y un SDK en cinco lenguajes: Java, Kotlin y Scala se ejecutan con Maven, Gradle o sbt, y JavaScript y TypeScript con un SDK aparte. Su página de instalación pide un OpenJDK LTS de 64 bits de la 11 a la 25, y Node.js 24 o posterior para el SDK de JavaScript.

El README de Locust lo presenta como una forma de escribir pruebas de carga escalables en Python puro, y sus metadatos del paquete exigen Python 3.11 o posterior. La página What is Locust dice que se basa en eventos con gevent, así que un solo proceso puede manejar muchos miles de usuarios concurrentes (comprobado el 13 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

En Gatling encadenas peticiones en un escenario y le das un perfil de inyección. En Locust escribes una clase de usuario con tareas y un tiempo de espera entre ellas.

Cincuenta usuarios concurrentes que listan usuarios y luego esperan de uno a tres segundos, durante cinco minutos. Con el SDK de Java de Gatling (imports omitidos):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

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

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

La misma prueba en Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

La referencia de inyección de Gatling incluye constantConcurrentUsers entre los pasos del modelo cerrado. Locust recibe el número de usuarios y la duración como opciones (comprobado el 13 de octubre de 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

¿Cómo modelan la carga Gatling y Locust?

Gatling ofrece modelos abiertos y cerrados, según el método que llames. Locust ejecuta un pool de usuarios, lo que equivale a un modelo cerrado.

La página de modelos de carga de Gatling define los sistemas cerrados como los que limitan los usuarios concurrentes, y los abiertos como aquellos en los que los usuarios siguen llegando aunque la aplicación responda despacio. Añade que la mayoría de los sitios web son abiertos. injectOpen recibe tasas de llegada e injectClosed objetivos de concurrencia.

La guía del locustfile dice que el tiempo de espera solo puede limitar el rendimiento y no lanza usuarios nuevos para alcanzar una tasa objetivo. Si una vuelta tarda más de lo que permite la espera, la tasa queda por debajo del objetivo (comprobado el 13 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica por qué importa.

¿Cómo se ejecuta una prueba mayor de lo que genera una sola máquina?

Locust trae el modo distribuido integrado. La edición open source de Gatling genera carga desde una sola máquina, y las ejecuciones distribuidas requieren Gatling Enterprise.

Locust arranca un proceso con --master y tantos procesos --worker como quieras. Según los docs de carga distribuida, un proceso de Python no usa más de un núcleo, así que se ejecuta un worker por núcleo, y --processes arranca varios en una máquina. Un operador de Kubernetes gestiona las ejecuciones distribuidas dentro de un clúster.

Las preguntas frecuentes de Gatling dicen que la Community Edition no admite pruebas distribuidas, y el README describe Enterprise como una ejecución en generadores de carga gestionados o en infraestructura privada (comprobado el 13 de octubre de 2026).

Hay una salida para ambas. LoadFocus, que publica este sitio, no ejecuta simulaciones de Gatling ni pruebas de Locust. Si prefieres no ejecutar ninguna de las dos a gran escala, ejecuta scripts de k6 y planes de prueba de JMeter desde 25 regiones en la nube. Su validador de k6 avisa de que los escenarios de tasa de llegada se ejecutan allí con un número fijo de usuarios, así que no mantienen un ritmo de peticiones. Pasar de cualquiera de las dos herramientas a esas obliga a reescribir la prueba.

¿Cómo deciden si una prueba ha pasado, y qué informes obtienes?

Gatling evalúa las aserciones después de la ejecución y escribe un informe HTML cada vez. Locust termina con el código 1 si falló alguna petición, y otras comprobaciones las añades como listener.

Las aserciones de Gatling se evalúan después de la simulación, y una sola aserción fallida hace fallar la simulación. Su informe HTML muestra percentiles del tiempo de respuesta, usuarios iniciados por segundo, usuarios concurrentes y peticiones por segundo.

Según los docs headless de Locust, la ejecución termina con el código 1 si alguna muestra falló, y un ejemplo de listener hace fallar la ejecución por el ratio de fallos, el tiempo de respuesta medio o el percentil 95. La referencia de configuración menciona --csv para archivos de estadísticas y --html para un informe (comprobado el 13 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

Gatling trae más protocolos, con límites en los más nuevos. Locust trae HTTP y HTTPS y espera un cliente de Python para el resto.

El README de Gatling enumera HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS bajo Apache 2.0 sin límites. gRPC, MQTT y GraphQL están bajo la Gatling Enterprise Component License, y las pruebas con ellos quedan limitadas a 5 usuarios concurrentes y 5 minutos en la Community Edition.

La página sobre otros sistemas de Locust muestra cómo envolver una librería de protocolo y notificar cada llamada, con ejemplos de gRPC y MQTT. La librería tiene que funcionar con gevent, que no puede parchear la E/S hecha en código C compilado, y locust-plugins añade usuarios para Kafka, Selenium y Playwright (comprobado el 13 de octubre de 2026).

¿Cuál deberías elegir?

Elige según el lenguaje y la forma de cargar el sistema. Gatling encaja con equipos JVM y pruebas en modelo abierto, y Locust con equipos Python y pruebas con lógica propia.

Elige Gatling en lugar de Locust si tu equipo vive en la JVM y quiere pruebas en Java, Kotlin o Scala construidas con Maven, Gradle o sbt, si necesitas un modelo abierto como una tasa de llegada fija, si necesitas JMS o Server-Sent Events, o si quieres aserciones y un informe sin código adicional.

Elige Locust en lugar de Gatling si tu equipo escribe Python y quiere que las pruebas reutilicen un cliente interno de Python, si quieres una interfaz web para iniciar una ejecución y cambiar la carga mientras corre, si necesitas el modo distribuido en la herramienta gratuita, o si el sistema recibe sobre todo usuarios que esperan y tu protocolo tiene una librería de Python compatible con gevent.

Para un constructor de pruebas con interfaz gráfica mira JMeter, y para un solo binario sin JVM ni Python mira k6.

FAQ

¿Es Gatling más rápido que Locust? 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.

¿Puede Locust ejecutar simulaciones de Gatling? No según la documentación de Locust, que describe las pruebas solo como código Python. Una simulación de Gatling hay que reescribirla como locustfile, y lo mismo vale a la inversa.

¿Puede LoadFocus ejecutar pruebas de Gatling o de Locust? 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, y para Locust su modo master y workers o su operador de Kubernetes.

Lecturas relacionadas

• Pruebas de carga con Gatling: la herramienta JVM a fondo
• Pruebas de carga con Locust: análisis de la herramienta
• Gatling vs k6: ¿simulaciones en la JVM o un binario Go?
• Locust vs JMeter: ¿scripts de Python o planes de JMeter?
• Modelo de carga abierto vs cerrado: cuál usar y cuándo

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