Stress testing
Plan tables and traffic estimates can only get you so far. A stress test answers the question directly: how much traffic can this specific site take, with its specific plugins and its specific database, before it starts to slow down or return errors.
We offer stress testing as an extended support service, priced per website and occasion - see the price list for the current price. One occasion covers one website and one test run.
It's most useful before a campaign, a product launch, a TV or podcast mention, or any moment where the traffic you expect is well above what the site normally sees.
How the test runs
We test against your production site, since that's the only environment that reflects what real visitors will actually hit. To keep that safe, the test is scheduled with you in advance and normally runs off-peak, when the fewest real visitors are on the site.
Traffic is ramped up gradually rather than thrown at the site all at once. That lets us watch response times climb step by step and identify where the site starts to struggle, instead of just knocking it over.
We focus on uncached requests. Templ Cache absorbs repeat traffic to the same page very efficiently, so hammering a cached page mostly measures the cache, not your site. The real ceiling is what PHP and the database can sustain when a request has to be generated from scratch.
Each stress test is scheduled individually rather than delivered on a fixed turnaround, so book it well ahead of the date you're preparing for.
What we need from you
Send us the exact URLs the traffic will land on, including any query arguments the campaign will append - tracking parameters such as ?utm_source=newsletter, filter parameters, or anything else tacked onto the address.
This matters more than it sounds. A URL with query arguments can miss the cache entirely, which means every single visitor triggers a full page generation instead of being served a cached copy. Knowing the real URLs up front lets us configure caching to match them, so the traffic hits cache instead of PHP. Raising the cache hit rate often increases how much traffic a site can handle by more than a plan upgrade would.
What you get back
You receive a written report covering:
- The maximum number of concurrent visitors the site sustained
- How response times developed as traffic increased
- The point at which the site started returning errors
- The bottlenecks we found, such as slow plugins, expensive database queries, or paths that never reach the cache
- A plan recommendation based on the measurements, rather than an estimate
Running your own load tests
Don't run load or stress tests against your Templ site yourself, and don't hire a third party to do it. It isn't permitted, and in practice it doesn't work.
Our protections can't tell the difference between a load test and a denial-of-service attack, because at the network level they look identical. The traffic source will most likely be blocked partway through, which means the numbers you get back describe our protection kicking in rather than your site's actual capacity.
A load test also moves a lot of data. That data counts toward your account's bandwidth pool and is billed as overage at the rate in the price list if it pushes you past what's included - see reduce data transfer for how that's measured. Traffic generated during a stress test we run for you is excluded from your bandwidth usage.
Contact support if you would like us to stress test your website.