Redis Object Caching for WordPress: Setup, Metrics & Architecture

Short answer: WordPress core includes an in-memory object cache that discards all stored data as soon as an HTTP request finishes. A persistent Redis object cache stores query results, options, transients, and user metadata in Redis in-memory storage across requests. This slashes MySQL query volume by 60% to 90%, speeding up uncached pages, logged-in user sessions, and WooCommerce checkout flows.

However, Redis is not an automatic magic button. Configured improperly or without cache group isolation, it can cause stale cart data, race conditions, or memory exhaustion.

How Redis fits into the WordPress architecture

Incoming Request
      │
      ▼
  Page Cache (Nginx / Cloudflare)? ──Yes──► Return static HTML (0ms PHP/DB)
      │
      No (Logged in, WooCommerce Cart, Admin)
      ▼
  PHP-FPM Worker
      │
      ▼
  wp_cache_get('key', 'group')
      ├── Found in Redis? ──────────► Return cached object (sub-millisecond)
      └── Cache Miss? ──────────────► Query MySQL ──► Store in Redis ──► Return

1. Setting up Redis with unix socket connection

Connecting to Redis via a UNIX domain socket eliminates TCP/IP network stack latency, delivering roughly 20% lower latency than connecting over 127.0.0.1:6379.

In /etc/redis/redis.conf:

unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770
maxmemory 512mb
maxmemory-policy allkeys-lru

Add your web server user (www-data) to the redis group so PHP-FPM can access the socket:

usermod -aG redis www-data

Then configure wp-config.php:

define( 'WP_REDIS_PATH', '/var/run/redis/redis-server.sock' );
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PREFIX', 'site_prod_' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

2. Non-persistent groups and WooCommerce safety

In WooCommerce stores, dynamic session data and cart fragments should never be cached permanently. Configure non-persistent cache groups in wp-config.php:

define( 'WP_REDIS_IGNORED_GROUPS', [
    'counts',
    'plugins',
    'wc_session_id',
] );

3. Monitoring cache hit ratio with redis-cli

A healthy WordPress Redis setup maintains a cache hit ratio above 85%. Inspect your live Redis metrics using redis-cli:

redis-cli -s /var/run/redis/redis-server.sock info stats

Look at keyspace_hits and keyspace_misses:

$$\text{Hit Ratio} = \frac{\text{keyspace_hits}}{\text{keyspace_hits} + \text{keyspace_misses}} \times 100$$

If your hit ratio falls below 70%, either your maxmemory is too small (causing constant key evictions) or a plugin is constantly calling wp_cache_flush().

---

Need enterprise Redis architecture or tuning for high-traffic WooCommerce? See my WordPress Performance Optimization services or contact me for technical consulting.