Cara Setup Redis Object Cache WordPress di VPS

Fungsi cache objek Redis untuk WordPress

Cache objek Redis untuk WordPress menyimpan hasil pertanyaan pangkalan data di dalam memori, supaya permintaan seterusnya membaca data tersebut daripada Redis dan bukannya bertanya kepada MySQL sekali lagi. WordPress sudah mempunyai cache objek dalam terasnya, WP_Object_Cache, tetapi ia berada dalam memori PHP dan akan dibuang apabila permintaan tamat. Fail drop-in menggantikannya dengan fail yang berhubung dengan Redis, supaya cache tersebut kekal daripada satu permintaan ke permintaan yang lain.

Cache objek bukanlah cache halaman, dan perbezaan ini menentukan sama ada panduan ini berguna untuk anda. Cache halaman menyimpan HTML lengkap bagi sesuatu URL dan menyajikannya semula tanpa menjalankan PHP langsung. Itu lebih pantas daripada apa sahaja yang boleh dilakukan oleh Redis, dan ia berfungsi untuk pelawat yang tidak log masuk. Sebaik sahaja seseorang log masuk, memasukkan item ke dalam troli, atau membuka admin, cache halaman akan diketepikan dan WordPress menjalankan keseluruhan permintaan: bootstrap, pemalam, dan pertanyaan. Cache objek menjadikan permintaan tersebut lebih ringan. Ia adalah alat untuk trafik yang tidak dapat disentuh oleh cache halaman: sesi log masuk, troli, daftar keluar, dan wp-admin. Pada kedai WooCommerce, itu adalah sebahagian besar daripada trafik yang memakan sumber.

Kedua-duanya boleh disusun, dan pada tapak yang sibuk, kedua-duanya diperlukan. Pastikan anda jelas tentang masalah yang ingin diselesaikan. Tapak brosur dengan pembaca tanpa nama mendapat hampir semua kelajuannya daripada cache halaman, dan menambah Redis padanya tidak membawa banyak perubahan.

Satu had yang jujur sebelum anda bermula. Cache objek tidak menjadikan pertanyaan yang perlahan menjadi pantas. Ia menghapuskan pengulangan pertanyaan yang telah pun dijalankan. Permintaan pertama selepas cache terlepas (miss) akan menanggung kos penuh, jadi pemalam yang menjalankan pertanyaan tanpa indeks masih akan menjalankannya sekali bagi setiap jangka hayat cache.

Keperluan awal

• Sebuah VPS Linux dengan shell dan sudo. Tiada panel kawalan diperlukan.
• WordPress yang dihoskan oleh PHP-FPM, contohnya pada stack LAMP di Ubuntu 24.04.
• WP-CLI pada pelayan. Setiap langkah di sini mempunyai padanan pada skrin pentadbir, namun versi shell adalah lebih pantas.
• Redis pada mesin yang sama dengan PHP. Latensi adalah tujuan utama, dan lompatan rangkaian akan menjejaskan prestasi tersebut.

Perintah di bawah ditulis untuk Ubuntu 24.04 dengan PHP 8.3 dan pengguna web www-data. Laraskan versi PHP dan pengguna mengikut tetapan pelayan anda. Jalankan perintah wp dari direktori WordPress anda, iaitu direktori yang mengandungi wp-config.php.

Memasang Redis dan sambungan PHP

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

redis-cli ping sepatutnya menjawab PONG. Jika ia mencetak Could not connect to Redis at 127.0.0.1:6379: Connection refused, pelayan tidak berjalan, jadi baca systemctl status redis-server sebelum meneruskan langkah seterusnya.

php-redis ialah PhpRedis, sambungan C daripada PECL. Ia lebih pantas daripada Predis, yang merupakan PHP tulen, dan pemalam akan menggunakannya secara automatik apabila ia tersedia. PHP-FPM memuatkan sambungan semasa permulaan, jadi sambungan baharu tidak akan kelihatan sehingga anda memulakan semula pool tersebut.

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

Berhati-hati dengan semakan terakhir itu: php -m menyenaraikan modul bagi PHP baris perintah, manakala FPM boleh memuatkan set yang berbeza. Semakan yang penting ialah diagnostik pemalam itu sendiri, yang terdapat di bahagian bawah.

Sehingga Ogos 2026, Ubuntu 24.04 membekalkan Redis 7.0.15, yang mencukupi untuk cache objek. Jika anda mahukan keluaran terkini, Redis menerbitkan repositori APT mereka 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 pengedaran anda membekalkan Valkey, iaitu fork yang dimulakan selepas perubahan lesen tahun 2024, ia menggunakan protokol yang sama dan semua arahan di bawah terpakai tanpa perubahan.

Bind Redis supaya tiada pihak lain boleh mencapainya

Redis tidak mempunyai kata laluan secara lalai. Sesiapa sahaja yang boleh membuka sambungan ke port 6379 boleh membaca setiap nilai yang dicache dan menjalankan FLUSHALL. Instans yang terdedah kepada internet akan ditemui oleh pengimbas dalam masa beberapa jam, jadi tetapan rangkaian perlu diutamakan sebelum penalaan.

Buka /etc/redis/redis.conf dan sahkan baris-baris ini:

bind 127.0.0.1 -::1
protected-mode yes

Kemudian periksa apa yang sebenarnya sedang mendengar, kerana fail konfigurasi hanyalah satu tuntutan dan ss adalah buktinya.

sudo ss -lntp | grep 6379

127.0.0.1:6379 adalah apa yang anda mahukan. 0.0.0.0:6379 bermaksud Redis sedang menjawab pada antaramuka awam: betulkan baris bind dan mulakan semula.

Apabila PHP dan Redis berada pada mesin yang sama, soket Unix adalah lebih baik daripada TCP loopback. Tiada stack TCP dalam laluan tersebut, dan akses ditentukan oleh keizinan fail dan bukannya oleh peraturan firewall yang mungkin anda ubah kemudian.

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

Soket tersebut dimiliki oleh pengguna dan kumpulan redis, jadi pengguna web perlu menyertai kumpulan 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 itu juga mesti memaparkan PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied bermaksud kumpulan tersebut tidak berkuat kuasa. Periksa id www-data, dan ingat bahawa PHP-FPM yang sedang berjalan mengekalkan kumpulan yang dimilikinya semasa permulaan, itulah sebabnya langkah memulakan semula disertakan dalam senarai. Biarkan TCP diaktifkan sehingga soket terbukti berfungsi, atau kesilapan menaip akan melumpuhkan kedua-dua laluan serentak.

Berapakah jumlah memori yang perlu diperuntukkan kepada Redis?

Tentukan angka tersebut berdasarkan pelayan anda sendiri. Redis tanpa maxmemory akan berkembang sehingga kernel kehabisan memori dan OOM killer menamatkan sesuatu proses, biasanya proses yang paling besar, yang pada pelayan WordPress sering kali merupakan MySQL. journalctl -k | grep -i "out of memory" menunjukkan proses yang ditamatkan tersebut selepas kejadian, dan laman web sudah pun tergendala pada ketika itu.

Mulakan dengan jumlah RAM keseluruhan dan lakukan penolakan. MySQL atau MariaDB menempah innodb_buffer_pool_size ditambah dengan penimbal (buffer) bagi setiap sambungan. PHP-FPM menelan kos pm.max_children didarab dengan saiz resident sebenar bagi satu worker, biasanya 64 MB hingga 128 MB pada laman web yang sarat dengan plugin. Kernel dan pelayan web memerlukan beberapa ratus megabait. Baki yang tinggal adalah had maksimum anda, dan Redis akan menerima sebahagian daripadanya.

Sekarang, lakukan pengukuran dan bukannya meneka. Selepas sehari menerima trafik sebenar:

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

Jika used_memory_human berada jauh di bawah had anda, rendahkan had tersebut dan berikan semula RAM kepada MySQL, yang akan menggunakannya dengan lebih baik. Jika ia mencecah had dan evicted_keys meningkat sepanjang hari, naikkan had tersebut. Tetapkan nilai dalam /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb terpakai serta-merta dan akan dilupakan pada but semula seterusnya, perangkap yang sama seperti sysctl -w biasa. Edit fail tersebut, kemudian sudo systemctl restart redis-server, dan baca semula nilainya. Mempunyai lapisan perlindungan kedua adalah berbaloi: had MemoryMax pada unit systemd menghalang Redis yang tersalah konfigurasi daripada menjatuhkan pelayan. Tetapkan ia melebihi maxmemory, jangan sesekali sama dengannya, kerana had cgroup akan menamatkan proses tersebut dan bukannya mengeluarkan kunci (evicting a key). Jika Redis berjalan dalam bekas (container) di samping WordPress, angka yang sama perlu diletakkan dalam had memori dalam fail Compose anda, dan pertimbangan yang sama mendorong pilihan untuk menjalankan pangkalan data dalam Docker atau pada hos.

Pilih polisi pengusiran (eviction policy) secara sengaja

Redis baharu menggunakan noeviction sebagai tetapan lalai. Semak tetapan anda:

redis-cli config get maxmemory-policy

Di bawah noeviction, instans yang penuh akan berhenti menerima penulisan dan menjawab dengan ralat ini:

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

Satu baris ralat tersebut merupakan mod kegagalan paling buruk dalam panduan ini, kerana laman web tidak terhenti sepenuhnya. Ia hanya menjadi perlahan. Setiap penulisan cache gagal, jadi WordPress kembali ke pangkalan data untuk mendapatkan nilai tersebut, kemudian cuba menyimpannya semula pada permintaan seterusnya dan gagal lagi. Laman web kini menanggung semua beban kerja pangkalan data asal ditambah dengan satu pusingan ke Redis bagi setiap kunci. Tiada apa-apa dalam admin WordPress yang memberitahu anda perkara ini sedang berlaku. Rentetan ralat tersebut muncul dalam log ralat PHP, jadi gunakan grep untuk OOM command not allowed apabila laman web menjadi perlahan selepas anda menambah cache.

allkeys-lru ialah tetapan lalai yang tepat di sini. Redis akan membuang kunci yang paling lama tidak digunakan apabila memori hampir penuh, yang merupakan tindakan yang diingini oleh cache objek, kerana setiap nilai di dalamnya hanyalah salinan data yang masih wujud dalam MySQL. Kehilangan satu kunci hanya menelan kos satu pertanyaan (query). Menolak penulisan pula menelan kos setiap pertanyaan, pada setiap permintaan, sehingga seseorang menyedarinya.

Elakkan polisi volatile-* untuk tugas ini. Polisi tersebut hanya mempertimbangkan kunci yang mempunyai tempoh luput, dan dokumentasi Redis menyatakan bahawa ia berkelakuan seperti noeviction apabila tiada kunci yang mempunyai tempoh luput. WordPress menyimpan kebanyakan entri cache objek tanpa TTL, jadi volatile-lru pada cache objek boleh menyebabkan ia penuh dan mula menolak penulisan. allkeys-lfu ialah alternatif yang wajar jika trafik anda kerap mengakses set kunci yang kecil, kerana ia mengusir berdasarkan kekerapan dan bukannya kebaharuan. Pilih satu secara sengaja dan catatkan sebabnya.

Persistence: biarkan ia dimatikan kecuali anda mempunyai sebab tertentu

Pakej redis.conf mendayakan syot kilat RDB dengan baris seperti save 900 1, dan membiarkan fail append-only dimatikan. Untuk cache objek tulen, syot kilat tidak memberikan sebarang manfaat. Data tersebut secara definisinya boleh dijana semula, dan cache yang dipulihkan daripada fail berusia dua puluh minit adalah set nilai lapuk yang akan dipercayai oleh WordPress.

Syot kilat juga mempunyai kos. BGSAVE melakukan fork pada proses, dan copy-on-write bermakna penggunaan memori boleh meningkat secara mendadak semasa proses anak menulis data. Pada VPS kecil, perkara ini akan kelihatan dalam log Redis:

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

dan selalunya amaran ini muncul semasa permulaan, yang merupakan cara Redis memberitahu anda bahawa fork berkemungkinan besar akan gagal kemudian:

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

Untuk mematikan syot kilat, tetapkan jadual save yang kosong dalam /etc/redis/redis.conf, mulakan semula, dan sahkan bahawa nilai tersebut kembali kosong.

save ""

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

Kekalkan persistence hanya jika instans yang sama menyimpan sesuatu yang tidak boleh anda bina semula, seperti baris gilir tugasan (job queue) atau pembilang had kadar (rate-limit counters). Dalam kes tersebut, asingkan kedua-duanya. Cache memerlukan kunci untuk disingkirkan (evicted) manakala data tahan lama memerlukan kunci untuk dikekalkan, dan maxmemory serta dasar penyingkiran (eviction) terpakai pada keseluruhan instans, bukan pada satu indeks pangkalan data sahaja. Dua instans pada dua soket adalah penyelesaian yang kemas.

Pasang pemalam dan fahami drop-in

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

wp redis enable mencetak Object cache enabled. apabila berjaya. Tindakan sebenarnya ialah menyalin wp-content/plugins/redis-cache/includes/object-cache.php ke wp-content/object-cache.php. Salinan tersebut ialah drop-in, dan drop-in itulah bahagian yang melaksanakan tugas tersebut. WordPress memuatkan wp-content/object-cache.php dengan sangat awal, sebelum sebarang kod pemalam dijalankan, yang membolehkan cache tersedia untuk keseluruhan permintaan. Pemalam yang aktif tanpa drop-in di tempatnya tidak akan menyimpan apa-apa cache.

Mesej kegagalan memberitahu anda bahagian mana yang rosak. Object cache could not be enabled. bermaksud salinan gagal, jadi wp-content tidak boleh ditulis oleh pengguna yang menjalankan WP-CLI. A foreign object cache drop-in was found. bermaksud pemalam caching lain sudah memiliki nama fail tersebut, dan penyelesaiannya ialah wp redis update-dropin. Mesej yang berakhir dengan Redis server is unreachable: diikuti oleh ralat klien bermaksud tetapan sambungan adalah salah, jadi kembali ke redis-cli ping.

Jika salinan gagal disebabkan oleh keizinan (permissions), letakkan fail tersebut secara manual dan berikan hak milik 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

Membuang pemalam tidak membuang drop-in. Jalankan wp redis disable terlebih dahulu, yang akan mencetak Object cache disabled. dan memadamkan fail tersebut. Memadamkan direktori pemalam sementara drop-in masih tertinggal akan menyebabkan tapak web terus menjalankan kod cache lama tanpa pemalam untuk mengemas kininya.

Tetapan sambungan dalam wp-config.php

Tambahkan tetapan ini di atas baris yang tertulis /* That's all, stop editing! */, kerana pemalar yang ditakrifkan selepas baris tersebut akan menjadi terlalu lewat.

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 laluan (path). Host dan port kemudiannya akan 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 tamat tempoh pada setiap kunci, dalam saat. Anda tidak memerlukannya jika menggunakan allkeys-lru, dan ia berguna jika anda mahukan had maksimum yang ketat bagi tempoh nilai cache yang boleh dianggap lapuk.

Satu Redis, beberapa tapak: awalan dan pangkalan data

Redis menyediakan enam belas pangkalan data bernombor secara lalai, dengan satu ruang kunci (keyspace) rata di dalam setiap satunya. Dua pemasangan WordPress yang dihalakan ke pangkalan data 0 tanpa awalan akan menulis nama kunci yang sama ke dalam ruang yang sama, menyebabkan satu tapak boleh membaca pilihan tapak yang lain dan menghidangkannya. Berikan setiap tapak awalan tersendiri.

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

Awalan memisahkan nama kunci. Indeks pangkalan data memisahkan ruang kunci, yang penting semasa proses pembersihan (flush): mengosongkan satu indeks tidak akan menjejaskan indeks yang lain. Pemalam tersebut juga mendokumentasikan WP_REDIS_SELECTIVE_FLUSH, yang memadamkan hanya kunci yang sepadan dengan awalan anda dan bukannya keseluruhan pangkalan data, dengan kos perlu melakukan imbasan untuk kunci tersebut.

Perkara yang tidak dipisahkan oleh awalan dan indeks ialah memori. maxmemory dan polisi pengusiran (eviction policy) terpakai kepada keseluruhan instans, jadi tapak yang sibuk boleh menolak kunci tapak yang kurang aktif keluar dan tiada satu pun yang akan melaporkannya. Tapak yang tidak boleh saling mempengaruhi antara satu sama lain memerlukan instans Redis yang berasingan, setiap satunya dengan soket dan had tersendiri.

Asingkan cache persekitaran staging daripada production

Tapak staging biasanya merupakan salinan fail dan pangkalan data production, yang bermaksud ia adalah salinan wp-config.php yang membawa prefix dan indeks pangkalan data yang sama. Jika ia dihalakan ke Redis yang sama, ia akan menulis kunci production dengan nilai daripada staging. Harga ujian atau pilihan yang diubah kemudiannya akan muncul pada tapak live tanpa sebarang proses deploy atau jejak perubahan.

Berikan nilai salt yang unik untuk setiap persekitaran secara manual. Dalam wp-config.php persekitaran staging:

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

Lebih baik lagi, sediakan instance Redis yang berasingan untuk staging, atau jangan gunakan object cache langsung. define( 'WP_REDIS_DISABLED', true ); mematikan cache semasa runtime dan mengekalkan fail drop-in di tempatnya, yang juga merupakan cara terpantas untuk mengesahkan sama ada sesuatu pepijat berpunca daripada cache atau tidak.

Tutorial lama menetapkan WP_CACHE_KEY_SALT untuk tujuan ini. Fail readme pemalam tersebut menandakan constant itu sebagai deprecated dan digantikan dengan WP_REDIS_PREFIX, jadi gunakan nama yang baharu.

Sahkan bukannya mempercayai

Mulakan dengan diagnostik pemalam itu sendiri.

wp redis status

Baris yang paling penting ialah Drop-in. Drop-in: Valid bermaksud WordPress sedang memuatkan fail pemalam ini. Drop-in: Not installed bermaksud penyalinan tidak pernah berlaku dan tapak tersebut tidak mempunyai cache yang kekal, tidak kira betapa hijau paparan skrin pentadbir kelihatan. Status melaporkan sambungan, dan Client menamakan sambungan yang digunakan, di mana anda mengesahkan PhpRedis dan bukannya Predis.

Kemudian tanya teras WordPress secara terus, kerana ia tidak mengambil kira apa yang difikirkan oleh pemalam.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) bermaksud teras sedang berkomunikasi dengan cache objek luaran.

Kemudian buktikan bahawa kunci sedang sampai, dengan awalan yang anda konfigurasikan.

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

dbsize yang meningkat semasa anda melayari tapak adalah buktinya. Sifar kunci dengan drop-in yang sah bermaksud sambungan gagal secara senyap, atau awalan tersebut bukanlah yang anda sangkakan.

Akhir sekali, lihat apa yang diukur oleh Redis untuk anda.

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

Nisbah hit ialah keyspace_hits / (keyspace_hits + keyspace_misses), dan dokumentasi Redis memberikan formula tersebut. Baca ia dengan dua peringatan. Pembilang merangkumi keseluruhan instans sejak kali terakhir ia dimulakan semula, jadi ia mencampurkan setiap tapak dan setiap aplikasi yang berkongsinya. Dan nisbah sejurus selepas pembersihan (flush) atau permulaan semula tidak bermakna apa-apa, kerana cache masih dalam proses pengisian. Biarkan ia berjalan sepanjang hari trafik biasa.

Jangan bandingkan nombor anda dengan kadar hit atau kiraan pertanyaan yang diterbitkan oleh syarikat pengehosan. Angka tersebut menggambarkan tapak mereka dan set pemalam mereka. Angka yang penting ialah angka anda sendiri, yang diukur sebelum dan selepas pada halaman yang tidak boleh dihidangkan oleh cache halaman.

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

Jalankan arahan tersebut dengan koleksi kuki yang telah log masuk, beberapa kali, dengan cache dimatikan (WP_REDIS_DISABLED) dan kemudian dihidupkan. Perbezaan itulah hasil anda.

Apabila Redis melambatkan WordPress

Satu instans penuh dengan polisi yang salah merupakan punca utama, seperti yang dibincangkan di atas: OOM command not allowed when used memory > 'maxmemory'. dalam log, dan tapak yang membayar untuk pangkalan data serta cache.

Redis pada hos lain adalah punca kedua. WordPress membuat ratusan panggilan cache objek dalam satu permintaan. Jika satu permintaan membuat 500 panggilan dan setiap perjalanan pergi-balik mengambil masa 1 ms, itu bermakna setengah saat masa menunggu yang tidak akan berlaku jika menggunakan soket tempatan. Pastikan Redis berada pada mesin yang sama, atau pada rangkaian peribadi dengan kependaman bawah satu milisaat. Sejauh mana kes mesin yang sama mendapat manfaat daripada kernel adalah persoalan berasingan: penjadualan sedar cache yang ditambah dalam Linux 7.2 cuba mengekalkan proses yang banyak berinteraksi seperti PHP-FPM dan Redis pada teras yang berkongsi cache, dan tetamu VPS melihat kurang manfaat ini berbanding bare metal.

Jadual pilihan autoload yang besar adalah punca ketiga, dan ia biasa berlaku pada tapak lama. WordPress menyimpan semua pilihan autoload sebagai satu kunci, jadi satu megabait data akan merentasi sambungan pada setiap permintaan. Ukur ia:

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 menambah nilai autoload baharu, jadi pertanyaan lama yang hanya memadankan 'yes' akan melaporkan data yang kurang tepat pada pemasangan moden. Apa-apa yang melebihi satu megabait adalah masalah yang perlu dibaiki dalam jadual options, bukan dalam Redis.

Satu but semula akan mengosongkan segala-galanya, jadi minit-minit selepas systemctl restart redis-server adalah tempoh semua cache terlepas (misses) dan semua kerja dilakukan oleh pangkalan data. Lakukan but semula apabila trafik rendah. Dan cache objek tidak menghalang wp-cron.php daripada tercetus semasa muat turun halaman pelawat, yang merupakan punca tersendiri bagi permintaan perlahan: pindahkan WP-Cron ke kerja cron sistem sebenar semasa anda berada di sini.

Penyelenggaraan

Lakukan flush selepas deployment yang mengubah pilihan atau kod tema dengan wp cache flush. Jalankan wp redis update-dropin selepas kemas kini plugin jika drop-in tidak mengemas kini dirinya sendiri, kerana drop-in daripada versi plugin lama yang digunakan pada plugin versi baharu merupakan punca sebenar gelagat yang ganjil. Pantau pelayan secara langsung dengan redis-cli --stat, yang mencetak satu baris sesaat. redis-cli monitor mencetak setiap arahan dan menggunakan CPU yang banyak pada instance yang sibuk, jadi gunakannya untuk beberapa saat sahaja semasa anda cuba menghasilkan semula sesuatu isu, kemudian hentikannya.

Satu lagi angka yang perlu diketahui: redis-cli info clients melaporkan connected_clients. PHP-FPM memegang satu sambungan bagi setiap worker, jadi angka tersebut sepatutnya selari dengan pm.max_children anda, dan tidak melebihi angka tersebut secara ketara. Jika ia berlaku, sesuatu proses sedang membuka sambungan dan tidak menutupnya.

FAQ

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

Ya, untuk trafik tanpa nama (anonymous). Page cache menghidangkan HTML yang disimpan tanpa menjalankan PHP, yang sentiasa lebih efisien daripada menjalankan WordPress dengan object cache yang sedia ada. Object cache mengendalikan permintaan yang perlu dilangkau oleh page cache: pengguna yang telah log masuk, troli beli-belah, daftar keluar (checkout), dan wp-admin. Bagi kedai atau tapak keahlian, kedua-duanya wajar dijalankan. Bagi tapak yang pelawatnya tidak pernah log masuk, page cache melakukan hampir semua kerja.

Berapa banyak memori yang perlu saya berikan kepada Redis untuk WordPress?

Tentukan berdasarkan pelayan anda sendiri dan bukannya menyalin angka orang lain. Ambil jumlah RAM, tolak MySQL buffer pool dan buffer bagi setiap sambungan, tolak pm.max_children yang didarab dengan saiz resident satu worker PHP-FPM, dan tolak beberapa ratus megabait untuk kernel serta pelayan web. Berikan Redis sebahagian daripada baki yang ada, kemudian semak used_memory_human dalam redis-cli info memory selepas sehari trafik dan buat pelarasan. Satu tapak WordPress biasanya menggunakan puluhan megabait, jadi maxmemory bersaiz 256 MB adalah permulaan yang mencukupi pada pelayan 4 GB.

Mengapa tapak saya menjadi lebih perlahan selepas mendayakan object cache Redis?

Punca biasa ialah instance yang penuh dan menjalankan polisi noeviction. Redis menolak penulisan baharu dan mengembalikan OOM command not allowed when used memory > 'maxmemory'., jadi WordPress kembali menggunakan pangkalan data untuk setiap nilai dan menanggung kerugian masa perjalanan pergi-balik (round trip) Redis sebagai tambahan. Semak redis-cli config get maxmemory-policy, tetapkan allkeys-lru, dan pastikan maxmemory tidak terlalu kecil. Punca biasa yang lain ialah pelayan Redis pada hos jauh, di mana ratusan perjalanan pergi-balik bagi setiap permintaan terkumpul, serta nilai pilihan (options) yang dimuatkan secara automatik bersaiz berbilang megabait yang merentasi sambungan pada setiap permintaan.

Bolehkah beberapa tapak WordPress berkongsi satu pelayan Redis?

Boleh, dengan langkah berjaga-jaga. Berikan setiap tapak WP_REDIS_PREFIX yang unik supaya nama kunci tidak bertindih, dan indeks WP_REDIS_DATABASE yang berasingan supaya pembersihan (flushing) satu tapak tidak mengosongkan tapak yang lain. Apa yang masih dikongsi ialah memori: maxmemory dan pengusiran (eviction) terpakai untuk keseluruhan instance, jadi tapak yang sibuk boleh mengusir kunci tapak yang kurang trafik. Tapak yang tidak boleh menjejaskan satu sama lain memerlukan instance Redis yang berasingan dengan had masing-masing.

Adakah selamat untuk memadam wp-content/object-cache.php?

Ya. Ia adalah fail drop-in, bukan sebahagian daripada teras WordPress, dan memadamkannya mengembalikan WordPress kepada cache per-permintaan (per-request) terbina dalamnya. Tapak akan terus berfungsi dan hanya melakukan lebih banyak pertanyaan pangkalan data. Gunakan wp redis disable, yang memadam fail tersebut dengan bersih dan melaporkan Object cache disabled.. Memadamnya secara manual adalah tindakan kecemasan yang tepat jika Redis terhenti atau tidak berfungsi dengan betul dan anda tidak dapat mengakses bahagian admin.