Redis RTT optimizer

Cuts the number of times a Drupal request waits for Redis, for deployments where the cache is a network hop away: AWS ElastiCache across availability zones, a managed Redis outside the cluster, or any topology where a cache read has to cross the network.

Drupal issues most of its Redis reads strictly one after another, because each answer decides what to ask next: a warm content listing on the test bench waits for Redis 166 times. On a single host nobody counts those waits. Across a network each one is paid in latency. This module makes the same work wait for the network far less often.

What changes is the waiting, not the work. Reads that Drupal issues one at a time are gathered into single pipelines; compare-and-set protocols move into Lua; a render cache redirect chain that had to be walked one hop at a time is fetched in one go once its shape is known. Nothing is deferred: every write, delete and invalidation reaches Redis at the point the stock backend sends it.

Project status: beta. The settings may still change before a stable release. It builds on Redis 2.x, which has no stable release yet. It supports Drupal 10.3 and later and 11.4 and later, not 11.0 to 11.3. It is not covered by Drupal's security advisory policy.

Features

Six changes, switched on in stages from settings.php:

• One round trip per bin read. The "last delete all" marker rides in the pipeline of the read that needed it, instead of costing a GET of its own.
• No redirect hop on render cache hits. The shape of a VariationCache redirect chain is memoised in APCu and the whole chain is fetched in one MGET. Every hop is checked against what was learned before the answer is used, so a stale mapping degrades to a miss, never to wrong data.
• Cache tag checksums in one MGET. The set of tags a request touches is nearly constant, so it is learned and fetched together. Checksums are still read on every request; only the grouping changes.
• One round trip per lock. Upstream, releasing or renewing a lock is a compare-and-swap done with WATCH/GET/MULTI/EXEC, five round trips. A Lua script does the same atomically in one.
• One round trip per invalidation. To invalidate a set of cache entries the stock backend sends, for each cache ID in turn, an HGET and, if the entry is valid, an HSET. Here each check-and-set is a Lua script, and the whole set travels in one pipeline.
• Connection settings the stock client leaves out. Connect timeout, a bounded read timeout, retry interval, TCP keepalive and TLS with peer verification, on the PhpRedisRtt client.

Where Lua is not available, the two savings that depend on it fall back to the commands the redis module sends, and the status report says so: a Redis with scripting out of the ACL or EVAL renamed, or the redis module's Predis client.

The module also ships the measurement half of the work: the optional X-Redis-RTT response header reports the round trips, commands and time spent in Redis and in the database for the request, so the saving can be measured on your own site.

Measured on warm, authenticated pages, counting round trips with this module's own counter on both sides: the stock redis backend on one site and this module on its twin, identical except for settings.php. The stock side uses the CountingPhpRedis client, which is the redis module's own connection with the same counter attached. Drupal 10.6, PHP 8.3, a deliberately heavy site; median of three requests after six warm-up requests, in two rounds with the order swapped, on the code now in the 1.0.x branch.

Warm, authenticated Stock redis This module Content listing 166 85-91 (-45% to -49%) Node edit form 61 31 (-49%) View a node 25 13 (-48%)

A round trip is a wait: one per command sent on its own, one per pipeline. These rows have been reproduced on separate benches, most recently on that same code.

Pages built from cold are mostly writing, which this module sends at the same point the stock backend does, so they gain less. And what the module removes is waiting on the network, so the saving grows with what a round trip costs on yours: if your cache is on localhost, this module is not for you.

Post-Installation

Enabling the module changes nothing on its own. All of it is configured in settings.php, because the cache backend has to be chosen before the service container exists; there is no administration UI and no configuration entity. Installing it does not swap anybody's Redis client either: $settings['redis.connection']['interface'] = 'PhpRedisRtt'; stays an explicit choice.

The status report at Administration > Reports > Status report shows which parts are active, so a half-finished configuration is visible rather than silent. With OPcache's opcache.validate_timestamps=0, reload PHP-FPM after every change to settings.php: until then the web server keeps the old configuration, whatever drush says.

The README has the lines to paste, how to roll out in stages and measure between them, and the recipe to take it all out again.

Additional Requirements

• Redis 2.x, which has no stable release yet. A dependency's stability flag is not inherited, so ask for both packages with theirs: composer require "drupal/redis:^2.0@alpha" "drupal/redis_rtt:^1.0@beta". Asking for this module alone, with or without its flag, does not resolve under the default minimum-stability.
• The phpredis PHP extension, 5.3 or newer, for the PhpRedisRtt client this module configures. The redis module's Predis client also works without it, minus the two savings that depend on Lua.
• Drupal 10.3 or later, or 11.4 or later. In 11.2 core added a cache tag preload of its own, which collided with this module's until the module was changed to keep out of its way. That fix was verified on 11.4.6 and the range was set to match, so Drupal 11.0 to 11.3 are not claimed.

Recommended modules/libraries

The APCu PHP extension is strongly recommended. Without it the render cache redirect shortcut and the cache tag checksum grouping still behave correctly, but nothing they learn survives the request, so they save nothing. The status report says so if APCu is missing.

Similar projects

Redis is not an alternative to this module but its foundation: this module extends its 2.x classes rather than replacing them, and switching back to the stock backend needs no migration.