Tuning cache backend configurations (e.g., compression)for Drupal 8 , 9 , 10 , and 11

Choosing a cache backend is only half the job — the default settings for Memcache or Redis are tuned to be safe and generic, not fast for your specific site. This lesson covers the handful of settings that actually move the needle: compression, connection reuse, and serialization overhead.

What you'll learn in this lesson

• How compression trades CPU time for reduced network and memory usage — and when that trade is worth it
• Why persistent connections matter more than almost any other single setting
• How the default PHP serializer can quietly become your bottleneck on large cached values

Compression: trading CPU for bandwidth and memory

$settings['redis.connection']['compression'] = TRUE;

Both Memcache and Redis client libraries support optional compression of values before they're stored. This shrinks memory usage in the cache server and reduces the bytes sent over the network on every read and write — genuinely useful when your cached values are large (a fully rendered page, a big Views result set). The cost is CPU time spent compressing and decompressing on every single cache operation.

Persistent connections: the setting with the biggest real-world impact

$settings['redis.connection']['persistent'] = TRUE;

Without this, every PHP request opens a brand-new TCP connection to your Redis or Memcache server, does its work, then tears the connection down — connection setup and teardown is pure overhead that happens on literally every page load. Enabling persistent connections lets PHP-FPM worker processes keep their connection open and reuse it across requests. On a busy site, this single setting often has more measurable impact than compression or any other individual tuning knob, because it eliminates a fixed cost that was being paid on every request regardless of what else was cached.

Serialization: what actually gets sent over the wire

Before a PHP array or object can be stored in Memcache or Redis, it has to be turned into a string — that's serialization, and it happens on every set() and every get() whether you think about it or not. PHP's built-in serialize()/unserialize() is the default and is reasonably fast, but for very large or deeply nested cached structures (a big render array with many nested children is a common culprit), an alternative serializer like igbinary can meaningfully reduce both CPU time and stored size:

$settings['redis.connection']['serializer'] = \Redis::SERIALIZER_IGBINARY;

igbinary is a PHP extension, not something that ships by default — it needs to actually be installed on your server (pecl install igbinary, or your distro's package) before this setting does anything useful.

Quick check: you enable compression on every cache bin site-wide, expecting a performance win, but a load test shows response times got slightly worse. What's the most likely explanation? (Answer: many of your cache bins probably hold small values — config objects, small entity fields — where compression's CPU overhead outweighs any bandwidth/memory savings. Compression should be scoped to bins with genuinely large values, like render or page, not applied blanket site-wide.)

Key takeaways

• Compression trades CPU for reduced memory/network usage — worth it for large cached values, a net loss for small ones.
• Persistent connections eliminate the per-request cost of opening a new connection to your cache server — often the single highest-impact tuning setting available.
• Every cached value gets serialized on write and deserialized on read; PHP's default serializer is fine generally, but igbinary can help meaningfully with large, deeply nested structures once installed.
• Tune per-bin where your client library supports it — a setting that helps one bin's workload can actively hurt another's.

Coming up next

Configuration only gets you so far without visibility — the next lesson covers actually measuring your cache hit and miss ratio, so you can tell whether any of this tuning made a real difference.