A daily total divided by 86 400 is a real number about a system and it is not the number to build for. Traffic has a shape, and the ratio between the busiest hour and the average one is a property of that shape: flat for an internal service, a factor of two or three for a consumer app with an evening, far more for anything driven by a broadcast. You pay for the mean and you build for the peak, and nothing but the profile says how far apart they are.
Core ideas
One hard idea: the provisioning multiplier is measured, not assumed. The other two concepts are what it is measured from and what happens when it is assumed instead.
The bill over a day is set by the total, which is the mean rate times 86 400. Whether the system stays up is set by the busiest hour. Those are different numbers about the same day — here 5 277.78 and 12 777.78 requests a second — and confusing them produces a system that is correctly sized for a day that never happens.
Peak over mean is 24 times the busiest bucket over the day’s total: two integers, and no rule of thumb anywhere in it. A consumer app with one evening peak gives 46/19, about 2.421×. Flatten the same day completely and the ratio is exactly 1. A broadcast where a single hour carries the day gives 26/3, about 8.667×. The number is a fact about the traffic and it has to be looked up.
At 5 277.78 a second of capacity against a peak of 12 777.78, the shortfall is 7 500 requests a second — not occasionally, but for an hour every day, at the hour that matters most. The failure is predictable and dated, which is what distinguishes it from the kind of overload that arrives as a surprise.
The material
What a profile is, how the peak and the mean come out of it, and what the ratio between them is a fact about.
A daily profile is the request count in each of the twenty-four hours of a day. Its mean rate is the daily total over 86 400 seconds; its peak rate is the busiest bucket over 3 600 seconds. The provisioning multiplier is the ratio of the two.
Both rates are computed from the same twenty-four numbers and neither is more real than the other. The mean is what the day cost; the peak is what the day required. A capacity estimate that reports one without the other has answered half a question, and usually the half that does not determine whether the system works.
The middle line is worth dwelling on. Peak over mean is 24 · peak bucket / daily total — both ends integers, so the multiplier is an exact fraction and is completely independent of how big the day is. Double every bucket and the ratio does not move; change the shape of the day and it does. The multiplier is a statement about shape and nothing else.
Twenty-four buckets rising to 46 000 000 requests at 21:00 and falling to 10 000 000 in the quiet hours; 456 000 000 requests over the day. The mean is 5 277.78 a second, the peak is 12 777.78, and the multiplier is 46/19. Anyone who sized this system from the daily total alone has built for 5 277.78 and will be 7 500 requests a second short every evening.
It is this profile’s answer. Flatten the shape in the lab — an internal service with no daily rhythm — and the multiplier falls to exactly 1, because the peak bucket is the mean bucket. Switch to the broadcast example, where one hour carries the day, and it rises to 26/3, about 8.667×. Three systems, one arithmetic, multipliers an order of magnitude apart.
So the estimate to distrust is the one that says “call it 2× for peak”. The multiplier is one of the few figures on this course that can be measured directly and cheaply from data the system already produces, and a measured one collapses a factor that would otherwise be carried as a ranged guess all the way to the machine count.
The peak this profile reports is the busiest hour, which is itself an average over 3 600 seconds. A five-minute burst inside that hour is flattened by the bucket and does not appear. So the multiplier computed here is a lower bound on the one a finer profile would give: bucket the same day by minute and the peak can only rise or stay the same, never fall.
That is the assumption to say out loud whenever this number is quoted. “Peak over mean is 2.421, measured hourly” is a complete statement; without the last two words it is a claim about a resolution nobody chose deliberately. Where the burstiness inside a bucket is the thing that matters, the tools are in “Queues and Utilisation” — this lesson is about the shape of the day, not the shape of a minute.
One more thing the profile does not carry: the read/write mix moves with it. A daily ratio of 100:1 can be a different ratio in the busiest hour, and the rates that get sized are the peak-hour ones. If the profile is being measured anyway, it costs nothing to bucket the two request kinds separately and find out.
Interactive
The provisioning multiplier comes from the profile
Method
Bucket the day, take both rates, divide, and say what resolution you used.
Twenty-four counts from a log or a metric is usually an afternoon of work and removes a factor from the estimate that would otherwise be guessed. It is also the one input on this course that a running system will simply hand you.
Daily total over 86 400. Write “mean” next to it, not “the rate”. Most of the damage this lesson is about comes from a figure that was correctly computed and then carried forward under a name that does not say which rate it is.
Busiest bucket over 3 600. This is the figure that goes into “From a Request’s Cost to a Machine Count”, and it is the only one of the two that decides whether the system stands up.
24 · peak bucket / daily total. The multiplier is independent of the size of the day, so it stays valid as the system grows and can be applied to a forecast total years later, which the two rates cannot.
An hourly peak is an hourly average, and a finer bucket can only raise it. Quoting the multiplier with its resolution is what keeps it from being read as a hard ceiling on demand.
One day, twenty-four buckets, and the three figures that come out of them.
The multiplier line is the one that generalises. 46/19 is an exact fraction of two integers and it does not depend on the size of the day at all: scale every bucket by ten and it is still 46/19. That is what makes it the figure worth recording and reusing, while the two rates go stale as soon as the system grows.
The shortfall line is the one that makes the case. 7 500 requests a second is not an outage risk in the abstract; it is a scheduled one, at a known hour, with the same size every day.
For a faded rehearsal, use the lab’s broadcast example. The supplied first move is that only one bucket is lifted, so the daily total is 23 quiet hours plus one large one. Predict whether the multiplier will be nearer 3 or nearer 9 before you look, then read off the peak, the mean and the ratio — and say what sizing that system to its mean would cost.
You should be able to take twenty-four bucket counts to a mean, a peak and an exact multiplier, say why the multiplier is independent of the size of the day, state the shortfall that sizing to the mean would produce, and name the resolution your peak was measured at.
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.