# Redis Refused 4,600 of 6,000 Writes at Its Memory Cap: Choosing a WordPress Object Cache in 2026

> Two cache servers, four failure modes, measured on 23 September 2026. Redis refused about 4,600 of 6,000 writes at its cap. Memcached refused none.

- Published: 2026-09-23
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: Object Cache, Redis, Memcached, Performance, WordPress, check:S6
- Canonical: https://xspeedcache.com/blog/redis-vs-memcached-wordpress/

---

Updated September 2026

A direct wordpress.org Plugin API query on 23 September 2026 returns **500,000+ active installs** for Redis Object Cache and **10** for Memcached Object Cache, whose last release was 8 November 2022. Both numbers describe WordPress plugins rather than the cache servers behind them, and that gap is the answer most guides never separate out. The comparison people expect is Redis against Memcached on speed. The more useful comparison is what each one does at the four moments a WordPress object cache actually breaks. This article covers the choice, not the installation.

## Quick Summary: Which One, and Why

Every number in the table below was measured in this run on 23 September 2026, against Redis 7.0.15 and memcached 1.6.24 on loopback. The method and its limits are published further down, before the results.

| If you want… | Do this | Why |
|:---|:---|:---|
| A cache that survives a server restart | Redis, with snapshots left on | 5,000 of 5,000 keys came back after a restart with a snapshot; 0 of 5,000 came back from memcached |
| A cache that never returns an error when it fills | memcached, or Redis set to `allkeys-lru` | Redis on its shipped policy refused about 4,600 of 6,000 writes at its memory cap; memcached refused none |
| To cache a large `alloptions` blob | Redis | memcached refused every value at 1,024KB and above, Redis accepted 8MB |
| The lowest per-lookup latency | memcached, by 2.9 microseconds | Real and measurable, and worth about 3ms on a page making 1,000 lookups |
| A plugin that is still maintained | Redis, through Redis Object Cache | Updated 18 September 2026 against 8 November 2022 |
| To decide whether to bother at all | Measure your TTFB first | The server segment is a median 7.2% of LCP in our 1,074-report study |

**The short answer: pick Redis, and pick it for the plumbing rather than the engine.** The two servers are close enough on speed that the difference disappears into a page load. The WordPress software connecting them is not close at all.

## What an Object Cache Can Move, and What It Cannot

An object cache stores the results of database queries between requests. It acts on the time your server spends building a page, which is the server half of Time to First Byte, and it does nothing to the browser work that follows.

That matters because of how small the server half usually is. Our own study of 1,074 scan reports split Largest Contentful Paint into three segments across 396 sites and found the server accounted for a median of **0.43 seconds, or 7.2% of LCP**. The same study found that [93.4% of slow WordPress sites stay slow](https://xspeedcache.com/blog/caching-did-not-fix-slow-wordpress/) when the entire measured server response is subtracted from their LCP.

### The floor an object cache competes against

A second first-party figure sets the floor. Across 886 WordPress sites carrying a server probe, the median TTFB of those already serving from cache was **192ms**, and [48.4% of the sample had under 100ms of headroom](https://xspeedcache.com/blog/when-not-to-use-caching-plugin/) above that floor. An object cache competes for a slice of that headroom, not for the whole page.

Three situations change the arithmetic and are where an object cache earns its place:

- **Routes a page cache cannot touch.** Carts, checkouts, account pages, logged-in views and the WordPress admin all run PHP on every request. No page cache runs there, so the object cache is the only cache in the path.
- **Sites with expensive queries.** WooCommerce product lookups, large taxonomies and meta queries repeat identical work request after request.
- **The first request after a purge.** Whatever rebuilds the page cache still has to run the queries once.

## The Four-Failure Test: The Method, and What It Cannot Tell You

Comparing two cache servers on throughput produces a number nobody can act on. The four things below are the ones that change what a WordPress site does in production, and each is reproducible in about ten minutes on any Linux box.

**The limitations come first, because they bound every number that follows.**

1. **Loopback, one container, no network.** Both servers ran on 127.0.0.1 alongside the client. A real site reaches its cache over a unix socket or a LAN hop. The latency figures are floors, and your absolute numbers will be larger.
2. **A synthetic keyspace.** 5,000 keys shaped like WordPress object cache keys (`wp:options:…`, `wp:post_meta:…`) with uniform values. Real sites have a skewed access distribution this does not reproduce, so the eviction counts describe the mechanism rather than predicting your hit rate.
3. **Two specific builds.** Redis 7.0.15 and memcached 1.6.24, both from Debian packages. Every default reported below was read back with `CONFIG GET` or `stats settings` in this run rather than quoted from documentation, but a different build or a distribution that ships its own config file can differ.
4. **This measures the servers, not the drop-ins.** The WordPress plugin sitting between your site and the server adds its own behaviour, and the last section covers that separately.

The protocol, in four steps:

| Step | What you do | What you record |
|:---|:---|:---|
| 1. Restart | Write 5,000 keys, restart the daemon, count survivors | Keys recovered, and which configuration recovered them |
| 2. Cap | Set a memory limit, write past it, count accepted against refused | Refusals, evictions, keys held |
| 3. Value ceiling | Write values from 64KB upward until one is rejected | The exact size of the first rejection |
| 4. Key ceiling | Write keys from 200 bytes upward until one is rejected | The exact length of the first rejection |

![The Four-Failure Test: what Redis and memcached each do at the four moments a WordPress object cache breaks, measured 23 September 2026](https://xspeedcache.com/images/blog/object-cache-four-failure-test.webp)

Run step 1 and step 2 against your own configuration before you trust anything a comparison article tells you, including this one. Both take a single shell loop.

## Failures 1 and 2: The Restart and the Memory Cap

### Only one of these caches can survive a restart, and only if you let it

5,000 keys with 512-byte values, written, then the daemon stopped and started.

| Configuration | Keys written | Keys after restart | Survived |
|:---|:---:|:---:|:---:|
| Redis, snapshots disabled (`--save ''`) | 5,000 | 0 | ❌ |
| Redis, after a completed `BGSAVE` | 5,000 | 5,000 | ✅ |
| memcached, any configuration | 5,000 | 0 | ❌ |

The snapshot file was 170,468 bytes for 5,000 keys. A Redis server started with no configuration file reports `save 3600 1 300 100 60 10000`, verified with `CONFIG GET save` in this run, so snapshots are on unless something turned them off.

The claim worth correcting is the one that says Redis persists and memcached does not. Redis persists **if persistence is configured**, and plenty of object-cache deployments disable it deliberately, on the reasoning that a cache should not be writing to disk. Those installations lose exactly as much as memcached does. Memcached has no configuration that changes this outcome.

### At its memory cap, Redis returns errors and memcached evicts

6,000 writes of 4KB each into an 8MB limit. This is the result that changed how we would answer the question.

| Server and policy | Writes accepted | Writes refused | Keys held | Keys evicted |
|:---|:---:|:---:|:---:|:---:|
| Redis `noeviction` (shipped default) | 1,426 | 4,574 | 1,426 | 0 |
| Redis `volatile-lru` | 1,425 | 4,575 | 1,425 | 0 |
| Redis `allkeys-lru` | 6,000 | 0 | 1,418 | 4,577 |
| Redis `allkeys-lfu` | 6,000 | 0 | 1,418 | 4,577 |
| memcached, `-m 8` | 6,000 | 0 | 1,840 | 4,160 |

Every refusal returned `OOM command not allowed when used memory > 'maxmemory'.` The eviction counts are read from Redis's own `evicted_keys` counter and memcached's `evictions` stat rather than inferred from the difference.

The workload was run twice. The shipped-policy refusals came out at 4,603 and 4,574 of 6,000, and the accepted counts at 1,397 and 1,426, so treat the figure as roughly 4,600 rather than an exact one. Redis's memory accounting includes its own overhead, which moves slightly between runs. What does not move is the shape: two policies refuse everything past the cap and three make room.

![6,000 writes of 4KB into an 8MB limit: Redis on its shipped policy accepted 1,426 and refused 4,574, while memcached accepted all 6,000 and evicted 4,160](https://xspeedcache.com/images/blog/object-cache-memory-cap.webp)

### The policy that looks safe and is not

The `volatile-lru` row is the one that catches people. It reads like an eviction policy and behaves like none, because it only evicts keys carrying an expiry. Per [Redis's own eviction documentation](https://redis.io/docs/latest/develop/reference/eviction/), fetched on 23 September 2026: *"The volatile-xxx policies behave like noeviction if no keys have an associated expiration."* WordPress supplies no expiry by default. The [core source on developer.wordpress.org](https://developer.wordpress.org/reference/functions/wp_cache_set/) gives the signature as `wp_cache_set( $key, $data, $group = '', $expire = 0 )`, so an object cache filled by ordinary plugin code holds almost nothing that `volatile-lru` is willing to remove.

Two practical consequences follow:

- Cap Redis and leave the policy alone, and a full cache stops accepting writes instead of making room.
- Cap it and choose `volatile-lru` because the name sounds conservative, and you get the same outcome with a policy name that hides it.

## Failures 3 and 4: Two Ceilings Only Memcached Has

Memcached rejects oversized values and oversized keys. Redis accepted everything tested in both dimensions.

| Value size | Redis | memcached |
|:---|:---:|:---:|
| 64KB to 1,000KB | ✅ stored | ✅ stored |
| 1,024KB | ✅ stored | ❌ `SERVER_ERROR object too large for cache` |
| 1,100KB to 8,192KB | ✅ stored | ❌ `SERVER_ERROR object too large for cache` |

`stats settings` reports `item_size_max 1048576`, exactly 1MB, which matches where the rejections began. This is not a rare edge case on WordPress. The `alloptions` blob is a single cached value holding every autoloaded option on the site, and on a site with years of plugin history it passes 1MB without anything unusual happening. When it does, under memcached, the single most-read entry in the object cache silently stops being cached while everything else keeps working.

The key ceiling is narrower and easier to hit than it looks.

| Key length | Redis | memcached |
|:---|:---:|:---:|
| 200 bytes | ✅ stored | ✅ stored |
| 249 and 250 bytes | ✅ stored | ✅ stored |
| 251 bytes and above | ✅ stored | ❌ `CLIENT_ERROR bad command line format` |

250 bytes sounds generous until you count what goes into a WordPress cache key: a site-unique salt, a blog ID on multisite, a group name, and then the key itself, which for some meta and taxonomy lookups is a serialized query. The Memcached Object Cache plugin's own installation instructions require a `WP_CACHE_KEY_SALT` constant described in its readme as a *"long random string"*, and every byte of it counts against the 250.

## The Latency Question, Measured Against Its Own Noise Floor

An object cache lookup happens hundreds of times per page, so a per-lookup difference is worth checking. It is also small enough to vanish into measurement noise, which is why [our benchmark protocol](https://xspeedcache.com/blog/wordpress-caching-plugin-benchmark-protocol/) requires a noise floor before any comparison. The rule from that work: measure the same thing repeatedly first, set the Minimum Detectable Difference at the interquartile range of those repeats, and refuse to report any gap smaller than it.

40,000 GET operations, 1KB values, ten interleaved blocks of 2,000 per server.

| Measurement | Redis 7.0.15 | memcached 1.6.24 |
|:---|:---:|:---:|
| Median per lookup | 38.9µs | 36.0µs |
| Interquartile range across ten blocks | 0.2µs | 0.2µs |
| Gap | 2.9µs, memcached faster | 2.9µs, memcached faster |
| Above the Minimum Detectable Difference of 0.2µs | ✅ detected | ✅ detected |

The gap is real. It survives the noise floor by a factor of fourteen, which is more than most plugin comparisons can claim. Then it meets the page budget, and the arithmetic below is arithmetic rather than measurement:

| Object cache lookups per page | Total gap |
|:---|:---:|
| 200 | 0.6ms |
| 500 | 1.5ms |
| 1,000 | 2.9ms |
| 2,000 | 5.8ms |

![The per-lookup gap of 2.9 microseconds clears the 0.2 microsecond noise floor, and comes to 2.9ms across 1,000 lookups against a 192ms median TTFB](https://xspeedcache.com/images/blog/object-cache-latency-budget.webp)

Against the 192ms median TTFB of a WordPress site already serving from cache, 2.9ms is 1.5%. Choosing memcached for the latency is choosing a measurable win you will never see on a waterfall. xSpeed Cache's own object cache panel offers both backends and defaults to Redis for this reason, as documented in [enabling Redis or Memcached](https://xspeedcache.com/docs/object-cache/). If you want to know whether the server half of your page is even the problem, [run the free xSpeed Scan](https://xspeedcache.com/scan/) on the URL first and read the delivery section before changing anything.

## The Plumbing Decides This, Not the Engine

Everything above compares two cache servers. WordPress does not talk to either of them directly. It talks to a drop-in installed by a plugin, and that is where the two options stop being comparable. All figures below were fetched from the wordpress.org Plugin API and plugin SVN on 23 September 2026.

| Plugin | Backend | Active installs | Version | Last updated | Tested up to |
|:---|:---|:---:|:---:|:---|:---:|
| [Redis Object Cache](https://wordpress.org/plugins/redis-cache/) | Redis | 500,000+ | 3.0.0 | 18 Sep 2026 | 7.1 |
| Docket Cache | File-based | 20,000+ | 26.04.06 | 22 Sep 2026 | 7.1 |
| W3 Total Cache | Both | 900,000+ | 2.10.6 | 4 Sep 2026 | 7.1 |
| [Memcached Object Cache](https://wordpress.org/plugins/memcached/) | memcached | 10 | 4.0.0 | 8 Nov 2022 | 6.1 |

Ten active installs, and the last release predates four years of WordPress. Its readme states that *"a memcached server and the PECL memcache extension are required"*, and [PECL memcache](https://pecl.php.net/package/memcache) last shipped a release on 30 April 2023. The newer `memcached` extension last shipped on 13 October 2025 and the `redis` extension on 6 November 2025, so even the PHP layer under the older path is the least maintained of the three.

The practical route to memcached on WordPress in 2026 is W3 Total Cache, which supports both backends and is actively maintained. That is a real option. It is also a caching plugin you would be adopting for one setting, which is a different decision from choosing a cache server.

**Neither option installs on shared hosting without the host's help.** Both need a daemon running on the server and a PHP extension compiled in, and a site owner can supply neither. Ask your host which they run before reading any comparison, this one included. If the answer is neither, the object cache is not the next thing to fix.

## Running This Across a Fleet of WordPress Sites

Configuration drift is what makes this expensive at scale. One site has Redis capped with `noeviction` and is silently refusing writes, another has snapshots off and starts cold after every reboot, a third has no object cache at all and nobody noticed. Each is invisible from the front end and each shows up only as slower pages.

We build xSpeed Cache, and it is ours: xSpeed Cache, xSpeed Scan and xSpeed Hub are WPDeveloper products, and WPDeveloper is a Startise company. The object cache panel connects Redis or memcached with one click and shows the connection state, so drift is visible rather than inferred. For agencies running the same check across a client list, [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) reports it fleet-wide, and the [agency use case](https://xspeedcache.com/use-cases/agencies/) covers the workflow. The object cache backend selector is free, and the [Free vs Pro breakdown](https://xspeedcache.com/free-vs-pro/) shows where the line falls.

### The host decides whether either option exists

The other half of this is the server. An object cache is only as useful as the host running it, and a host that will not run Redis at all makes the entire comparison moot. We recommend xCloud, and it is ours as well: [xCloud](https://xcloud.host/) and WPDeveloper are both Startise companies, and it ships Redis on every plan with bring-your-own-server pricing.

Once a backend is connected, [our Redis setup guide](https://xspeedcache.com/blog/setup-redis-object-cache-wordpress/) covers the two shipped defaults worth changing on day one.

## Common Mistakes People Make Choosing an Object Cache

- **Capping Redis without setting an eviction policy.** The measurement above: about 4,600 refused writes out of 6,000. Set `maxmemory-policy allkeys-lru` at the same time you set `maxmemory`, or set neither.
- **Choosing `volatile-lru` because it sounds safer.** It behaves as `noeviction` for a WordPress keyspace, because WordPress writes cache entries with no expiry.
- **Assuming Redis persistence is on.** It is on by default and off in many object-cache deployments. Check with `CONFIG GET save` rather than assuming either way.
- **Treating the 1MB memcached value ceiling as theoretical.** A mature site's `alloptions` blob crosses it, and the failure is silent.
- **Benchmarking the two servers before checking whether the server half of TTFB is the problem.** [Measure the page first](https://xspeedcache.com/scan/).
- **Installing an object cache plugin that has not shipped since 2022** because an article from 2019 recommended it.

## Frequently Asked Questions

### I set maxmemory on Redis and my site started throwing errors. What happened?

Redis's shipped policy is `noeviction`, which returns `OOM command not allowed when used memory > 'maxmemory'.` rather than making room. In two runs it refused 4,574 and 4,603 of 6,000 writes once the cap was reached. Set `maxmemory-policy allkeys-lru` and the same workload accepted all 6,000.

### My object cache is empty every morning and I never flushed it. Why?

Something restarts the server nightly and your cache is not persisting. Redis with snapshots disabled recovered 0 of 5,000 keys in this run, and memcached recovered 0 of 5,000 under every configuration. Check `CONFIG GET save` on Redis. On memcached there is nothing to check, because a cold start is the only behaviour it has.

### I switched to memcached and one specific query got slower. Is that expected?

If that query's cached result is over 1MB, yes. Memcached returns `SERVER_ERROR object too large for cache` at 1,024KB and above, so the entry is never stored and the query runs every time. The `alloptions` blob is the usual culprit.

### Is Redis faster than Memcached for WordPress?

No. Memcached was faster in this run, by 2.9 microseconds per lookup across 40,000 operations, which clears the 0.2µs noise floor and amounts to roughly 2.9ms on a page making 1,000 lookups. Against a 192ms median TTFB that is 1.5%, which is not a reason to choose either one.

### I chose `volatile-lru` and Redis still refuses writes when full. Is that a bug?

No. Redis's documentation states that the volatile policies behave like `noeviction` when no keys carry an expiration, and WordPress's `wp_cache_set()` defaults `$expire` to 0. Use `allkeys-lru` for an object cache.

### Can I run both Redis and Memcached on the same site?

You can run both servers, but WordPress loads one object cache drop-in at `wp-content/object-cache.php` and only one is active. Running two is a way to have a second copy of the data nothing reads.

### Does an object cache help if I already have a page cache?

On uncacheable routes, yes, and that is where it earns its place. Carts, checkouts, account pages and the admin run PHP on every request, so the page cache is absent and the object cache is the only one left. On cacheable pages the page cache usually gets there first.

### How much memory should I give it?

Enough that eviction is rare, then an eviction policy for when your estimate is wrong. Watch `evicted_keys` on Redis or `evictions` on memcached: a number climbing steadily means the cache is too small to hold a working set.

### My host says they offer Redis. Does that mean it is already working?

Not necessarily. A running daemon is one of three things needed, alongside the PHP extension and the WordPress drop-in. Check whether `wp-content/object-cache.php` exists before assuming anything is cached.

### Which should I pick if I am starting today?

Redis, through Redis Object Cache, which has 500,000+ active installs and shipped on 18 September 2026. The engines are close. The WordPress software connecting them is not, and that is the part you will live with.

### Is Docket Cache a real alternative if my host runs neither?

It is a genuine third option, at 20,000+ installs and updated 22 September 2026, and it stores objects on disk rather than in a daemon. On fast local storage it beats no object cache. On network storage it can be slower than the queries it replaces, so measure before and after.

### Does a caching plugin replace any of this?

No. A page cache and an object cache sit at different layers and solve different problems, which is why plugins such as xSpeed Cache offer an object cache connection rather than a substitute for one. The [80-capability comparison](https://xspeedcache.com/comparison/) sets out which layer each feature sits in.

## Conclusion: Redis, for Reasons That Have Little to Do With Redis

Both servers do the job. Memcached is marginally faster per lookup, refuses nothing when full, and carries two ceilings that a mature WordPress site will eventually hit. Redis stores anything you give it, survives a restart when persistence is left on, and will refuse writes at its cap unless you set the policy yourself.

| Your goal | Pick | The catch |
|:---|:---|:---|
| A default that will not surprise you | Redis Object Cache | Set `maxmemory-policy allkeys-lru` on day one |
| A warm cache after every reboot | Redis with snapshots on | Confirm with `CONFIG GET save`, do not assume |
| Absolute lowest lookup latency | memcached | Worth 1.5% of a median cached TTFB |
| memcached on a maintained plugin | W3 Total Cache | You are adopting a full caching plugin for one setting |
| Neither available on your host | Docket Cache, or move hosts | Disk-backed, so storage speed decides it |

**What to do this week:**

1. Run `CONFIG GET maxmemory-policy` on your Redis. If it returns `noeviction` or `volatile-lru` and `maxmemory` is set, change it to `allkeys-lru` today.
2. Check whether `wp-content/object-cache.php` exists at all. Many sites that believe they have an object cache do not.
3. Measure the server half of your TTFB before tuning any of this, because a median of 7.2% of LCP is what is available to win.
4. If your host runs neither daemon, ask them before shopping for plugins.
5. If you want the page cache layer handled at the same time, xSpeed Cache is [$29/yr at the founding price](https://xspeedcache.com/pricing/) with a 14-day money-back guarantee, and its object cache panel connects either backend with one click.

The four tests above take about ten minutes and they will tell you more about your own configuration than any comparison table can, this one included. If you run them and get different numbers, we would rather hear about it than not.