Working AtlasCaching

Hit-Rate Wind Tunnel

Compare three ways to keep often-requested data ready. Then add new requests and watch how quickly each recovers.

TryWith reduced motion, use Step model to reveal hit rates. Inject a scan burst, then compare recovery.

Watch forHigher concentration sends more requests to a few popular keys; lower concentration spreads them out.

Jump to the model

Independent systems exercise

Standalone teaching model; it represents no production implementation.

Interactive model

Warming up…

The cache lanes just (re)started — give them a moment to fill before the hit-rate lines mean anything.

Workload

Hot-key concentration1.1

Higher values concentrate requests on fewer popular keys; lower values spread them across more keys.

The starting workload is Zipf-like: a few keys get many requests, while most keys are rare.

Adds 80 distinct cold keys once, then removes them from the looping stream. Compare how each policy recovers; the result depends on the current workload.

Cache hit (slot flashes)
Cache miss (slot recolors)
LRU hit-rate line
LFU hit-rate line
ARC hit-rate line
ARC's p — T1/T2 boundary marker

Seed1

LRU hit rate

LFU hit rate

ARC hit rate

ARC p

0.0/ 12

Adaptive T1 target size

LRU · last 60

—

LFU · last 60

—

ARC · last 60

—

The cards show full-run rates; the chart and this readout track the last 60 requests.

Preparing the interactive experiment…

Skill practicedKeep often-requested data ready as demand changes

Transferable practiceA cache keeps reused data close at hand; this model compares how often each rule finds it ready.

Understand the result

Implementations of LRU, vanilla LFU and ARC process the same seeded synthetic request stream. Inject a one-time burst of distinct cold keys, then compare recovery. This LFU model does not age or decay old counts, and results depend on the generated workload.

Controls

Hot-key concentration: Zipf skew controls how concentrated requests are on a few popular keys. Higher values send more requests to fewer keys.
Inject scan burst: Adds one burst of distinct cold keys after the current request; the burst is removed after it plays once.
Reseed: Restarts the comparison with a new deterministic request stream so the same policies can be compared under different inputs.
Step model: When reduced motion is enabled, advances the simulation in four paced frames while automatic animation stays paused.

What to watch for

Before the scan, compare all three policies on the current seeded skewed workload.
Click Inject scan burst and inspect how this request sequence affects each policy; a scan need not produce the same result under every workload.
Compare ARC on this seeded run. Its ghost lists can help it adapt to some workload shifts, but this result is not universal.
Watch ARC p (the adaptive boundary between its recency and frequency lists) shift as the workload changes.

Why it happens

LRU evicts the least-recently used entries, so a scan larger than the cache can displace previously hot keys even when scanned keys are not reused. ARC tracks recently evicted keys in ghost lists and uses later hits there to adjust its balance between recency and frequency. This seeded sequence illustrates how scan resistance can help; the hit-rate result depends on the request stream and cache size.

What this exercise helps me practice

This standalone teaching model compares eviction policies on repeated lookup workloads and explores how hit rate changes after a synthetic workload shift. It is an independent cache-policy exercise and does not represent a shipped cache, a production eviction policy, or measured hit rate.

See the broader engineering brief