Object cache misses that look like “Redis is broken”

When Redis shows as up but every page still runs a full SQL stack, you are usually seeing object cache misses, not a dead service. Someone restarts Redis, the site feels better for a short while, then the miss rate climbs again under normal traffic. That pattern almost always means a plugin is writing unique keys that never get reused, or Redis has no memory cap and no eviction policy. Set maxmemory with allkeys-lru so the cache can drop cold keys. Restarting Redis empties it on purpose; a rebuild under steady traffic is expected and fine.

redis-cli info stats | head

Watch keyspace_hits against keyspace_misses. A cold cache after a restart will show almost all misses at first, then hits should rise if keys are stable. If misses stay dominant for hours with steady traffic, keys are not being reused. Check info memory next and compare used_memory to maxmemory. Growing evicted_keys is healthy. A Redis instance that never caps memory and never evicts will pressure the box, swap, and take MariaDB down with it.

Unique keys are not a working cache

A plugin that folds a timestamp, a visitor id, or a full request URI into the object key will never hit on the next request. Honest WooCommerce session handling will miss for new guests and hit for the same shopper; that is normal. A page builder that keys on a random UUID per view is a leak, not a cache. On staging only, redis-cli --scan can show whether key names look stable or look like one-off snowflakes. If you cannot guess the next key from the last, the plugin is journaling instead of caching.

Object cache is not LSCache. Clearing a miss storm will not store full HTML for anonymous visitors. It only makes PHP cheaper when the page still has to run. Bind Redis to localhost, set a firm memory limit, choose allkeys-lru, and then find the plugin that wants a unique key on every hit.

What a healthy miss looks like

The first request after a deploy should miss. The first load of a rare admin screen should miss. A cart for a brand-new session should miss. Those misses mean the cache is doing its job. What you do not want is every logged-out homepage missing object keys that include a timestamp in the name. Dump a small sample of keys and read the patterns. Stable names reuse; random names never will.

With allkeys-lru, Redis can drop a cold admin key so the hot alloptions blob stays in memory. That is correct behavior. noeviction with a full dataset is the outage path. If used_memory sits at maxmemory and evicted_keys stays at zero, you either have noeviction or a maxmemory of zero that has not filled yet. Fix the policy before the next traffic spike so Redis stays a cache instead of a second database with worse durability.

Practical checks before you blame Redis

Confirm the daemon is listening only where PHP expects it, usually localhost. Confirm maxmemory is set to a real ceiling your VPS or dedicated box can spare beside MariaDB. Confirm the eviction policy is allkeys-lru so full memory produces evictions instead of errors. Then review recent plugin or theme changes that might have introduced per-request key material. After those steps, a short restart is safe; the cache will refill from real traffic, and a healthy hit ratio should return if the keys themselves are reusable.