Locust vs JMeter: ¿scripts de Python o planes de JMeter?

Locust y Apache JMeter son dos herramientas de pruebas de carga gratuitas y open source, y cuál encaja mejor depende sobre todo de cómo quiere construir las pruebas tu equipo. Elige Locust si tu equipo escribe Python y quiere la lógica de prueba como código normal, ejecutada por usuarios ligeros basados en eventos. Elige JMeter si necesitas protocolos más allá de HTTP como JDBC, JMS o LDAP, prefieres montar las pruebas en una interfaz gráfica o ya tienes una colección de planes de prueba .jmx.

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

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

En Locust una prueba es un programa en Python. En JMeter una prueba es un plan que montas en una interfaz gráfica de escritorio y guardas en un archivo, y de ahí salen casi todas las demás diferencias.

El README de Locust describe pruebas escritas con bucles, condiciones y bibliotecas de Python normales. Se instala con pip install locust y necesita Python 3.11 o posterior, según sus metadatos de paquete.

Una prueba de JMeter es un árbol de elementos: 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 descargas, 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). Cuando un paso necesita lógica de verdad, un sampler JSR223 ejecuta un script de Groovy dentro del plan.

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

En Locust escribes una clase de Python por cada tipo de usuario, con métodos marcados como tareas. En JMeter añades un Thread Group y samplers en la interfaz gráfica, guardas el plan y lo ejecutas desde la línea de comandos.

Un usuario de Locust que espera entre uno y tres segundos entre tareas y consulta la lista de usuarios tres veces más a menudo que la ficha de un usuario concreto:

from locust import HttpUser, task, between


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

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

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Para lanzarlo sin interfaz con 50 usuarios, cinco nuevos por segundo, durante cinco minutos:

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

En JMeter la misma prueba es un Thread Group con 50 hilos y un periodo de rampa de subida, que contiene dos samplers HTTP Request. La guía de inicio ejecuta un plan guardado en modo CLI, y -e -o añade el informe HTML al final:

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

El archivo .jmx es XML, como muestran los ejemplos que incluye JMeter, y cuesta más revisarlo en un pull request que un archivo Python. JMeter también puede grabar un plan desde el navegador; lo más parecido en Locust es har2locust, un conversor de grabaciones HAR a locustfile que sigue en beta (comprobado el 9 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

JMeter cubre muchos más protocolos de serie. Locust trae HTTP y HTTPS y espera que aportes un cliente Python para todo lo demás.

El README de JMeter enumera HTTP y HTTPS, SOAP y REST, FTP, bases de datos mediante JDBC, LDAP, mensajería JMS, correo por SMTP, POP3 e IMAP, TCP, comandos nativos y objetos Java. JDBC y JMS necesitan los JAR del controlador que proporciona tu proveedor de base de datos o de JMS.

La página sobre otros protocolos de la documentación de Locust muestra cómo envolver una biblioteca de protocolo, con ejemplos para gRPC, XML-RPC y MQTT, y remite a locust-plugins para Kafka, Selenium y Playwright (comprobado el 9 de octubre de 2026). La biblioteca tiene que funcionar con gevent, porque la E/S hecha en código C compilado bloquea todo el proceso; la documentación cita el controlador de PostgreSQL psycopg2, que necesita un paquete adicional. Para pruebas de carga contra bases de datos, el sampler JDBC de JMeter es el camino más corto.

¿Cómo funcionan los usuarios virtuales en Locust y JMeter?

JMeter ejecuta cada usuario virtual como un hilo de Java. Locust ejecuta cada usuario como un greenlet en el bucle de eventos de gevent, lo que mantiene bajo el coste de cada usuario.

Cada hilo de un Thread Group de JMeter recorre el plan completo de forma independiente. JMeter arranca por defecto con un heap de 1 GB, que según su guía puede quedarse corto en planes grandes y con muchos hilos.

Según su README, un solo proceso de Locust puede manejar muchos miles de usuarios concurrentes. La documentación de carga distribuida añade que un proceso de Python no puede aprovechar del todo más de un núcleo de CPU, así que se lanza un worker por núcleo, algo que --processes prepara por ti en una sola máquina.

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

Las dos tienen un modo distribuido integrado. En Locust un master dirige a los workers que ejecutan los usuarios, y en JMeter el cliente lanza el plan de prueba completo en cada servidor remoto.

En Locust, un proceso iniciado con --master ejecuta la interfaz web y les indica a los procesos --worker cuándo arrancar y detener usuarios. La documentación de Locust también cubre un operador de Kubernetes y Azure Load Testing, un servicio de Microsoft que ejecuta pruebas de Locust en la nube (comprobado el 9 de octubre de 2026).

El modo de pruebas remotas de JMeter permite que un cliente controle tantos servidores como quieras mediante RMI. 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, el editor de este sitio, ejecuta tus planes de prueba de JMeter existentes sin cambios desde 25 regiones en la nube, sin servidores remotos que configurar. LoadFocus no ejecuta pruebas de Locust, así que para Locust siguen valiendo las opciones de arriba para escalar.

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

Las dos se ejecutan sin interfaz desde la línea de comandos. Locust además termina con el código de salida 1 cuando fallan peticiones, y JMeter genera el informe HTML más completo.

La documentación del modo headless de Locust muestra un listener de eventos corto que fija el código de salida según la tasa de fallos, el tiempo de respuesta medio o el percentil 95, además de un ejemplo para GitHub Actions. Las opciones --csv y --html guardan los resultados y un informe al terminar.

La documentación de JMeter es tajante: las pruebas de carga se ejecutan en modo CLI y la interfaz gráfica queda para construir y depurar. Su README remite a bibliotecas de terceros para Maven, Gradle y Jenkins. El panel de JMeter incluye una tabla APDEX, una tabla de estadísticas con tres percentiles configurables, resúmenes de errores y gráficos del tiempo de respuesta.

¿Cuál deberías elegir?

Elige Locust si tu equipo escribe Python 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 HTTP, si tus testers prefieren una interfaz gráfica o si ya tienes planes .jmx.

Locust encaja con escenarios que tienen bucles, ramificaciones y datos generados, con pruebas que reutilizan un cliente Python interno de tu API y con mucha concurrencia de usuarios que pasan la mayor parte del tiempo esperando.

JMeter es la mejor opción para probar JDBC, JMS, LDAP, FTP o correo, donde Locust necesitaría un cliente que tendrías que mantener tú, y para testers que graban un recorrido en el navegador y lo afinan de forma visual. Una empresa que ya usa JMeter conserva además sus planes y su experiencia.

FAQ

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

¿Locust puede ejecutar archivos .jmx de JMeter? No según su documentación, que describe las pruebas solo como locustfiles de Python. Pasar un plan de prueba de JMeter a Locust significa reescribirlo en Python.

¿LoadFocus puede ejecutar pruebas de Locust? No. LoadFocus ejecuta scripts de JMeter y k6. Para escalar una prueba de Locust más allá de una máquina, usa el modo master y workers de Locust, su operador de Kubernetes o Azure Load Testing.

Lecturas relacionadas

• Pruebas de carga con Locust: análisis de la herramienta
• Gatling vs JMeter: ¿pruebas como código o un plan en GUI?
• k6 vs Artillery: qué herramienta de pruebas de carga elegir
• k6 vs Locust: ¿scripts JavaScript o usuarios Python?
• Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?
• JMeter vs Postman: ¿qué herramienta para pruebas de carga?

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