Redis vs Memcached for WordPress: Object Cache Setup and Benchmarks

Why Object Caching Changes Everything

Every uncached page load on WordPress triggers dozens of database queries. The same user meta, option values, and transients get fetched repeatedly. An object cache stores these results in memory so the database only gets hit once.

The two real options are Redis and Memcached. Both are in-memory key-value stores. Both are fast. But they work differently, and picking the wrong one for your setup leads to wasted memory, stale data, and false confidence in your caching layer. For a broader look at WordPress performance optimization, explore our dedicated hub.

Here is how each one actually works with WordPress, when to use which, and how to set them up properly. For more WordPress tutorials, browse our how-to collection.

WordPress has a built-in object cache API: wp_cache_set(), wp_cache_get(), wp_cache_delete(). By default, this cache only lives for a single page request. When the request ends, the cache is gone.

A persistent object cache replaces this default with an external store that survives between requests. Install a drop-in plugin like object-cache.php and suddenly wp_cache_get() reads from Redis or Memcached instead of rebuilding data from MySQL every time.

The difference is dramatic. A typical WordPress page goes from 50-100 database queries down to 5-10. Response time drops by 40-60%.

Redis is more than a cache. It is a data structure server that supports strings, lists, sets, hashes, and sorted sets. For WordPress, the key advantages are:

• Persistence, Redis can write to disk, so your cache survives a restart
• Data types, Stores complex structures natively without serialization overhead
• Pub/Sub, Supports real-time messaging between processes
• Lua scripting, Run atomic operations server-side
• Replication, Built-in master-replica support for high availability

For WordPress specifically, Redis handles transients, session data, and the full page cache in a single service. No separate tools needed.

Install Redis on Ubuntu/Debian

sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Configure Redis for WordPress

Edit /etc/redis/redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru
bind 127.0.0.1
port 6379

The allkeys-lru policy evicts the least recently used keys when memory is full. This is exactly what you want for a cache, old data gets pushed out automatically.

WordPress Configuration

Add to wp-config.php:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

Install the Redis Object Cache plugin or manually place the object-cache.php drop-in into wp-content/.

Memcached does one thing: store key-value pairs in memory. It is simpler than Redis, uses less memory per key, and distributes data across multiple servers natively.

• Multi-threaded, Uses all CPU cores, while Redis is single-threaded
• Lower memory overhead, No persistence, no complex data types means less memory per key
• Horizontal scaling, Built-in consistent hashing distributes keys across servers
• Battle-tested, Facebook, Twitter, and Wikipedia use it at massive scale

The tradeoff: no persistence, no data types beyond strings, and no built-in replication.

Install Memcached

sudo apt install memcached php-memcached
sudo systemctl enable memcached
sudo systemctl start memcached

Configure Memcached

Edit /etc/memcached.conf:

-m 256
-p 11211
-l 127.0.0.1
-c 1024

The -m flag sets memory in MB. The -c flag sets max connections.

WordPress Configuration

Use the Memcached Object Cache drop-in. Place object-cache.php in wp-content/ and add to wp-config.php:

$memcached_servers = array(
    'default' => array( '127.0.0.1:11211' ),
);

Tested on a WooCommerce store with 5,000 products, 50,000 orders, and 200 concurrent users. Server: 4 vCPU, 8GB RAM, NVMe SSD.

Memcached is slightly faster on raw throughput because of its multi-threaded architecture. Redis uses slightly more memory but has a higher hit rate due to smarter eviction.

The real-world difference between them is negligible for most WordPress sites. Both cut response times by 60%+ compared to no cache.

• You run WooCommerce or any plugin that uses sessions heavily
• You want cache persistence across restarts
• You need the cache for multiple purposes (object cache + session store + queue)
• You run a single WordPress server
• You want monitoring tools like RedisInsight

When to Choose Memcached

• You have multiple web servers and need distributed caching
• Memory is tight and you need lower overhead per key
• You only need simple key-value caching, nothing else
• Your hosting provider only supports Memcached

Redis

redis-cli info stats | grep -E "hit|miss|keys"

Watch for keyspace_hits vs keyspace_misses. Your hit rate should be above 90%. Below that means your cache is too small or keys are expiring too fast.

Memcached

echo "stats" | nc 127.0.0.1 11211 | grep -E "get_hits|get_misses|bytes"

Same principle: hits divided by (hits + misses) gives your hit rate.

WordPress-Level Monitoring

Install Query Monitor. It shows exactly which cache calls hit, which missed, and how long each database query took. This is the single best tool for understanding whether your object cache is actually working.

• Cache too small, If maxmemory is too low, keys get evicted constantly and your hit rate drops. Start with 256MB and monitor.
• No eviction policy, Without maxmemory-policy, Redis returns errors when full instead of evicting old keys. Always set allkeys-lru.
• Multiple sites, one database, If you run multisite or multiple WordPress installs on the same Redis, use WP_REDIS_DATABASE or key prefixes to prevent collisions.
• Stale cache after deploys, Flush the cache after code changes: wp cache flush.
• TCP vs Unix socket, For local connections, Unix sockets are 10-20% faster than TCP. Set WP_REDIS_SCHEME to unix and WP_REDIS_PATH to the socket path.

For most WordPress sites, Redis is the better choice. It handles more use cases, has better tooling, and the persistence feature means your cache survives restarts without a cold-start penalty.

Choose Memcached only if you specifically need distributed caching across multiple servers or your hosting limits you to it.

Either way, running WordPress without a persistent object cache in production is leaving 60% of your performance on the table. Pick one, set it up properly, monitor the hit rate, and your database will finally stop being the bottleneck.

database cleanup database optimization

Last modified: March 26, 2026