Load testing your site

Sooner or later, usually just before a launch, somebody asks the reasonable question: "can we hammer the site with ApacheBench (or JMeter, siege, wrk) to see what it really handles?"

The short answer is no — not from a single machine. A load test fired from one address doesn't measure your site at all. It measures the DoS protection, which will treat it exactly like the attack it resembles and block the testing address almost instantly. The numbers you get back describe the shield pushing back on one IP — they say nothing about how the site performs under real traffic.

The good news: real performance testing is absolutely possible — it just has to look like real traffic. This page covers why the single-address version can't work, what to use instead, and the two things to get right before a genuine load audit.

Why a single-address test can't work

Every site here sits behind the same layered protection that keeps the whole server safe, and a one-address flood trips it by design. Several independent levels are watching:

• The network edge firewall. Abusive request patterns from an address get that address blocked at the firewall — the same automatic shield described in I'm blocked, or my site is slow.
• Per-address connection limits in the web server. Nginx caps how many simultaneous connections a single address may hold, with the tightest cap on dynamic (PHP) requests — precisely the requests a load test tries to pile up.
• Request-pattern monitoring. Automatic monitors watch the request stream for flood patterns and escalate to time-limited firewall blocks.

A benchmarking tool opening hundreds of concurrent connections from one IP walks straight into all three. First its connections get capped (so your "concurrency" number is fiction), then the address gets blocked (so the run ends in a wall of errors or timeouts). If you ran one and now can't reach your own site — that's the block, it's time-limited, and the same page explains how it lifts on its own.

There's no per-site opt-out for this, and that's a feature: the shield is shared, and it can't tell your well-meant benchmark from the hostile flood that looks byte-for-byte the same.

What to use instead

Match the tool to the question you're actually asking:

• "Is my site configured well? How fast are my pages?" — use an external page-speed service (Pingdom-style tools, and their many modern equivalents). They fetch your pages the way one visitor's browser does, measure honestly, and never look like a flood. For most sites this answers the real question — and the caching guide explains what those numbers mean on a BOA-cached site.
• "Will the site survive launch-day traffic?" — use a professional load testing service that emulates real traffic: many simultaneous visitors, coming from many different IP addresses, with realistic browsing behaviour. Distributed traffic like that doesn't trip the per-address protections, so it measures the site rather than the shield. This is the only meaningful way to run a pre-launch performance audit here.

Before a real load test — two things to get right

Tell your host first. Open a short support request with the date of the test, the site being tested, and the address ranges the testing service publishes for its agents. Your host can keep an eye on the run and, where it makes sense, allow-list the agents' addresses — the same one-minute allow-list job described on I'm blocked, or my site is slow. A coordinated test produces clean numbers; a surprise one produces a support ticket.

Point the test at the production name, not a preview alias. A domain with a dev/devel label in it (for example www.dev.example.com) is a .dev. preview URL, and those deliberately behave differently: caching is effectively out of the picture so that developers always see fresh pages. Load-testing a name like that measures the site with its performance armour off — the results will not match what real visitors experience on the real domain. Test www.example.com, not www.dev.example.com.

Related

• I'm blocked, or my site is slow — what a protection block looks like from the outside, why it lifts on its own, and what to send your host if it doesn't.
• Restricting access to your site — the rest of the built-in protection family, and the pieces of it that are yours to adjust.
• The front cache & Drupal's page cache — what BOA's caching layers do to page-speed measurements, and why a warm page is the number that matters.
• Developing your site — the .dev. preview aliases in full, including everything else they switch off.
• Reference — BOA's configuration variables, control-file settings, and commands collected in one place.