Locust Slow Requests: Diagnose and Debug Bottlenecks (2026)

Locust’s "Slow Requests" warning isn’t about your application being slow; it’s about Locust’s master process being too busy to tell the workers to stop sending requests.

This happens when your load test is generating so much traffic that the Locust master process, which orchestrates everything, can’t keep up with the commands to start and stop requests. The workers, oblivious to the master’s struggle, keep churning out requests until the master eventually catches up, issuing a "slow request" warning for requests that took longer than your specified slow_request_timeout.

Here are the common culprits, from most to least frequent:

1. Overwhelmed Master CPU

The Locust master process is a single-threaded Python process. It’s responsible for aggregating statistics from all workers, rendering the web UI, and sending control signals. If it’s drowning in data or busy with UI updates, it can’t efficiently process worker messages.

Diagnosis: On the machine running the Locust master, check CPU usage.

top -n 1 -H -p $(pgrep -f "locust.main")

Look for the locust.main process consuming 100% CPU on one core.

Fix: Reduce the load on the master.

• Disable the Web UI: If you don’t need to see real-time statistics, run Locust without the web UI.

  locust --no-web -f your_locustfile.py --master
  

  This frees up significant CPU cycles.
• Reduce stats_history_size: The web UI keeps a history of statistics. A large history can consume more memory and processing.

  locust --stats-history-size 100 -f your_locustfile.py --master
  

  (Default is 500).
• Increase num_users gradually: Don’t ramp up users too quickly.

Why it works: Disabling the UI removes a massive chunk of work. Reducing history limits the data the master needs to process and store.

2. Network Latency Between Master and Workers

If the network connection between your Locust master and workers has high latency or is saturated, messages can get delayed. The master might not receive worker statistics or task start/stop signals in a timely manner.

Diagnosis: Run ping from the master to each worker, and from each worker to the master.

ping <worker_ip_address>

Look for average round-trip times consistently above 10ms.

Fix: Ensure master and workers are on the same low-latency network segment.

• Colocate Master and Workers: If possible, run them on the same network or even the same machine (for smaller tests).
• Increase heartbeat_interval and heartbeat_timeout: These control how often master and workers check in. Increasing them can make the system more tolerant of temporary network blips, but it also makes failure detection slower.

  locust --master-bind-host 0.0.0.0 --master-bind-port 5557 \
         --heartbeat-interval 5000 --heartbeat-timeout 15000 \
         -f your_locustfile.py --master
  

  (Defaults are 1000ms and 3000ms respectively).

Why it works: A faster, more reliable network reduces message queuing and dropped packets. Adjusting heartbeat timings can help the system tolerate minor network issues without reporting false positives.

3. Too Many Workers

Each worker process adds overhead to the master. The master needs to manage connections, receive statistics, and send commands to every single worker. Beyond a certain point (which depends heavily on master CPU), adding more workers can saturate the master.

Diagnosis: Monitor master CPU usage as you increase the number of workers. If master CPU spikes dramatically with each new worker, you’ve hit a limit.

Fix:

• Reduce the number of workers: Distribute the load differently.
• Use a more powerful master machine: If you need many workers, ensure your master has sufficient CPU cores and RAM.
• Run multiple Locust masters (for very large tests): For extremely large-scale tests, you can run multiple master processes, each with its own set of workers. This is an advanced setup.

Why it works: By reducing the number of entities the master has to manage, you decrease its processing load.

4. Inefficient locustfile.py Logic on Workers

While the "slow requests" warning points to the master, sometimes the workers are so busy executing complex logic within your locustfile.py that they can’t respond to the master’s stop signals promptly. This is less common for simple HTTP requests but can happen with heavy on_start, on_stop, or complex task logic involving extensive local processing.

Diagnosis: Monitor CPU usage on the worker machines. If workers are consistently at high CPU, they might be struggling.

top -n 1 -H -p $(pgrep -f "locust.runners")

Look for locust.runners processes consuming significant CPU.

Fix: Optimize your locustfile.py.

• Simplify task logic: Move heavy processing out of tasks.
• Use gevent.monkey_patch() wisely: Ensure it’s applied early.
• Avoid blocking I/O: Use asynchronous libraries if necessary, but generally, Locust handles HTTP asynchronously well.

Why it works: A more efficient worker can process master signals faster, reducing the time it takes to acknowledge a stop command.

5. High locust_request_timeout Value

This is a bit of a red herring, but important to understand. The slow_request_timeout parameter (default 60 seconds) is the maximum time Locust will wait for a request to be acknowledged by the worker before marking it as slow. It’s not the timeout for the HTTP request itself. If your application is genuinely taking minutes to respond, Locust will eventually give up and warn you. However, the "slow requests" warning usually implies Locust couldn’t even tell it to stop in time.

Diagnosis: Check your locustfile.py for the HttpUser or User class, or the command-line arguments.

class WebsiteUser(HttpUser):
    # ...
    slow_request_timeout = 120 # Example: if you set this high

Or on the command line:

locust -f your_locustfile.py --slow-request-timeout 120

Fix: If your application legitimately takes a long time to respond, increase this value.

locust -f your_locustfile.py --slow-request-timeout 120

Why it works: This simply extends the grace period Locust gives for a request to be acknowledged. However, if you’re seeing many slow requests with a default timeout, increasing it is masking the underlying master or network issue.

The next error you’ll likely encounter after fixing these is a gradual decrease in reported requests per second, or the web UI becoming unresponsive due to the sheer volume of data being processed.