v2.8.0 adds ~1s/request that scales with Redis key count (2.7.0 OK)

Hi, thanks for the plugin.

After updating 2.7.0 → 2.8.0 on a busy production site, every request became ~1s slower. Under concurrent traffic this exhausted the PHP-FPM pool and the site returned 502/504 (NGINX: upstream timed out). Reverting to 2.7.0 fixed it immediately. The Redis server itself was healthy throughout.

Key finding — the overhead scales with the number of keys in the site’s Redis DB. Using the same 2.8.0 drop-in, a single WP-CLI request (no concurrency, warm cache):

2.8.0 drop-in, Redis DB with ~26 keys (idle site): ~0.42s
2.8.0 drop-in, Redis DB with tens of thousands of keys: ~1.44s
2.7.0 drop-in, same large DB: ~0.49s

So 2.7.0 is flat regardless of key count, but 2.8.0 adds a per-request cost proportional to how many keys exist in the database — looks like a per-request key-space scan/enumeration. This is why a low-traffic staging copy (tiny cache) showed no issue while production (large cache) was hit hard.

Environment

• Plugin: 2.7.0 (good) vs 2.8.0 (slow)
• WordPress 7.0, PHP 8.3.31 (PHP-FPM + NGINX)
• PhpRedis 6.3.0, igbinary not loaded
• Redis server 6.2.20, localhost, maxmemory-policy allkeys-lru, rejected_connections: 0, plenty of free memory
• Custom WP_REDIS_PREFIX and a dedicated WP_REDIS_DATABASE; WP_REDIS_TIMEOUT/READ_TIMEOUT = 3

Ruled out: wp redis status on 2.8.0 = Connected / Drop-in Valid / Errors: []; Redis server fast (ping instant, few clients, no rejected connections); no PHP fatals. Moving object-cache.php aside instantly restored ~0.4s bootstrap.

Questions

1. Did 2.8.0 add a per-request key-space scan/count (or change connection/serializer handling) that scales with DB key count?
2. Is this known with PhpRedis built without igbinary?
3. Happy to provide a profiler trace or test a patch on a copy that reproduces it.

Thanks!