Fixing Redis Object Cache Bottlenecks & High Latency on WordPress

When WordPress traffic scales, an in-memory object cache like Redis is critical to prevent repeated MySQL queries. However, a misconfigured Redis instance often creates a reverse bottleneck—where PHP processes freeze waiting for Redis socket locks, driving TTFB above 3 seconds.

---

Act 1: The Crime Scene (Symptoms of Redis Contention)

An online retailer noticed that during sales campaigns, their server CPU spiked to 100% and checkout requests stalled with 504 Gateway Timeouts. Despite having Redis Object Cache Pro active, server response degraded rapidly under 50 concurrent buyers.

Inspecting wp-config.php and Redis latency via CLI revealed:

$ redis-cli --latency -h 127.0.0.1 -p 6379
min: 0, max: 1420, avg: 184.22 (240 samples)

A healthy local Redis instance must respond in < 1ms. An average latency of 184ms with spikes over 1.4 seconds meant PHP workers spent their entire lifecycle waiting for Redis replies rather than serving dynamic content.

---

Act 2: Forensic Root Cause

1. Unix Socket vs TCP Loopback Overhead

The site was configured to connect to Redis over 127.0.0.1:6379. Under heavy concurrency, the Linux kernel TCP stack experienced port exhaustion and socket queue bottlenecks.

2. Unrestricted Maxmemory & Eviction Policy Failure

Redis was running without a defined memory ceiling. When memory filled up, Redis stopped accepting writes and entered blocking swap mode, grinding the server to a halt.

3. Session Locking on WooCommerce Cart Data

Non-blocking transients were configured with default blocking locks, causing concurrent customer requests to queue up behind single session keys.

---

Act 3: The Surgical Fix

1. Switching to High-Speed Unix Domain Sockets

In /etc/redis/redis.conf, enable unix sockets and disable TCP overhead:

# /etc/redis/redis.conf
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770
timeout 0
tcp-keepalive 0

Add the web server user (www-data) to the redis group:

sudo usermod -a -G redis www-data
sudo systemctl restart redis-server

2. Enforcing LFU Memory Eviction Policy

Ensure Redis never runs out of RAM or swaps to disk:

maxmemory 1024mb
maxmemory-policy allkeys-lfu
maxmemory-samples 7

3. Tuning WordPress Redis Object Cache Parameters

In wp-config.php, update the connection to use the socket:

define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis-server.sock');
define('WP_REDIS_TIMEOUT', 1.0);
define('WP_REDIS_READ_TIMEOUT', 1.0);
define('WP_REDIS_MAXTTL', 86400);

---

The Verdict: Sub-0.5ms Object Cache Response

After switching to Unix domain sockets and tuning memory eviction:

• Redis latency dropped from 184ms down to 0.12ms.
• TTFB during checkout dropped from 3,140ms down to 84ms.
• Server CPU dropped by 64% under identical concurrent traffic.

---

🔗 Interconnected Engineering Triages & Architecture Mesh:

Infrastructure bottlenecks are rarely isolated. Upstream server performance, database query patterns, and DOM execution are tightly interlocked:

• Diagnosing Unindexed Slow Queries in MySQL 8.0 with EXPLAIN ANALYZE: Pinpoint table scans and temporary tables choking database throughput.
• Reducing DOM Tree Size Below 800 Nodes: Prevent mobile viewport rendering stalls and main-thread blocking.
• Mitigating Interaction to Next Paint (INP) Delays from GTM: Audit heavy tracking payloads blocking main-thread responsiveness.