How do you decide how many hours a sustained load run must hold?
answer
- Duration answers a question, not a calendar
- Which build-up should this make visible?
- The slope must clear its noise band
- Reach a readable fraction of headroom
- Two occurrences of the longest cycle
basics
~10 sDerive it from the build-up you expect to surface: the hold must be long enough for that accumulation to clear measurement noise and cover a readable fraction of the headroom. Calendar convenience decides nothing.
solid answer
~40 sWork backwards from the mechanism. Name what is expected to accumulate — retained memory, leaked handles, on-disk growth, a slowly filling structure — then pilot its rate at the target load and measure the spread of that rate across repeats. The hold must be long enough that the expected change is several times that spread, and long enough to reach a readable fraction of the headroom so the slope extrapolates into hours-before-it-hurts. Add two occurrences of any periodic cycle that must land inside the window. Take the largest of those constraints and state it with its reason. If the honest answer is weeks, amplify rather than wait — raise the share of the accumulating operation, or lower the ceiling it fills — and record every amplification with the result.
code
pseudocode · 14 lines# Inputs measured in a short pilot, not guessed
growth_per_hour = 40 # resource units accumulated per hour at the target rate and mix
noise_per_hour = 12 # spread of that same slope across repeated pilots
headroom = 900 # units left before the resource hurts
periodic_cycle_h = 6 # longest scheduled cycle the hold must contain
hold_for_signal = 3 * noise_per_hour / growth_per_hour # slope clears the noise band
hold_for_trend = 0.5 * headroom / growth_per_hour # covers half the headroom
hold_for_periodic = 2 * periodic_cycle_h # two occurrences, not one
hold_hours = max(hold_for_signal, hold_for_trend, hold_for_periodic)
record(mechanism_expected, hold_hours, amplifications_applied)
record("not reachable in this window", mechanisms_slower_than(hold_hours))go deeper
Be ready to say what a run held at a steady rate for many hours is looking for: something that builds up slowly rather than a single bad response. Know that its length is chosen deliberately, not inherited from whenever the environment was free.
Explain how a hold length is derived — the expected accumulation rate from a pilot, the spread of that rate across repeats, and the headroom before the resource hurts. An interviewer at this level expects arithmetic, not a habit.
Show that you pilot the growth rate before committing an environment for a day, that you amplify honestly when the natural trajectory is weeks, and that you write down which mechanisms the chosen window could not have surfaced.
Own the policy: which changes earn a sustained hold at all, how often it runs, and what residual risk the organisation accepts when the affordable window is shorter than the mechanism needs. That trade-off is a budget and schedule decision, not a testing one.
## A hold length is an argument, not a habit A run that holds a steady arrival rate for many hours costs more than any other kind of performance run: it locks an environment, a dataset and usually a person for the whole time. Its length is therefore the one parameter that has to be argued rather than inherited. "Overnight" and "twenty-four hours" answer the question *when was the environment free*, not the question *what is this hold meant to make visible*. The useful reframing is that a long hold is a hypothesis with a stopwatch attached. Before it starts, someone should be able to write this sentence: *"If this build-up is present, it will show as this measurable change after about this many hours at this rate."* Everything about the duration follows from that sentence. If the sentence cannot be written, the run has no defensible length, because it has no question. ## Working the duration backwards 1. **Name the mechanism.** Memory retained per operation and never released; handles, connections or sessions leaked on a path that runs rarely; log volume, spooled records or temporary files growing on disk; a pooled or cached structure with a ceiling so high that a short run never finishes filling it; periodic work that only lands once a day. 2. **Measure its rate cheaply.** A short pilot at the target rate and mix gives an approximate accumulation per hour. A guessed rate produces a guessed duration. 3. **Measure the noise.** Repeat that pilot two or three times and look at the spread of the same slope. The hold is long enough only when the expected change is several times that spread; a slope buried inside the noise is not a finding. 4. **Find the headroom.** How much of the resource exists before the system misbehaves? A hold that reaches a readable fraction of that headroom lets the slope be extrapolated into hours-before-it-hurts. A hold that moves the figure by one percent supports no extrapolation at all. 5. **Add the cycles.** If periodic work has to be inside the window, the hold must contain at least two occurrences of the longest cycle that matters, because one occurrence can never be separated from a coincidence. The chosen hold is the largest of those constraints, and it is stated together with its reason: *"twenty-six hours, so the retained-memory slope clears its noise band by a factor of four and two rotation events land inside the window."* | Expected mechanism | Why a short hold misses it | What sets the hold length | |---|---|---| | Memory retained per operation | The slope sits inside sampling noise for the first hour | Time for the slope to clear its noise band and cover a readable fraction of headroom | | Handles or sessions leaked on a rare path | That path barely executes | Enough occurrences of the rare operation, which may mean changing the mix rather than the clock | | On-disk growth: logs, spooled records, temporary files | Growth is tiny against free space | Time to reach a measurable fraction of the volume | | A pooled or cached structure with a high ceiling | It is still filling when a short run ends | Time for the fill to complete, so the flat remainder can be read | | Periodic work: scheduled jobs, rotation, maintenance | It never lands inside the window | Two occurrences of the longest cycle | ## Shortening a hold honestly When the natural trajectory is weeks, waiting is not the only option, but every shortcut changes what the resulting number means, so every shortcut is recorded beside the result. - **Raise the share of the accumulating operation.** Shift the traffic mix towards the path that leaks rather than raising the overall rate, so the build-up advances while everything else stays comparable. - **Lower the ceiling.** Give the component less memory, a smaller cache limit or a smaller volume, so the same slope meets its wall sooner. The slope is still real; only the wall moved. - **Compress the cycle.** Where a schedule is configurable, shorten the period of the periodic work so two occurrences fit inside a shorter window. - **Do not extrapolate silently.** A four-hour slope projected across three weeks is a claim, not a measurement, and it fails precisely when growth is non-linear, which is the case the long hold existed to catch. ## What the run plan has to record - The mechanism the hold is meant to surface, in one sentence. - The rate and mix held, and the hold length together with the arithmetic that produced it. - Every amplification applied, so a reader can translate the result back into real operating hours. - **What this hold could not have surfaced**: the mechanisms whose trajectory is longer than the window. That last line is the one most often missing, and its absence causes the characteristic failure of this run shape. A team holds for exactly as long as the environment happened to be free, finds nothing, and the result is quoted for a year as evidence that the system is stable under sustained load. It is only evidence about build-ups fast enough to appear inside that window. Writing the boundary down turns an over-claimed pass into an honest one, and gives the next person a starting point: the hold that would close the gap, and the amplification that would make it affordable.
- Someone asks for a twenty-four-hour hold because it fits the overnight window. How do you answer?Ask what it is meant to surface. If the suspected build-up would be visible in six hours, the extra eighteen buy nothing and cost the environment; if it needs four days, twenty-four hours produces a confident false pass. Convert the calendar request into a mechanism, price the hold that mechanism needs, and offer amplification if that price is too high.
- How would you shorten a hold whose expected mechanism needs two weeks?Amplify rather than wait. Shift the traffic mix towards the operation that accumulates, reduce the ceiling it fills by giving the component less memory or a smaller cache limit, or shorten the configured period of any cycle that must land inside. Each advances the trajectory rather than the clock. Record every amplification beside the result, because the figures no longer map one-to-one onto real operating hours.
saying these in an interview costs you the question
- Picks a round number of hours with no mechanism named
- Holds overnight because that is when the environment is free
- Cannot say what growth would have to appear to fail
- Extrapolates a four-hour slope across three weeks as linear
- Reports a pass without saying what the window could not reach
- Believes any long hold rules out slow build-up