Capacity is bought for the busiest hour and used at the average one. Buy peak/ρ_target and use the mean, and the share you paid for and did not use is 1 − mean·ρ_target/peak. The size of the day cancels out of that fraction entirely: only the shape of the profile and the target utilisation move it.
Core ideas
The formula is one line. What it is worth knowing is what is missing from it, and what happens to a service that acts on the waste figure directly.
Nobody runs the busy hour at a hundred per cent: waiting explodes as ρ approaches one, which is the subject of “The Knee: Response Time vs Utilisation”. So the purchase is peak/ρ_target — 12 000/0.7 = 17 143 rps here — and the headroom in that division is bought deliberately rather than wasted.
Every hour below the peak contributes its own gap, and averaged over the day the capacity actually consumed is the mean: 5 250 rps against 17 143 purchased. The 16/7 peak-to-mean ratio is the whole of what the profile contributes — the same shape at ten times the traffic gives exactly the same waste.
1 − mean·ρ/peak is built from a ratio and a fraction, so doubling every bucket changes nothing and switching from requests to watts changes nothing. Only two things move it: flattening the profile, and raising the utilisation you are prepared to run the peak at. That is the entire list.
The material
Where the two capacities come from, why the fraction is scale-free, and what happens if you act on it by cutting to the average.
For a load profile with maximum peak and average mean, bought at a target utilisation ρ_target for the busiest hour, the purchased capacity is peak/ρ_target, the used capacity is mean, and the waste is
1 − mean·ρ_target/peak,
the share of what was bought that was not used, averaged over the period the profile covers.
ρ here is the λ/μ of “λ, μ and ρ” and nothing else: demand over the capacity actually in service. This course does not define a second utilisation, and every page that prints a ρ means that one.
Note the middle line. used/paid is mean·ρ/peak, which is (mean/peak)·ρ — the reciprocal of the peak-to-mean ratio, multiplied by the target utilisation. Both factors are pure numbers, which is why nothing about the size of the service survives into the answer.
Multiply every hour of the profile by ten. The peak becomes 120 000 rps, the mean 52 500, the purchase 171 429 — and the waste is 1 − 52 500 × 0.7/120 000, which is 111/160 again. Growth does not improve this number. Flattening the profile does, and so does daring to run the peak hour hotter.
This is the misconception the lesson exists for, and it is easy to fall into because the number really is 69.4%. But that figure is an average over the day, and the day has a shape: cut the fleet to the 5 250 rps you use on average and nine of the twenty-four hours are over capacity, the worst of them by 6 750 rps.
At the peak hour the utilisation of that cut fleet would be 12 000/5 250 = 16/7, which is not a busy queue — it is ρ > 1, where there is no steady state at all and the backlog grows at λ − μ for as long as the hour lasts. “λ, μ and ρ” is where that threshold is established; the point here is that the waste figure gives no warning of it, because it is a mean and the failure is at the maximum.
The honest reading of 69.4% is that the profile is expensive, not that the fleet is oversized. Three moves change the number and none of them is a straight cut: raise ρ_target from 70% to 80% and the waste falls to 1 − 5 250 × 0.8/12 000 = 65%; move work out of the peak hour so the peak-to-mean ratio falls; or put work on the trough that does not care when it runs, which raises the mean without touching the peak.
Set the shape to flat and peak = mean, so the waste is 1 − ρ_target — 30% at a seventy per cent target, and that residue is the headroom, which is not waste at all. A perfectly flat profile is the best case and it is rare, which is why batch work, index rebuilds and backfills are scheduled into troughs: they are the cheapest capacity in the building because they are already paid for.
The profile this lesson uses is the consumer shape of “Peak to Average”, on “Capacity Estimation” — one evening peak, a quiet early morning. That course turned a population into a peak rate; this one prices the gap that peak leaves behind for the other twenty-three hours.
Interactive
The gap between what you buy and what you use
Method
Two capacities and one subtraction — and then the check that stops the number being acted on wrongly.
The peak is a maximum over the period, not the busiest bucket you happened to look at. Both come from the same profile, so state the period: a waste figure over a day and one over a week are different numbers about different shapes.
peak/ρ_target is what you buy. Choosing ρ_target is a latency decision rather than a cost one — the response-time multiplier is 1/(1 − ρ) — and it should be decided before this arithmetic rather than tuned to make the waste look better.
111/160 here. Keeping it exact makes it obvious that the answer contains only a ratio and a fraction, and therefore that nothing about the volume of traffic is in it.
Take the capacity you propose and count the hours of the profile above it, and the worst overshoot. Cutting to the mean here leaves nine hours over and a worst case of 6 750 rps, with ρ = 16/7 at the peak. That test is one pass over the buckets and it is what separates a saving from an outage.
A higher ρ_target, a flatter profile, or more work in the trough. “Reduce waste” without one of those named is not a proposal, because the only other way to move the number is to serve less traffic.
The profile is the consumer shape: quiet overnight, a long climb, one peak at 21:00. Everything below is exact.
The two blocks at the bottom are the lesson. The first shows that the 69.4% cannot be taken as slack: acting on it directly puts nine hours of the day above capacity and the busiest one far above it. The second shows the lever that does work — ten points of target utilisation moved the waste by more than four points, and it cost latency rather than reliability.
Notice that the volume never appeared. 16/7 and 7/10 are the only inputs to the waste, and both are pure numbers: the same fraction comes out for a service a hundred times the size with the same daily shape.
For a faded attempt, take the business profile — two humps either side of lunch, which is flatter. Predict before computing whether its waste is above or below 69.4% at the same ρ_target, then read the peak, the mean and the waste off the lab and say which of the two factors did the work.
You should be able to compute peak/ρ_target, the mean, and 1 − mean·ρ_target/peak as an exact fraction, show that the answer does not change when the whole profile is scaled, and count the hours a proposed cut would put over capacity before you propose it.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.