wpcompass.io

WordPress hosting comparisons, managed WP reviews, performance optimization

WordPress Object Cache: Redis vs Memcached Benchmarked

by Sarah Mitchell
WordPress Object Cache: Redis vs Memcached Benchmarked

WordPress Object Cache: Redis vs Memcached Benchmarked

A WordPress object cache sits between PHP and your database. Every time WordPress needs a post, option, or term, it normally fires a SQL query. With a persistent object cache in place, the result of that query lives in memory and gets returned in microseconds instead of milliseconds. The difference shows up immediately in TTFB.

Most WordPress site owners know the concept. Fewer know which backend to choose, how to configure it, or whether a given managed host's built-in cache is actually doing what the marketing page implies. This article works through all three questions with measured results.

Why TTFB Is the Metric That Matters Here

Page speed tools report a lot of numbers. For object caching, TTFB (Time to First Byte) is the one that directly reflects database pressure. LCP and TBT can be moved by frontend changes — image formats, script deferral, layout shifts. TTFB is almost entirely a server-side number. If your object cache is working, TTFB drops. If it is not working, no amount of frontend tuning recovers that time.

Baseline for this test: a WooCommerce 8.5 store running on a $20/month VPS (2 vCPU, 4 GB RAM, Ubuntu 22.04, PHP 8.2, MariaDB 10.6, Nginx). No page cache, no CDN, no opcode cache changes — isolating the object cache variable only. Median TTFB measured with k6 over 200 requests, 10 concurrent users, shop archive page.

Baseline TTFB (no object cache): 610 ms

How Each Backend Works

Redis

Redis is a single-threaded, in-memory data structure store. It supports strings, hashes, lists, sets, sorted sets, and more. For WordPress, the relevant features are:

  • Persistence options: Redis can write to disk (RDB snapshots or AOF logs), meaning cache survives a restart.
  • Key expiry and eviction policies: configurable per key or globally (e.g., allkeys-lru).
  • Pub/sub and Lua scripting: not used by WordPress directly, but available if you extend with custom code.
  • Single-threaded command processing: no race conditions on atomic operations.

The two most-used WordPress Redis plugins are Redis Object Cache by Till Krüss (version 2.5.4 at time of writing) and Object Cache Pro (a commercial plugin, v1.20.1). Redis Object Cache uses a persistent connection by default; Object Cache Pro adds a relay PHP extension that keeps a local in-memory copy inside the PHP process, eliminating the network round-trip entirely.

Memcached

Memcached is a simpler, multi-threaded key-value store. It supports strings only, has no persistence, and uses a slab allocator for memory management. For WordPress:

  • No persistence: a restart clears all cached data, forcing a cold-cache rebuild.
  • Multi-threaded: can use multiple CPU cores, which matters on very high-concurrency workloads.
  • Lower memory overhead per connection: slightly more efficient than Redis at extreme connection counts.
  • WordPress plugin: the maintained option is Memcached Object Cache (a drop-in, not a plugin in the traditional sense; latest commit March 2024).

Test Setup and Configuration

All three configurations ran on the same VPS with the same WooCommerce database (3,200 products, 14,000 orders). Each cache backend was allocated 256 MB of RAM.

Redis configuration (/etc/redis/redis.conf changes):

maxmemory 256mb
maxmemory-policy allkeys-lru
save ""

Persistence disabled to match Memcached's in-memory-only behavior for a fair comparison. The allkeys-lru policy evicts the least-recently-used key when memory is full.

Memcached configuration (/etc/memcached.conf changes):

-m 256
-t 4

Four threads to match the 2 vCPU count (Memcached recommends 2× CPU threads).

WordPress wp-config.php addition for both:

define( 'WP_CACHE', true );

For Redis Object Cache, the drop-in (object-cache.php) is installed via the plugin's admin screen. For Memcached, the drop-in is placed manually in wp-content/.

Object Cache Pro with the Relay extension was tested as a third variant. Relay keeps a per-process in-memory cache inside PHP-FPM workers, so the Redis network socket is only hit on a miss within the Relay layer.

Benchmark Results

All figures are median TTFB across 200 requests, 10 concurrent users, k6 load test, shop archive page, WordPress 6.5, WooCommerce 8.5.

Configuration Median TTFB p95 TTFB DB Queries (avg) Memory Used
No object cache (baseline) 610 ms 890 ms 47 —
Redis Object Cache 2.5.4 198 ms 310 ms 12 38 MB
Memcached Object Cache (drop-in) 187 ms 298 ms 12 31 MB
Object Cache Pro 1.20.1 + Relay 112 ms 161 ms 12 44 MB

A few things stand out:

  1. Redis and Memcached land within 11 ms of each other at the median. The difference is inside measurement noise for most real-world workloads. The claim that one is categorically faster than the other does not hold at this concurrency level.
  2. Database query count drops identically — from 47 to 12 — regardless of backend. The object cache is doing the same work in both cases.
  3. Object Cache Pro + Relay is a different tier. The 86 ms gap over Redis Object Cache comes from eliminating the Unix socket round-trip. Each PHP-FPM worker holds its own copy of warm keys. The trade-off is higher memory consumption per worker and a commercial license (~$95/year for one site).
  4. p95 matters more than median for WooCommerce. Cart and checkout pages hit the database harder. The p95 column shows Redis Object Cache and Memcached are nearly identical there too.

Which Backend to Choose

Given the benchmark data, the decision comes down to operational factors rather than raw speed.

Factor Redis Memcached
Persistence after restart Yes (configurable) No
WordPress plugin ecosystem Strong (two active plugins) One drop-in, less maintained
Managed host support Widely available Less common
Memory efficiency Slightly higher overhead Slightly lower overhead
Multi-site support Yes (key prefix per site) Yes (key prefix per site)
Object Cache Pro compatibility Yes (required) No

For most WordPress operators, Redis is the practical choice — not because it is faster, but because the plugin ecosystem is better maintained, managed hosts (Kinsta, Cloudways, GridPane, SpinupWP) offer it as a one-click add-on, and Object Cache Pro requires Redis if you want the Relay tier.

Memcached makes sense if you are on a host that provides it natively (some cPanel stacks default to Memcached) and you are not planning to use Object Cache Pro.

Recommended Settings for Production

These are the settings that produced the benchmark results above. Treat them as a starting point, not a final answer — your workload's hot-key distribution will determine the right maxmemory value.

Redis (redis.conf):

  • maxmemory: start at 10% of available RAM, monitor redis-cli info memory for used_memory_peak_human, adjust upward if evictions are frequent.
  • maxmemory-policy allkeys-lru: correct for WordPress, where you want the cache to self-manage without crashing on full memory.
  • save "": disable persistence unless you have a specific reason to keep it (persistence adds fsync overhead).
  • tcp-backlog 511: reduces connection queue drops under burst traffic.

Redis Object Cache plugin:

  • Enable persistent connections (default on).
  • Set global groups to include users, userlogins, usermeta, user_meta, site-options, site-lookup, blog-lookup, blog-details, rss, global-posts, blog-id-cache, networks, sites, blog_meta — this is the default list; verify it in the plugin's diagnostics screen.
  • Enable non-persistent connections only if you are on a host that limits Redis connections per account.

Object Cache Pro (if budget allows):

  • Enable Relay via the plugin settings screen (requires the Relay PHP extension, which GridPane and Cloudways support).
  • Set relay.maxmemory in php.ini to 32–64 MB per PHP-FPM worker. More than that and you risk OOM on shared environments.

Do This First

Before installing any object cache plugin, run this WP-CLI command to confirm no drop-in is already present:

wp eval 'echo WP_CONTENT_DIR . "/object-cache.php";'
ls -lh $(wp eval 'echo WP_CONTENT_DIR . "/object-cache.php";' 2>/dev/null)

If a file exists and you install a second plugin that writes its own drop-in, you get silent conflicts — the newer file wins, but only if the plugin successfully overwrites it. Some managed hosts write-protect wp-content/ at the filesystem level, meaning the plugin's drop-in never lands and you cache nothing while the plugin dashboard reports everything is fine.

After installing, verify the cache is actually being used:

wp cache set test_key test_value 60
wp cache get test_key

Output should be test_value. If it returns empty, the drop-in is not active.

Then measure. Run a k6 or wrk load test against your shop archive or homepage before and after. If TTFB does not drop by at least 30%, check whether a page cache is already absorbing the database load — in that case, object cache gains will be smaller because the page cache is serving most requests without hitting PHP at all.

What Managed Hosts Actually Give You

Managed WordPress hosts frequently advertise "built-in Redis" or "server-level caching." The details vary significantly:

  • Kinsta: Redis is available as a paid add-on ($100/year). It is a shared Redis instance with a per-site key prefix. Object Cache Pro is bundled at no extra cost for Kinsta customers, which is a meaningful value-add given the license price.
  • Cloudways: Redis is available on all plans via the "Add-ons" tab. Relay is supported on PHP 8.1+ stacks. The Redis instance is dedicated per server, not shared.
  • GridPane: Redis Object Cache and Object Cache Pro are both supported. GridPane's stack documentation specifies allkeys-lru as the default eviction policy, which matches the recommended setting above.
  • WP Engine: uses a proprietary object cache layer. You cannot install a custom Redis drop-in. TTFB behavior depends on their internal implementation, which is not publicly documented.

If you are evaluating managed hosts partly on caching architecture, ask specifically whether you can install a custom object-cache.php drop-in. Hosts that lock wp-content/ limit your ability to tune this layer.

Conclusion

The WordPress object cache benchmark result is clear: both Redis and Memcached cut database queries from 47 to 12 and reduce median TTFB from 610 ms to roughly 190 ms on a WooCommerce store at moderate concurrency. The choice between them is an operational decision, not a performance one — Redis wins on ecosystem and managed host availability. Object Cache Pro with Relay is the only configuration that produces a meaningfully different result, dropping TTFB to 112 ms by eliminating the network round-trip inside PHP-FPM workers.

Measure your baseline TTFB before installing anything. Verify the drop-in is active with WP-CLI after installing. Then re-measure. The numbers will tell you whether the cache is working — the marketing copy will not.