LHAS

You were right — thanks for pushing back, and apologies for the misleading report.

I re-tested properly, and 2.8.0 is not the cause.

Steady state (single WP-CLI request, warm cache, same Redis server): 2.7.0 and 2.8.0 are identical at ~0.42s, and it does not scale with key count — I retested against a DB with ~380,000 keys and 2.8.0 was still ~0.42s. So my “scales with key count” claim was simply wrong.

Under concurrency (origin-direct load test, PHP-FPM pool max_children=10), mean / max response times, with 0 errors or timeouts in every run:

• 20 concurrent: 2.8.0 (Metrics on) 59 / 96 ms vs 2.7.0 74 / 131 ms
• 50 concurrent: 2.8.0 151 / 171 ms vs 2.7.0 156 / 187 ms
• 100 concurrent (10× the pool): 2.8.0 285 / 335 ms vs 2.7.0 306 / 383 ms

So 2.8.0 is equal-to-slightly-faster than 2.7.0, and having Metrics enabled made no difference. It’s now running in production on 2.8.0 with no issues (bootstrap ~0.42s, no 504s).

What actually caused the incident: I had updated via WP-CLI (wp plugin update redis-cache), which updates the plugin but does not sync the drop-in — leaving plugin 2.8.0 + drop-in 2.7.0, so I then ran wp redis update-dropin separately. That meant hand-swapping the live object-cache.php on a high-traffic site, and the 504 burst was a one-off transient around that swap — not 2.8.0’s per-request behavior. My “1.44s” figure was measured during that overload, so it was an artifact of the saturated server, not the plugin. When I later upgraded through the wp-admin UI (which updates the plugin and syncs the drop-in together, in one step), it was completely clean.

So this was entirely on my end — a CLI two-step that performed the drop-in swap separately, under load — not a 2.8.0 regression. Apologies for the noise, and thanks for the plugin.