Redis ลดงานฐานข้อมูลซ้ำได้ แต่ไม่ได้ดีเสมอไป network latency, eviction, serialization และ plugin behavior อาจกลายเป็นคอขวดใหม่
สถานะ “connected” ไม่ได้พิสูจน์ว่า object cache สุขภาพดี ควรวัด hit rate, latency, memory pressure และพฤติกรรมแอปจริง
1. ตรวจว่า Redis ทำงานอยู่ที่ไหน
Unix socket, local TCP และ remote Redis มี latency ต่างกันมาก cache ระยะไกลอาจช้ากว่า query ฐานข้อมูลที่พยายามแทน
2. ตรวจหน่วยความจำและ eviction policy
การ eviction บ่อยทำให้ประสิทธิภาพไม่สม่ำเสมอและลบ object ก่อนสร้างประโยชน์
3. แยก object cache จาก page cache
Object cache, full-page cache และ CDN เก็บข้อมูลคนละชนิด ต้องล้างชั้นที่ถือค่าค้างจริง
4. หา object ใหญ่หรือเปลี่ยนบ่อย
options ขนาดใหญ่ transients และ key ที่เปลี่ยนบ่อยเพิ่มต้นทุนหน่วยความจำและ serialization
5. วัด wp-admin แยกต่างหาก
ปัญหา object cache อาจเห็นชัดในหน้าผู้ดูแลแม้ benchmark หน้าเว็บ anonymous ดูดี
6. เปรียบเทียบก่อนและหลัง Redis ในเงื่อนไขเดียวกัน
การวัด A/B แบบควบคุมมีค่ากว่าการเดา หากเส้นทางเป้าหมายเร็วขึ้นเมื่อปิด object cache ให้หาสาเหตุก่อนเปิดอีกครั้ง