Application load and stress testing

The question that brings you here is usually “how much can it take?”. A number of requests per second on its own does not tell you what to do on Monday. You need to know which resource saturates first, with what symptom, and how much headroom you have before you get there.

How I work. I rebuild the real user path from data you already have. I ramp up in steps until errors or latency cross a threshold agreed in advance, and stop there. Load runs at a fixed rate rather than a fixed number of users, because otherwise the generator slows down together with the server and the number looks better than the truth. The target needs observability, or you will know it broke without knowing what broke.

The target is the origin, not the CDN. If traffic goes through Cloudflare or similar, a test that does not bypass it measures the provider’s cache and returns a number that means nothing for your server.

For one test on an isolated VPS, I wrote the criteria first: p95 below 3 seconds, fewer than 1% invalid responses and no dropped iterations. I bypassed the CDN and used a constant arrival rate. Only then did I read the result: 3 HTML requests per second for 10 minutes with p95 1.102 seconds. The short stage at 5 requests per second passed at about 96% CPU; at 6, latency crossed the limit. The production server was not stress tested: the result describes that environment and workload, not a capacity figure transferable to another server.

What I need from you: written authorisation with a window and a duration, an environment that genuinely resembles production, and the availability of whoever runs the infrastructure. On shared hosting synthetic load is often forbidden by the contract. It happened on an e-commerce store I later migrated: the contract required an authorisation the engagement did not include, so I did not run the test. It is written in the limits of that case study, not hidden.

When this is the wrong service: if the system is slow with a single user, a load test confirms it is slow under load and you will have paid for a confirmation. We start with a single-user measurement, which costs less and answers sooner.