Performance and Load Testing
Find the ceiling in a test, on a day you chose.
Fast enough is a number, not a feeling
Every system has a point where response times stop being flat and start climbing. Most teams never find out where theirs is, because nothing has pushed it that far yet. Then something does.
Load testing finds that point on purpose. We put the system under the volumes you expect, then well past them, and watch what changes: what it holds, where it bends, and which part gives way when it does. What comes out is a number you can plan against instead of a hope.
This runs alongside automated testing, which checks that the system is correct. Load testing checks that it is still correct when a lot of people are using it at once.
Four ways we get brought in
The first is the most common, and the cheapest place to find a problem.
Before go-live
Proving a new system at realistic volumes and worst-case ones, while there is time to change the answer.
Sizing the infrastructure
How much is enough, settled by measurement. Overspending and undersizing show up in the same test.
A live system that has slowed
We measure first and change nothing until the constraint is found: the obvious suspect is usually innocent.
Someone is asking for numbers
A customer or partner about to connect wants proof it will take their volume. A test report does that.
What a load test actually establishes
The scope comes first: your architecture, user profiles, peak scenarios and the benchmarks that matter, agreed before any test runs. Then four kinds of pressure - load at expected demand, stress beyond it, spike for sudden surges, and soak for the slow failures that only emerge over hours.
The rate it holds
How many requests a second the system sustains with response times still inside the target you set. Not the average, which hides the problem, but the slow end where your unhappiest users live.
Where it bends
The load at which the line stops being flat, and what causes it there: the database, the network, the container, the code, or the way the platform scales.
Which failures matter
A response that is not a success is not automatically a fault in your software. Separating the application's failures from the platform's, and from the test harness's own, changes what you go and fix.
What lands on your desk
- The numbers, run by run
- So the next test has something to compare against.
- A ceiling to plan against
- The rate the system holds and the point it stops holding.
- A fix list in order of what it buys you
- Since the first change is usually worth more than the next five. Where sizing is the question,.
- a recommendation with the evidence behind it
- And where performance belongs in the pipeline,.
- an automated suite running in your CI/CD process
- So the standard is checked on every change.
Load-tested by the supplier that had to connect to it
Our most recent integration was load-tested by the detection provider connecting to it, rather than by us.
| Item | Result | Notes |
|---|---|---|
| Requests driven | 3,480 | ten runs across about 90 minutes, by the provider whose platform had to connect to it |
| Rate sustained | 5 a second | roughly 18,000 an hour against an expected busy-hour peak of about 1,000 - which we publish as 17x, not 18x, to stay on the conservative side of two approximate figures |
| Slowest 5% of responses | 1.5s | at the production rate over a four-minute run, inside our three-second target |
| Application errors | Zero | sixteen responses came back as something other than success; not one was a fault in the application |
Common questions
How much load should we test to?
Past the volume you expect, and then further, until the response times bend. The number you actually want is not "it handled the forecast" but "it holds up to here, and this is what gives way first".
Our system is already live and slow. Is that the same job?
It is a different one. Proving a new system is a measurement exercise; fixing a slow one starts with finding which part is actually the constraint, which is rarely the part people assume. We measure before changing anything, because the obvious culprit is often innocent.
Doesn't the cloud scale automatically?
It does, but not always quickly enough. On a recent build the default scaling rule reacted only after the first requests had already timed out, so the platform was technically scaling and the customer was still seeing failures. Testing is how you find that out before it matters.
What do we actually receive?
The numbers run by run, the rate the system holds inside your response-time target, the point where it stops holding, and what gave way there. Where sizing is the question, a recommendation with the evidence attached.
Can you test something you didn't build?
Yes, and it is a common first engagement. A load test is one of the few ways to get an honest answer about a system nobody wants to take responsibility for.