Locust lets you describe user journeys in Python
Log in, fetch a list, then open an item: Locust lets you put that sequence in regular Python and repeat it with simulated users. The README example uses an HTTP client and a login hook, with task methods for later requests. That is an attractive fit for a Python team whose workload includes conditional behavior or application-specific data. You can review the scenario alongside the service code instead of maintaining a separate graphical plan.
Our checkout contained 430 files and roughly 44,433 source lines, taking 10.4 MB before the measured install. The project offers a live web interface and a command-line path, with request timing and errors available for export. I'd choose it when the scenario's behavior matters more than a simple URL hammer. A misleading login sequence or unrealistic wait policy can still produce a neat report, so knowing Python doesn't remove the need to understand the application.
What happened when we ran it
Our sandbox completed an npm install at Locust commit 25a559c in 5 seconds, reported 0 packages installed, and used 18 MB on disk. We ran it on October 11, 2026, in a fresh Debian container with 3 CPUs, 8 GB of RAM, image lab-node:22, no secrets, and no elevated privileges. The run classified the checkout as a Node/npm project. Locust's README and repository metadata describe its load-testing runtime as Python.
The harness found no build script or target and skipped that step. It also found no test script or target and skipped tests. A skipped step is no passing result, and a successful npm command supplies no evidence that Locust's Python package imports or starts. We cannot use this run to claim a working Python installation, validated scenarios, or measured request throughput. The limitation belongs beside the result rather than hidden behind an install-success label.
Npm audit reported 0 known vulnerabilities, with 0 critical, high, moderate, or low findings. That result covers the npm audit performed in this run, not an examination of Python dependencies. The scan found 2 CI workflow files and a Dockerfile, with no tests directory. A directory-name scan also cannot establish that the Python project has no tests. The useful measured conclusion is narrow: the detected npm path completed and the core runtime remained unverified.
HTTP users don't reproduce a browser page load
The locustfile guide explicitly says HttpUser doesn't render pages or parse HTML to load resources. Cookies are tracked, but JavaScript execution and asset fetching aren't automatic browser behavior. If your goal is judging the experience of an interactive frontend under load, this default client misses part of the job. Locust's request statistics can still help investigate the backend calls, provided you model those calls explicitly.
Our 3-CPU, 8 GB container result doesn't supply a browser-performance measurement or a load-generator capacity figure. Even for an API, write down what users actually do: whether they authenticate, which data they read, and when they pause. Locust's Python hooks let you encode that work, but the author is responsible for choosing it. I'd reject a scenario that reports success for requests made with an expired token before trusting its latency graph.
Request names matter as well. The guide shows how a stable name groups varying item URLs so results describe an operation instead of separating every record identifier. That helps a report answer a practical question, such as whether opening items slows down. Issue 3437 requests a more convenient way to refresh authentication headers before requests. It illustrates the surrounding code authenticated workloads may need, rather than proving authentication is unsupported.
Custom protocols and distributed workers need engineering
The other-protocol guide explains how an adapter emits request events so Locust can record results. It warns that libraries doing input/output inside compiled C code may resist gevent's cooperative scheduling and block the whole process. That is a concrete reason to pass if your required client library cannot cooperate and you can't maintain an adapter. The broad protocol-extension promise needs to be checked against the library you actually use.
The 18 MB npm footprint says nothing about that adapter's Python environment or its operating cost. Distributed runs add a master and workers, and the distributed guide says the master coordinates users while workers run them. It also notes that the process-launch convenience depends on fork() and doesn't work on Windows. Plan worker reachability and scenario distribution separately from installing the local command, especially if your load generators sit on different machines.
October fixes show maintenance without validating our runtime
The last push was October 10, 2026, and GitHub listed 5 open issues and PRs. Release 2.46.7, published October 4, includes corrections for invalid user counts, request behavior, and pacing after clock changes. Current pull requests address reporting directories and malformed HTTP responses. The small combined queue accompanies recent activity, but neither fact substitutes for a Python runtime check on the environment you intend to operate.
K6 is the comparison for a team preferring JavaScript scenarios. JMeter offers another load-testing workflow when a graphical plan is useful. I'd choose Locust for Python developers willing to own realistic request journeys and inspect their client libraries. Before relying on it, verify the Python runtime and a representative authenticated scenario on your chosen machines. Our 5-second npm success is a record of a limited harness path, and it leaves that adoption check open.