Find the limit before your users do
A system that responds well with ten people can stop with four hundred on the first business day of the month. The question is not whether it holds, it is where it breaks first and how long before that you find out.
Why the bottleneck only appears in production
Staging is usually tested with a volume that looks nothing like the real peak of the operation.
The test used the wrong volume
Validating with the load of an ordinary day says nothing about month-end close, a campaign or the fiscal year turnover, which are exactly the moments when a stoppage costs the most.
The bottleneck is blamed on the wrong place
Without measurement by layer, slowness becomes a debate between the application, database and infrastructure teams, and nobody can prove where it is.
There is no evidence to decide the go-live
The decision to go live or postpone ends up being made on perception, with no number to back the choice afterwards.
How it works
The test reproduces the peak the operation really faces.
Defining the peak scenario
Survey of the moment of highest real load, with the business area: which transaction, which volume, which concurrency, which window.
User simulation
Execution with simulated users reproducing the scenario’s behavior, not just synthetic requests with no session context.
Measurement by layer
Collection of response time and consumption by layer, to separate application, database and infrastructure limits.
Report with the breaking point
Delivery of the volume at which response time degrades, the point at which the operation stops, and a recommendation for every bottleneck found.
What is measured
The output is evidence for a decision, not a pretty chart.
| Indicator | What it answers | Decision it supports |
|---|---|---|
| Response time per transaction | How long the user waits under load | Performance acceptance at go-live |
| Degradation point | At what volume the response gets worse | Capacity sizing |
| Breaking point | At what volume the system stops | Declared operating limit |
| Consumption by layer | Where the resource saturates first | Where to invest in infrastructure |
| Recovery behavior | Whether the system comes back on its own | Contingency plan |
Numbers
Real operating data.
- +12KUsers simulated in stress testsMeasured in the operation of a large customer.
Frequently asked questions
Does the test run in production?
No. It runs in a comparably sized staging environment, precisely to find the limit without causing the stoppage you want to avoid.
Does it work for SAP and for web applications?
Yes. The scenario changes, the logic does not: reproduce the real peak, measure by layer and deliver the point where it degrades.
Do I need this if the system has never gone down?
A system that has never gone down has not yet found its peak. The test exists so you learn that number before the operation does.
See also
What is the heaviest day of your operation?
We reproduce that day in staging and deliver where the system starts to give way.