Redis Cache TTFB'yi Nasıl Düşürür?

Redis'in nesne önbelleği olarak işlevi

Redis bir veritabanı değil, bellek içi veri yapısı deposudur (in-memory data structure store). Nesne önbelleği modunda kullanıldığında, PHP uygulamanızın hesapladığı ya da veritabanından çektiği sonuçları, bir sonraki aynı istekte kullanılmak üzere RAM'de saklar. Disk I/O yoktur; ağ üzerinden MySQL'e gitmek gerekmez.

Mekanizma basittir. Uygulama bir veriyi ilk kez istediğinde önbellekte bulamaz, buna cache miss denir; veritabanından çeker ve sonucu bir anahtar-değer çifti olarak Redis'e yazar. Sonraki istekte aynı anahtarı soran uygulama Redis'ten mikrosaniyeler içinde yanıt alır, buna cache hit denir. TTFB üzerindeki etki, cache hit oranı yükseldikçe belirginleşir.

Redis'i yalnızca oturum depolaması veya kuyruk sistemi olarak kullananlar, nesne önbelleği modunun ne anlam ifade ettiğini atlayabilir. İki kullanım birbirinden ayrıdır: oturum verisi kullanıcıya özeldir ve çoğunlukla küçüktür; nesne önbelleği ise uygulama genelinde paylaşılan, pahalı hesaplamaların sonuçlarını tutar.

TTFB üzerindeki etkinin mekanizması

TTFB, sunucunun isteği aldığı andan ilk byte'ı gönderdiği ana kadar geçen süredir. Bu sürenin içinde PHP kodunun çalışması, veritabanı sorgularının tamamlanması ve yanıtın oluşturulması yer alır. Redis nesne önbelleği bu zincirin veritabanı ayağını kısaltır.

Tipik bir WordPress sayfası, menüler, widget'lar, gönderi meta verileri ve seçenekler için onlarca ayrı veritabanı sorgusu üretir. Her sorgu, MySQL sürecinin sorguyu ayrıştırması, indeksi taraması, satırları döndürmesi ve TCP üzerinden yanıt göndermesi anlamına gelir. Yük yokken bu döngü birkaç milisaniye sürebilir; ancak sunucu meşgulken bu süre artar.

Redis devreye girdiğinde sorguların büyük bölümü önbellekten karşılanır. PHP işlem süresi kısalır, MySQL bağlantı havuzu daha az baskıya maruz kalır. Yalın bir ifadeyle: Redis, veritabanını devre dışı bırakmaz; veritabanına gidilmesi gereken durumları azaltır.

Ağ gecikmesi, TLS el sıkışması veya CDN yapılandırması TTFB'nin başka bileşenleridir; Redis bunlara dokunmaz. Salt veritabanı sorgu gecikmesini hedef alır. Çok oturumlu, kişiselleştirilmiş veya dinamik içeriklerde önbellek bypass oranı yüksek olursa etki azalır; statik, az değişen içeriklerde ise cache hit oranı yüksek olduğundan fark belirginleşir.

WordPress'te Redis kurulumu ve yapılandırması

WordPress'te Redis nesne önbelleğini etkinleştirmek iki bileşen gerektirir: Redis sunucusu ve bir object cache drop-in dosyası. Drop-in, WordPress'in wp-content/object-cache.php konumuna yerleştirilen özel bir dosyadır; WordPress bu dosya mevcutsa onu otomatik olarak yükler.

En yaygın kullanılan bağlayıcı, phpredis PHP eklentisi veya predis PHP kütüphanesidir. Sunucu tarafında Redis'in kurulu ve erişilebilir olması gerekir; çoğu zaman 127.0.0.1:6379 adresinde çalışır. Yönetilen barındırma sağlayıcıları genellikle Redis'i ek bir servis olarak sunar.

Kurulumdan sonra wp-config.php dosyasına birkaç sabit eklenir:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

Ardından WP-CLI ile etkinleştirmek mümkündür:

wp redis enable

Çalıştığını doğrulamanın güvenilir yolu, wp redis status çıktısını incelemek ve HTTP yanıt başlıklarında drop-in tarafından eklenen durum başlıklarının görünmesini beklemektir. WordPress yönetici panelinde de durum göstergesi belirginleşir.

TTL (time to live) değeri, önbelleğe alınan verilerin ne kadar süre geçerli kalacağını belirler. Varsayılan olarak çoğu object cache uygulaması TTL'yi birkaç saat ile bir gün arasında tutar. İçerik sık güncelleniyorsa TTL'yi kısaltmak ya da güncelleme anında önbelleği temizlemek gerekir; aksi hâlde ziyaretçilere bayat veri servis edilir.

Özel PHP uygulamalarında Redis entegrasyonu

WordPress dışında, özel bir PHP uygulaması veya çerçeve kullanıyorsanız Redis entegrasyonu doğrudan phpredis eklentisi ya da predis/predis Composer paketi üzerinden yapılır.

Temel kullanım şu kalıpla özetlenebilir:

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$key = 'user_profile_' . $userId;
$data = $redis->get($key);

if ($data === false) {
    $data = $db->query('SELECT * FROM users WHERE id = ?', [$userId]);
    $redis->setex($key, 3600, serialize($data));
}

return unserialize($data);

setex, TTL ile birlikte veri yazan komuttur; anahtar bir saat sonra otomatik olarak silinir. Bu basit kalıp, tekrarlayan kullanıcı profili sorgularını tamamen önbellekten karşılar.

Laravel kullananlar için Cache::remember() metodu aynı mantığı uygular; arka uç olarak Redis seçildiğinde, .env dosyasında CACHE_DRIVER=redis tanımlandığında tüm cache çağrıları Redis'e yönlenir. Symfony'de Cache component benzer bir arayüzle çalışır.

Çerçeve hangisi olursa olsun, sorgunun önbelleğe alınmaya değer olup olmadığını değerlendirmek önemlidir. Sık çalışan, hesaplama maliyeti yüksek ve nadiren değişen sorgular ideal adaylardır. Her sorguyu körlemesine önbelleklemek, güncelleme sorunları yaratır ve belleği gereksiz yere tüketir.

Ne zaman işe yarar, ne zaman gereksiz kalır

Redis nesne önbelleği, yüksek cache hit oranı sağlayan senaryolarda etkilidir. Bunu belirleyen üç etken vardır: içeriğin ne sıklıkla değiştiği, kullanıcı başına kişiselleştirme miktarı ve toplam sorgu sayısı.

Anasayfa, kategori sayfaları ve durağan içerikler, az değişen ve çok ziyaret edilen yapılar olduğundan cache hit oranı yüksektir. Redis bu senaryolarda TTFB'yi belirgin biçimde düşürür. Tersine, kişiselleştirilmiş veya oturum bağımlı sayfalarda cache hit oranı düşer; sepet içerikleri, kişisel öneriler ve hesap sayfaları bunların başında gelir. Önbellek anahtarı kullanıcı kimliğiyle farklılaştığında, yani her kullanıcı için ayrı bir cache girdisi oluştuğunda, Redis bellek tüketimini artırır ama TTFB'ye anlamlı bir katkı yapmaz.

Tersine etki yaratan bir durum da şudur: Redis sunucusu ayrı bir makinede çalışıyorsa ve ağ gecikmesi yüksekse, Redis yanıt süreleri zaman zaman yerel veritabanı sorgusundan daha yavaş olabilir. Aynı sunucuda veya yerel ağda çalışan Redis bu riski ortadan kaldırır.

Sayfa önbelleği ile nesne önbelleği aynı şey değildir. Sayfa önbelleği, PHP'nin hiç çalışmadığı tam HTML yanıtlarını saklar; nesne önbelleği ise PHP çalışırken veritabanı sorgularını kısaltır. İkisi birlikte kullanılabilir ve çoğu üretim ortamında öyle kullanılır. Salt Redis kurulumu yapıp sayfa önbelleklemesini atlamak, daha yüksek etkili fırsatı gözden kaçırmak anlamına gelebilir.

Redis'in TTFB katkısını izole ederek ölçmek

Redis'in TTFB'ye etkisini doğru ölçmek için değişkeni izole etmek gerekir. Doğru yöntem, aynı uç nokta için Redis etkin ve devre dışı durumlarını karşılaştırmaktır.

Temel bir ölçüm curl ile yapılabilir:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/hedef-sayfa

Redis etkinken ve devre dışıyken aynı komutu çalıştırarak farkı görmek mümkündür. Yeterli. Doğal varyasyonu dengelemek için her ölçüm beş ila on kez tekrarlanmalı, medyan değer kullanılmalıdır; tek bir ölçüm yanıltıcı olabilir.

WordPress'te wp redis status komutu hit ve miss sayılarını gösterir. Yüksek miss oranı, önbelleğin henüz ısınmadığını ya da TTL'nin çok kısa ayarlandığını işaret eder. İlk birkaç istek her zaman miss olur; cache ısındıktan sonraki ölçüm anlamlıdır.

Sunucu taraflı APM (Application Performance Monitoring) araçları sorgu bazında süre gösterir. Hangi sorguların en uzun sürdüğünü görmek ve Redis'in bunları bypass edip etmediğini doğrulamak için bu veriler kullanılabilir. Önbellek etkinleştirilmeden önce hangi sorgular TTFB'yi şişiriyor, bunu anlamak kurulumun değerini önceden tahmin ettirir.

Sık yapılan yapılandırma hataları

Redis kurulumu tamamlanmış görünse de beklenen TTFB düşüşü gelmiyorsa çoğunlukla birkaç yapılandırma sorunu söz konusudur.

maxmemory politikası ayarlanmamışsa Redis bellek dolduğunda eski girdileri silmek yerine yeni yazma işlemlerini reddedebilir. maxmemory-policy allkeys-lru veya volatile-lru değeri, önbellek kullanımı için doğru seçimdir; aksi hâlde Redis nesne önbelleği olarak değil, sonsuz büyüyen bir depo olarak davranır ve bellek tükenmesine yol açar.

WordPress'te bazı eklentiler nesne önbelleğini doğrudan yönetmeye çalışır. Drop-in yerine çakışan bir eklenti varsa önbellek hiç çalışmıyor olabilir. wp cache get 'test_key' 'test_group' ile manuel test, drop-in'in gerçekten aktif olup olmadığını gösterir.

Kalıcı bağlantı (persistent connection) kullanmamak da yaygın bir hatadır. Her PHP işleminin Redis'e ayrı TCP bağlantısı açması, bağlantı kurma maliyetini yoğun trafikte biriktirir ve kazanımı kısmen ezer. phpredis ile pconnect() kullanmak ya da PHP-FPM yapılandırmasında kalıcı bağlantıyı etkinleştirmek bu sorunu giderir.

Önbellek anahtarlarının yeterince özgün olmaması ise veri karışmasına neden olabilir. Kullanıcıya özel veriler için anahtar tasarımında kullanıcı kimliği mutlaka dahil edilmeli; hem genel hem özel verileri barındıran sayfalarda önbellek gruplaması dikkatle yapılmalıdır. Yanlış anahtar stratejisi, TTFB'yi düşürmek bir yana, tutarsız içerik servisine yol açar.