WordPress Redis Nesne Önbelleği Kurulumu

Redis nesne önbelleğinin WordPress için işlevi

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ı, bu mekanizmayı Redis ile iletişim kuran bir yapıyla değiştirir; böylece önbellek, istekler arasında 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, URL'in 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 ise o isteği daha az maliyetli hale getirir. Sayfa önbelleğinin dokunamadığı trafik için kullanılan araç budur: oturum açmış kullanıcılar, sepetler, ödeme işlemleri ve wp-admin. Bir WooCommerce mağazasında maliyetli trafiğin büyük bir kısmı bu alandadır.

Bu iki yapı birbirini tamamlar ve yoğun bir sitede her ikisi de bulunmalıdır. 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 Redis eklemek çok az fark yaratır.

Başlamadan önce dürüst bir sınırlama: Nesne önbelleği, yavaş bir sorguyu hızlandırmaz. Zaten çalışmış bir sorgunun tekrarını ortadan kaldırır. Önbellek ıskalamasından (miss) sonraki ilk istek tam maliyeti öder, bu nedenle indekslenmemiş bir sorgu çalıştıran bir eklenti, bu sorguyu önbellek ömrü boyunca bir kez çalıştırmaya devam eder.

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üresini düşürmek temel amaçtır; ağ üzerinden yapılan bir sıçrama 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ı adını 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 yanıtını 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 dosyasını okuyun.

php-redis, PECL üzerinden gelen C tabanlı bir eklenti olan PhpRedis'tir. Saf 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 havuzu yeniden başlatana kadar görünmez olacaktır.

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

Son kontrole dikkat edin: php -m, komut satırı PHP'sinin modüllerini listeler; FPM ise farklı bir modül kümesi yükleyebilir. Önemli olan kontrol, eklentinin kendi tanılamasıdır; bu aşağıda yer almaktadır.

Ekim 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 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'teki lisans değişikliğinden sonra çatallanan Valkey'i sunuyorsa, aynı protokolü kullandığı için bu kılavuzun WordPress tarafı aynı şekilde çalışır. Sunucudaki isimler aynı kalmaz. Debian'ın Valkey paketleri valkey-server, valkey-cli, /etc/valkey/valkey.conf ve bir valkey-server.service birimi kurar; redis-server, redis-cli veya /etc/redis/redis.conf kurmaz. Bir Valkey sunucusunda, aşağıdaki her komut ve yolda bu isimleri değiştirin; soket yolunu ve servis kullanıcısını soket adımlarından önce kendi yapılandırma dosyasından okuyun.

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 olan örnekler saatler içinde tarayıcılar tarafından bulunur; bu nedenle ağ ayarları, performans iyileştirmelerinden önce gelir.

/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 neyin dinlendiğini kontrol edin; çünkü yapılandırma dosyası bir beyandır, 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 soketi kullanmak loopback TCP'den daha verimlidir. Bu yöntemde TCP yığını devre dışı kalır 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

Soketin 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ı da PONG olmalıdır. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied ifadesi, grup değişikliğinin etkili olmadığını gösterir. id www-data dosyasını kontrol edin ve çalışan bir PHP-FPM sürecinin başlangıçtaki grup izinlerini koruduğunu unutmayın; yeniden başlatma işleminin listede yer almasının nedeni budur. Soketin çalıştığından emin olana 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 olay gerçekleştikten sonra gösterir, ancak o aşamada site zaten erişilemez durumdadır.

Toplam RAM miktarından başlayarak çıkarma işlemi yapın. MySQL veya MariaDB, innodb_buffer_pool_size ve bağlantı başına düşen tampon bellekleri rezerve eder. PHP-FPM, pm.max_children değerinin bir worker'ın gerçek resident boyutuyla (eklenti yoğun bir sitede genellikle 64 MB ile 128 MB arası) çarpımı kadar maliyet oluşturur. Çekirdek ve web sunucusu için birkaç yüz megabaytlık pay bırakılmalıdır. Geriye kalan miktar sizin üst sınırınızdır ve Redis bu payın 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ında kalıyorsa, limiti düşürün ve RAM'i daha verimli kullanacak olan MySQL'e geri verin. Eğer limitinize dayanıyorsa 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 ayarı anlık olarak uygulanır ancak yeniden başlatmada unutulur; bu, yapılandırma dosyası olmayan bir sysctl -w ile aynı tuzaktır. Dosyayı düzenleyin, ardından sudo systemctl restart redis-server komutunu çalıştırın ve değeri tekrar okuyarak doğrulayın. İ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 değerinin üzerinde tutun, asla eşit yapmayın; çünkü cgroup sınırı, anahtar silmek (evict) yerine süreci doğrudan sonlandırır. Eğer Redis, WordPress ile yan yana 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 host üzerinde ç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 çevrimdışı olmaz, 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 siteye önbellek ekledikten sonra yavaşlama yaşanırsa OOM command not allowed ifadesini grep ile arayın.

allkeys-lru bu iş için doğru varsayılandır. Redis, bellek dolduğunda en az kullanılan anahtarı (LRU) siler; bir nesne önbelleğinin tam olarak ihtiyaç duyduğu şey budur, çünkü içindeki her değer MySQL'de hâlâ var olan verilerin bir kopyasıdır. Bir anahtarı kaybetmek tek bir sorguya mal olur. Yazma işlemini reddetmek ise, birisi fark edene kadar her istekte her sorguya mal 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 çoğu nesne önbelleği girdisini TTL olmadan depolar, bu nedenle bir nesne önbelleğinde volatile-lru kullanmak belleğin dolmasına ve yazma işlemlerinin reddedilmesine neden olabilir. 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

Redis 7.0 için paketlenmiş redis.conf, save satırını yorum satırı olarak bırakır ancak bu, anlık görüntüleri (snapshots) kapatmaz. Bir save satırı olmadığında, Redis yerleşik RDB zamanlamasına geri döner: en az bir anahtar değiştiyse bir saat sonra, 100 anahtar değiştiyse beş dakika sonra ve 10.000 anahtar değiştiyse 60 saniye sonra anlık görüntü alır. Append-only dosyası kapalı kalır. Eski kılavuzlar, Redis 6 varsayılanı olan save 900 1 değerinden bahseder. Saf bir nesne önbelleği için anlık görüntülerin bir faydası yoktur. Veri tanım gereği yeniden oluşturulabilir ve yirmi dakika öncesine ait bir dosyadan geri yüklenen önbellek, WordPress'in güveneceği eski değerler kümesidir.

Anlık görüntülerin bir maliyeti de vardır. BGSAVE süreci çatallar (fork) ve copy-on-write mekanizması, çocuk süreç yazma işlemi yaparken bellek kullanımının aniden 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 genellikle başlangıçta şu uyarı çıkar; bu, Redis'in çatallama işleminin daha sonra başarısız olma ihtimalinin yüksek olduğunu size 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ş geldiğini 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) ister, kalıcı veriler ise anahtarların tutulmasını ister; maxmemory ve silme politikası tek bir veritabanı dizinine değil, tüm örneğe uygulanır. İki farklı soket üzerinde iki ayrı örnek, 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; bu da wp-content dizininin WP-CLI çalıştıran kullanıcı tarafından yazılabilir olmadığını gösterir. A foreign object cache drop-in was found., başka bir önbellekleme eklentisinin o dosya adını zaten kullandığı 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 kısmına 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ı kaldırmaz. Ö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 kalırken eklenti dizinini silerseniz, site güncelleyecek bir eklenti olmadan eski önbellek koduyla çalışmaya 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 ihtiyacınız yoktur; ancak önbelleğe alınmış bir değerin ne kadar eski olabileceğine dair kesin bir üst sınır belirlemek istediğinizde kullanışlıdır.

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

Redis varsayılan olarak on altı numaralı veritabanı sunar ve her birinin içinde düz bir anahtar alanı (keyspace) bulunur. Önek (prefix) olmadan 0 numaralı veritabanına yönlendirilen iki WordPress kurulumu, aynı anahtar isimlerini aynı alana yazar; bu nedenle bir site diğerinin ayarlarını okuyabilir ve sunabilir. Her siteye kendi önekini verin.

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

Önek, anahtar isimlerini birbirinden ayırır. Veritabanı dizini ise anahtar alanlarını ayırır; bu, temizleme (flush) sırasında önemlidir: bir dizini boşaltmak diğerlerine dokunmaz. Eklentinin benioku dosyası, tüm veritabanı yerine yalnızca önekinizle eşleşen anahtarları temizleyen WP_REDIS_SELECTIVE_FLUSH değerini de listeler; ancak bu sabit, önceden haber verilmeksizin bozulabilecek desteklenmeyen seçenekler altında dosyalanmıştır ve arkasındaki Lua betiğinin yavaş olduğu konusunda uyarıda bulunur. Site başına ayrı bir veritabanı dizini, temizlemeleri birbirinden ayırmanın daha güvenli yoludur.

Öneklerin ve dizinlerin ayırmadığı şey bellektir. maxmemory ve silme politikası tüm örneğe bir bütün olarak uygulanır; bu nedenle yoğun bir site, sakin bir sitenin anahtarlarını dışarı itebilir ve ikisi de bunu raporlamaz. Birbirini etkilememesi gereken siteler, her biri kendi soketine ve kendi limitine sahip ayrı Redis örneklerine ihtiyaç duyar.

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 üzerinde aynı öneki ve aynı veritabanı indeksini taşıdığı anlamına gelir. Eğer staging sitesini aynı Redis örneğine yönlendirirseniz, üretim anahtarlarının üzerine staging değerlerini yazar. Bu durumda, herhangi bir dağıtım veya iz olmaksızın canlı sitede test fiyatları veya değiştirilmiş seçenekler görünür hale gelir.

Her ortamı manuel olarak yapılandı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 iyisi, staging ortamına özel bir Redis örneği atayın veya hiç nesne önbelleği kullanmayın. define( 'WP_REDIS_DISABLED', true ); ayarı, önbelleği çalışma zamanında devre dışı bırakır ve drop-in dosyasını yerinde tutar; 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

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, 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 bildirir; Client ise kullanılan eklentiyi belirtir; Predis yerine PhpRedis kullanıldığını buradan teyit edebilirsiniz.

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

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ı sıfırsa, bağlantı sessizce başarısız oluyor veya önek düşündüğünüzden farklı olabilir.

Son olarak, Redis'in sizin için ölçtüğü verilere 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 belgeleri bu formülü açıklar. Bu veriyi iki uyarıyı dikkate alarak okuyun. Sayaçlar, son yeniden başlatmadan bu yana tüm örneği kapsar; bu nedenle aynı Redis örneğini paylaşan tüm siteleri ve uygulamaları birbirine karıştırır. Ayrıca, bir temizleme (flush) veya yeniden başlatma işleminden hemen sonraki oran hiçbir anlam ifade etmez, çünkü önbellek henüz dolmaktadır. Sistemin normal bir trafik gününde çalışmasına izin verin.

Kendi değerinizi 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) sunamadığı bir sayfada, önbellek açıkken 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/

Bunu, 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, elde ettiğiniz sonuçtur.

Redis WordPress'i yavaşlattığında

Yanlış yapılandırılmış bir politika ile çalışan tam bir Redis örneği en büyük sorundur; yukarıda bahsedilen OOM command not allowed when used memory > 'maxmemory'. hatası loglarda görülür ve site hem veritabanı hem de önbellek için kaynak tüketir.

İkinci sorun ise Redis'in başka bir sunucuda çalışmasıdır. WordPress tek bir istekte yüzlerce nesne önbelleği (object cache) çağrısı yapar. Eğer bir istek 500 çağrı yapıyorsa ve her gidiş-dönüş süresi 1 ms ise, 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. Aynı sunucu durumunda çekirdekten ne kadar kazanç sağlandığı ayrı bir konudur: Linux 7.2 ile eklenen önbellek duyarlı zamanlama, PHP-FPM ve Redis gibi yoğun iletişim kuran süreçleri aynı önbelleği paylaşan çekirdeklerde tutmaya çalışır; bir VPS konuğu, bare metal sunucuya kıyasla bu avantajdan daha az yararlanır.

Üçüncü sorun ise devasa boyuttaki otomatik yüklenen (autoloaded) seçenekler tablosudur; bu durum 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 durum, Redis'te değil, options tablosunda düzeltilmesi gereken bir sorundur.

Yeniden başlatma işlemi her şeyi temizler, bu nedenle systemctl restart redis-server sonrası geçen dakikalar tamamen önbellek ıskalamaları (miss) ve veritabanı yükü ile geçer. Yeniden başlatma işlemini trafiğin düşük olduğu zamanlarda yapın. Ayrıca bir nesne önbelleği, ziyaretçi sayfa yüklemelerinde wp-cron.php tetiklenmesini durdurmaz; bu durum 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. Bir eklenti güncellemesinden sonra 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 daha yeni bir eklenti ile çalışması, beklenmedik davranışların temel nedenidir. Saniyede bir satır çıktı veren redis-cli --stat ile canlı sunucuyu 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.

Bilinmesi gereken son bir değer: redis-cli info clients, connected_clients hakkında rapor sunar. PHP-FPM her worker için bir bağlantı tutar, bu nedenle bu değer pm.max_children ile 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. Bir sayfa önbelleği, PHP çalıştırmadan depolanmış HTML'i sunar; bu, WordPress'i sıcak bir nesne önbelleği ile çalıştırmaktan her zaman daha az maliyetlidir. Nesne önbelleği, sayfa önbelleğinin atlamak zorunda olduğu istekleri yönetir: oturum açmış kullanıcılar, sepetler, ödeme işlemleri ve wp-admin. Bir mağaza veya üyelik sitesinde her ikisini de çalıştırmak faydalıdır. Ziyaretçilerin asla oturum açmadığı bir sitede ise sayfa önbelleği işin neredeyse tamamını yapar.

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

Bunu bir rakamı kopyalayarak değil, kendi sunucunuzun kapasitesine göre belirleyin. Toplam RAM miktarını alın, MySQL buffer pool ve bağlantı başına düşen tampon bellekleri çıkarın, pm.max_children ile bir PHP-FPM çalışanının bellek kullanımını çarpıp toplamdan düşün, çekirdek ve web sunucusu için birkaç yüz megabayt daha ayırın. Kalan kısmın bir bölümünü Redis'e verin, ardından bir günlük trafikten sonra redis-cli info memory içindeki used_memory_human değerini kontrol edip ayarlama yapın. Tek bir WordPress sitesi genellikle onlarca megabaytlık alana yerleşir, 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ı?

Genel neden, noeviction politikasını çalıştıran dolu bir örnektir. Redis yeni yazma işlemlerini reddeder ve OOM command not allowed when used memory > 'maxmemory'. 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, istek başına yüzlerce gidiş-dönüş süresinin biriktiği uzak bir sunucudaki Redis sunucusu 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 atayın. Paylaşmaya devam ettikleri şey bellektir: maxmemory ve çıkarma (eviction) politikası tüm örnek için geçerlidir; bu nedenle yoğun bir site, sessiz bir sitenin anahtarlarını bellekten çıkarabilir. Birbirini etkilememesi gereken siteler, kendi limitlerine sahip ayrı Redis örneklerine ihtiyaç duyar.

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 ve silinmesi WordPress'i yerleşik istek bazlı önbelleğine döndürür. Site çalışmaya devam eder, sadece daha fazla veritabanı sorgusu yapar. Dosyayı temiz bir şekilde silen ve Object cache disabled. raporlayan wp redis disable komutunu tercih edin. Redis kapalıysa veya hatalı davranıyorsa ve yönetici paneline erişemiyorsanız, dosyayı elle silmek doğru bir acil durum müdahalesidir.