English for Locust Load Testing

Locust is a load-testing tool where test scenarios are written as ordinary Python code rather than a proprietary DSL, which makes it flexible but means teams need shared vocabulary — “user class,” “task,” “spawn rate,” “RPS” — to discuss test design without ambiguity. A vague “the load test failed” hides whether the system broke, the test script broke, or the results were simply misread. This guide covers the English used when discussing Locust with a team.

Key Vocabulary

User class — a Python class defining a simulated user’s behavior (which endpoints it hits, in what pattern, with what wait time between actions), the basic building block of a Locust test. “Add a separate user class for the checkout flow — mixing it into the browsing user class makes it hard to control the ratio between the two behaviors.”

Task (and task weight) — a method within a user class representing one action a simulated user can take, optionally weighted so some actions happen more often than others, mirroring real traffic patterns. “Give the product-page task a higher weight than checkout — in real traffic, way more users browse than actually complete a purchase.”

Spawn rate (ramp-up) — how quickly Locust adds new simulated users during a test, distinct from the total number of users; a low spawn rate ramps up gradually, while a high one hits the target load almost immediately. “Slow the spawn rate down — jumping to five thousand users in ten seconds tests a traffic spike scenario, not the steady-state load we actually wanted to measure today.”

RPS (requests per second) — the throughput metric showing how many requests the system under test is actually handling, which can plateau or drop even as simulated user count keeps climbing, revealing a bottleneck. “RPS flattened out at two thousand users even though we kept adding more — that’s the system hitting its ceiling, not Locust failing to generate enough load.”

Distributed mode (master/worker) — running Locust across multiple worker processes or machines coordinated by a master, needed when a single machine can’t generate enough load itself to stress the target system. “One machine couldn’t push past three thousand simulated users without Locust itself becoming the bottleneck — we switched to distributed mode with four workers to get past that ceiling.”

Common Phrases

• “Is this a separate user class, or should it be a weighted task within an existing one?”
• “What spawn rate are we using — are we testing steady load or a sudden traffic spike?”
• “Did RPS plateau before we hit the target user count? That’s worth investigating on its own.”
• “Do we need distributed mode, or is a single machine enough to generate the load we need?”
• “Is this failure the system under test breaking, or Locust itself running out of resources?”

Example Sentences

Reviewing a pull request: “This test script has checkout and browsing in the same user class with equal task weights — split them out, since real traffic has far more browsing than purchasing.”

Explaining a design decision: “We deliberately set a slow spawn rate for this test, since we’re modeling gradual daily traffic growth, not a flash-sale spike — that’s a separate test scenario.”

Describing an incident: “The load test looked like it failed, but RPS had actually plateaued well before the target user count — the bottleneck was the database connection pool, not Locust running out of capacity.”

Professional Tips

• Say “user class” and “task” precisely when discussing test design — they’re the two building blocks, and vague descriptions like “the test script” make it hard to reason about test coverage.
• Distinguish spawn rate from total user count explicitly — a test can fail to represent real conditions if the ramp-up doesn’t match the traffic pattern being modeled.
• Watch and report RPS plateauing, not just user count reached — a system can be at its real ceiling well before the simulated user target is hit.
• Mention distributed mode when load-generation capacity, not the target system, is the actual bottleneck — it’s a different problem than the system under test being slow.

Practice Exercise

1. Explain in two sentences why task weighting matters for realistic load test results.
2. Write a one-sentence code review comment recommending a slower spawn rate for a steady-load test.
3. Describe, in your own words, what it means for RPS to plateau before the target user count is reached.