Pruebas de carga con Locust: análisis de la herramienta

Locust es una herramienta de pruebas de carga en Python, gratuita y con licencia MIT, en la que cada prueba es un programa de Python, ejecutado por usuarios ligeros desde una interfaz web o la línea de comandos. Las pruebas de carga con Locust encajan con equipos que escriben Python y prueban sobre todo servicios HTTP. A quien necesite muchos protocolos de serie o un editor gráfico de pruebas le irá mejor JMeter, y a quien escriba JavaScript, k6.

No hemos ejecutado Locust para este análisis. Los datos salen de la documentación, el repositorio y la página de PyPI de Locust, comprobados el 9 de octubre de 2026, y las valoraciones son nuestras.

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

Lars Holmberg mantiene Locust y Microsoft patrocina ese trabajo. Las versiones salen a menudo: 17 en lo que va de 2026.

El README de Locust nombra a ambos. PyPI muestra la 2.46.7, publicada el 4 de octubre de 2026, como última versión, y exige Python 3.11 o posterior (comprobado el 9 de octubre de 2026).

¿Cómo funciona un locustfile?

Un locustfile es un módulo de Python normal con al menos una clase de usuario. Cada usuario simulado ejecuta sus tareas una tras otra y hace una pausa entre ellas según su wait_time.

Según la guía del locustfile, HttpUser da a cada usuario un client que envuelve python-requests, conserva las cookies y registra cada petición. Los métodos marcados con @task se eligen al azar, ponderados por el número del decorador, y on_start se ejecuta una vez por usuario. Este usuario inicia sesión, navega por el catálogo cuatro veces más de lo que compra y lanza como mucho una tarea cada 10 segundos:

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

catch_response te permite dar por fallida una petición según su contenido, y name agrupa las URL variables en una sola fila de estadísticas. Las demás funciones de espera son constant, between, constant_throughput y, desde la versión 2.46.6, poisson; nuestra guía sobre el tiempo de reflexión en pruebas de carga explica cómo esas pausas dan forma a la carga. La documentación añade que el tiempo de espera solo puede limitar el rendimiento y no lanza usuarios nuevos para alcanzar un ritmo objetivo. Una prueba de Locust es, por tanto, un grupo fijo de usuarios: un modelo de carga cerrado.

¿Conviene usar la interfaz web o el modo headless?

La interfaz web mientras exploras y el modo headless para ejecuciones repetibles.

El comando locust arranca una interfaz web en el puerto 8089. Allí indicas el host, los usuarios y la rampa de subida, sigues gráficos en vivo y cambias la carga a mitad de prueba. El modo headless recibe los mismos ajustes como opciones:

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u fija los usuarios, -r cuántos arrancan por segundo y -t la duración, con la rampa de subida incluida. Los mismos ajustes funcionan también en locust.conf o pyproject.toml.

¿Cómo funciona el modo distribuido?

Un proceso master gestiona la interfaz web y coordina, mientras los procesos worker ejecutan los usuarios y le envían sus estadísticas. Necesitas un worker por núcleo de CPU, porque un proceso de Python no puede aprovechar del todo más de un núcleo.

Según la documentación de carga distribuida, un solo proceso supera las mil peticiones por segundo con un plan de prueba sencillo, así que las pruebas más grandes se reparten:

# en la máquina master
locust -f locustfile.py --master
# en cada máquina worker, un worker por núcleo
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - descarga el locustfile desde el master. --processes depende de fork(), así que no funciona en Windows, y cada cambio en el locustfile obliga a reiniciar todos los procesos. La documentación cubre además un operador de Kubernetes y Azure Load Testing (comprobado el 9 de octubre de 2026).

LoadFocus, el editor de este sitio, no ejecuta pruebas de Locust. Ejecuta planes de prueba de JMeter y scripts de k6 desde 25 regiones en la nube, así que para Locust las vías de arriba siguen siendo las formas de escalar.

¿Puede Locust probar protocolos distintos de HTTP?

Sí, si aportas un cliente de Python para el protocolo. Solo HTTP y HTTPS vienen integrados.

La página sobre otros protocolos muestra cómo envolver un cliente para que cada llamada quede registrada, con ejemplos para XML-RPC y gRPC y clases de usuario experimentales para MQTT, Socket.IO y OpenAI. El proyecto aparte locust-plugins añade usuarios para Kafka, FTP, Selenium y Playwright (comprobado el 9 de octubre de 2026).

Para HTTP existe también FastHttpUser, que usa geventhttpclient y consume mucha menos CPU. En el mejor caso, según la documentación, un proceso llega a unas 16.000 peticiones por segundo, frente a 4.000 con HttpUser. FastHttpUser no hace más rápida cada petición, y por defecto no verifica los certificados TLS.

¿Qué informes da Locust y cómo encaja en la CI?

Obtienes gráficos en vivo en la interfaz web y, si los pides, archivos de resultados. En la CI, Locust termina con código 1 si alguna petición falló.

Según la referencia de configuración, --csv escribe archivos de estadísticas, historial y fallos, --html guarda un informe y --json imprime las estadísticas finales. --otel exporta a un backend de OpenTelemetry. La documentación del modo headless muestra un listener que hace fallar la ejecución según la tasa de fallos, el tiempo de respuesta medio o el percentil 95, y nuestra guía de pruebas de carga en GitHub Actions lo integra en un workflow.

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

Destaca en la lógica de las pruebas y con muchos usuarios simultáneos que pasan casi todo el tiempo esperando. Es más flojo en peticiones por proceso y en los protocolos que tienes que conectar por tu cuenta.

Como las pruebas son Python puro, los bucles, las condiciones, los datos generados y tu propio cliente de API funcionan sin más, y las pruebas viven en el control de versiones. La página What is Locust explica que el bajo coste de cada usuario encaja con cargas muy concurrentes, aunque admite que otras herramientas pueden enviar más peticiones por segundo con el mismo hardware.

Los límites que reconoce la propia documentación:

• Un proceso de Python usa un solo núcleo de CPU.
• Las bibliotecas que hacen E/S en C bloquean el proceso, salvo que gevent pueda parchearlas.
• HttpUser no analiza HTML ni carga los recursos de la página.
• El tiempo de espera no puede añadir usuarios para sostener un ritmo de peticiones.

¿Qué otras herramientas de Python hay para pruebas de carga?

Locust es el motor de Python con desarrollo activo. Molotov, la principal alternativa, no publica ninguna versión en PyPI desde 2022, y Taurus ejecuta Locust con uno de sus ejecutores.

Molotov es una herramienta para Python 3.8+ construida sobre asyncio y aiohttp; su última versión en PyPI es la 2.6, del 21 de octubre de 2022, y el último commit de su rama principal es de noviembre de 2023 (comprobado el 21 de octubre de 2026). Taurus ejecuta un locustfile, o peticiones GET y POST sencillas escritas en YAML, con su ejecutor locust. Locust lo instalas tú, en modo distribuido Taurus solo arranca el master y su ajuste throughput no tiene efecto con este ejecutor (comprobado el 21 de octubre de 2026).

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

Elige otra herramienta cuando su lenguaje, sus protocolos o su modelo de carga encajen mejor con tu equipo.

Nuestro repaso de herramientas de pruebas de carga open source pone Locust junto a otras cinco.

Elige k6 en lugar de Locust si tu equipo escribe JavaScript, quiere criterios de aprobado o suspenso como thresholds en el script, o necesita un modelo de carga abierto, que es lo que ofrecen los ejecutores arrival-rate de k6 (comprobado el 9 de octubre de 2026). LoadFocus ejecuta scripts de k6 desde 25 regiones en la nube, pero lanza los escenarios arrival-rate con un número fijo de usuarios; para sostener un ritmo de peticiones, ejecútalos con k6 directamente.

Elige JMeter en lugar de Locust si necesitas JDBC, JMS, LDAP o FTP de serie, como enumera su README, o si tus testers montan las pruebas en una interfaz gráfica. Locust vs JMeter compara ambas a fondo.

Elige Gatling en lugar de Locust si tu equipo trabaja sobre la JVM y quiere perfiles de inyección abiertos y cerrados en una misma API (comprobado el 9 de octubre de 2026). Gatling vs JMeter lo trata con más detalle.

FAQ

¿Locust es gratis para uso comercial? Sí. Locust se publica con licencia MIT, que permite el uso comercial, la modificación y la redistribución.

¿Qué versión de Python necesita Locust? Python 3.11 o posterior, según sus metadatos en PyPI. Instálalo con pip install locust, o ejecútalo en un entorno temporal con uvx locust.

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

Lecturas relacionadas

• Locust vs JMeter: ¿scripts de Python o planes de JMeter?
• Herramientas de pruebas de carga open source: seis opciones
• k6 vs Locust: ¿scripts JavaScript o usuarios Python?
• Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?

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