CodeIgniter 4 Projesi İçin Redis Sunucu Yapılandırması ve Best Practice Önerileri

Selam,
Ben bu senaryoda Redis’i ayrı bir VPS’e taşımak yerine aynı sunucuda tutardım. Özellikle tek web sunucusu varsa ve ana hedef TTFB düşürmekse, Redis’i lokal çalıştırıp mümkünse TCP yerine unix socket üzerinden bağlamak daha mantıklı olur.
Çünkü cache ve session tarafı neredeyse her request’te devreye giriyor. Redis’i ayrı bir makineye aldığında, aynı datacenter içinde bile olsa araya ekstra network gecikmesi giriyor. Bu gecikme küçük görünür ama yüksek istek sayısında TTFB tarafında hissedilebilir. Tek sunuculu yapıda ayrı Redis VPS’i çoğu zaman performanstan çok komplekslik ekliyor.
40 GB RAM bu iş için fazlasıyla yeterli. Redis zaten komut işleme tarafında ağırlıklı olarak tek thread çalıştığı için ayrı 4 çekirdekli bir sunucunun CPU avantajı da pratikte çok anlamlı olmaz. Ayrı Redis sunucusu daha çok load balancer arkasında birden fazla web sunucusu kullanmaya başladığında anlam kazanır; o noktada ortak session/cache store ihtiyacı doğar.
Linux tarafında ise birkaç ayar önemli. vm.overcommit_memory = 1 mutlaka yapılmalı, THP kapalı olmalı ve somaxconn değeri Redis tarafındaki backlog ayarıyla uyumlu tutulmalı. Bir de maxmemory ayarlanırken RAM’in tamamı Redis’e verilmemeli; özellikle persistence kullanılıyorsa fork sırasında oluşacak bellek ihtimali için pay bırakmak gerekir.
CI4 tarafında en çok gözden kaçan konu session lock oluyor. Aynı session’a ait eşzamanlı isteklerde RedisHandler kilit koyduğu için, özellikle AJAX yoğun yapılarda istekler birbirini bekleyebiliyor. Bu durumda sorun Redis yavaşlığı gibi görünse de aslında istekler session lock yüzünden sıraya girmiş oluyor. Session gerekmeyen endpoint’lerde session’ı hiç açmamak veya işi bitince erken kapatmak ciddi fark ettirebilir.
Session ve cache’i aynı Redis instance’ında tutma konusunda da dikkatli olmak lazım. Eğer aynı instance’ta allkeys-lru gibi bir eviction policy kullanılırsa, bellek dolduğunda session key’leri de silinebilir ve kullanıcılar sebepsiz logout olabilir. Daha sağlıklı yapı, session ve cache’i ayrı instance/port olarak ayırmak olur. Session tarafında persistence açık ve daha korumacı bir policy; cache tarafında ise yeniden üretilebilir veri olduğu için LRU ve persistence kapalı yapı tercih edilebilir.
Ek olarak phpredis kullanmanı öneririm; Predis’e göre performans tarafında daha iyi sonuç verir. Redis timeout değerlerini de düşük tutmak önemli, çünkü Redis tarafındaki kısa bir takılmanın tüm uygulamayı bekletmesini istemezsin. Popüler cache key’lerinde de stampede ihtimaline karşı TTL’leri biraz dağıtmak veya regenerate sırasında lock kullanmak faydalı olur.