Cara Setup Redis Object Cache WordPress di VPS

Fungsi Redis object cache untuk WordPress

Redis object cache untuk WordPress menyimpan hasil pertanyaan pangkalan data di dalam memori, supaya permintaan seterusnya membaca data tersebut daripada Redis dan bukannya meminta MySQL sekali lagi. WordPress sudah mempunyai object cache 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.

Object caching bukanlah page caching, dan perbezaan ini menentukan sama ada panduan ini berguna untuk anda. Page cache menyimpan HTML yang telah siap 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, page cache akan berhenti berfungsi dan WordPress menjalankan keseluruhan permintaan: bootstrap, pemalam, dan pertanyaan. Object cache menjadikan permintaan tersebut lebih ringan. Ia adalah alat untuk trafik yang tidak dapat disentuh oleh page cache: sesi log masuk, troli, daftar keluar, dan wp-admin. Bagi kedai WooCommerce, itu adalah sebahagian besar daripada trafik yang memakan sumber.

Kedua-duanya boleh digunakan bersama, dan bagi 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 page cache, dan menambah Redis kepadanya tidak membawa banyak perubahan.

Satu had yang perlu diketahui sebelum anda bermula. Object cache 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.

Prasyarat

• Sebuah VPS Linux dengan akses shell dan sudo. Tiada panel kawalan diperlukan.
• WordPress yang dihoskan oleh PHP-FPM, contohnya pada stack LAMP di Ubuntu 24.04.
• WP-CLI dipasang 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 faktor utama, dan lompatan rangkaian akan menjejaskan prestasi.

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 memaparkan 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, iaitu 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 muktamad ialah diagnostik pemalam itu sendiri, yang diterangkan di 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.

Mengikat Redis supaya tiada akses luar

Redis tidak mempunyai kata laluan secara lalai. Sesiapa sahaja yang boleh membuka sambungan ke port 6379 boleh membaca setiap nilai dalam cache 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 antara muka awam: betulkan baris bind dan mulakan semula.

Apabila PHP dan Redis berada pada pelayan yang sama, soket Unix adalah lebih baik daripada TCP loopback. Tiada tindanan TCP dalam laluan tersebut, dan akses ditentukan oleh kebenaran 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 terus berkembang sehingga kernel kehabisan memori dan OOM killer menamatkan sesuatu proses, biasanya proses yang paling besar, yang pada pelayan WordPress selalunya adalah MySQL. journalctl -k | grep -i "out of memory" menunjukkan proses yang ditamatkan tersebut selepas kejadian, dan pada ketika itu laman web anda sudah pun tergendala.

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 sebanyak pm.max_children didarab dengan saiz resident sebenar bagi satu worker, biasanya antara 64 MB hingga 128 MB pada laman web yang sarat dengan pemalam. Kernel dan pelayan web memerlukan beberapa ratus megabait. Baki yang tinggal adalah had maksimum anda, dan Redis akan mendapat sebahagian daripadanya.

Sekarang, lakukan pengukuran dan bukannya meneka. Selepas satu hari 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 itu 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. Sunting 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 lebih tinggi daripada 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) dengan sengaja

Redis yang baharu dipasang 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'.

Baris tunggal itu 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 beban kerja pangkalan data asal ditambah dengan perjalanan pergi-balik ke Redis bagi setiap kunci. Tiada apa-apa dalam pentadbir WordPress yang memberitahu anda bahawa 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 betul di sini. Redis akan membuang kunci yang paling lama tidak digunakan (least recently used) apabila memori hampir penuh, yang merupakan perkara tepat yang diperlukan 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 mencapai 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 snapshot RDB dengan baris seperti save 900 1, dan membiarkan fail append-only dimatikan. Untuk cache objek tulen, snapshot 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.

Snapshot 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 snapshot, 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 disingkirkan (evicted) manakala data tahan lama memerlukan kunci dikekalkan, dan maxmemory berserta dasar penyingkiran (eviction) terpakai untuk keseluruhan instans, bukan untuk 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. WordPress memuatkan wp-content/object-cache.php dengan sangat awal, sebelum sebarang kod pemalam dijalankan, itulah sebabnya cache tersedia untuk keseluruhan permintaan. Pemalam yang aktif tanpa drop-in di tempatnya tidak akan menyimpan sebarang cache.

Mesej kegagalan memberitahu anda bahagian mana yang rosak. Object cache could not be enabled. bermaksud penyalinan 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 penyalinan 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 baris ini di atas baris yang tertulis /* That's all, stop editing! */, kerana pemalar yang ditakrifkan selepasnya 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 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 memaparkannya. 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 kedua-duanya tidak akan melaporkannya. Tapak yang tidak boleh saling mempengaruhi memerlukan instans Redis yang berasingan, setiap satunya dengan soket dan had tersendiri.

Asingkan cache staging daripada pengeluaran

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

Berikan nilai unik (salt) bagi setiap persekitaran secara manual. Dalam wp-config.php staging:

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

Lebih baik lagi, berikan staging instans Redis miliknya sendiri, atau tiada cache objek langsung. define( 'WP_REDIS_DISABLED', true ); mematikan cache pada masa jalan (runtime) dan membiarkan drop-in di tempatnya, yang juga merupakan cara terpantas untuk membuktikan sama ada sesuatu pepijat berpunca daripada cache atau tidak.

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

Sahkan ia dan jangan terus percaya

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 boleh mengesahkan penggunaan PhpRedis dan bukannya Predis.

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

wp eval 'var_dump( wp_using_ext_object_cache() );'

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

Seterusnya, buktikan bahawa kunci sedang sampai, dengan awalan yang telah 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 bukan seperti yang anda sangkakan.

Akhir sekali, lihat apa yang Redis ukur 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. Selain itu, nisbah sejurus selepas pembersihan (flush) atau permulaan semula tidak membawa makna, kerana cache masih dalam proses pengisian. Biarkan ia berjalan sepanjang hari dengan 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 ujian tersebut dengan balang kuki (cookie jar) 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 adalah punca utama, seperti yang dibincangkan di atas: OOM command not allowed when used memory > 'maxmemory'. dalam log, dan tapak web 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.

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

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 memberikan laporan yang kurang tepat pada pemasangan moden. Sebarang data melebihi satu megabait adalah masalah yang perlu dibaiki dalam jadual pilihan, bukan dalam Redis.

Satu proses restart akan mengosongkan segala-galanya, jadi beberapa minit selepas systemctl restart redis-server akan dipenuhi dengan misses dan beban kerja pangkalan data. Lakukan restart apabila trafik rendah. Selain itu, cache objek tidak menghalang wp-cron.php daripada berjalan semasa pelawat memuatkan halaman, yang merupakan punca tersendiri bagi permintaan perlahan: pindahkan WP-Cron ke sistem cron job sebenar sementara anda berada di sini.

Penyelenggaraan

Lakukan pembersihan (flush) selepas proses deploy yang mengubah pilihan atau kod tema dengan wp cache flush. Jalankan wp redis update-dropin selepas kemas kini pemalam jika drop-in tidak mengemas kini dirinya sendiri, kerana drop-in daripada versi pemalam lama yang digunakan pada versi pemalam 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 instans 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 mengekalkan satu sambungan bagi setiap worker, jadi angka tersebut sepatutnya selari dengan pm.max_children anda, dan tidak melebihi angka tersebut dengan perbezaan yang 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 log masuk. 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 dan wp-admin. Pada laman kedai atau keahlian, kedua-duanya wajar dijalankan. Pada laman yang pengunjungnya tidak pernah log masuk, page cache melakukan hampir keseluruhan kerja.

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

Tentukan jumlahnya 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 didarabkan dengan saiz resident bagi satu worker PHP-FPM, dan tolak beberapa ratus megabait untuk kernel serta pelayan web. Berikan sebahagian daripada baki tersebut kepada Redis, kemudian semak used_memory_human dalam redis-cli info memory selepas sehari trafik dan buat pelarasan. Satu laman WordPress biasanya menggunakan puluhan megabait, jadi maxmemory sebesar 256 MB adalah permulaan yang mencukupi pada pelayan 4 GB.

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

Punca biasa ialah instans 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 akan terkumpul, serta nilai pilihan autoloaded bersaiz berbilang megabait yang merentasi sambungan pada setiap permintaan.

Bolehkah beberapa laman WordPress berkongsi satu pelayan Redis?

Boleh, dengan langkah berjaga-jaga. Berikan setiap laman WP_REDIS_PREFIX yang unik supaya nama kunci tidak bertindih, dan indeks WP_REDIS_DATABASE yang berasingan supaya pembersihan (flushing) satu laman tidak mengosongkan laman yang lain. Apa yang masih dikongsi ialah memori: maxmemory dan pengusiran (eviction) terpakai untuk keseluruhan instans, jadi laman yang sibuk boleh mengusir kunci laman yang kurang trafik. Laman yang tidak boleh saling mempengaruhi memerlukan instans 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 akan mengembalikan WordPress kepada cache per-permintaan terbina dalam. Laman akan terus berfungsi dan hanya melakukan lebih banyak pertanyaan pangkalan data. Gunakan wp redis disable, yang memadamkan fail tersebut dengan bersih dan melaporkan Object cache disabled.. Memadamkannya secara manual adalah tindakan kecemasan yang betul jika Redis terhenti atau tidak berfungsi dengan baik dan anda tidak dapat mengakses bahagian admin.