Object cache with Redis

A Redis object cache keeps WordPress query results and options in memory so PHP can reuse them without hitting the database on every request. WordPress reaches Redis through a drop-in file named object-cache.php, usually on 127.0.0.1. When memory limits and eviction are set correctly, repeated work drops and the site stays steadier under load.

Place the object-cache drop-in

WordPress looks for wp-content/object-cache.php on each request. A Redis object cache plugin, or WP Toolkit on WordPress accounts, installs that file for you. After it is in place, PHP talks to Redis on localhost rather than any public port. On shared hosting that includes Redis, the service is already bound to localhost, but you still need the drop-in. Without it, WordPress silently uses ordinary in-process memory even while the Redis daemon is running.

AUTH on localhost is still useful if you run plugins you do not fully trust. Also watch for plugins that write a unique key on every view, such as a fresh session id per visitor. Those keys never get reused, fill the cache, and create a long miss storm that looks like Redis is failing when the real problem is a leak.

Cap memory and choose eviction

redis-cli info memory | head

Read used_memory and maxmemory from that output. If maxmemory is 0, Redis has no ceiling and can grow until the server swaps. Set a cap that still leaves RAM for MariaDB, LiteSpeed, and PHP. Use a policy such as allkeys-lru so cold keys are dropped instead of new writes being refused. Eviction is normal for a cache; it is how Redis stays useful under pressure.

On a VPS you manage yourself, install Redis, bind it to localhost, set maxmemory and eviction, then enable the drop-in. On plans where Redis is already provided, confirm the drop-in after you turn on the plugin or Toolkit option. A full Redis with no eviction often shows up as “the database is slow,” because the box is swapping and MariaDB is the first service to feel it.

What the object cache does not fix

Redis object cache does not replace proper indexes. A large autoload value in wp_options still loads on bootstrap, and Redis will only cache that blob until you reduce it. Run Query Monitor on staging to see whether you are caching real work or caching a heavy query set. Page cache through LiteSpeed Cache still serves full HTML to logged-out visitors. Redis does not replace that layer.

If used_memory sits at the cap and the hit rate stays poor, a plugin is likely flooding unique keys. Disable that plugin, flush Redis, and measure again. Do not raise maxmemory only to hide the leak. That spends RAM on data that never helps the next request. Keep the drop-in active, keep Redis capped, and treat eviction as part of a healthy setup rather than a failure.