07 · Testing · Morning peak
When thirty stores order at once, see the slowest slice and the bloat after the run
The performance tester uses the morning peak to see where it slows, how slow the slowest slice is, and whether the run leaves bloat. Whether the books post twice is for backend to prove with evidence.
The performance tester uses a business peak, not an idle number
The scene he wants comes from the floor: Monday morning peak, thirty stores submitting orders inside ten minutes. What marks this role is watching response time, error rate, and the slowest slice of requests at the same time. Looking only at average time hides the people who tap twice in the peak. Data volume should be close to three months after go-live, not an empty database of ten documents. On an empty database every index looks fast. He confirms with the database engineer which statement is slow, and whether it is lock wait or a missing index. The test report writes the bottleneck, the concurrency, p99, and whether the same query recovers after the run.
How to press so it still looks like people
The script mixes in real proportions: most of it is querying orders waiting to submit, a smaller part is submit, and occasionally a duplicate submit. Making everything a submit produces a number the floor never sees, and fills the queue so you misread the system as unable to cope. Think time and tap interval are written into the scene. He also counts one client retry after timeout in the model, because a phone really does retry. Retry density is written from the real client. Too dense, and the conclusion is pessimistic. No retry at all, and the conclusion is optimistic.
Thirty stores submit at once
In the ten minutes before order cutoff, the historical peak is about thirty stores. Performance testing on staging runs at twice that peak. Average time is acceptable. p99 reaches three seconds. The report lists the slowest slice of requests on its own, and writes that it is lock wait. If the same store shows two drafts during the load test, he logs one line of “correctness suspicion” and hands it to backend to prove with a request ID. He does not write “no duplicate drafts” as a pass condition of performance testing itself. This role's pass conditions are: peak shape, the slowest slice, and whether idle recovers after the run. He does not sign a report that only writes transactions per second.
Before the run he fills document volume to the three-month-after-go-live level, then clears the orders this run created. Without that cleanup, the next run sits on dirtier data. After the peak he returns the system to idle and looks at the same query once more. If it is still slow after recovery, the run left a bloated table or an index problem. That is not floor concurrency. Treating bloat as concurrency wrongly asks for more machines. Treating concurrency as bloat lets the same statement kill the next peak. The two conclusions must not be mixed in the report.
After one run, average time still looks fine, but the idle query is four times slower than before the run. Statistics on the order table were not refreshed, and the optimizer chose a full table scan. He writes that line in the report as bloat, and requires the release window to carry a collect-statistics step. If it had been written as “need more machines,” next week would buy capacity that is never used, and the peak would still be dragged down by the same statement. Script think time is written from the store manager's real tap interval, not the load-tool default. The default is too dense. It fills a queue that never happens, then misreads the system as unable to cope. Load-test accounts must not hold production privilege. Staging store master data is copied from peak stores. Ten documents from a demo store do not stand for thirty stores. The report appendix gives the statements of the slowest slice and the lock-wait chart. A p99 without the chart he treats as not tested. The load-test window must not overlap the release window. When they overlap, a slowdown cannot tell a candidate from data volume. He asks the release manager to put both windows on the same calendar, at least one day apart.