Redis Object Cache WordPress di VPS: Panduan Pengaturan

Fungsi cache objek Redis untuk WordPress

Cache objek Redis untuk WordPress menyimpan hasil kueri database di memori. Dengan begitu, permintaan berikutnya membacanya dari Redis, bukan meminta data yang sama lagi ke MySQL. WordPress sudah memiliki cache objek di core, WP_Object_Cache, tetapi cache tersebut berada di memori PHP dan dibuang saat permintaan berakhir. Sebuah file drop-in menggantinya dengan cache yang berkomunikasi dengan Redis. Dengan demikian, 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 sebuah 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, memasukkan 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 ini digunakan untuk trafik yang tidak dapat ditangani oleh cache halaman: sesi pengguna yang sudah login, keranjang, checkout, dan wp-admin. Pada toko WooCommerce, sebagian besar trafik yang mahal berasal dari area tersebut.

Keduanya dapat digunakan bersamaan, dan pada situs yang sibuk keduanya diperlukan. Pastikan Anda memahami masalah yang sedang diperbaiki. Situs profil perusahaan dengan pembaca anonim memperoleh hampir seluruh peningkatan kecepatannya dari cache halaman. Menambahkan Redis ke situs tersebut hanya memberikan sedikit perubahan.

Sebelum memulai, pahami satu batasan penting. Cache objek tidak membuat kueri yang lambat menjadi cepat. Cache ini menghilangkan pengulangan kueri yang sudah dijalankan. Permintaan pertama setelah cache miss tetap membayar biaya penuh. Jadi, plugin yang menjalankan kueri tanpa indeks tetap menjalankannya satu kali selama masa berlaku cache.

Yang Anda perlukan terlebih dahulu

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

Perintah di bawah ini 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.

Instal 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 menghasilkan PONG. Jika menampilkan 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, yaitu ekstensi C dari PECL. Ekstensi ini lebih cepat daripada Predis, yang ditulis sepenuhnya dalam PHP, dan plugin akan menggunakannya secara otomatis jika tersedia. PHP-FPM memuat ekstensi saat mulai berjalan. Karena itu, ekstensi baru tidak akan dikenali sebelum Anda me-restart pool.

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

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

Per Agustus 2026, Ubuntu 24.04 menyediakan Redis 7.0.15, yang memadai untuk cache objek. 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, Valkey menggunakan protokol yang sama dan semua langkah di bawah ini berlaku tanpa perubahan.

Bind Redis agar tidak dapat diakses pihak lain

Secara default, Redis tidak memiliki kata sandi. Apa pun yang dapat membuka koneksi ke port 6379 dapat membaca semua nilai yang di-cache dan menjalankan FLUSHALL. Instance yang terekspos ke Internet dapat ditemukan pemindai dalam hitungan jam. Karena itu, pengaturan jaringan harus dilakukan sebelum penyetelan.

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 listen, karena file konfigurasi hanya menyatakan konfigurasi dan ss adalah buktinya.

sudo ss -lntp | grep 6379

127.0.0.1:6379 adalah hasil yang diharapkan. 0.0.0.0:6379 berarti Redis menjawab pada antarmuka publik. Perbaiki baris bind, lalu lakukan restart.

Jika PHP dan Redis berjalan pada mesin yang sama, Unix socket lebih baik daripada TCP loopback. Tidak ada stack TCP dalam jalur tersebut. Akses ditentukan oleh permission file, bukan oleh aturan firewall yang mungkin Anda ubah kemudian.

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

Socket tersebut dimiliki oleh user dan group redis. Karena itu, user web harus menjadi anggota group tersebut.

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 menampilkan PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied berarti group belum diterapkan. Periksa id www-data. 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. Jika tidak, salah ketik dapat menonaktifkan kedua jalur sekaligus.

Berapa banyak memori yang harus dialokasikan untuk Redis?

Tentukan nilainya 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 bahwa proses itu sudah dihentikan. Saat itu, situs biasanya sudah tidak dapat diakses.

Mulailah dari total RAM, lalu kurangi kebutuhan komponen lain. MySQL atau MariaDB mencadangkan innodb_buffer_pool_size ditambah buffer untuk setiap koneksi. PHP-FPM menggunakan pm.max_children dikalikan ukuran resident aktual satu worker. Pada situs dengan banyak plugin, nilainya biasanya 64 MB hingga 128 MB. Kernel dan web server memerlukan beberapa ratus megabita. Sisa memori menjadi batas atas Anda, dan Redis mendapat sebagian dari sisa tersebut.

Selanjutnya, 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 kepada MySQL. MySQL 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 setelah restart berikutnya. Ini merupakan jebakan yang sama seperti sysctl -w tanpa konfigurasi permanen. Edit file tersebut, lalu sudo systemctl restart redis-server, kemudian baca kembali nilainya. Sebaiknya tetapkan batas kedua: MemoryMax pada unit systemd mencegah Redis yang salah konfigurasi membuat server tidak dapat berfungsi. Tetapkan nilainya di atas maxmemory, jangan sama dengan nilai tersebut, karena batas cgroup akan menghentikan proses, bukan mengeluarkan key. Jika Redis berjalan dalam container bersama WordPress, gunakan angka yang sama pada batas memori di file Compose Anda. Pertimbangan yang sama juga menentukan pilihan menjalankan database di Docker atau pada host.

Pilih kebijakan eviksi dengan sengaja

Redis baru menggunakan noeviction secara default. Periksa konfigurasi Anda:

redis-cli config get maxmemory-policy

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

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

Satu baris ini menunjukkan mode kegagalan terburuk dalam panduan ini karena situs tidak langsung down. Situs menjadi lebih lambat. Setiap operasi tulis cache gagal, sehingga WordPress kembali ke database untuk mengambil nilai tersebut. WordPress kemudian mencoba menyimpannya lagi pada request berikutnya, tetapi kembali gagal. Situs kini menanggung seluruh beban kerja database semula, ditambah satu round trip ke Redis untuk setiap key. Tidak ada informasi di admin WordPress yang menunjukkan 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 membuang key yang paling lama tidak digunakan ketika memori menipis. Ini sesuai dengan kebutuhan object cache karena setiap nilai di dalamnya merupakan 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 kebutuhan ini. Kebijakan tersebut hanya mempertimbangkan key yang memiliki expiry. Redis mendokumentasikan bahwa kebijakan tersebut berperilaku seperti noeviction jika tidak ada key yang memiliki expiry. 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 merupakan alternatif yang layak jika trafik Anda sangat sering mengakses sejumlah kecil key, karena kebijakan ini melakukan eviksi berdasarkan frekuensi, bukan kebaruan akses. Pilih kebijakan dengan sengaja dan catat alasannya.

Persistence: nonaktifkan kecuali ada alasannya

redis.conf bawaan mengaktifkan snapshot RDB dengan baris seperti save 900 1 dan 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 sekumpulan nilai lama yang akan dipercaya oleh WordPress.

Snapshot juga membutuhkan sumber daya. BGSAVE melakukan fork proses, dan mekanisme copy-on-write dapat meningkatkan penggunaan memori secara tajam saat proses anak menulis. Pada VPS kecil, kondisi ini terlihat di log Redis:

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

Peringatan berikut juga sering muncul saat startup. Redis memberi tahu bahwa fork kemungkinan akan gagal di kemudian hari:

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 pembatasan laju. Dalam kasus tersebut, pisahkan keduanya. Cache memerlukan penghapusan key, sedangkan data durable memerlukan key yang dipertahankan. maxmemory dan eviction berlaku untuk seluruh instance, bukan hanya satu indeks database. Dua instance pada dua socket adalah pilihan yang tepat.

Pasang plugin dan pahami drop-in

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

wp redis enable menampilkan Object cache enabled. jika berhasil. Perintah ini sebenarnya menyalin wp-content/plugins/redis-cache/includes/object-cache.php ke wp-content/object-cache.php. Salinan tersebut 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. Dengan demikian, 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 penyalinan gagal, sehingga wp-content tidak dapat ditulisi oleh pengguna yang menjalankan WP-CLI. A foreign object cache drop-in was found. berarti plugin caching lain sudah menggunakan nama file tersebut. Perbaikannya 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 penyalinan gagal karena permission, tempatkan file tersebut secara manual lalu ubah kepemilikannya kepada pengguna 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 ini menampilkan 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 baris berikut di atas baris yang berbunyi /* That's all, stop editing! */, karena konstanta yang didefinisikan 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. 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 menetapkan masa kedaluwarsa untuk setiap key, dalam detik. Anda tidak memerlukannya bersama allkeys-lru, dan pengaturan ini berguna jika Anda ingin menetapkan batas maksimum berapa lama nilai yang di-cache boleh menjadi kedaluwarsa.

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 keyspace yang sama. Akibatnya, satu situs dapat membaca opsi milik situs lain dan menyajikannya. Berikan setiap situs prefix sendiri.

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

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

Prefix dan indeks tidak memisahkan penggunaan memori. maxmemory dan kebijakan eviction berlaku untuk seluruh instance. Karena itu, situs yang sibuk dapat mengeluarkan key milik situs yang tidak sibuk, dan keduanya tidak melaporkan kejadian tersebut. Situs yang tidak boleh saling memengaruhi memerlukan instance Redis terpisah. Setiap instance memiliki 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 deployment dan tanpa jejak.

Berikan salt yang berbeda untuk 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 atau bukan.

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

Verifikasi, jangan langsung memercayainya

Mulai dengan diagnostik bawaan plugin.

wp redis status

Baris yang paling penting adalah Drop-in. Drop-in: Valid berarti WordPress memuat file milik plugin ini. Drop-in: Not installed berarti proses penyalinan tidak pernah terjadi dan situs tidak memiliki persistent cache, meskipun tampilan admin menunjukkan status hijau. Status melaporkan koneksi, sedangkan Client menyebutkan ekstensi yang digunakan. Di sinilah Anda memastikan bahwa yang digunakan adalah PhpRedis, bukan Predis.

Selanjutnya, tanyakan langsung kepada WordPress core karena komponen ini tidak bergantung pada asumsi plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) berarti core sedang berkomunikasi dengan external object cache.

Kemudian buktikan bahwa key masuk menggunakan prefix yang Anda konfigurasi.

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

dbsize yang terus meningkat saat Anda membuka berbagai halaman situs adalah buktinya. Jumlah key yang tetap 0 meskipun drop-in valid berarti koneksi gagal tanpa pesan yang jelas, atau prefix yang digunakan bukan prefix yang Anda kira.

Terakhir, periksa metrik yang dikumpulkan 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. Bacalah dengan memperhatikan 2 hal. Counter mencakup seluruh instance sejak restart terakhir, sehingga mencampurkan semua situs dan aplikasi yang menggunakannya. Rasio segera setelah flush atau restart juga tidak bermakna karena cache masih terisi. Biarkan sistem berjalan selama 1 hari dengan trafik normal.

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

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

Jalankan pengujian tersebut menggunakan cookie jar yang sudah login, beberapa kali, dengan cache dinonaktifkan (WP_REDIS_DISABLED), lalu aktifkan cache dan ulangi. Selisihnya adalah hasil Anda.

Saat Redis memperlambat WordPress

Instance penuh dengan kebijakan yang salah adalah penyebab utama, yang telah dibahas di atas: OOM command not allowed when used memory > 'maxmemory'. dalam log, serta situs yang membayar database dan cache sekaligus.

Redis pada host lain adalah penyebab kedua. WordPress menjalankan ratusan panggilan object cache dalam satu request. Jika satu request menjalankan 500 panggilan dan setiap round trip memerlukan 1 ms, waktu tunggunya mencapai setengah detik. Socket lokal tidak mengalami latensi ini. Jalankan Redis pada mesin yang sama, atau pada jaringan privat dengan latensi di bawah 1 ms.

Tabel opsi autoload yang sangat besar adalah penyebab ketiga, dan ini umum pada situs lama. WordPress menyimpan semua opsi autoload sebagai satu key, sehingga data berukuran megabyte melewati 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 perkiraan yang terlalu rendah pada instalasi modern. Ukuran di atas 1 megabyte harus diperbaiki pada tabel opsi, bukan pada Redis.

Restart mengosongkan semuanya. Karena itu, beberapa menit setelah systemctl restart redis-server seluruh request menjadi cache miss dan menjalankan operasi database. Lakukan restart saat trafik rendah. Object cache juga tidak mencegah wp-cron.php berjalan saat halaman dimuat oleh pengunjung. Ini merupakan sumber request lambat lainnya: pindahkan WP-Cron ke tugas cron sistem yang sebenarnya saat Anda memperbaikinya.

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 dan digunakan pada plugin yang lebih baru benar-benar dapat menyebabkan 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. Karena itu, 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. Karena itu, angka tersebut seharusnya mendekati pm.max_children, bukan melebihinya hingga satu orde besarnya. Jika tidak, ada sesuatu yang membuka koneksi tetapi 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. Cara ini selalu lebih ringan daripada menjalankan WordPress dengan object cache yang sudah terisi. Object cache menangani permintaan yang harus dilewati oleh page cache: pengguna yang login, keranjang, checkout, dan wp-admin. Pada toko atau situs membership, keduanya layak digunakan. Pada situs yang pengunjungnya tidak pernah login, page cache melakukan hampir seluruh pekerjaan.

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

Tentukan 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 lakukan penyesuaian. Satu situs WordPress biasanya menggunakan puluhan megabyte, jadi maxmemory sebesar 256 MB merupakan titik awal yang longgar pada server 4 GB.

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

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

Bisakah beberapa situs WordPress menggunakan satu server Redis?

Bisa, dengan hati-hati. Berikan WP_REDIS_PREFIX yang unik untuk setiap situs agar nama key tidak bertabrakan, serta index WP_REDIS_DATABASE terpisah agar penghapusan seluruh cache satu situs tidak mengosongkan cache situs lain. Hal yang tetap digunakan bersama adalah memori: maxmemory dan eviction berlaku untuk seluruh instance. Akibatnya, 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. 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 dengan benar dan melaporkan Object cache disabled.. Menghapusnya secara manual merupakan langkah darurat yang tepat jika Redis mati atau bermasalah dan Anda tidak dapat mengakses admin.