Choosing Memcached Eviction and TTL for High-Throughput Web Caches

The decision you actually face

High-throughput web caches hit a wall when memory is fixed and traffic is bursty. The problem is not whether memcached caches, it is how it decides what to drop and when. With a fixed -m limit, memcached evicts using an approximate LRU and expires items by TTL. You must choose a combination that keeps hit ratio stable without spiking origin load.

The useful takeaway: size memory to your working set, use TTL for correctness, and let LRU handle the rest. Tuning one without the other creates either stale data or churn.

Constraints memcached gives you

LRU eviction under memory pressure

Memcached allocates a fixed slab memory pool. When full, new sets trigger eviction of the least recently used items in the slab class. Eviction is approximate and per slab, not global. Client libraries do not change this, but they do affect key distribution and item size.

TTL expiration

Each item can be stored with an expiration in seconds. Memcached checks expiration on access and during periodic sweeps. Granularity is second-level; sub-second expirations are not supported. TTL is the only built-in correctness control.

Protocol overhead

Binary protocol reduces per-request overhead versus ASCII for large payloads and pipelining. It does not change eviction, but it changes how many ops you can sustain on the same memory.

Options compared

Trade-offs

Read-through simplifies app code by loading missing keys from origin on a cache miss. It pairs well with moderate TTL because misses are bounded. Write-through ensures consistency on every update but adds latency to the write path and is rarely used with memcached for high-throughput reads.

Larger max memory reduces eviction frequency and improves hit ratio, at the cost of host RAM and slab fragmentation. Smaller memory increases eviction and origin pressure, which can cascade under load.

Short TTL improves freshness but raises set operations and origin queries. Long TTL reduces origin load but risks serving stale data after updates. Memcached has no invalidation broadcast, so TTL is the practical control.

Cautions: eviction behavior can differ between client libraries due to consistent hashing and connection pooling. TTL granularity is second-level, so do not design for millisecond freshness.

Concrete validation setup

Start with bounded memory

Run memcached on the cache host with an explicit memory cap. Run as a user with permission to bind the port.

memcached -m 64 -p 11211 -l 127.0.0.1

-m sets megabytes of slab memory. -l binds to localhost for testing. Increasing -m changes host memory usage; do not exceed available RAM.

Observe eviction and hit ratio

Connect to the stats port from the same host.

echo stats | nc localhost 11211

Look for counters related to evictions, get hits, and get misses. A rising evictions counter indicates memory pressure. Hit ratio is derived from hits versus misses. Stable hit ratio with low evictions suggests memory is sized for the working set.

Check slab stats to see which size classes are full. That guides item size limits with -I.

Validate read-through performance

Use a load tool such as memtier to generate read-heavy traffic with a realistic key distribution. Compare latency and miss rate with different TTL values. Expect higher miss rate as TTL shortens, and lower origin load as TTL lengthens.

Limitations and checks

Memcached does not support per-key priorities or weighted eviction. Expiration is lazy; items may live slightly past TTL until accessed. Do not assume sub-second expiration.

Practical check: after a traffic change, re-sample stats for evictions and hit ratio over several minutes. If evictions grow while hit ratio falls, increase -m or reduce TTL for cold objects. If origin load spikes after TTL reduction, lengthen TTL for stable objects.