When extra capacity arrives minutes after a surge, how do you keep a performance run from hiding that delay?

## The gap the run has to expose Systems that add serving capacity in response to demand do it on a delay: something has to notice, something has to be started, and the new capacity has to become useful — warmed, connected, registered and actually receiving work. That delay is frequently measured in minutes, while the jump in demand it is responding to is measured in seconds. The whole point of a surge run against such a system is the interval in between, when demand is at its peak and capacity is still whatever it was before. Call it the **exposure window**: from the moment demand rises to the moment added capacity is genuinely serving. Everything that decides whether the surge was survivable happens inside it, and a run design either measures it or erases it. ## Three habits that erase the window 1. **Pre-provisioning for the run.** Raising the system to peak size before starting, "so the test is fair", turns a surge run into a steady-state measurement at a large size. It shows the system can serve that demand. It shows nothing whatever about absorbing its arrival. 2. **Rehearsing at high demand first.** A warm-up pass at the peak rate leaves the extra capacity already added when the measured pass begins, so the measured surge lands on a system that has already reacted to an earlier one. 3. **Starting the clock late.** Beginning measurement once figures have stopped moving skips over precisely the window the run exists to observe, and reports the recovered state as the whole result. ## Designing so the delay is measured - Start from the size the system would genuinely be at under the baseline arrival rate, reached by *running* at the baseline rate rather than by configuring the size directly. - Timestamp two independent series: offered demand, and serving capacity that is actually accepting work. The interval between the rise in the first and the rise in the second is the exposure window, and it is a reported number in its own right. - Compute the response time distribution, refusal count, pending-work depth and completion count **for the exposure window alone**. Averaged across a twenty-minute run, a two-minute exposure disappears into comfort. - Record which of four things happened to the demand that could not be served inside the window: served slowly, queued, refused explicitly, or accepted and dropped. These are very different outcomes and only the last is a defect on its face. - Repeat with the transition time varied. If demand arrives faster than capacity can be added, the exposure window is bounded by the capacity mechanism; if slower, it is bounded by demand. Which regime the product lives in is the useful output. ## What a pre-warmed pass has actually demonstrated | Run design | What it proves | What it cannot say | |---|---|---| | Started at baseline size, capacity added during the run | behaviour through the exposure window | nothing about sizes never reached | | Raised to peak size before demand rose | the larger configuration serves that demand | anything about absorbing the arrival | | Capacity held fixed throughout | behaviour of the system as it stands today | how the reactive mechanism behaves | A pre-warmed pass is a legitimate run and answers a real question — can the larger configuration serve this demand? — but it has to be reported as that question's answer and not as a surge result. The confusion is common enough that the size the system started at belongs in the result itself, not in the setup notes: **what the system started as is part of what was measured.** ## Reading the outcome honestly If the system survived only because capacity was raised before demand rose, the honest finding is that its surge behaviour is still unknown and its steady behaviour at that size is good. If it survived with capacity arriving during the run, the findings are the exposure window's duration, what happened to demand inside it, and whether recovery completed once capacity arrived — including whether that capacity was later released, and how the system behaved while it was being released. There is a second-order effect worth recording. Capacity that arrives late arrives *after* a backlog has already formed, so for a period the system is serving current demand and accumulated backlog together. Peak resource use can therefore occur several minutes after peak demand, and peak response time later still. A run that stops measuring when demand stops misses that entirely, which is a second reason the post-surge observation window has to outlast the capacity mechanism rather than merely outlasting the demand. ## What this run does not answer How much capacity should be added, what the reaction should be triggered by, and how large the system should be sized are separate decisions with their own analysis and their own inputs. This run's contribution is narrower and far more concrete: the measured length of the exposure window, and the measured consequence of demand that landed inside it.