Mengira Redis Object Cache Aktif Padahal object-cache.php Belum Terpasang

Service Redis sudah running, plugin Redis Object Cache sudah aktif, jadi WordPress pasti sudah pakai Redis. Asumsi ini sering muncul, dan cukup sering juga salah. Yang menentukan apakah WordPress memakai object cache persisten bukan service Redis atau status plugin. Penentunya satu file kecil bernama object-cache.php di folder wp-content. Kalau file itu tidak ada atau tidak bisa terhubung, Redis cuma diam di server, sementara setiap request tetap mengirim query yang sama ke MySQL.

Kenapa Redis yang running belum berarti dipakai WordPress

WordPress punya object cache API, yaitu fungsi seperti wp_cache_get() dan wp_cache_set() yang dipakai core, tema, dan plugin untuk menyimpan hasil query sementara. Secara default, implementasinya adalah class WP_Object_Cache yang menyimpan data di memori PHP selama satu request saja. Begitu halaman selesai dirender, isinya hilang. Request berikutnya mulai dari nol lagi. Saat WordPress mulai berjalan, core mengecek apakah ada file wp-content/object-cache.php. Kalau ada, file itu dimuat dan menggantikan implementasi default. File seperti ini disebut drop-in, yaitu file khusus di wp-content yang dimuat langsung oleh core, bukan lewat mekanisme aktivasi plugin biasa. Drop-in inilah yang berbicara dengan Redis. Plugin-nya sendiri lebih berperan sebagai pembungkus: halaman pengaturan, perintah WP-CLI, dan salinan drop-in yang siap dipasang. Di plugin Redis Object Cache, mengaktifkan plugin biasanya hanya memunculkan menu Settings > Redis. Drop-in baru disalin ke wp-content setelah kamu klik tombol Enable Object Cache di halaman itu, atau menjalankan wp redis enable lewat WP-CLI. Langkah kedua ini yang paling sering terlewat. Plugin lain punya alur yang mirip, tapi letak tombol dan istilahnya berbeda, jadi cek dokumentasi plugin yang kamu pakai. Di situs sepi, bedanya hampir tidak terasa. Masalahnya baru kelihatan saat traffic naik. Tanpa cache persisten, setiap request mengulang query untuk options, post meta, term, dan data user. MySQL menerima query identik berkali-kali, worker PHP-FPM lebih lama menunggu, dan antrean request mulai menumpuk. Pemilik situs lalu memasang Redis karena berharap situsnya lebih ringan, tapi tidak ada yang berubah karena drop-in tidak pernah terpasang. Di meja support, keluhan seperti Redis sudah aktif tapi situs tetap lambat biasanya langsung kita jawab dengan satu pertanyaan: file drop-in-nya ada atau tidak? Untuk langkah debugging performa yang lebih umum, lihat Catatan Praktis WordPress Performance & Debugging untuk Troubleshooting Sehari-hari.

Cek pertama: apakah object-cache.php ada, dan milik siapa

Jalankan perintah berikut dari root instalasi WordPress. Semuanya read-only.

BASH

# Apakah drop-in ada?
ls -la wp-content/object-cache.php

# Header file biasanya menyebut plugin pembuatnya
head -n 20 wp-content/object-cache.php

# Status menurut plugin Redis Object Cache (hanya ada kalau plugin ini aktif)
wp redis status

# Apakah WordPress memuat object cache eksternal?
wp eval 'var_dump( wp_using_ext_object_cache() );'

Kalau ls menampilkan No such file or directory, kamu sudah dapat jawabannya: WordPress belum memakai Redis sama sekali. Kalau file-nya ada, baca header di beberapa baris awal. Plugin cache lain, misalnya LiteSpeed Cache atau W3 Total Cache, juga bisa menulis object-cache.php versi mereka sendiri. Bisa saja file yang ada justru milik plugin lain yang dikonfigurasi ke Memcached atau malah nonaktif. Dari dashboard, kamu juga bisa melihatnya di halaman Plugins, tab Drop-ins. Output wp redis status biasanya menampilkan status koneksi, client PHP yang dipakai, dan kondisi drop-in, misalnya valid, tidak ada, atau milik plugin lain. Format persisnya tergantung versi plugin. Sementara itu, wp_using_ext_object_cache() yang mengembalikan bool(true) hanya berarti ada drop-in eksternal yang dimuat. Fungsi ini tidak menjamin backend-nya Redis. Jadi gabungkan hasilnya dengan header file tadi.

Drop-in ada tapi tidak tersambung

Kondisi kedua yang juga sering terjadi: drop-in sudah terpasang, tapi koneksinya gagal. Penyebab yang paling umum ada tiga. Pertama, ekstensi PHP-nya tidak ada di versi PHP yang dipakai situs. Plugin Redis Object Cache bisa memakai beberapa client, misalnya ekstensi phpredis atau library Predis. Hati-hati dengan php -m, karena perintah itu mengecek PHP CLI. Versi PHP CLI bisa berbeda dengan versi PHP-FPM yang melayani situs, terutama di server dengan banyak versi PHP. Cara yang lebih akurat adalah melihat Tools > Site Health > Info di bagian server atau memeriksa phpinfo dari situsnya, lalu hapus file phpinfo itu setelah selesai. Kedua, alamat Redis tidak sesuai. Ada server yang Redis-nya listen di TCP 127.0.0.1:6379, ada yang hanya lewat unix socket, dan ada yang memakai password. Plugin Redis Object Cache membaca konstanta di wp-config.php, yang ditaruh sebelum baris komentar That's all, stop editing.

PHP

// Contoh saja, sesuaikan dengan setup server kamu
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'tokocontoh_' );
// Kalau Redis pakai password: WP_REDIS_PASSWORD
// Kalau lewat unix socket: WP_REDIS_SCHEME 'unix' dan WP_REDIS_PATH

Ketiga, beberapa situs berbagi satu Redis tanpa prefix. Prefix adalah awalan nama key, gunanya supaya key situs A tidak bertabrakan dengan key situs B. Tanpa prefix dan tanpa database index terpisah, data antar situs bisa tercampur. Selain itu, flush cache di satu situs bisa ikut mengosongkan cache situs lain. Di VPS yang menampung banyak WordPress, beri setiap situs prefix yang unik. Setelah konfigurasi diubah, jalankan lagi wp redis status. Status koneksi harus berubah menjadi tersambung sebelum kamu lanjut ke langkah berikutnya.

Membuktikan cache benar-benar terisi dan terbaca

Status tersambung belum membuktikan cache bekerja. Bukti yang lebih kuat datang dari sisi Redis: key situsmu ada, dan angka hit-nya naik.

BASH

# Redis hidup? Jawaban yang diharapkan: PONG
redis-cli ping

# Counter hit dan miss sejak Redis terakhir start
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'

# Contoh key dengan prefix situs, pakai SCAN (bukan KEYS)
redis-cli --scan --pattern 'tokocontoh_*' | head -n 20

Kalau Redis pakai password, tambahkan autentikasi ke redis-cli sesuai setup server. Kalau situs memakai database index selain 0, tambahkan opsi -n dengan nomor database-nya, terutama untuk perintah scan. Cara membacanya sederhana. Catat nilai keyspace_hits, buka beberapa halaman situs, lalu jalankan perintah yang sama sekali lagi. Kalau angkanya naik, berarti ada yang membaca data dari Redis. Hasil scan dengan prefix memastikan bahwa yang membaca memang WordPress milikmu, bukan aplikasi lain yang kebetulan memakai Redis yang sama. Kalau angka hit tidak bergerak dan tidak ada key dengan prefix situsmu, kembali ke dua bagian sebelumnya. Rasio kasarnya bisa dihitung dengan rumus hits / (hits + misses). Ingat, counter ini dihitung sejak Redis terakhir start dan mencakup semua aplikasi yang memakainya. Anggap angka ini sebagai indikasi, bukan ukuran pasti untuk satu situs. Tepat setelah cache di-flush, miss tinggi itu normal karena cache masih terisi ulang. Peringatan untuk server production: hindari KEYS * dan MONITOR. KEYS memindai semua key sekaligus dan bisa memblokir Redis kalau jumlah key-nya besar. MONITOR mencetak setiap perintah yang masuk dan menambah beban cukup berat saat traffic ramai. Pakai --scan seperti contoh di atas.

Kenapa drop-in bisa hilang tanpa disadari

Melewatkan tombol Enable bukan satu-satunya penyebab. Drop-in yang tadinya aktif juga bisa hilang belakangan, dan biasanya tidak ada pesan error yang mencolok. Migrasi dan restore adalah penyebab yang paling sering. Tool migrasi atau backup parsial kadang hanya menyalin folder plugins, themes, dan uploads, sehingga file yang berada langsung di root wp-content tertinggal. Setelah pindah server, plugin terlihat aktif, tapi drop-in-nya tidak ikut terbawa. Plugin cache lain juga bisa menimpa file yang sama. Kalau dua plugin sama-sama ingin mengelola object cache, mereka bisa saling menulis ulang object-cache.php. Pilih satu plugin untuk object cache dan matikan fitur object cache di plugin lainnya. Permission juga perlu dicek. Kalau wp-content tidak bisa ditulis oleh user PHP, tombol Enable bisa gagal menyalin file. Menonaktifkan plugin Redis Object Cache biasanya juga ikut menghapus drop-in-nya, jadi setelah mengaktifkannya lagi, drop-in perlu di-enable ulang. Terakhir, hati-hati dengan clone staging. Kalau staging di-clone dari production lengkap dengan wp-config.php dan drop-in, lalu memakai Redis, database index, dan prefix yang sama, kedua situs akan berbagi cache. Akibatnya data staging bisa muncul di production, begitu juga sebaliknya. Ganti prefix atau database index setiap kali membuat clone. Pegangan praktisnya: anggap Redis object cache sebagai tiga lapis yang harus dicek terpisah. Lapis pertama adalah service Redis yang hidup. Lapis kedua adalah PHP situs yang bisa terhubung ke Redis. Lapis ketiga adalah drop-in object-cache.php yang benar-benar dimuat WordPress. Setelah migrasi, restore, ganti plugin cache, atau membuat clone staging, jalankan wp redis status lalu bandingkan keyspace_hits sebelum dan sesudah membuka beberapa halaman. Pengecekan ini cuma makan dua menit dan jauh lebih bisa dipercaya daripada sekadar melihat status plugin yang aktif.