Hi Bart,
You’ll need to debug this. Redis Object Cache is just providing an API to communicate with the object cache, it’s your plugins/themes and WP core that’s actually doing the cache calls.
Try using Query Monitor to have a closer look.
Hi Till,
Thank you for your response. I understand Redis Object Cache is an API layer.
However, Query Monitor does not show AJAX/REST API calls made by Gutenberg after page load. The 5 GB of network traffic is generated by Gutenberg’s /wp/v2/media/ REST calls – with Redis disabled these same calls only generate 60 MB.
Is there a way to see what Redis is actually caching during these REST calls? For example via WP-CLI or Redis diagnostics?
Best regards, Bart
You can use redis-cli MONITOR to see what keys are going in and out.
As well as redis-cli --bigkeys maybe one of your plugins is storing images in the cache, which is a bad practice.
Hi Till,
Thanks for the suggestion. We ran both MONITOR and –bigkeys.
No plugin is storing images in the cache — the biggest keys are legitimate: options:alloptions (775 KB), options:yootheme (144 KB), and a feed transient (585 KB).
We cleaned up alloptions from ~1.2 MB down to 775 KB by removing stale data from inactive plugins (OMGF, Thrive, AIOSEO, WP Rocket cache entries), but the performance issue persists.
Bart
-------- summary -------
Sampled 19443 keys in the keyspace!
Total key length in bytes is 1572597 (avg len 80.88)
Biggest string found '"CL-c178f1cf-f183-4f63-8d80-b78713cd6dc1bk1a:options:alloptions"' has 775801 bytes
Biggest zset found '"CL-c178f1cf-f183-4f63-8d80-b78713cd6dc1bk1a:redis-cache:metrics"' has 619 members
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
19442 strings with 30509054 bytes (99.99% of keys, avg size 1569.23)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 zsets with 619 members (00.01% of keys, avg size 619.00)
Hi Till,
we found the root cause: switching from LSAPI to PHP-FPM resolved the issue almost completely. With LSAPI + Redis the site generated ~5 GB of network traffic just from opening one post in the editor — with PHP-FPM it dropped to ~10 MB.
It seems LSAPI was amplifying the Redis traffic massively under the combination of WPML + Gutenberg REST calls.
Thanks for your help!
Best regards,
Bart
