Using tools like JMeter or Locust for load testingfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Using tools like JMeter or Locust for load testing
Last updated :  
11.x , 10.x , 9.x , 8.x

Every optimization technique in this tutorial has been about a single request's performance. Load testing asks a different question entirely: what happens when a thousand requests arrive at once? A site that's fast for one visitor can still fall over under concurrent load if PHP-FPM workers exhaust, the database connection pool maxes out, or a cache stampede occurs — none of which a single manual page load would ever reveal.

What you'll learn in this lesson

  • Why single-request speed and concurrent-load capacity are different questions
  • Writing a basic load test scenario with Locust
  • Reading results correctly — averages hide the numbers that actually matter

A basic Locust scenario

# locustfile.py
from locust import HttpUser, task, between

class DrupalVisitor(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def view_homepage(self):
        self.client.get("/")

    @task(1)
    def search(self):
        self.client.get("/search?keys=example")
locust -f locustfile.py --host=https://staging.example.com --users 100 --spawn-rate 10

This simulates 100 concurrent virtual users, ramping up 10 at a time, weighted toward the homepage (3x more frequent than search) — a rough approximation of real traffic mix rather than hammering one single endpoint unrealistically.

Never load test production directly. A real load test generates real traffic load, indistinguishable from a traffic spike or, at high enough volume, a denial-of-service attack against your own site. Always test against a staging environment that mirrors production's actual configuration and data volume — testing against a thin local dev environment tells you little about how production infrastructure actually behaves under load.

Reading results: averages lie

A load test reporting "average response time: 200ms" can hide a distribution where 95% of requests are genuinely fast and 5% take 8 seconds — the average smooths right over that tail. Always look at percentiles specifically: p50 (median), p95, and p99 tell you what your slowest meaningful fraction of visitors actually experiences, which matters far more for user experience than the average.

Quick check: a load test shows an average response time of 300ms, but p99 shows 6 seconds. What does that gap tell you? If you said a small but real fraction of requests are hitting a serious bottleneck the average is hiding entirely — worth investigating specifically, not dismissing because the average looks fine — you've understood exactly why percentiles matter more than averages here.

Key takeaways

  • Load testing reveals concurrent-request problems that no single manual page load ever would.
  • Locust (or JMeter) simulates realistic concurrent traffic patterns, weighted toward actual usage mix, not uniform hammering.
  • Never load test production directly — always target a staging environment that mirrors production configuration and data volume.
  • Read percentiles (p95, p99), not just averages — the average hides exactly the tail that matters most for real user experience.

Coming up next

You've now got a way to generate realistic load. Next, we look at watching your site's real production behavior continuously, not just during a deliberate test.