Page caching hides the problem; object caching fixes it. On a 2 vCPU \/ 2 GB instance, moving WordPress persistent object cache from MySQL to Redis cut median database query time from 38 ms to 4 ms and reduced TTFB on uncached pages by roughly 45% in my tests. Here is the full setup, the tuning that matters, and how to prove the gain on your own box.<\/p>\n\n\n\n
Every Adjust the PHP version suffix if needed ( Give every site its own prefix – on a multi-site VPS a shared prefix silently mixes keys between installations. The plugin drops A healthy object cache settles above 90% hits. Below 70% usually means a plugin is writing unique keys per request (often a poorly written slider or analytics plugin), and For a single VPS, Redis over a unix socket wins on latency and lets the same instance serve sessions and background jobs. Memcached only earns its place when the working set is far larger than available RAM and cold restarts are acceptable.<\/p>\n\n\n\nget_option()<\/code>, WP_Query<\/code> and transient lookup normally round-trips to MySQL – and for a page-cache miss, that can be hundreds of queries. With a persistent object cache, the results live in RAM and survive between requests.<\/p>\n\n\n\n1 – Install Redis and the PHP client<\/h2>\n\n\n\n
sudo apt update\nsudo apt -y install redis-server php-redis\nsudo systemctl enable --now redis-server\nredis-cli ping # PONG\nphp -m | grep -i redis<\/code><\/pre>\n\n\n\nphp8.3-redis<\/code>): the package name must match the FPM pool that serves the site.<\/p>\n\n\n\n2 – Tune redis.conf for a cache, not a database<\/h2>\n\n\n\n
sudo tee \/etc\/redis\/redis.conf.d\/vps-cache.conf <<'EOF'\nunixsocket \/run\/redis\/redis-server.sock\nunixsocketperm 770\nport 0\nmaxmemory 256mb\nmaxmemory-policy allkeys-lru\nsave \"\"\nappendonly no\ntcp-keepalive 60\nEOF\nsudo systemctl restart redis-server\nredis-cli -s \/run\/redis\/redis-server.sock ping<\/code><\/pre>\n\n\n\n3 – Wire it into WordPress<\/h2>\n\n\n\n
sudo -u www-data wp config set WP_REDIS_SCHEME unix --raw\nsudo -u www-data wp config set WP_REDIS_PATH \/run\/redis\/redis-server.sock\nsudo -u www-data wp config set WP_REDIS_PREFIX \"wpsite1:\"\nsudo -u www-data wp plugin install redis-cache --activate\nsudo -u www-data wp redis enable\nsudo -u www-data wp redis status<\/code><\/pre>\n\n\n\nobject-cache.php<\/code> into wp-content\/<\/code>; keep it out of version control and note that it must be removed if the plugin is ever uninstalled, or WordPress will throw a fatal error.<\/p>\n\n\n\n4 – Verify the hit rate is real<\/h2>\n\n\n\n
redis-cli -s \/run\/redis\/redis-server.sock info stats | \\\n egrep 'keyspace_hits|keyspace_misses|evicted_keys'\nredis-cli -s \/run\/redis\/redis-server.sock info memory | egrep 'used_memory_human|maxmemory_human'\nredis-cli -s \/run\/redis\/redis-server.sock dbsize<\/code><\/pre>\n\n\n\nevicted_keys<\/code> climbing fast means maxmemory<\/code> is too small.<\/p>\n\n\n\n5 – Measure before and after<\/h2>\n\n\n\n
# warm the cache, then measure uncached pages\nsudo -u www-data wp cache flush\nab -n 2000 -c 50 -H \"Cookie: wordpress_logged_in_test=1\" https:\/\/example.com\/ \\\n | egrep 'Requests per second|Time per request'\n# query count from the app side\nwp eval 'global $wpdb; echo $wpdb->num_queries;'<\/code><\/pre>\n\n\n\nMetric (uncached page, 50 clients)<\/th> MySQL cache<\/th> Redis object cache<\/th><\/tr><\/thead> Queries per request<\/td> 182<\/td> 41<\/td><\/tr> Median DB time<\/td> 38 ms<\/td> 4 ms<\/td><\/tr> TTFB (p50)<\/td> 610 ms<\/td> 335 ms<\/td><\/tr> Requests\/sec<\/td> 78<\/td> 142<\/td><\/tr> MySQL CPU<\/td> 46%<\/td> 12%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Redis, Memcached, or APCu?<\/h2>\n\n\n\n
Option<\/th> Scope<\/th> Best for<\/th> Caveat<\/th><\/tr><\/thead> APCu<\/td> Single PHP process<\/td> Very small single-worker sites<\/td> Per-process only, lost on every deploy<\/td><\/tr> Memcached<\/td> Network, shared across pools<\/td> Simple key\/value with a huge working set<\/td> No data structures, no persistence, no Lua<\/td><\/tr> Redis<\/td> Unix socket or network<\/td> Object cache plus sessions, queues, rate limits<\/td> Requires a correct maxmemory and eviction policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Pitfalls that cost hours<\/h2>\n\n\n
used_memory<\/code> above 80% of maxmemory<\/code> and on evicted keys per minute.<\/li><\/ul>\n\n\n\n\nSizing the cache and reading the signals<\/h2>\n\n\n\n
redis-cli -s \/run\/redis\/redis-server.sock info stats | egrep 'hits|misses|evicted'\nredis-cli -s \/run\/redis\/redis-server.sock --scan --pattern 'wpsite1:*' | wc -l\nredis-cli -s \/run\/redis\/redis-server.sock info memory | egrep 'used_memory_human|maxmemory_human'<\/code><\/pre>\n\n\n\nredis-cli --bigkeys<\/code>.<\/li>maxmemory<\/code> in 64 MB steps while memory headroom allows, then re-measure query counts.<\/li>KEYS<\/code> or FLUSHALL<\/code>, and confirm persistence is still disabled for a pure cache.<\/li>