Redis Object Cache WordPress di VPS: Panduan Konfigurasi

Fungsi cache objek Redis untuk WordPress

Cache objek Redis untuk WordPress menyimpan hasil kueri database di memori. Dengan demikian, permintaan berikutnya membacanya dari Redis, bukan meminta MySQL menjalankan kueri yang sama lagi. WordPress sudah memiliki cache objek di core, WP_Object_Cache, tetapi cache tersebut berada di memori PHP dan dibuang ketika permintaan berakhir. File drop-in menggantinya dengan cache yang berkomunikasi dengan Redis, sehingga cache tetap tersedia dari satu permintaan ke permintaan berikutnya.

Caching objek bukan caching halaman. Perbedaan ini menentukan apakah panduan ini relevan bagi Anda. Cache halaman menyimpan HTML akhir dari suatu URL dan menyajikannya kembali tanpa menjalankan PHP sama sekali. Cara ini lebih cepat daripada apa pun yang dapat dilakukan Redis, dan berfungsi bagi pengunjung yang belum login. Saat seseorang login, menambahkan item ke keranjang, atau membuka admin, cache halaman tidak lagi digunakan dan WordPress menjalankan seluruh permintaan: bootstrap, plugin, dan kueri. Cache objek membuat permintaan tersebut lebih ringan. Cache objek ditujukan untuk trafik yang tidak dapat ditangani oleh cache halaman: sesi pengguna yang login, keranjang, checkout, dan wp-admin. Pada toko WooCommerce, sebagian besar trafik yang mahal berasal dari aktivitas tersebut.

Keduanya dapat digunakan bersama, dan pada situs yang sibuk keduanya diperlukan. Pastikan Anda memahami masalah yang sedang diperbaiki. Situs presentasi dengan pembaca anonim memperoleh hampir seluruh peningkatan kecepatannya dari cache halaman. Menambahkan Redis ke situs seperti itu hanya menghasilkan sedikit perubahan.

Ada satu batasan penting yang perlu dipahami sebelum memulai. Cache objek tidak membuat kueri yang lambat menjadi cepat. Cache objek hanya menghilangkan pengulangan kueri yang sudah pernah dijalankan. Permintaan pertama setelah cache miss tetap membayar biaya penuh. Jadi, plugin yang menjalankan kueri tanpa indeks tetap akan menjalankannya satu kali selama masa berlaku cache.

Hal yang diperlukan terlebih dahulu

• Linux VPS dengan shell dan sudo. Control panel tidak diperlukan.
• WordPress yang disajikan oleh PHP-FPM, misalnya pada stack LAMP di Ubuntu 24.04.
• WP-CLI pada server. Setiap langkah di sini memiliki padanan pada layar admin, tetapi versi shell lebih cepat.
• Redis pada mesin yang sama dengan PHP. Latensi adalah tujuan utama, dan satu lompatan jaringan dapat menghilangkan manfaatnya.

Perintah di bawah ditulis untuk Ubuntu 24.04 dengan PHP 8.3 dan pengguna web www-data. Sesuaikan versi PHP dan pengguna dengan server Anda. Jalankan perintah wp dari direktori WordPress, yaitu direktori yang berisi wp-config.php.

Install Redis dan ekstensi PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping seharusnya menjawab PONG. Jika hasilnya Could not connect to Redis at 127.0.0.1:6379: Connection refused, server tidak berjalan. Baca systemctl status redis-server sebelum melanjutkan.

php-redis adalah PhpRedis, ekstensi C dari PECL. Ekstensi ini lebih cepat daripada Predis, yang seluruhnya ditulis dalam PHP, dan plugin akan menggunakannya secara otomatis jika tersedia. PHP-FPM memuat ekstensi saat dijalankan. Karena itu, ekstensi baru tidak akan terdeteksi sampai Anda me-restart pool.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Berhati-hatilah dengan pemeriksaan terakhir tersebut: php -m menampilkan modul PHP pada command line, sedangkan FPM dapat memuat kumpulan modul yang berbeda. Pemeriksaan yang menentukan adalah diagnostik milik plugin, yang dijelaskan lebih lanjut di bawah.

Per Agustus 2026, Ubuntu 24.04 menyediakan Redis 7.0.15. Versi ini sesuai untuk object cache. Jika Anda menginginkan rilis terbaru, Redis menyediakan repositori APT sendiri.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Jika distribusi Anda menyediakan Valkey, yaitu fork yang dimulai setelah perubahan lisensi pada 2024, protokolnya tetap sama dan semua langkah di bawah berlaku tanpa perubahan.

Batasi Redis agar tidak dapat diakses oleh pihak lain

Redis tidak memiliki kata sandi secara default. Apa pun yang dapat membuka koneksi ke port 6379 dapat membaca setiap nilai cache dan menjalankan FLUSHALL. Instance yang terekspos ke Internet biasanya ditemukan oleh pemindai dalam hitungan jam, sehingga pengaturan jaringan harus dilakukan sebelum tuning.

Buka /etc/redis/redis.conf dan pastikan baris berikut ada:

bind 127.0.0.1 -::1
protected-mode yes

Kemudian periksa apa yang benar-benar sedang listening, karena file konfigurasi hanya menyatakan pengaturan dan ss adalah buktinya.

sudo ss -lntp | grep 6379

127.0.0.1:6379 adalah hasil yang diinginkan. 0.0.0.0:6379 berarti Redis menjawab pada interface publik: perbaiki baris bind lalu lakukan restart.

Jika PHP dan Redis berada pada server yang sama, Unix socket lebih baik daripada TCP loopback. Tidak ada TCP stack dalam jalurnya, dan akses ditentukan oleh permission file, bukan oleh aturan firewall yang mungkin Anda ubah nanti.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Socket tersebut dimiliki oleh user dan group redis, sehingga user web harus ditambahkan ke group itu.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Perintah tersebut juga harus mencetak PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied berarti group belum diterapkan. Periksa id www-data, dan ingat bahwa PHP-FPM yang sedang berjalan mempertahankan group yang dimilikinya saat start. Karena itu, restart tercantum dalam daftar. Biarkan TCP tetap aktif sampai socket terbukti berfungsi, karena typo dapat menonaktifkan kedua jalur sekaligus.

Berapa besar memori yang harus dialokasikan untuk Redis?

Turunkan jumlahnya berdasarkan server Anda sendiri. Redis tanpa maxmemory akan terus bertambah hingga kernel kehabisan memori dan OOM killer menghentikan sebuah proses, biasanya proses terbesar. Pada server WordPress, proses tersebut sering kali adalah MySQL. journalctl -k | grep -i "out of memory" menunjukkan penghentian itu setelah terjadi, sedangkan situs sudah tidak dapat diakses.

Mulai dari total RAM, lalu kurangi kebutuhan komponen lain. MySQL atau MariaDB mencadangkan innodb_buffer_pool_size, ditambah buffer per koneksi. PHP-FPM menggunakan pm.max_children dikalikan ukuran resident sebenarnya dari satu worker, yang umumnya 64 MB hingga 128 MB pada situs dengan banyak plugin. Kernel dan web server memerlukan beberapa ratus megabyte. Sisa memori menjadi batas maksimum Anda, dan Redis mendapatkan sebagian dari sisa tersebut.

Sekarang lakukan pengukuran, bukan perkiraan. Setelah satu hari menerima trafik nyata:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Jika used_memory_human jauh di bawah batas Anda, turunkan batas tersebut dan kembalikan RAM ke MySQL agar dapat memanfaatkannya dengan lebih baik. Jika nilainya terus mencapai batas dan evicted_keys meningkat sepanjang hari, naikkan batas tersebut. Tetapkan nilainya di /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb langsung berlaku saat ini dan akan hilang pada restart berikutnya. Ini merupakan jebakan yang sama seperti sysctl -w tanpa konfigurasi lain. Edit file tersebut, lalu sudo systemctl restart redis-server, kemudian baca kembali nilainya. Batas kedua juga berguna: MemoryMax pada unit systemd mencegah Redis yang salah konfigurasi menghentikan seluruh server. Tetapkan nilainya di atas maxmemory, jangan sama dengan nilai tersebut, karena batas cgroup akan menghentikan proses, bukan mengeluarkan key. Jika Redis berjalan dalam container yang sama dengan WordPress, angka yang sama harus dimasukkan ke dalam batas memori pada file Compose, dan pertimbangan yang sama menentukan pilihan menjalankan database di Docker atau pada host.

Pilih kebijakan eviction secara sengaja

Redis yang baru diinstal menggunakan noeviction secara default. Periksa konfigurasi Anda:

redis-cli config get maxmemory-policy

Dengan noeviction, instance yang penuh berhenti menerima operasi tulis dan mengembalikan pesan berikut:

(error) OOM command not allowed when used memory > 'maxmemory'.

Satu baris tersebut adalah mode kegagalan terburuk dalam panduan ini karena situs tidak langsung down. Situs menjadi lebih lambat. Setiap operasi penulisan cache gagal, sehingga WordPress kembali ke database untuk mengambil nilai tersebut, lalu mencoba menyimpannya lagi pada request berikutnya dan kembali gagal. Situs kini harus menjalankan seluruh pekerjaan database semula, ditambah satu round trip ke Redis untuk setiap key. Tidak ada informasi dalam admin WordPress yang memberi tahu bahwa hal ini sedang terjadi. String tersebut muncul di error log PHP. Jadi, lakukan grep untuk OOM command not allowed ketika situs menjadi lebih lambat setelah Anda menambahkan cache.

allkeys-lru adalah default yang tepat untuk kasus ini. Redis menghapus key yang paling lama tidak digunakan ketika memori terbatas. Ini sesuai dengan kebutuhan object cache karena setiap nilai di dalamnya adalah salinan data yang masih ada di MySQL. Kehilangan satu key menimbulkan biaya satu query. Menolak operasi tulis menimbulkan biaya setiap query, pada setiap request, sampai seseorang menyadarinya.

Hindari kebijakan volatile-* untuk keperluan ini. Kebijakan tersebut hanya mempertimbangkan key yang memiliki waktu kedaluwarsa, dan Redis mendokumentasikan bahwa perilakunya menjadi seperti noeviction ketika tidak ada key yang memilikinya. WordPress menyimpan sebagian besar entri object cache tanpa TTL. Karena itu, volatile-lru pada object cache dapat memenuhi memori lalu mulai menolak operasi tulis. allkeys-lfu adalah alternatif yang layak jika trafik Anda sangat sering mengakses sejumlah kecil key, karena kebijakan tersebut melakukan eviction berdasarkan frekuensi, bukan waktu terakhir digunakan. Pilih salah satunya secara sengaja dan catat alasannya.

Persistence: biarkan nonaktif kecuali diperlukan

Paket redis.conf mengaktifkan snapshot RDB dengan baris seperti save 900 1, tetapi menonaktifkan file append-only. Untuk cache objek murni, snapshot tidak memberikan manfaat. Data tersebut dapat dibuat ulang, dan cache yang dipulihkan dari file berusia dua puluh menit berisi nilai kedaluwarsa yang akan dipercaya oleh WordPress.

Snapshot juga menggunakan sumber daya. BGSAVE melakukan fork pada proses, dan mekanisme copy-on-write dapat menyebabkan penggunaan memori meningkat tajam saat proses anak menulis data. Pada VPS kecil, hal ini terlihat di log Redis:

Can't save in background: fork: Cannot allocate memory

Peringatan berikut juga sering muncul saat startup. Peringatan ini menunjukkan bahwa Redis memperkirakan fork kemungkinan gagal pada waktu berikutnya:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Untuk menonaktifkan snapshot, tetapkan jadwal save kosong di /etc/redis/redis.conf, lakukan restart, lalu pastikan nilainya kembali kosong.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Pertahankan persistence hanya jika instance yang sama menyimpan sesuatu yang tidak dapat dibuat ulang, seperti antrean pekerjaan atau penghitung rate limit. Dalam kasus tersebut, pisahkan keduanya. Cache memerlukan key yang dapat dieviction, sedangkan data persisten memerlukan key yang tetap disimpan. maxmemory serta eviction berlaku untuk seluruh instance, bukan hanya satu indeks database. Dua instance pada dua socket adalah solusi yang tepat.

Instal plugin dan pahami drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable mencetak Object cache enabled. jika berhasil. Perintah tersebut sebenarnya menyalin wp-content/plugins/redis-cache/includes/object-cache.php ke wp-content/object-cache.php. Salinan itu adalah drop-in, dan drop-in inilah yang menjalankan fungsinya. WordPress memuat wp-content/object-cache.php sangat awal, sebelum kode plugin apa pun dijalankan. Karena itu, cache tersedia untuk seluruh request. Plugin yang aktif tanpa drop-in tidak menyimpan cache apa pun.

Pesan kegagalan menunjukkan bagian mana yang bermasalah. Object cache could not be enabled. berarti proses penyalinan gagal, sehingga wp-content tidak dapat ditulisi oleh user yang menjalankan WP-CLI. A foreign object cache drop-in was found. berarti plugin caching lain sudah menggunakan nama file tersebut, dan solusinya adalah wp redis update-dropin. Pesan yang diakhiri Redis server is unreachable: lalu diikuti error dari client berarti pengaturan koneksi salah. Periksa kembali redis-cli ping.

Jika proses penyalinan gagal karena masalah permission, letakkan file tersebut secara manual dan ubah kepemilikannya ke user web.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Menghapus plugin tidak menghapus drop-in. Jalankan wp redis disable terlebih dahulu. Perintah tersebut mencetak Object cache disabled. dan menghapus file tersebut. Jika Anda menghapus direktori plugin sementara drop-in tetap ada, situs akan terus menjalankan kode cache lama tanpa plugin yang dapat memperbaruinya.

Pengaturan koneksi di wp-config.php

Tambahkan ini di atas baris yang berbunyi /* That's all, stop editing! */, karena konstanta yang ditetapkan setelahnya sudah terlambat.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Untuk Unix socket, tetapkan skema dan path-nya. Host dan port kemudian diabaikan.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL memaksa setiap key kedaluwarsa dalam hitungan detik. Anda tidak memerlukannya bersama allkeys-lru, dan pengaturan ini berguna jika Anda ingin menetapkan batas maksimum seberapa lama nilai cache boleh menjadi usang.

Satu Redis, beberapa situs: prefix dan database

Secara default, Redis menyediakan enam belas database bernomor, dengan satu keyspace datar di dalam setiap database. Dua instalasi WordPress yang diarahkan ke database 0 tanpa prefix akan menulis nama key yang sama ke ruang yang sama. Akibatnya, satu situs dapat membaca opsi situs lain dan menyajikannya. Berikan prefix terpisah untuk setiap situs.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Prefix memisahkan nama key. Indeks database memisahkan keyspace, yang penting saat proses flush: mengosongkan satu indeks tidak memengaruhi indeks lainnya. Plugin juga mendokumentasikan WP_REDIS_SELECTIVE_FLUSH, yang hanya menghapus key yang cocok dengan prefix Anda, bukan seluruh database, tetapi harus memindai key tersebut.

Prefix dan indeks tidak memisahkan penggunaan memori. maxmemory dan kebijakan eviction berlaku untuk seluruh instance. Karena itu, situs yang sibuk dapat mengeluarkan key situs yang tidak sibuk, dan keduanya tidak melaporkan kondisi tersebut. Situs yang tidak boleh saling memengaruhi memerlukan instance Redis terpisah, masing-masing dengan socket dan batasnya sendiri.

Jauhkan staging dari cache production

Situs staging biasanya merupakan salinan file dan database production. Artinya, staging juga menyalin wp-config.php dengan prefix dan indeks database yang sama. Jika diarahkan ke Redis yang sama, staging akan menulis key production dengan nilai staging. Harga pengujian atau opsi yang diubah kemudian dapat muncul di situs live tanpa deploy dan tanpa jejak.

Pisahkan salt setiap environment secara manual. Di wp-config.php milik staging:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Lebih baik lagi, gunakan instance Redis khusus untuk staging atau jangan gunakan object cache sama sekali. define( 'WP_REDIS_DISABLED', true ); menonaktifkan cache saat runtime dan membiarkan drop-in tetap terpasang. Ini juga merupakan cara tercepat untuk membuktikan apakah bug disebabkan oleh cache.

Tutorial lama menggunakan WP_CACHE_KEY_SALT untuk tujuan ini. README plugin tersebut menandai constant itu sebagai deprecated dan menggantinya dengan WP_REDIS_PREFIX. Karena itu, gunakan nama baru tersebut.

Verifikasi, jangan hanya mempercayainya

Mulai dengan diagnostik bawaan plugin.

wp redis status

Baris yang paling penting adalah Drop-in. Drop-in: Valid berarti WordPress memuat file plugin ini. Drop-in: Not installed berarti penyalinan tidak pernah terjadi dan situs tidak memiliki cache persisten, meskipun tampilan admin terlihat normal. Status melaporkan koneksi, sedangkan Client menunjukkan ekstensi yang digunakan. Di sini, pastikan yang digunakan adalah PhpRedis, bukan Predis.

Selanjutnya, tanyakan langsung kepada core WordPress karena core tidak bergantung pada informasi dari plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) berarti core sedang berkomunikasi dengan cache objek eksternal.

Kemudian buktikan bahwa key masuk, menggunakan prefix yang Anda konfigurasi.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

Nilai dbsize yang meningkat saat Anda menjelajahi situs adalah buktinya. Jika jumlah key tetap nol meskipun drop-in valid, koneksi mungkin gagal secara diam-diam, atau prefix yang digunakan bukan prefix yang Anda kira.

Terakhir, periksa metrik yang disediakan Redis.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Rasio hit adalah keyspace_hits / (keyspace_hits + keyspace_misses), dan dokumentasi Redis memberikan rumus tersebut. Perhatikan dua hal. Counter mencakup seluruh instance sejak restart terakhir, sehingga mencampur semua situs dan aplikasi yang menggunakannya. Selain itu, rasio sesaat setelah flush atau restart tidak bermakna karena cache masih diisi. Biarkan sistem berjalan selama satu hari dengan trafik normal.

Jangan bandingkan angka Anda dengan hit rate atau jumlah query yang dipublikasikan perusahaan hosting. Angka tersebut menggambarkan situs dan kumpulan plugin mereka. Angka yang penting adalah angka milik Anda sendiri, yang diukur sebelum dan sesudah pada halaman yang tidak dapat disajikan oleh page cache.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Jalankan pengujian tersebut dengan cookie jar yang sudah login, beberapa kali, dengan cache dimatikan (WP_REDIS_DISABLED), lalu dengan cache diaktifkan. Selisihnya adalah hasil Anda.

Saat Redis memperlambat WordPress

Instance penuh dengan policy yang salah adalah penyebab utama, seperti yang dibahas di atas: OOM command not allowed when used memory > 'maxmemory'. dalam log, sementara situs membayar biaya database dan cache.

Redis pada host lain adalah penyebab kedua. WordPress melakukan ratusan pemanggilan object cache dalam satu request. Jika sebuah request melakukan 500 pemanggilan dan setiap round trip memerlukan 1 ms, waktu tunggunya mencapai setengah detik. Socket lokal tidak memiliki tambahan waktu tunggu tersebut. Jalankan Redis pada mesin yang sama, atau pada jaringan privat dengan latensi di bawah satu milidetik. Seberapa besar keuntungan dari kernel pada mesin yang sama merupakan persoalan terpisah: penjadwalan yang menyadari cache dan ditambahkan di Linux 7.2 berupaya menempatkan proses yang sering berkomunikasi, seperti PHP-FPM dan Redis, pada core yang berbagi cache. Guest VPS memperoleh manfaat ini lebih kecil daripada bare metal.

Tabel options yang sangat besar dan dimuat otomatis adalah penyebab ketiga. Hal ini umum pada situs lama. WordPress menyimpan semua options yang dimuat otomatis sebagai satu key, sehingga data berukuran satu megabyte melintasi koneksi pada setiap request. Ukur ukurannya:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 menambahkan nilai autoload baru. Karena itu, query lama yang hanya mencocokkan 'yes' akan menghasilkan angka yang lebih rendah pada instalasi modern. Ukuran di atas satu megabyte merupakan masalah yang harus diperbaiki pada tabel options, bukan pada Redis.

Restart mengosongkan semuanya. Karena itu, beberapa menit setelah systemctl restart redis-server seluruh pemanggilan menjadi miss dan seluruh pekerjaan database harus dilakukan ulang. Lakukan restart saat trafik rendah. Object cache juga tidak menghentikan wp-cron.php berjalan saat halaman dimuat pengunjung. Ini merupakan sumber request lambat tersendiri: pindahkan WP-Cron ke system cron job yang sebenarnya selagi Anda memperbaiki bagian ini.

Pemeliharaan

Jalankan flush setelah deploy yang mengubah opsi atau kode tema dengan wp cache flush. Jalankan wp redis update-dropin setelah pembaruan plugin jika drop-in tidak memperbarui dirinya sendiri, karena drop-in dari versi plugin yang lebih lama yang digunakan pada plugin versi lebih baru merupakan sumber nyata perilaku yang tidak semestinya. Pantau server aktif dengan redis-cli --stat, yang mencetak satu baris setiap detik. redis-cli monitor mencetak setiap perintah dan menggunakan CPU secara signifikan pada instance yang sibuk, jadi gunakan selama beberapa detik saat mereproduksi masalah, lalu hentikan.

Ada satu angka terakhir yang perlu diketahui: redis-cli info clients melaporkan connected_clients. PHP-FPM mempertahankan satu koneksi untuk setiap worker, jadi angka tersebut seharusnya mengikuti pm.max_children, bukan melebihinya hingga satu tingkat besaran. Jika tidak, berarti ada sesuatu yang membuka koneksi dan tidak menutupnya.

FAQ

Apakah saya masih memerlukan page cache jika menjalankan object cache Redis?

Ya, untuk trafik anonim. Page cache menyajikan HTML tersimpan tanpa menjalankan PHP, yang selalu lebih ringan daripada menjalankan WordPress dengan object cache yang sudah terisi. Object cache menangani permintaan yang harus dilewati oleh page cache: pengguna yang sudah login, keranjang, checkout, dan wp-admin. Pada toko atau situs keanggotaan, keduanya layak digunakan. Pada situs yang pengunjungnya tidak pernah login, page cache menangani hampir seluruh beban.

Berapa banyak memori yang harus saya alokasikan untuk Redis pada WordPress?

Hitung berdasarkan server Anda sendiri, bukan dengan menyalin angka. Ambil total RAM, kurangi buffer pool MySQL dan buffer per koneksi, kurangi pm.max_children dikalikan ukuran resident satu worker PHP-FPM, lalu kurangi beberapa ratus megabyte untuk kernel dan web server. Alokasikan sebagian sisa tersebut untuk Redis, kemudian periksa used_memory_human di redis-cli info memory setelah satu hari menerima trafik dan sesuaikan nilainya. Satu situs WordPress biasanya menggunakan puluhan megabyte, sehingga maxmemory sebesar 256 MB merupakan titik awal yang longgar pada server dengan RAM 4 GB.

Mengapa situs saya menjadi lebih lambat setelah mengaktifkan object cache Redis?

Penyebab yang umum adalah instance penuh dan menggunakan kebijakan noeviction. Redis menolak penulisan baru dan mengembalikan OOM command not allowed when used memory > 'maxmemory'., sehingga WordPress kembali menggunakan database untuk setiap nilai dan tetap menanggung round trip Redis yang tidak menghasilkan apa-apa. Periksa redis-cli config get maxmemory-policy, tetapkan allkeys-lru, dan pastikan maxmemory tidak terlalu kecil. Penyebab umum lainnya adalah server Redis berada pada host jarak jauh, sehingga ratusan round trip untuk setiap permintaan terakumulasi, serta nilai opsi autoload berukuran beberapa megabyte yang dikirim melalui koneksi pada setiap permintaan.

Dapatkah beberapa situs WordPress menggunakan satu server Redis bersama-sama?

Bisa, dengan pengaturan yang cermat. Berikan WP_REDIS_PREFIX yang unik untuk setiap situs agar nama key tidak bertabrakan, serta indeks WP_REDIS_DATABASE yang terpisah agar penghapusan cache satu situs tidak mengosongkan cache situs lain. Hal yang tetap digunakan bersama adalah memori: maxmemory dan eviction berlaku untuk seluruh instance, sehingga situs yang sibuk dapat menghapus key milik situs yang tidak sibuk. Situs yang tidak boleh saling memengaruhi memerlukan instance Redis terpisah dengan batasnya masing-masing.

Apakah aman menghapus wp-content/object-cache.php?

Ya. File tersebut adalah drop-in, bukan bagian dari WordPress core, dan menghapusnya mengembalikan WordPress ke cache bawaan per permintaan. Situs tetap berfungsi dan hanya menjalankan lebih banyak kueri database. Sebaiknya gunakan wp redis disable, yang menghapus file tersebut dengan bersih dan melaporkan Object cache disabled.. Menghapusnya secara manual merupakan langkah darurat yang tepat jika Redis tidak aktif atau bermasalah dan Anda tidak dapat mengakses admin.