WordPress Redis Nesne Önbelleği Kurulumu

WordPress için Redis nesne önbelleği ne işe yarar

WordPress için bir Redis nesne önbelleği, veritabanı sorgularının sonuçlarını bellekte tutar; böylece bir sonraki istek, MySQL'e tekrar sormak yerine veriyi Redis üzerinden okur. WordPress çekirdeğinde halihazırda bir nesne önbelleği bulunur, WP_Object_Cache, ancak bu önbellek PHP belleğinde yaşar ve istek sona erdiğinde silinir. Bir drop-in dosyası, bunu Redis ile iletişim kuran bir yapı ile değiştirir; böylece önbellek, bir istekten diğerine varlığını sürdürür.

Nesne önbelleği, sayfa önbelleği ile aynı şey değildir ve bu fark, bu kılavuzun sizin için uygun olup olmadığını belirler. Bir sayfa önbelleği, bir URL'nin oluşturulmuş HTML çıktısını saklar ve PHP'yi hiç çalıştırmadan tekrar sunar. Bu, Redis'in yapabileceği her şeyden daha hızlıdır ve giriş yapmamış ziyaretçiler için çalışır. Birisi giriş yaptığı, sepete ürün eklediği veya yönetici panelini açtığı anda sayfa önbelleği devre dışı kalır ve WordPress tüm isteği baştan sona çalıştırır: bootstrap, eklentiler, sorgular. Nesne önbelleği, işte o isteği daha az maliyetli hale getirir. Sayfa önbelleğinin dokunamadığı trafik için kullanılan araçtır: oturum açmış kullanıcılar, sepetler, ödeme işlemleri ve wp-admin. Bir WooCommerce mağazasında maliyetli trafiğin büyük kısmı budur.

Bu ikisi birlikte çalışır ve yoğun bir sitede her ikisi de gereklidir. Hangi sorunu çözdüğünüz konusunda net olun. Anonim okuyuculara sahip bir tanıtım sitesi, hızının neredeyse tamamını sayfa önbelleğinden alır ve buna Redis eklemek çok az şey değiştirir.

Başlamadan önce dürüst bir sınırlama: Nesne önbelleği, yavaş bir sorguyu hızlandırmaz. Sadece daha önce çalışmış bir sorgunun tekrarını ortadan kaldırır. Önbellek ıskalandıktan sonraki ilk istek tam maliyeti öder; bu nedenle indekslenmemiş bir sorgu çalıştıran bir eklenti, önbellek ömrü boyunca bu sorguyu yine de bir kez çalıştırır.

Başlamadan önce gerekenler

• Shell erişimi ve sudo olan bir Linux VPS. Kontrol paneli gerekmez.
• PHP-FPM tarafından sunulan bir WordPress kurulumu; örneğin Ubuntu 24.04 üzerinde bir LAMP yığını.
• Sunucuda WP-CLI yüklü olmalıdır. Buradaki her adımın yönetim paneli üzerinde bir karşılığı vardır ancak shell sürümü daha hızlıdır.
• PHP ile aynı makinede çalışan Redis. Gecikme süresi temel amaçtır ve ağ üzerinden yapılan bir atlama bu avantajı ortadan kaldırır.

Aşağıdaki komutlar, PHP 8.3 ve www-data web kullanıcısı kullanan Ubuntu 24.04 için yazılmıştır. PHP sürümünü ve kullanıcıyı kendi sunucunuza göre düzenleyin. wp komutlarını, wp-config.php dosyasını içeren WordPress dizininizden çalıştırın.

Redis ve PHP eklentisinin kurulumu

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

redis-cli ping, PONG sorusuna yanıt vermelidir. Eğer Could not connect to Redis at 127.0.0.1:6379: Connection refused çıktısını veriyorsa sunucu çalışmıyordur; bu durumda devam etmeden önce systemctl status redis-server kısmını okuyun.

php-redis, PECL üzerinden sağlanan C tabanlı bir eklenti olan PhpRedis'tir. Tamamı PHP ile yazılmış olan Predis'ten daha hızlıdır ve eklenti, mevcut olduğunda bunu otomatik olarak kullanır. PHP-FPM eklentileri başlangıçta yükler, bu nedenle yeni bir eklenti havuz yeniden başlatılana kadar görünmez.

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

Son kontrolde dikkatli olun: php -m, komut satırı PHP'sinin modüllerini listeler; FPM ise farklı bir set yükleyebilir. Asıl önemli olan kontrol, eklentinin kendi tanılamasıdır ve bu ilerleyen bölümlerde yer almaktadır.

Ağustos 2026 itibarıyla Ubuntu 24.04, nesne önbelleği için yeterli olan Redis 7.0.15 paketini sunmaktadır. Eğer güncel bir sürüm kullanmak isterseniz, Redis kendi APT deposunu yayınlamaktadır.

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

Eğer dağıtımınız, 2024 yılındaki lisans değişikliğinden sonra oluşturulan çatal (fork) olan Valkey'i sunuyorsa, aynı protokolü kullandığı için aşağıda belirtilen her şey hiçbir değişiklik yapılmadan geçerlidir.

Redis'i dış erişime kapatmak için bağlama

Redis varsayılan olarak parola koruması içermez. 6379 numaralı porta bağlantı açabilen her türlü istemci, tüm önbellek değerlerini okuyabilir ve FLUSHALL komutlarını çalıştırabilir. İnternete açık Redis örnekleri saatler içinde tarayıcılar tarafından bulunur; bu nedenle ağ yapılandırması, performans ayarlarından önce gelmelidir.

/etc/redis/redis.conf dosyasını açın ve şu satırları doğrulayın:

bind 127.0.0.1 -::1
protected-mode yes

Ardından gerçekte hangi portun dinlendiğini kontrol edin; yapılandırma dosyası bir beyan, ss ise kanıttır.

sudo ss -lntp | grep 6379

İstediğiniz çıktı 127.0.0.1:6379 olmalıdır. 0.0.0.0:6379 ifadesi, Redis'in genel ağ arayüzünden yanıt verdiğini gösterir: bind satırını düzeltin ve servisi yeniden başlatın.

PHP ve Redis aynı sunucuda bulunduğunda, Unix socket kullanımı loopback TCP'den daha verimlidir. Bu yöntemde TCP yığını kullanılmaz ve erişim, daha sonra değiştirilebilecek bir güvenlik duvarı kuralı yerine dosya izinleri ile belirlenir.

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

Socket dosyasının sahibi redis kullanıcısı ve grubudur; bu nedenle web kullanıcısının bu gruba dahil edilmesi gerekir.

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

Bu komutun çıktısı PONG olmalıdır. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied ifadesi, grup değişikliğinin devreye girmediğini gösterir. id www-data dosyasını kontrol edin; çalışan bir PHP-FPM sürecinin başlangıçtaki grup izinlerini koruduğunu unutmayın, bu nedenle yeniden başlatma işlemi listede yer almaktadır. Socket bağlantısının çalıştığı doğrulanana kadar TCP'yi etkin bırakın; aksi takdirde yapılacak bir yazım hatası her iki erişim yolunu da aynı anda kapatabilir.

Redis ne kadar bellek almalı?

Bu değeri kendi sunucunuzdan yola çıkarak belirleyin. maxmemory ayarı yapılmamış bir Redis, çekirdek belleği tükenene kadar büyür; bu noktada OOM killer devreye girerek genellikle en büyük süreci sonlandırır. WordPress sunucularında bu süreç genellikle MySQL'dir. journalctl -k | grep -i "out of memory", bu sonlandırma işlemini gerçekleştikten sonra gösterir ancak o aşamada site zaten erişilemez durumdadır.

Toplam RAM miktarından yola çıkarak çıkarma işlemi yapın. MySQL veya MariaDB, innodb_buffer_pool_size ve bağlantı başına tampon bellek ayırır. PHP-FPM, bir işçinin gerçek yerleşik bellek boyutu ile çarpılan pm.max_children kadar maliyet oluşturur; eklenti yoğunluklu bir sitede bu değer genellikle 64 MB ile 128 MB arasındadır. Çekirdek ve web sunucusu için birkaç yüz megabaytlık bir pay bırakılmalıdır. Geriye kalan miktar sizin üst sınırınızdır ve Redis bunun bir kısmını alır.

Şimdi tahmin etmek yerine ölçüm yapın. Bir günlük gerçek trafikten sonra:

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

Eğer used_memory_human limitinizin çok altındaysa, limiti düşürün ve RAM'i daha verimli kullanacak olan MySQL'e geri verin. Eğer limit seviyesinde sabitleniyorsa ve evicted_keys gün boyu yükseliyorsa, limiti artırın. Değeri /etc/redis/redis.conf içinde ayarlayın.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb anında uygulanır ancak bir sonraki yeniden başlatmada unutulur; bu, doğrudan sysctl -w kullanmanın getirdiği tuzakla aynıdır. Dosyayı düzenleyin, ardından sudo systemctl restart redis-server komutunu çalıştırın ve değeri tekrar okuyun. İkinci bir güvenlik duvarı oluşturmak faydalıdır: systemd birimi üzerinde bir MemoryMax sınırı, yanlış yapılandırılmış bir Redis'in sunucuyu çökertmesini engeller. Bu değeri maxmemory üzerinde ayarlayın, asla eşit tutmayın; çünkü cgroup sınırı, anahtar silmek yerine süreci doğrudan sonlandırır. Redis, WordPress'in yanında bir container içinde çalışıyorsa, aynı rakam Compose dosyanızdaki bellek sınırları için de geçerlidir ve veritabanını Docker içinde veya ana makinede çalıştırma tercihi de aynı mantıkla belirlenir.

Tahliye politikasını bilinçli seçin

Yeni kurulan bir Redis varsayılan olarak noeviction kullanır. Kendi ayarınızı kontrol edin:

redis-cli config get maxmemory-policy

noeviction altında, tam dolu bir instance yazma işlemlerini kabul etmeyi durdurur ve şu yanıtı verir:

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

Bu tek satırlık hata, bu kılavuzdaki en kötü başarısızlık modudur; çünkü site tamamen kapanmaz, sadece yavaşlar. Her önbellek yazma işlemi başarısız olduğundan, WordPress değeri almak için veritabanına geri döner, ardından bir sonraki istekte tekrar depolamaya çalışır ve yine başarısız olur. Site artık orijinal veritabanı yükünün tamamını ve üzerine her anahtar için Redis'e yapılan gidiş-dönüş maliyetini öder. WordPress yönetim panelinde bunun gerçekleştiğine dair hiçbir uyarı yer almaz. Bu ifade PHP hata günlüğünde görünür, bu nedenle bir önbellek ekledikten sonra site yavaşlarsa OOM command not allowed ifadesini grep ile arayın.

allkeys-lru burada doğru varsayılandır. Redis, bellek dolduğunda en az kullanılan anahtarı (LRU) siler; bir nesne önbelleğinin tam olarak istediği budur, çünkü içindeki her değer MySQL'de zaten var olan verinin bir kopyasıdır. Bir anahtarı kaybetmek tek bir sorguya mal olur. Yazma işlemini reddetmek ise, birisi fark edene kadar her istekte her sorgunun veritabanına gitmesine neden olur.

Bu görev için volatile-* politikalarından kaçının. Bunlar yalnızca son kullanma tarihi olan anahtarları dikkate alır ve Redis belgelerine göre, hiçbir anahtarın süresi dolmadığında noeviction gibi davranırlar. WordPress, nesne önbelleği girdilerinin çoğunu TTL olmadan depolar, bu nedenle nesne önbelleğinde volatile-lru kullanmak belleğin dolmasına ve yazma işlemlerinin reddedilmesine yol açabilir. Trafiğiniz küçük bir anahtar kümesine çok sık erişiyorsa allkeys-lfu makul bir alternatiftir; çünkü yakınlık yerine sıklığa göre tahliye yapar. Birini bilinçli olarak seçin ve nedenini not edin.

Kalıcılık: bir nedeniniz yoksa kapalı tutun

Paketlenmiş redis.conf, save 900 1 gibi satırlarla RDB anlık görüntülerini (snapshot) etkinleştirir ve append-only dosyasını kapalı bırakır. Saf bir nesne önbelleği (object cache) için anlık görüntüler bir fayda sağlamaz. Veriler tanım gereği yeniden oluşturulabilir niteliktedir ve yirmi dakika önceki bir dosyadan geri yüklenen önbellek, WordPress'in güveneceği eski değerlerden oluşan bir kümedir.

Anlık görüntülerin bir maliyeti de vardır. BGSAVE süreci çatallandırır (fork) ve copy-on-write mekanizması, alt süreç yazma işlemi yaparken bellek kullanımının hızla artabileceği anlamına gelir. Küçük bir VPS üzerinde bu durum Redis günlüğünde şu şekilde görünür:

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

ve başlangıçta genellikle şu uyarı belirir; bu, Redis'in size çatallanma işleminin ileride başarısız olma ihtimalinin yüksek olduğunu bildirmesidir:

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

Anlık görüntüleri kapatmak için /etc/redis/redis.conf içinde boş bir kaydetme zamanlaması ayarlayın, yeniden başlatın ve değerin boş döndüğünü doğrulayın.

save ""

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

Kalıcılığı yalnızca aynı örnek (instance) üzerinde iş kuyruğu veya hız sınırlama sayaçları gibi yeniden oluşturamayacağınız veriler varsa tutun. Bu durumda ikisini ayırın. Bir önbellek anahtarların silinmesini (eviction) isterken, kalıcı veriler anahtarların tutulmasını gerektirir; maxmemory ve silme politikaları tek bir veritabanı dizinine değil, tüm örneğe uygulanır. İki farklı soket üzerinde iki ayrı örnek çalıştırmak temiz çözümdür.

Eklentiyi kurun ve drop-in dosyasının işleyişini anlayın

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

wp redis enable, başarı durumunda Object cache enabled. çıktısını verir. Gerçekte yaptığı işlem, wp-content/plugins/redis-cache/includes/object-cache.php dosyasını wp-content/object-cache.php konumuna kopyalamaktır. Bu kopya drop-in dosyasıdır ve işi yapan kısım da bu dosyadır. WordPress, wp-content/object-cache.php dosyasını herhangi bir eklenti kodu çalışmadan önce, çok erken bir aşamada yükler; önbelleğin tüm istek boyunca kullanılabilir olmasının nedeni budur. Drop-in dosyası yerinde olmayan aktif bir eklenti hiçbir şeyi önbelleğe almaz.

Hata mesajları, sürecin hangi yarısının başarısız olduğunu size bildirir. Object cache could not be enabled., kopyalama işleminin başarısız olduğu anlamına gelir; yani wp-content, WP-CLI'ı çalıştıran kullanıcı tarafından yazılabilir değildir. A foreign object cache drop-in was found., başka bir önbellekleme eklentisinin o dosya adına zaten sahip olduğu anlamına gelir; çözüm ise wp redis update-dropin komutudur. Redis server is unreachable: ile biten ve ardından istemci hatası gelen bir mesaj, bağlantı ayarlarının yanlış olduğunu gösterir; bu durumda redis-cli ping bölümüne geri dönün.

Kopyalama işlemi izinler nedeniyle başarısız olursa, dosyayı manuel olarak yerleştirin ve sahipliğini web kullanıcısına verin.

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

Eklentiyi kaldırmak, drop-in dosyasını silmez. Önce wp redis disable komutunu çalıştırın; bu komut Object cache disabled. çıktısını verir ve dosyayı siler. Drop-in dosyası geride kalmışken eklenti dizinini silerseniz, site güncelleyecek bir eklenti olmaksızın eski önbellek kodunu çalıştırmaya devam eder.

wp-config.php içindeki bağlantı ayarları

Bunları, /* That's all, stop editing! */ yazan satırın üzerine ekleyin; çünkü bu satırdan sonra tanımlanan sabitler işleme alınmak için çok geç kalmış olur.

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

Unix socket için şemayı ve yolu ayarlayın. Bu durumda host ve port değerleri göz ardı edilir.

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

WP_REDIS_MAXTTL, her anahtar için saniye cinsinden bir geçerlilik süresi zorunlu kılar. allkeys-lru kullanıyorsanız buna ihtiyaç duymazsınız; ancak önbelleğe alınmış bir değerin ne kadar eski olabileceğine dair kesin bir üst sınır belirlemek istediğiniz durumlarda kullanışlıdır.

Tek bir Redis, birden fazla site: önekler ve veritabanları

Redis varsayılan olarak on altı adet numaralandırılmış veritabanı ve her birinin içinde düz bir anahtar alanı (keyspace) sunar. Önek kullanılmadan 0 numaralı veritabanına yönlendirilen iki WordPress kurulumu, aynı anahtar isimlerini aynı alana yazar; bu durumda bir site diğerinin ayarlarını okuyabilir ve kendi içeriğiymiş gibi sunabilir. Her siteye kendine özgü bir önek atayın.

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

Önek, anahtar isimlerini birbirinden ayırır. Veritabanı indeksi ise anahtar alanlarını ayırır; bu durum temizleme (flush) işlemi sırasında önemlidir: bir indeksi boşaltmak diğerlerine dokunmaz. Eklenti ayrıca, tüm veritabanını silmek yerine yalnızca önekinizle eşleşen anahtarları silen ve tarama maliyeti getiren WP_REDIS_SELECTIVE_FLUSH seçeneğini de belgeler.

Öneklerin ve indekslerin ayıramadığı tek şey bellektir. maxmemory ve tahliye politikası (eviction policy), tüm Redis örneği için geçerlidir; bu nedenle yoğun bir site, daha az kullanılan bir sitenin anahtarlarını bellekten atabilir ve hiçbir taraf bu durumu raporlamaz. Birbirini etkilememesi gereken siteler için, her biri kendi soketine ve kendi bellek limitine sahip ayrı Redis örnekleri kullanılmalıdır.

Staging ortamını üretim önbelleğinden ayrı tutun

Staging sitesi genellikle üretim dosyalarının ve veritabanının bir kopyasıdır; bu da wp-config.php kopyasının aynı öneki ve aynı veritabanı dizinini taşıdığı anlamına gelir. Staging sitesini aynı Redis sunucusuna yönlendirirseniz, üretim anahtarlarını staging değerleriyle üzerine yazar. Bu durumda test amaçlı bir fiyat veya değiştirilmiş bir seçenek, herhangi bir dağıtım veya iz bırakmadan canlı sitede görünür hale gelir.

Her ortamı manuel olarak farklılaştırın. Staging ortamının wp-config.php dosyasında şu değişikliği yapın:

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

Daha da iyisi, staging ortamına kendi Redis örneğini atayın veya nesne önbelleğini tamamen devre dışı bırakın. define( 'WP_REDIS_DISABLED', true );, çalışma zamanında önbelleği kapatır ve eklenti dosyasını yerinde bırakır; bu yöntem aynı zamanda bir hatanın önbellekten kaynaklanıp kaynaklanmadığını anlamanın en hızlı yoludur.

Eski eğitimlerde bunun için WP_CACHE_KEY_SALT ayarı kullanılıyordu. Eklentinin benioku dosyasında bu sabit değerin kullanımdan kaldırıldığı ve yerine WP_REDIS_PREFIX getirildiği belirtilmiştir, bu nedenle yeni ismi kullanın.

Güvenmek yerine doğrulayın

İşe eklentinin kendi tanılama araçlarıyla başlayın.

wp redis status

En önemli satır Drop-in satırıdır. Drop-in: Valid, WordPress'in bu eklenti dosyasını yüklediği anlamına gelir. Drop-in: Not installed ise kopyalama işleminin hiç gerçekleşmediğini ve yönetici paneli ne kadar yeşil görünürse görünsün sitede kalıcı bir önbellek olmadığını gösterir. Status bağlantı durumunu raporlar, Client ise kullanılan eklentiyi belirtir; burada Predis yerine PhpRedis kullanıldığını teyit edebilirsiniz.

Ardından doğrudan WordPress çekirdeğine sorun, çünkü çekirdek eklentinin ne düşündüğüyle ilgilenmez.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true), çekirdeğin harici bir nesne önbelleği (object cache) ile iletişim kurduğu anlamına gelir.

Daha sonra, yapılandırdığınız önek (prefix) ile anahtarların ulaştığını kanıtlayın.

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

Sitede gezinirken dbsize değerinin artması bunun kanıtıdır. Geçerli bir drop-in dosyasına rağmen anahtar sayısının sıfır olması, bağlantının sessizce başarısız olduğunu veya önekin düşündüğünüzden farklı olduğunu gösterir.

Son olarak, Redis'in sizin için ölçtüğü değerlere bakın.

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

İsabet oranı (hit ratio) keyspace_hits / (keyspace_hits + keyspace_misses) değeridir ve Redis dokümantasyonu bu formülü açıklar. Bu değeri okurken iki noktaya dikkat edin. Sayaçlar, son yeniden başlatmadan bu yana tüm örneği (instance) kapsar; bu nedenle aynı Redis örneğini paylaşan tüm sitelerin ve uygulamaların verileri birbirine karışır. Ayrıca, önbellek temizlendikten veya yeniden başlatıldıktan hemen sonraki oran hiçbir anlam ifade etmez, çünkü önbellek henüz dolmaktadır. Sistemin normal bir trafik gününü tamamlamasına izin verin.

Kendi değerlerinizi bir barındırma şirketinin yayınladığı isabet oranı veya sorgu sayısıyla kıyaslamayın. Bu veriler onların sitelerini ve eklenti setlerini tanımlar. Önemli olan, sayfa önbelleğinin (page cache) sunamayacağı bir sayfada, önbellek açık ve kapalıyken ölçtüğünüz kendi değerinizdir.

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

Bu testi, oturum açılmış bir çerez setiyle, önbellek kapalıyken (WP_REDIS_DISABLED) ve ardından açıkken birkaç kez çalıştırın. Aradaki fark sizin gerçek sonucunuzdur.

Redis WordPress'i ne zaman yavaşlatır

Yanlış politikaya sahip tam bir instance, yukarıda ele alınan en büyük sorundur: log dosyasındaki OOM command not allowed when used memory > 'maxmemory'. hatası ve hem veritabanı hem de önbellek için kaynak harcayan bir site.

Başka bir sunucudaki Redis ikinci sorundur. WordPress, tek bir istekte yüzlerce nesne önbelleği çağrısı yapar. Eğer bir istek 500 çağrı yapıyorsa ve her gidiş-dönüş 1 ms sürüyorsa, bu durum yerel bir soketin yaratmayacağı yarım saniyelik bir bekleme süresi oluşturur. Redis'i aynı sunucuda veya milisaniyenin altında gecikme süresine sahip özel bir ağda tutun.

Çok büyük bir otomatik yüklenen (autoloaded) seçenekler tablosu üçüncü sorundur ve eski sitelerde yaygındır. WordPress, otomatik yüklenen tüm seçenekleri tek bir anahtar olarak önbelleğe alır; bu nedenle her istekte bir megabaytlık veri bağlantı üzerinden geçer. Bunu ölçün:

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 yeni otomatik yükleme değerleri ekledi, bu nedenle yalnızca 'yes' ile eşleşen eski bir sorgu, modern bir kurulumda eksik raporlama yapar. Bir megabaytı aşan her şey, Redis'te değil, options tablosunda düzeltilmesi gereken bir sorundur.

Yeniden başlatma her şeyi boşaltır, bu nedenle systemctl restart redis-server sonrası dakikalar tamamen "miss" (isabetsiz) durumlarıdır ve veritabanı üzerinde yük oluşturur. Trafiğin düşük olduğu zamanlarda yeniden başlatın. Ayrıca bir nesne önbelleği, ziyaretçi sayfa yüklemelerinde wp-cron.php tetiklenmesini durdurmaz; bu da kendi başına yavaş isteklerin bir kaynağıdır: buradayken WP-Cron'u gerçek bir sistem cron işine taşıyın.

Bakım işlemleri

Seçenekleri veya tema kodunu değiştiren bir dağıtımın ardından wp cache flush ile önbelleği temizleyin. Eklenti güncellemesi sonrasında drop-in dosyası kendini güncellemediyse wp redis update-dropin komutunu çalıştırın; eski bir eklenti sürümüne ait drop-in dosyasının yeni bir eklenti ile kullanılması beklenmedik davranışlara yol açar. Canlı sunucuyu, saniyede bir satır çıktı veren redis-cli --stat ile izleyin. redis-cli monitor her komutu yazdırır ve yoğun bir sunucuda ciddi CPU tüketir; bu nedenle sadece bir sorunu yeniden oluştururken birkaç saniyeliğine kullanın ve ardından durdurun.

Bilmeniz gereken son bir değer daha var: redis-cli info clients, connected_clients değerini raporlar. PHP-FPM her worker için bir bağlantı tutar, bu nedenle bu rakam pm.max_children değerinizle uyumlu olmalı ve onu bir büyüklük sırası kadar aşmamalıdır. Eğer aşıyorsa, bir süreç bağlantıları açıyor ancak kapatmıyor demektir.

FAQ

Redis nesne önbelleği kullanıyorsam sayfa önbelleğine (page cache) hâlâ ihtiyacım var mı?

Evet, anonim trafik için gereklidir. Sayfa önbelleği, PHP çalıştırmadan depolanmış HTML içeriğini sunar; bu işlem, nesne önbelleği dolu olsa bile WordPress çalıştırmaktan her zaman daha az maliyetlidir. Nesne önbelleği ise sayfa önbelleğinin atlamak zorunda olduğu istekleri (oturum açmış kullanıcılar, sepet, ödeme ve wp-admin) yönetir. Bir mağaza veya üyelik sitesinde her ikisini de kullanmak avantajlıdır. Ziyaretçilerin hiçbir zaman oturum açmadığı bir sitede ise işin neredeyse tamamını sayfa önbelleği yapar.

WordPress için Redis'e ne kadar bellek ayırmalıyım?

Bir rakamı kopyalamak yerine kendi sunucunuzun kapasitesine göre karar verin. Toplam RAM miktarından MySQL tampon havuzunu (buffer pool) ve bağlantı başına düşen tamponları çıkarın. Ardından, bir PHP-FPM çalışanının kapladığı bellek miktarı ile pm.max_children değerini çarpıp bu sonucu da çıkarın. Çekirdek ve web sunucusu için birkaç yüz megabaytlık bir pay ayırın. Kalan miktarın bir kısmını Redis'e verin, bir gün süren trafikten sonra redis-cli info memory içindeki used_memory_human değerini kontrol ederek ayarlama yapın. Tek bir WordPress sitesi genellikle onlarca megabayt ile çalışır; bu nedenle 4 GB RAM'li bir sunucuda 256 MB maxmemory cömert bir başlangıçtır.

Redis nesne önbelleğini etkinleştirdikten sonra sitem neden yavaşladı?

Genellikle bunun nedeni, noeviction politikasıyla çalışan dolu bir örnektir. Redis yeni yazma işlemlerini reddeder ve OOM command not allowed when used memory > 'maxmemory'. hatası döndürür; bu durumda WordPress her değer için veritabanına geri döner ve üzerine bir de boşa giden Redis gidiş-dönüş süresini ekler. redis-cli config get maxmemory-policy değerini kontrol edin, allkeys-lru ayarını yapın ve maxmemory değerinin çok küçük olmadığından emin olun. Diğer yaygın nedenler, uzak bir sunucuda çalışan Redis'in istek başına yüzlerce gidiş-dönüş süresi eklemesi ve her istekte bağlantı üzerinden geçen, megabaytlarca boyuta ulaşan otomatik yüklenen (autoloaded) seçenek değerleridir.

Birden fazla WordPress sitesi tek bir Redis sunucusunu paylaşabilir mi?

Dikkatli olmak kaydıyla paylaşabilirler. Anahtar isimlerinin çakışmaması için her siteye benzersiz bir WP_REDIS_PREFIX verin ve bir sitenin önbelleğini temizlemenin diğerini boşaltmaması için ayrı bir WP_REDIS_DATABASE indeksi kullanın. Ancak bellek ortak kalır: maxmemory ve çıkarma (eviction) politikaları tüm örnek için geçerlidir; bu nedenle yoğun bir site, sessiz bir sitenin anahtarlarını bellekten silebilir. Birbirini etkilememesi gereken siteler için kendi limitlerine sahip ayrı Redis örnekleri kullanılmalıdır.

wp-content/object-cache.php dosyasını silmek güvenli mi?

Evet. Bu bir "drop-in" dosyasıdır, WordPress çekirdeğinin bir parçası değildir; silinmesi WordPress'i yerleşik istek bazlı önbelleğine döndürür. Site çalışmaya devam eder ancak veritabanı sorgu sayısı artar. Dosyayı temiz bir şekilde silen ve Object cache disabled. raporlayan wp redis disable komutunu tercih edin. Redis kapalıysa veya hatalı çalışıyorsa ve yönetici paneline erişemiyorsanız, dosyayı elle silmek doğru bir acil durum hamlesidir.