Scene 11

Hit ratio — the headline and the diagnostic ladder

Hit ratio is the one number that tells you whether the CDN is earning its money — request hit ratio for users, byte hit ratio for the bandwidth bill — and when it's low the diagnostic ladder is Vary cardinality → TTL config → purge frequency → bypass rules → cookie cache key.

Previously

Every lever we've built — TTL, Vary, purge, shield, bypass — moves one number, origin RPS, and the headline that summarizes them all is hit ratio; this is the dashboard you read, and the ladder you walk when it's low.

Scene 11

Hit ratio — the headline and the diagnostic ladder

Watch
Try it
Predict
Capture

What to watch for

How do you tell if your CDN is earning its money? The first number you check is what fraction of requests it serves from its own cache vs forwarding to origin — that fraction is the hit ratio, and it splits into two: request hit ratio (what users feel) and byte hit ratio (what the CFO pays for). Healthy dashboard shown: request hit ratio 92%, byte hit ratio 88%, origin RPS low; the Sankey is mostly green-HIT and the thin red MISS share is spread evenly across the five buckets — no single failure mode dominates.

Implementation

Highlighted lines are the ones running in the diagram right now.

Dashboard.computeHitRatio

the two headline numbers, computed from edge log lines

1def computeHitRatio(edge_logs):
2    hits = count(l for l in edge_logs if l.cache == 'HIT')
3    misses = count(l for l in edge_logs if l.cache == 'MISS')
4    request_hit_ratio = hits / (hits + misses)
5 
6    bytes_from_cache = sum(l.bytes for l in edge_logs
7                           if l.cache == 'HIT')
8    total_bytes = sum(l.bytes for l in edge_logs)
9    byte_hit_ratio = bytes_from_cache / total_bytes
10 
11    # diverges when one big-object class misses
12    return request_hit_ratio, byte_hit_ratio

Operator.diagnose

the 5-step ladder, ordered cheapest-investigation-first

1def diagnose(metrics):
2    if metrics.vary_cardinality_per_url > 5:
3        return 'vary'        # one curl, read Vary header
4    if metrics.ttl_avg < 60 or metrics.no_store_pct > 0.1:
5        return 'ttl'         # curl asset, read Cache-Control
6    if metrics.purge_rate_per_hour > 10:
7        return 'purge'       # check CI logs for zone-wide purges
8    if metrics.bypass_pct > 0.2:
9        return 'bypass'      # audit /api/* style rules
10    if metrics.cookie_in_key:
11        return 'cookie'      # strip cookies for asset paths
12    return 'investigate_origin'

Sources

Where this sits in Build a CDN

Scene 11 of 13, in the Operating act — Shield, bypass routes, and the hit-ratio dashboard.. Request hit ratio vs byte hit ratio, and the 5-step ladder when it crashes: Vary cardinality → TTL config → purge frequency → bypass rules → cookie key.

Up next. Now that you can read the dashboard and run the ladder, the capstone asks the inverse question: design the configuration that produces a healthy one for a stated workload.

All 13 scenes in Build a CDN · Every curriculum

Designs that use this

Built with Arqly

Every scene in Build a CDN builds on the one before it.All 13 Build a CDN scenes