A CDN is billed in bytes, so the hit rate that decides the invoice is a byte hit rate: the share of bytes served from the edge, not the share of requests. The two come apart whenever object size varies with popularity, and it usually does in the unhelpful direction — the popular objects are the small ones, so the cheap hits are the cheap ones.
Core ideas
The same harmonic ratio as the skew lessons, weighted differently. The weighting is the entire content, and it changes the answer by a factor of three here.
The request hit rate sums p_i over the cached ranks. The byte hit rate sums p_i × size_i over the same ranks, divided by the same sum over all ranks. With size_i ∝ i^b the weights are i^(b−s), so it is the identical harmonic ratio at exponent s − b — one formula, not a second model.
At b = 0 every object is the same size and the two rates are the same number under two names: that is the control. Move b off zero and they separate, and at b = s the byte hit rate collapses to exactly C/N, the uniform rate, because size grows exactly as fast as popularity falls.
Real edge workloads have b > 0: thumbnails and API responses are popular and small, video segments and installers are unpopular and large. So the byte hit rate is the lower of the two, and an origin-load estimate made from the request hit rate is optimistic. At N = 20, s = 1, C = 4 and b = 1 it is 57.91% against 20.00%.
The material
One weighted sum, three cases that fall out of it, and the invoice that follows the second number.
For a cache holding the top C of N ranked objects, the request hit rate is the share of requests served from it and the byte hit rate is the share of bytes served from it. With Zipf popularity p_i ∝ 1/iˢ and sizes size_i ∝ i^b, the second is Σ i^(b−s) over the cached ranks divided by the same sum over all ranks.
b is a size exponent, positive when popular objects are small. Setting b = 0 recovers the request hit rate exactly, which is how you can tell the two formulas are one formula.
Everything that follows is that one ratio evaluated at three exponents, and each case arrives as arithmetic rather than as an assertion.
N = 20, s = 1, C = 4, b = 1. The top four objects are 57.91% of the requests and exactly 20.00% of the bytes — which is C/N = 4/20, because b = s here. A gap of 37.91 points between two numbers people use interchangeably.
Push the size profile harder and the gap widens. At b = 2 on the same catalogue the byte hit rate falls to 4.76% while the request hit rate is unchanged at 57.91%: the edge is still serving more than half of the requests and is now serving one twentieth of the bytes, because the objects it is not holding are enormous.
Origin egress is (1 − byte hit rate) × total bytes, and the bill is that times the price per gigabyte times the days. At 50 000 GB/day of edge egress with a 20.00% byte hit rate, 40 000 GB/day still leaves the origin, and at two cents a gigabyte over thirty days that is $24 000.
Nearly twice the bill, from using the number that was on the dashboard. And the error is one-sided: because b > 0 is the normal shape of an edge workload, substituting the request hit rate always under-estimates origin egress. A capacity plan made this way is optimistic exactly where being wrong is expensive.
The same gap applies to the origin’s capacity, not only its bill. The origin must actually serve 40 000 GB a day; the request hit rate predicted 21 047 GB, and a link, an origin fleet and an autoscaling policy sized against the second number meet the first one on the day the video catalogue gets popular.
Two moves change the byte rate rather than the request rate. Caching by bytes served rather than by request count — admitting large popular objects even though they cost more slots — moves the byte hit rate directly. And splitting large objects into range-cacheable pieces turns one big miss into many small hits, which is why video is served in segments.
One caution on the model. size_i ∝ i^b is a smooth profile, and real catalogues are lumpy: a handful of very large objects can dominate the byte totals without being anywhere near a clean curve. Use this to understand the direction and the rough size of the gap, and measure the byte hit rate itself before writing a number into a budget.
Interactive
The byte hit rate is a different number, and it is the one on the invoice
Method
Get the byte hit rate first. Every number after it is a multiplication, and every one of them is wrong if you used the other rate.
A CDN dashboard reports both and they are labelled similarly. If only one is available, assume it is the request hit rate, because that is the one that is easier to compute and the one more often displayed by default.
Measure it if you can: bytes served from the edge over total bytes served. If you have to estimate, use the size profile — the same harmonic ratio at exponent s − b — and carry an interval rather than a figure.
(1 − byte hit rate) × total bytes per day. Keep decimal gigabytes, 1 GB = 10⁹ B, because that is what egress is billed in and mixing it with binary gibibytes moves the answer by seven per cent.
Multiply by the price per gigabyte and the days. Then compute what the request hit rate would have predicted and report both, because the difference between them is the single most useful sentence in the estimate.
Two hit rates off the same ranks, and then the invoice each of them would have produced.
The b = s coincidence is worth noticing rather than relying on: at this catalogue the byte hit rate is exactly the uniform rate C/N, which makes the arithmetic clean and is not a general fact. Move b to 2 and it falls to 4.76%, taking the bill to $28 571.43.
For a faded rehearsal, keep N = 20 and s = 1 but set b = 0. The supplied first move is that the two hit rates must now be equal; confirm that, compute the origin egress and the bill, and say which of the three cases — b = 0, b = s, b > 0 — describes a video CDN and which describes a cache of thumbnails.
The lab draws the share of requests by rank and the share of bytes by rank as two profiles with the cached prefix shaded in both. The gap between the two shaded areas is the whole lesson, and setting b = 0 closes it.
You should be able to distinguish a request hit rate from a byte hit rate, compute the second from a size profile, turn it into origin gigabytes per day and a monthly bill, and state the gap between the two forecasts as the reason the distinction is worth making.
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.