Integrating Memcache for faster cache storagefor Drupal 8 , 9 , 10 , and 11

Home » Performance Optimization » Integrating Memcache for faster cache storage
Last updated :  
8.x , 9.x , 10.x , 11.x

In the last lesson, file-based caching hit a wall the moment you add a second web server — each server keeps its own separate cache, so there's no single source of truth. Memcache solves exactly that problem: it's a standalone, in-memory key-value store that every web server in your cluster connects to over the network, so they all read and write the same cached data. Think of it as a shared whiteboard in a hallway instead of each person keeping their own private notepad.

What you'll learn in this lesson

  • Why Memcache is the natural next step once file-based caching stops scaling
  • How to wire the Memcache API contrib module into Drupal's cache backend system
  • The one real tradeoff Memcache brings: cached data isn't persistent

Installing and configuring the Memcache backend

Memcache support in Drupal comes from the contrib Memcache API module, which — like the file cache backend from the last lesson — provides a real implementation of CacheBackendInterface that talks to a running Memcached server over the network:

composer require drupal/memcache
drush en memcache -y

Then point Drupal at it in settings.php, exactly the same pattern as the file backend — only the service ID changes:

$settings['cache']['default'] = 'cache.backend.memcache';

$settings['memcache']['servers'] = [
  '127.0.0.1:11211' => 'default',
];

Every web server in your cluster points at the same Memcached server (or cluster of them), which is what actually solves the shared-cache problem — cache writes from one server are immediately visible to reads on every other one, because they're all hitting the same in-memory store.

The tradeoff: Memcache is genuinely volatile

$settings['memcache']['servers'] = [
  '127.0.0.1:11211' => 'default',
];
Memcache does not persist data to disk, ever, by design. If the Memcached process restarts — a server reboot, a routine service restart, an out-of-memory eviction — every cached value it held is simply gone. That's an acceptable trade for cache data (Drupal will just recompute it and re-cache it on the next request), but it means you must never store anything in a Memcache-backed cache bin that you can't afford to lose or regenerate on demand. This is exactly why Drupal's own cache system is designed as a "may vanish at any time" contract in the first place — CacheBackendInterface::get() is always allowed to return nothing, and calling code is required to handle that gracefully.

Memory limits and eviction

Memcached is given a fixed memory allocation at startup (commonly configured with a -m flag on the memcached process itself, e.g. -m 512 for 512MB). Once that limit is reached, Memcached evicts the least-recently-used items to make room for new ones — you don't manage this yourself, and Drupal doesn't need to know it's happening. The practical implication is that a busy site with a small memory allocation will see a lower cache hit rate simply because popular-but-not-recently-touched items get evicted to make room, not because anything is misconfigured.

Quick check: your Memcached server restarts unexpectedly at 3am. What happens to your Drupal site when the first visitor loads a page at 3:01am? (Answer: nothing breaks — every cache read simply misses, Drupal recomputes the page fresh exactly as if nothing had ever been cached, and re-populates the now-empty cache. The site is momentarily slower, not broken, which is the whole point of treating cache as disposable.)

Key takeaways

  • Memcache is a shared, in-memory cache backend — every web server in a cluster reads and writes the same data, unlike file-based caching.
  • Install it via the contrib Memcache API module and point $settings['cache']['default'] at cache.backend.memcache.
  • Memcache never persists to disk — a restart wipes everything it held. This is fine for cache data specifically, since Drupal always treats a cache miss as valid and just recomputes.
  • Memcached evicts least-recently-used data once its fixed memory allocation fills up — a low hit rate under memory pressure is expected behavior, not a bug.

Coming up next

Redis offers the same shared, in-memory model as Memcache, but adds optional persistence and richer data structures — the next lesson walks through when that extra capability is worth the added operational complexity.