WordPress Object Cache Benchmark: Redis vs Memcached vs APCu Compared

In standard WordPress architectures, page caching plugins (like WP Super Cache, WP Rocket, or LiteSpeed Cache) intercept incoming HTTP requests and serve pre-compiled static HTML files to unauthenticated visitors. However, for logged-in administrators, WooCommerce shoppers, members-only portals, and interactive web applications, full-page caching is bypassed by necessity.

For these dynamic sessions, the primary performance bottleneck is repetitive database queries. WordPress executes dozens of identical queries on every page load to retrieve transients, term taxonomies, and option keys from the wp_options table. An in-memory object cache resolves this by intercepting database read operations and storing query results directly in high-speed RAM on your Linux VPS.

In this technical benchmark, we test the three leading object caching architectures for WordPress: Redis, Memcached, and APCu, evaluating request throughput, latency, memory utilization, and persistence.

1. The Contenders: Architectural Overview

• Redis: An advanced, in-memory key-value data structure store supporting strings, hashes, sets, and pub/sub. Operates as an external daemon with optional disk persistence and robust replication features.
• Memcached: A high-performance, distributed memory object caching system designed exclusively for string-based key-value caching. Extremely lightweight and multi-threaded by design.
• APCu (APC User Cache): An in-memory key-value store built directly into the PHP runtime engine. Requires no external daemon, communicating directly inside the PHP process shared memory.

2. Benchmark Testing Methodology & Hardware Setup

All benchmarks were conducted on a standardized CpanelFree Linux VPS instance configured as follows:

• Server Hardware: 4 Dedicated vCPU cores (AMD EPYC), 8GB DDR5 ECC RAM, NVMe SSD storage.
• Software Environment: Ubuntu 24.04 LTS, Nginx 1.26, PHP 8.3-FPM, MariaDB 11.4.
• Application Under Test: WordPress 6.6 with WooCommerce and 25,000 published products.
• Load Generation Tool: k6 generating 150 concurrent authenticated users executing dynamic cart additions, account browsing, and checkout simulations for 10 minutes.

3. Performance Benchmark Results

Performance Metric	Redis (TCP/Socket)	Memcached	APCu	No Object Cache
Requests / Second (RPS)	482 RPS	465 RPS	390 RPS	48 RPS
p95 Latency (Response Time)	42ms	46ms	58ms	480ms
MariaDB CPU Utilization	6% CPU	7% CPU	11% CPU	94% CPU (Choked)
Cache Hit Ratio	98.4%	97.1%	89.6%	0% (Direct SQL)
Persistence Across Restarts	Yes (RDB/AOF)	No (Volatile)	No (PHP Reload Clears)	N/A

4. Deep Architectural Analysis

Why Redis Won the Shootout

Redis achieved the highest throughput (482 RPS) and lowest p95 latency (42ms) when configured over a local UNIX domain socket (/var/run/redis/redis-server.sock). Beyond sheer speed, Redis supports granular key eviction policies, data persistence (ensuring your cache stays warm across server reboots), and rich telemetry tools via redis-cli monitor.

When to Use Memcached

Memcached is a phenomenal multi-threaded memory engine. In massive horizontal server clusters where multiple PHP nodes query a central distributed cache pool, Memcached’s multi-threaded core can occasionally out-scale single-threaded Redis processes when memory allocations exceed 32GB. However, for 95% of single-to-medium VPS deployments, Redis’s rich data structures and socket support provide superior real-world WordPress speed.

The Problem with APCu

While APCu avoids TCP/socket overhead by living directly inside PHP shared memory, it suffers from two fatal architectural limitations in modern production:

1. Every time PHP-FPM reloads (e.g., during deployments or worker recycling), APCu completely clears its cache, causing severe database query spikes.
2. APCu memory cannot be shared across multiple web servers or separate PHP-FPM worker pools, making it unsuitable for clustered hosting.

5. Production Redis Unix Socket Tuning Guide

To eliminate network loopback TCP overhead and achieve maximum possible Redis throughput on your VPS, switch Redis to UNIX domain sockets in /etc/redis/redis.conf:

# Enable Unix Domain Socket
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770

# Configure memory boundaries
maxmemory 512mb
maxmemory-policy allkeys-lru

# Disable TCP port if web server runs on the same machine
port 0

Add the web server user to the redis group and update wp-config.php:

sudo usermod -aG redis www-data
sudo systemctl restart redis-server php8.3-fpm

define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis-server.sock');
define('WP_CACHE_KEY_SALT', 'cpanelfree_prod_');

Advanced Redis In-Memory Tuning & Real-World Latency Diagnostics

To extract maximum performance from Redis on enterprise WordPress sites, sysadmins must tune kernel parameters and memory allocators:

• Eliminating Linux Kernel Memory Overcommit Latency: Redis performs background snapshotting (BGSAVE) using fork system calls. If Linux kernel memory overcommit is restricted, Redis throws warnings and can fail to write data under heavy write loads. Fix this in /etc/sysctl.conf:

  vm.overcommit_memory = 1
  net.core.somaxconn = 65535

  Apply settings immediately using sudo sysctl -p.

• Tuning Jemalloc Memory Fragmentation: Over weeks of continuous key turnover, in-memory caches suffer from memory fragmentation. Inspect real-time fragmentation ratios using the Redis CLI:

  redis-cli info memory | grep mem_fragmentation_ratio

  If the ratio exceeds 1.5, trigger dynamic active defragmentation in redis.conf without restarting the daemon:

  activedefrag yes
  active-defrag-ignore-bytes 100mb
  active-defrag-threshold-lower 10

• Analyzing Key Eviction Rates: If your allocated Redis cache pool fills up, Redis begins evicting older keys based on your maxmemory-policy (such as allkeys-lru). Monitor evictions via redis-cli info stats | grep evicted_keys. A high eviction rate indicates that your WordPress database requires a larger physical RAM allocation on your VPS.