WordPress Site Health had been nagging me to use a persistent object cache. I already run Zend OpCache, so I wondered what else I needed.
OpCache is an opcode cache: it stores the compiled bytecode of the PHP source so the engine need not recompile it on every request. The object cache is a different layer, holding the results of database queries and transients. WordPress ships with a non-persistent object cache that lives only for the duration of a single request; making it persistent means backing it with something that survives across requests, such as Redis.
On this site I manage the WordPress tree with svn and do not let PHP write into it, which changes a couple of the steps from the usual click-in-the-dashboard instructions. While I also generally prefer nginx and PHP-FPM, this site is still on Apache with mod_php. However, the installation is basically the same regardless of the web server software, but troubleshooting differs between them. I’m covering both here.
Install Redis and PhpRedis
These two packages are needed (on Debian 13 [trixie]):
sudo apt install redis-server php-redis
php-redis is the PhpRedis extension: a Redis client compiled in C. The plugin can also fall back to the pure-PHP Predis client, but PhpRedis is faster and is preferred automatically when present.
Installing the extension usually activates it for you: on Debian the package’s dpkg triggers reload PHP-FPM, so PhpRedis is live the moment the install finishes — on the PHP-FPM site I did not have to reload anything by hand.
Confirm the result on the plugin’s Overview tab, under Settings → Redis, which names the active client. If it does not report PhpRedis, reload PHP yourself. With PHP-FPM, reload the pool — the service name carries your PHP version:
sudo systemctl reload php8.4-fpm
With Apache and mod_php the interpreter is embedded in the web server, so reload Apache itself:
sudo systemctl reload apache2
Until PhpRedis is active the plugin falls back to the pure-PHP Predis client, which still works but is slower.
Install the plugin
I use Redis Object Cache by Till Krüss. Install it the usual way, or drop it into wp-content/plugins/ and activate it. It coexists happily with a page cache such as WP Super Cache — they occupy different drop-ins (object-cache.php versus advanced-cache.php) and cache different things.
Configure the connection
I run more than one WordPress site against the same Redis instance, so each site gets its own logical database number and its own key prefix. Add these to wp-config.php, above the /* That's all, stop editing! */ line:
// WP_REDIS_DATABASE: scopes cache flushes to this site. // WP_CACHE_KEY_SALT: prevents key collisions if databases coincide. define('WP_REDIS_DATABASE', 1); define('WP_CACHE_KEY_SALT', 'kimmo:');
WP_REDIS_DATABASE is an integer; Redis provides databases 0–15 by default. The two settings guard against different failure modes: a distinct database number keeps one site’s flush from clearing another’s cache, and the salt keeps keys from colliding should two sites ever land in the same database.
If you have enabled the Redis Unix socket, point the plugin at it with WP_REDIS_PATH; otherwise it connects to 127.0.0.1:6379 by default.
Enable the drop-in
The plugin normally enables itself by copying object-cache.php up into wp-content/. Since I do not let PHP write into the tree, I place it by hand — and rather than copy it, I symlink it, so it always matches the installed plugin version and never goes stale:
cd wp-content ln -s plugins/redis-cache/includes/object-cache.php
A relative symlink stays valid regardless of where the tree is checked out, and when the plugin updates the drop-in follows along automatically. The Enable/Disable buttons on the plugin’s settings page will not work, since they too need to write here; that is expected. To disable the object cache, remove the symlink.
Verify
The plugin’s Overview tab should now report the drop-in as Valid, the connection as Connected, and the client as PhpRedis. From the shell, watch the keys land in the right database:
redis-cli -n 1 dbsize redis-cli -n 1 --scan | head
A rising dbsize and keys carrying the kimmo: prefix confirm that the drop-in loaded, connected to the intended database, and applied the salt.