Locust
Python-based load testing with distributed execution. Define user behaviour in code and scale across multiple machines.
Overview
Locust, created in 2009, is an open-source load testing tool written in Python. Unlike JMeter or Gatling which use declarative test definitions, Locust lets you write user behaviour as Python code. This makes it extremely flexible — you can generate dynamic data, call external APIs, query databases, and implement complex logic directly in your test scripts.
Locust uses a master-slave architecture for distributed load testing. A single Locust master can coordinate thousands of slave nodes, each running Python processes that simulate users.
What it's used for
Locust is ideal when:
- Python team: Tests are Python code, fitting naturally into Python projects.
- Complex user behaviour: Dynamic data generation, conditional logic, and external API calls in tests.
- Distributed load testing needed: Scale across multiple machines with simple master-slave setup.
- Custom integrations required: Connect to databases, message queues, or internal systems during tests.
Pros & Cons
Pros
- Python code — full programming power in test scripts
- Simple distributed testing with master-slave architecture
- Web UI for real-time monitoring during test execution
- Extensible via Python libraries (requests, SQLAlchemy, etc.)
- Free and open source (MIT licence)
Cons
- Python only — not suitable for Java or JavaScript teams
- Single-threaded per process — needs more processes for high concurrency
- No built-in GUI for test creation
- Smaller ecosystem than JMeter
- Less efficient resource usage than Go-based k6 or Scala-based Gatling
Platforms & Integrations
Locust runs on Windows, macOS, and Linux. It requires Python 3.7+. Distributed testing is supported natively.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full framework, distributed testing, web UI |
NZ Context
Locust is popular among NZ Python-heavy teams, particularly in data science and backend-focused companies. Rocket Lab (NZ-founded aerospace company) has used Python-based tooling for internal systems testing. For NZ teams already using Python for backend development, Locust is a natural choice for load testing.
Alternatives
- k6 — JavaScript-based. Better performance per machine.
- JMeter — GUI-based. Better for non-programming testers.
- Gatling — More efficient for high-concurrency web scenarios.
When to choose Locust
A quick decision guide for NZ teams evaluating performance testing options.
| Choose Locust when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team writes Python — backend devs already know the language and can write realistic user scenarios without a DSL | You need to push 50,000+ virtual users from a single machine — k6 or Gatling are far more CPU-efficient and will cost you less in cloud spend | Grafana + InfluxDB — stream Locust metrics in real time so you get persistent dashboards, not just the in-run web UI |
| Your load scenarios are complex — dynamic tokens, database seed lookups, conditional flows based on API responses — things a declarative tool would make painful | Your testers are non-technical and need a GUI to build scripts — JMeter's graphical recorder will save them weeks of frustration | pytest — run Locust headless in CI alongside your functional suite so load thresholds become a failing test, not a manual check |
| You need distributed load from multiple regions and want to avoid a commercial SaaS licence — Locust workers deploy trivially on Docker or Kubernetes | You're testing a browser-heavy frontend with client-side rendering — Locust only speaks HTTP; use k6 browser mode or Playwright instead | Datadog or New Relic APM — correlate Locust load events with server-side traces so you can pinpoint which service degrades first under load |
| You're testing non-HTTP protocols — gRPC, WebSocket, MQTT — Locust's pluggable client model handles these cleanly via custom client classes | Stakeholders expect polished HTML reports out of the box — Gatling produces a self-contained HTML report that non-technical managers can read; Locust's CSV export needs post-processing | GitHub Actions + Docker Compose — spin up Locust master + workers ephemerally on every release branch so load testing never gets skipped before a go-live |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were a performance engineer at CloudBooks preparing for their end-of-financial-year spike — where tens of thousands of NZ accountants reconcile accounts simultaneously on the same evening
I would…
Model the actual user journey in Locust Python code: authenticate via OAuth, open the dashboard, trigger a bank feed reconciliation, then export a GST return. Real token handling, real session state. Run 2,000 simulated users ramped over 10 minutes from three AWS regions simultaneously. Any endpoint breaching a 2-second p95 response time gets a bug filed before the release goes out — not a post-mortem after.
If…
I were on the QA team at ListRight and a developer asked me whether to use Locust or k6 for testing their new listings search API
I would…
Ask one question first: what language does the team write day-to-day? If Python, Locust wins — the dev can own and maintain the test script without a context switch. If JavaScript, reach for k6 instead; it runs 30–40% more virtual users on identical hardware and the scripting feels natural to a Node developer. Don't pick tools on name recognition — pick them on who has to maintain them at 2am during an incident.
If…
I were introducing Locust to a team at Revenue NZ where most testers have a manual background and no Python experience
I would…
Start with a two-hour Python basics session focused only on the subset Locust needs: classes, methods, decorators, and the requests library. Then pair-write the first Locust script together against a non-production environment — one tester drives, I navigate. Within a week they can copy-adapt an existing script for a new endpoint. If after a month nobody is confident maintaining the code, that's a signal to re-evaluate: switch to k6 or consider a hosted option like Grafana Cloud k6 that abstracts some of the scripting complexity.
The bottom line: Locust is the right tool when your team already thinks in Python — the moment you're fighting the language, you're spending debugging budget on infrastructure instead of finding real performance bugs.
Interview questions
Questions you are likely to get if you list locust on your CV — with what interviewers are really testing for.
What is the difference between Locust and JMeter, and why might a Python team prefer Locust?
What they’re really testing: Whether you understand tool trade-offs at a conceptual level, not just whether you can run a script.
Strong answer covers: Locust test scripts are plain Python code vs. JMeter’s XML/GUI definitions; Locust fits naturally into a Python CI pipeline and version control workflow; JMeter has a richer GUI and a larger plugin ecosystem which is better for non-programmers — mention that the right choice depends on who will maintain the tests long-term.
When would you choose k6 over Locust for a load testing engagement?
What they’re really testing: Whether you make tool decisions on evidence rather than habit or hype.
Strong answer covers: k6 is written in Go and runs 30–40% more virtual users per machine, so it costs less in cloud compute at high concurrency; k6 uses JavaScript which suits frontend-heavy or Node.js teams; Locust wins when the team already writes Python and needs complex data-driven scenarios; bring up that at a NZ SaaS company like CloudBooks or Pushpay, machine cost under sustained load matters when running tests from multiple cloud regions.
You’re joining the performance testing team at ListRight. Their checkout flow involves OAuth login, dynamic search results, and cart state — how would you model that in Locust?
What they’re really testing: Whether you can translate a real multi-step user journey into Locust code, not just fire HTTP requests at a single endpoint.
Strong answer covers: Define a HttpUser class with a @task sequence mirroring the real flow (login → search → view listing → add to cart); handle the OAuth token in on_start so it authenticates once per virtual user and reuses the session; use wait_time = between(1, 3) to simulate realistic think time; mention seeding test data (e.g. unique search terms per user) from a CSV to avoid cache distortion.
Your Locust tests pass locally with 50 users but the master node shows massive failure rates when you run 500 users in CI. How do you diagnose this?
What they’re really testing: Systematic fault isolation under pressure — can you separate infrastructure problems from application problems.
Strong answer covers: First check Locust’s own web UI or CSV output to distinguish connection errors from HTTP 4xx/5xx errors — they point to different root causes; verify CI worker CPU and open file descriptor limits (ulimit -n) since Locust is single-threaded per process and can exhaust OS socket limits; check whether the CI environment is running in the same AWS region as the target — cross-region latency inflates response times; finally confirm the test environment can actually sustain 500 concurrent users (it may be under-provisioned relative to production).
How would you structure a distributed Locust setup to load test a government API like Revenue NZ’s myIR gateway, and what safeguards would you put in place?
What they’re really testing: Whether you understand Locust’s master-worker architecture and whether you think about blast radius before firing load at critical infrastructure.
Strong answer covers: Deploy one Locust master and multiple worker nodes via Docker Compose or Kubernetes — workers connect to the master and the master distributes user allocation; always target a dedicated load-test environment, never production — government systems like Revenue NZ myIR process real taxpayer data and an unexpected spike can trigger incident responses; set an explicit --run-time and --stop-timeout so tests terminate cleanly; define SLO thresholds (e.g. p95 < 2s, error rate < 1%) as automated pass/fail gates in CI rather than eyeballing the Locust web UI after the fact.