Redis kan databasewerk verminderen, maar is niet automatisch een voordeel. Netwerklatency, eviction, serialisatie en plugingedrag kunnen een nieuw knelpunt vormen.
“Connected” bewijst niet dat de object cache gezond is. Meet hit rate, latency, geheugendruk en echt applicatiegedrag.
1. Controleer waar Redis draait
Lokale socket, lokaal TCP en remote Redis hebben heel verschillende latencyprofielen. Een remote cache kan trager zijn dan de queries die hij vervangt.
2. Controleer geheugen en evictionbeleid
Veel evictions geven onregelmatige performance en verwijderen objecten voordat ze waarde opleveren.
3. Scheid stale data van page cache
Object cache, full-page cache en CDN bewaren verschillende dingen. Wis de laag die de verouderde waarde werkelijk bevat.
4. Zoek grote of snel wisselende objecten
Grote options, transients en high-churn keys kosten geheugen en serialisatietijd.
5. Meet wp-admin apart
Backendschermen tonen object-cacheproblemen vaak duidelijker dan anonieme front-endbenchmarks.
6. Vergelijk met en zonder Redis
Een gecontroleerde A/B-meting is beter dan aannames. Wordt het gemeten pad sneller zonder object cache, onderzoek dat eerst.