WordPress Nesne Önbelleği: Redis, Memcached veya Hiçbiri

Her WordPress sayfa yüklemesi onlarca veritabanı sorgusu çalıştırır. Seçenekler, kullanıcı meta verileri, transient'ler, yazı verileri — aynı şeyler tekrar tekrar çekilir. WordPress object cache tam da burada devreye girer: sorgu sonuçlarını bellekte saklayarak WordPress'in her seferinde veritabanına gitmesini engeller.
İçindekiler
Makale başlıklarına göz atarak istediğiniz içeriğe kolaylıkla ulaşın.

Her WordPress sayfa yüklemesi onlarca veritabanı sorgusu çalıştırır. Seçenekler, kullanıcı meta verileri, transient’ler, yazı verileri — aynı şeyler tekrar tekrar çekilir. WordPress object cache tam da burada devreye girer: sorgu sonuçlarını bellekte saklayarak WordPress’in her seferinde veritabanına gitmesini engeller.

Ancak çoğu “Redis vs Memcached” makalesi yanlış yapıyor — object cache’in gerçekte ne yaptığını açıklamadan doğrudan karşılaştırmaya atlıyorlar. Bunu düzeltelim.

WordPress Object Cache Gerçekte Ne Yapar?

WordPress 2.5’ten bu yana yerleşik bir object cache’e sahiptir. WordPress her bir seçenek getirdiğinde, yazı meta verisi yüklediğinde veya kullanıcı verisi aldığında, sonucu wp_cache_set() ile bir PHP dizisinde saklar. Aynı veri tekrar gerektiğinde wp_cache_get() çağrısıyla başka bir SQL sorgusu çalıştırmak yerine bellekten alır.

Çoğu kişinin kaçırdığı nokta şu — varsayılan object cache yalnızca tek bir istek süresince yaşar. Sayfa yüklenmeyi bitirdiğinde, önbelleğe alınmış tüm veri kaybolur. Bir sonraki ziyaretçi aynı sorguları baştan tetikler.

Bu, varsayılan davranıştır. Eklenti gerekmez. WordPress bunu kutudan çıktığı haliyle yapar.

Kalıcı (persistent) object cache oyunu değiştirir. Veriyi istekle birlikte ölen bir PHP dizisinde saklamak yerine, Redis veya Memcached gibi harici bir bellek deposunda saklar. Artık önbelleğe alınmış veri istekler arasında hayatta kalır. Ziyaretçi A ana sayfayı yükler ve önbelleği doldurur. Ziyaretçi B, veritabanına hiç dokunmadan önbelleğe alınmış sürümü alır.

Mekanizma bir WordPress “drop-in”ıdır — wp-content/ klasörüne yerleştirilen object-cache.php adlı özel bir dosya. WordPress her istekte bu dosyayı kontrol eder. Varsa, varsayılan WP_Object_Cache sınıfı yerine onu kullanır. Redis veya Memcached eklentileri sisteme bu şekilde bağlanır.

Kalıcı Object Cache’e Gerçekten Ne Zaman İhtiyacınız Var?

İhtiyacınız olan durumlar

  • Siteniz WooCommerce veya oturum açmış kullanıcılarla çalışan bir üyelik eklentisi kullanıyorsa (sayfa önbelleği kimliği doğrulanmış isteklerde pek yardımcı olmaz)
  • Karmaşık sorgulara sahip yüksek trafikli bir siteniz varsa — özellikle sayfa önbelleğine alınamayan dinamik sayfalar
  • Yönetim paneliniz yavaşsa — object cache arka ucu dramatik şekilde hızlandırır
  • Sayfa başına yüzlerce veritabanı sorgusu görüyorsanız

İhtiyacınız olmayan durumlar

  • Çoğunlukla anonim ziyaretçilere ve bir sayfa önbelleği eklentisine sahip basit bir blog işletiyorsanız
  • Hosting’iniz Redis veya Memcached desteklemiyorsa (paylaşımlı hosting genellikle desteklemez)
  • Günlük 1.000’den az ziyaretçiniz varsa ve karmaşık eklenti kullanmıyorsanız

Object cache, sayfa önbelleğini tamamlar — onun yerini almaz. Sayfa önbelleği tam HTML sayfaları sunar. Object cache ise sayfa önbelleğine alınamayan içerik için veritabanı sorgularını azaltır.

Redis vs. Memcached: Gerçek Farklar

Veri Kalıcılığı

Redis veriyi diske yazabilir. Redis sunucunuz yeniden başlarsa, önbellek son anlık görüntüden geri yüklenebilir. Memcached tamamen bellek içidir — yeniden başlatın ve her şey gider.

WordPress için bu, düşündüğünüzden daha az önemlidir. Soğuk bir önbellek birkaç sayfa yüklemesiyle kendini yeniden oluşturur. Ancak milyonlarca önbellek anahtarına sahip büyük bir WooCommerce mağazası işletiyorsanız, sıcak yeniden başlatma güzel bir özellik.

Veri Yapıları

Redis string, liste, küme, sıralı küme, hash ve daha fazlasını destekler. Memcached yalnızca anahtar-değer çifti ve string değerlerle sınırlıdır.

Temel WordPress object cache’i için bu fark çoğunlukla önemsizdir — WordPress her iki durumda da serileştirilmiş PHP verisini string olarak saklar. Ancak önbelleği doğrudan kullanan özel işlevsellik oluşturuyorsanız, Redis daha fazla esneklik sunar.

Bellek Yönetimi

Memcached bir slab allocator kullanır. Belleği parçalar halinde önceden ayırır ve öğeleri en yakın eşleşen slab boyutuna atar. Verimlidir ancak önbelleğe alınan öğeleriniz boyut olarak çok farklılık gösterdiğinde bellek israfına neden olabilir.

Redis standart sistem allocator’ları (varsayılan olarak jemalloc) kullanarak talep üzerine bellek ayırır. Daha esnek, ancak zamanla parçalanabilir.

Her ikisi de maksimum bellek sınırı belirlemenize izin verir. Her ikisi de sınıra ulaştığında eski anahtarları çıkarır. Redis daha fazla çıkarma politikası sunar (LRU, LFU, rastgele, volatile-tabanlı).

Replikasyon ve Yüksek Erişilebilirlik

Redis yerleşik replikasyona sahiptir. Otomatik yük devretme için Redis Sentinel veya yatay ölçeklendirme için Redis Cluster kurabilirsiniz. Memcached‘in yerel replikasyonu yoktur — harici araçlara ihtiyacınız olur.

Çoğu WordPress sitesi için bu abartılı. Ancak bir yük dengeleyici arkasında yüksek erişilebilirlik kurulumu çalıştırıyorsanız, Redis altyapıyı basitleştirir.

Gözlemlenebilirlik

Redis burada kazanır. Anahtarları inceleyebilir, anahtar başına bellek kullanımını kontrol edebilir, MONITOR ile komutları gerçek zamanlı izleyebilir ve INFO ile ayrıntılı istatistikler alabilirsiniz. Memcached’in stats komutu temel bilgileri verir ancak tek tek anahtarları veya boyutlarını kolayca göremezsiniz.

WordPress Eklenti Ekosistemi

Redis daha iyi WordPress eklenti desteğine sahiptir. Object Cache Pro (ücretli) ve Redis Object Cache (ücretsiz) olgun ve iyi bakımlıdır. Memcached için seçenekler daha sınırlı ve daha az aktif geliştirilmektedir.

Hız Karşılaştırma

ÖzellikRedisMemcached
Veri kalıcılığıEvet (RDB/AOF)Hayır
Veri yapılarıString, liste, küme, hash vb.Yalnızca string
ReplikasyonYerleşik (Sentinel, Cluster)Yok (harici araç gerektirir)
Bellek verimliliğiİyi, parçalanabilirİyi, slab allocator
Maks. bellek çıkarma6 politika (LRU, LFU vb.)Yalnızca LRU
Anahtar incelemeTam (SCAN, DEBUG OBJECT)Sınırlı
Çoklu iş parçacığıTek iş parçacıklı (6.0+’da I/O threadleri)Çoklu iş parçacıklı
WordPress eklentileriMükemmelSınırlı

Öneri

Redis kullanın. Temel anahtar-değer işlemleri için daha hızlı olduğundan değil — anlamlı bir fark yok. Ancak ekosistemi, hata ayıklama araçları ve WordPress eklenti seçenekleri daha iyi bakımlı olduğu için.

Memcached’i tercih edeceğim tek senaryo: sunucunuzda zaten çalışıyor ve altyapıya dokunmak istemiyorsanız. Sıfırdan kurulum yapıyorsanız, Redis doğru tercih.

Object Cache’inizin Çalıştığını Doğrulayın

Drop-in Durumunu Kontrol Edin

WP yönetim panelinde Eklentiler → Drop-in’ler‘e gidin. object-cache.php dosyasının orada listelendiğini görmelisiniz. Eksikse, önbellek eklentiniz ne derse desin kalıcı önbellek aktif değildir.

WP-CLI ile de kontrol edebilirsiniz: wp cache type komutu Redis veya Memcached döndürmelidir. WP_Object_Cache diyorsa, varsayılan kalıcı olmayan önbelleği çalıştırıyorsunuz.

İsabet Oranlarını Kontrol Edin

Sağlıklı bir object cache %85’in üzerinde isabet oranına sahip olmalıdır. Daha düşük rakamlar görüyorsanız, bir sorun var — ya önbellek çok küçük, anahtarlar çok hızlı sona eriyor ya da bir eklenti sürekli önbelleği temizliyor.

Redis ile komut satırından kontrol edebilirsiniz: redis-cli INFO stats | grep keyspacekeyspace_hits ve keyspace_misses sayıları gerçek durumu anlatır. Hesaplama: hits / (hits + misses) × 100.

Sık Karşılaşılan Sorunlar

object-cache.php Çakışması

Aynı anda yalnızca bir object-cache.php drop-in’i var olabilir. Redis Object Cache yüklerseniz ama zaten bir Memcached drop-in’i veya yönetilen hosting sağlayıcınızın kendi drop-in’i varsa, çakışma yaşarsınız. Kurulumdan önce wp-content/object-cache.php dosyasının zaten var olup olmadığını ve kimin koyduğunu kontrol edin.

Düşük Bellek Sınırları

Varsayılan Redis maxmemory genellikle 64MB’dır. Bir WooCommerce mağazası veya çok eklentili bir site için bu hızla dolar. Dolduğunda Redis anahtar çıkarmaya başlar, isabet oranınız düşer ve veritabanını yeniden zorlamaya başlarsınız. Çoğu WordPress sitesi için 128-256MB iyi bir başlangıç noktasıdır.

Canlıda SAVEQUERIES ve WP_DEBUG

WP_DEBUG veya SAVEQUERIES etkinse, Object Cache Pro ve benzeri eklentiler her önbellek işlemi için backtrace saklar. Bu son derece bellek yoğundur ve bellek tükenmesinden PHP ölümcül hatalarına neden olabilir. Canlıda asla çalıştırmayın. wp-config.php dosyanızda her ikisinin de false olduğundan emin olun.

Sürekli Önbellek Temizleyen Eklentiler

Bazı eklentiler wp_cache_flush() çağrısını çok agresif yapar. Her temizlemede her şeyin veritabanından yeniden oluşturulması gerekir. İsabet oranınız şüpheli derecede düşükse, büyük olasılıkla budur. Redis komutlarını izleyerek suçluyu yakalayabilirsiniz: redis-cli MONITOR | grep FLUSHDB

Transient Davranış Değişiklikleri

Kalıcı bir object cache yüklediğinizde, WordPress transient’leri artık veritabanında değil object cache’te saklar. Bu genellikle iyidir (daha az veritabanı şişkinliği), ancak transient’ler artık önbellek çıkarmasına tabidir. Transient’lerin günlerce kalmasına bağımlı eklentileriniz varsa, Redis bellek baskısı altında bunları çıkardığında bozulabilirler.

Serileştirme Yükü

WordPress her nesneyi önbelleğe almadan önce serileştirir. 500 yazılık karmaşık bir WP_Query sonucu gibi büyük nesneler için serileştirme/serileştirme çözme maliyeti, sorguyu tekrar çalıştırmaktan daha yüksek olabilir. Nadir, ancak özel veri önbelleğe alıyorsanız bilmenizde fayda var.

“Hiçbir Şey Yapma” Seçeneği

Bazen en iyi object cache, hiç kalıcı object cache olmamaktır.

Varsayılan WordPress object cache her istek içinde çalışmaya devam eder. Siteniz çoğunlukla anonim ziyaretçilerden oluşuyor ve bir sayfa önbelleği isteklerin %95’ini karşılıyorsa, Redis karmaşıklığı eklemeye değmeyebilir. Sayfa önbelleğini atlayan sayfalar (yönetim paneli, AJAX, WP-Cron) yığınınıza başka bir hizmet eklemeyi haklı kılacak kadar veritabanı yükü oluşturmayabilir.

Gerçek veritabanı sorgu sayınıza ve yükünüze bakarak başlayın. Sayfa başına 50-80 sorgu görüyorsanız ve veritabanı sunucunuz zorlanmıyorsa, Redis’e hiç ihtiyacınız olmayabilir. Önce veritabanınızı optimize etmeye odaklanın — şişmiş tabloları temizleyin, eksik indeksleri düzeltin, otomatik yüklenen veriyi azaltın.

Object cache bir araçtır, bir gereklilik değil. Veriler gerekli olduğunu gösterdiğinde kullanın.