Mühendislik: Redis ile Laravel’de Performans Mimarisi

1. Manifesto: Etkili Sistemler İnşa Etmenin Sanatı

Birçok geliştirici için yazılım geliştirme, “çalışıyor” aşamasında sona erer. Başarıları kapatılan Jira biletlerinin sayısı ve başarıyla dağıtılan özelliklerle ölçülür. Ancak bir mühendis için bu an, yalnızca başlangıçtır. Gerçek iş, kod metin olmaktan çıkıp altyapıyla etkin bir şekilde etkileşime girdiği yerde başlar.

Performansın, bir “tuning” olarak değil, mimarinin temelini oluşturan bir unsur olarak değerlendirilmesi gerektiğine inanarak ENGINEERING kategorisini başlatıyorum.

Neden önemli?

• Geliştirme Ekonomisi: 200 ms’de yanıt veren bir sistem, önemli ölçüde daha az CPU ve bellek kaynağı tüketir. Bu da doğrudan daha düşük cloud hosting maliyetlerine ve projelerin uzun ömürlü olmasına dönüşür.

• Kullanıcı Deneyimi: “Anlık internet” çağındayız. Ekstra 100 ms, kullanıcının sayfayı kapatma riski anlamına gelir. Hızlı bir web sitesi, ziyaretçisinin zamanına saygı duyan nazik bir web sitesidir.

• Ölçeklenebilirlik: Bir sistem mühendislik çözümü olarak tasarlandığında, ilk trafik patlamasında “dağılmaz”. Tahmin edilebilir, kararlı ve teşhis edilmesi kolaydır.
  Bu, sihir veya şans değil. Bu, bilinçli araç seçiminin, “kapağın altındaki” (SQL sorgularından ağ gecikmesine kadar) ne olduğunun anlaşılmasının ve veri akışlarını yönetmedeki disiplinin sonucudur. Bu yazıda, kaotik kodları nasıl düzenli, yüksek yük sistemlerine dönüştürdüğümüzü paylaşacağım.

2. Redis Temeli: Sadece Bir Cache Değil

Modern Laravel mimarisinde veritabanı (MySQL/PostgreSQL) “Kesin Doğru” olarak kabul edilir. Ancak, her kullanıcının bir sayfa talep ettiğinde veritabanından okumak gereksizdir. Disk I/O işlemleri ve karmaşık SQL birleşimleri, yük arttıkça ana darboğaz haline gelir.

Redis, bu yükü RAM’e (In-Memory Data Structure Store) devreder. Bunu CACHE_STORE ve SESSION_DRIVER olarak kullanarak iki katmanlı bir sistem oluşturuyoruz:

• Hızlı Katman (RAM): Sıkça talep edilen veriler (blog sayfaları, karmaşık hesaplama sonuçları, oturumlar) için.

• Güvenilir Katman (Disk): İşlem bütünlüğü gerektiren uzun dönemli veri depolama için.

Temel Dağıtım (Ubuntu/Debian)

Kurulum beş dakikalık bir iş, ancak ne yaptığımızı anlamak önemlidir. Sadece bir sunucu kurmuyoruz; uygulamamızın ihtiyaçları için sunucunun RAM’inin bir kısmını “biçimlendiriyoruz”.

# Paket indeksini güncelle ve sunucuyu kur
sudo apt update && sudo apt install redis-server
# PHP-Redis bağlantısı için sürücüyü kur
sudo apt install php-redis

Kurulumdan sonra, Laravel’i bu katmanı kullanacak şekilde .env dosyası üzerinden yönlendirmelisiniz:

# Cache ve oturum sürücülerini değiştir
CACHE_STORE=redis
SESSION_DRIVER=redis

Veritabanı İzolasyonu: Önek Stratejisi

Üretim sunucuları genellikle birden fazla uygulamayı barındırır. İsimleri yapılandırmazsanız, bir projenin cache’i diğerinin cache’iyle kaçınılmaz olarak çakışır. Bir önek, sizin “dijital hijyeninizdir”.

config/database.php dosyasına, sıkı bir anahtar yapısı tanımlıyoruz:

'redis' => [
    'options' => [
        // Eşsizlik için proje ismi kullan
        'prefix' => env(, Str::slug(env(, ), ).),
    ],
],

Bir mühendis için neden önemli?

• Temizlik (İzolasyon): Anahtarlarınız, örneğin oleant_blog_post_1, üçüncü taraf uygulamalarından alınan anahtarlarla asla çakışmaz.

• Debug dostu: redis-cli’ye eriştiğinizde, rastgele anahtarlar yerine net bir yapı görürsünüz. Bu, “kayıp” verileri ararken veya belirli bir modülün cache’ini temizlerken zaman kazandırır.

3. Mekanikler ve Mimari: responsecache’in Uygulanması

spatie/laravel-responsecache paketini endüstri standardı olarak seçtik. Bu, HTTP isteğini uygulama yaşam döngüsünün en başında “dolaşmayı” sağlar; Laravel, ağır servisleri yüklemeden, denetleyicileri çözmeden veya veritabanında SQL sorguları gerçekleştirmeden önce.

Kurulum ve Başlatma

Paket Kurulumu:

composer require spatie/laravel-responsecache

Yayınlama Yapılandırması: (örn. önbelleğe alınmaması gereken sayfaları hariç tutmak için) yapılandırma dosyasını yayınlayarak ince ayar yapıyoruz:

php artisan vendor:publish --provider="Spatie\ResponseCache\ResponseCacheServiceProvider"

Bundan sonra config/responsecache.php dosyasını alacaksınız. Burada hariç tutma mantığını tanımlıyoruz.

Route Entegrasyonu

Bizim durumumuzda, cache tüm lokalizasyon grubunda küresel olarak uygulanır. Bu, sistem veya API yollarını etkilemeden sitenin tüm kamu sayfalarını otomatik olarak kapsayan şık bir çözümdür.

Route::group(['prefix' => LaravelLocalization::setLocale(), 
    'middleware' => [ 
        'localizationRedirect', 
        'localeViewPath',
        'cacheResponse' // 
    ]], function () {
        // Grubun içindeki tüm yollar otomatik olarak cache'lenir
});

İstisna Yönetimi

Tüm “oyun kuralları”, config/responsecache.php dosyasında tanımlanır. cache_profile anahtarında, BaseCacheProfile sınıfını genişleten bir sınıf belirtirsiniz. Bu sınıf, önbellekleme karar mantığının yoğunlaştığı yerdir.

• Miras yoluyla esneklik: Varsayılan olarak standart CacheAllSuccessfulGetRequests sınıfı yalnızca GET isteklerini ve başarılı yanıtları kapsar. Bu davranışı değiştirmek için, BaseCacheProfile‘den genişlettiğiniz kendi sınıfınızı yaratabilir ve shouldCacheRequest ile shouldCacheResponse yöntemlerini geçersiz kılabilirsiniz.

• Belirli İstisnalar: shouldCacheRequest yönteminde, her zaman “canlı” kalması gereken rota maskelerini (örneğin, /contact veya /admin/*) tanımlayabilirsiniz. Bu, her kullanıcı için benzersiz olmasını gerektiren CSRF tokenleri ile formlar için kritik öneme sahiptir.

Cache Hijyeni: php artisan optimize:clear

Önbellekleme disiplin gerektirir. Önbellek, uygulamanızın “donmuş durumu”dur. Dağıtım sırasında veya mantığı değiştirirken (örneğin, çevirileri güncellerken), önbellek güncel tutulmalıdır.

php artisan optimize:clear komutunu CI/CD pipeline’ımıza zorunlu bir adım olarak veya dağıtımın son eylemi olarak kullanıyoruz. Bu komut “her şeyi temizler”: yapılandırmaları, yolları, görünümleri ve elbette ResponseCache‘i geçersiz kılar. Bu, kullanıcıların her zaman ürününüzün en güncel versiyonunu görmesini sağlar, eski kodun “hayaletleri” değil.

4. İzleme: Kanıta Dayalı Geliştirme

Mühendislik ölçülebilirlik üzerine kuruludur. Eğer bir sonucu ölçemezseniz, onu yönetemezsiniz. redis-cli monitor aracı, uygulamanın depolama katmanıyla nasıl iletişim kurduğunu gerçek zamanlı olarak görmemizi sağlar.

Redis’i “Okuma” Yöntemi

redis-cli monitor komutunu terminalde çalıştırdığınızda, Laravel’in Redis’e gönderdiği komutların akışını görürsünüz. Önbellek mimarisinde, verimliliği doğrulayan bir kalıp ararız:

• Bir “Cache Hit” sırasında davranış: Belirli bir anahtar için, projenizin öneki ile eşleşen hızlı bir GET komut patlaması göreceksiniz. Bu, Laravel’in denetleyici yürütmesine veya MySQL sorgularına ulaşmadığı anlamına gelir; veriler doğrudan RAM’den “yakalanmıştır”. Bu, istenen 200 ms yanıt süresinin kaynağıdır.

• Bir “Cache Miss” sırasında davranış: Bir sayfanın yüklenmesi uzun sürerse ve izleme (veya DB genel kaydı) ile birçok SQL veritabanı sorgusu veya SET komutları görürseniz, bu, sistemin önbelleği “ısıtmak” zorunda kaldığı anlamına gelir.

Bir Mühendis için Neden Önemli?

Bu araç olmadan, geliştirme “tahmin oyunları” haline gelir. monitor ile:

• Mimarinin Doğrulanması: cacheResponse middleware’inin isteği gerçekten engellediğinden emin olun.

• Darboğazları Belirleme: Basit bir sayfayı güncellemek için 50’den fazla Redis isteği görüyorsanız, önbellek mimariniz muhtemelen çok ayrıntılıdır ve optimize edilmelidir.

• Kanıt Sağlama: İşletme, “site neden daha hızlı oldu?” dediğinde, bunu yalnızca bir TTFB grafiğiyle göstermek yerine, veritabanının tamamen boşaltıldığını gösteren gerçek zamanlı bir komut akışı sunabilirsiniz.

Mühendislik Disiplini: Önemli yeniden yapılandırmalar sonrasında test oturumları sırasında redis-cli monitor kullanın. Bu, önbellek geçersiz kılmasının yanlışlıkla bozulup bozulmadığını ve uygulamanın iş mantığını atlayarak RAM’den eski verileri sunup sunmadığını doğrulamanın en iyi yoludur.

Projenizin performansını gerçek zamanlı olarak kontrol etmek ister misiniz? Detaylı bir TTFB analizi ve mimarinizdeki gizli darboğazları tanımlamak için sayfa yükleme süresi denetleme aracımızı kullanın.

5. Mimari Köprü: Filament ve Otomatik Önbellekleme

Geçersiz Kılma

İçerik yönetimi için Filament kullanmak, muazzam bir geliştirme hızı sağlasa da, frontend’de içerik tazeliğini nasıl garanti edeceğiniz sorusunu ortaya çıkarır. Her bir gönderi yayınlandığında önbelleği temizlemek için terminale veya yönetim paneline manuel olarak gitmek istemiyor için. Mühendislik yaklaşımı, olay otomasyonudur.

Post model için bir Gözlemci uyguladık. Artık, içerik yönetim panelinde güncellendiğinde, Laravel bunu model seviyesinde “görür” ve önbelleği otomatik olarak temizler.

Gözlemci Aracılığıyla Uygulama:

namespace App\Observers;
use App\Models\Post;
use Spatie\ResponseCache\Facades\ResponseCache;
class PostObserver
{
    public function saved(Post $post): void
    {
        // Gönderi oluşturma veya güncelleme esnasında otomatik önbellek sıfırlama
        ResponseCache::clear();
    }
    public function deleted(Post $post): void
    {
        ResponseCache::clear();
    }
}

Neden önemli?

• Tutarlılık: Kullanıcı her zaman taze içerik görür. Bir güncellemeye sonrası “takılma” veya bayat metin parçaları yoktur.

• Yazar için UX: Yönetici, “Kaydet” butonuna tıklamanın “teknik” sonuçlarından endişelenmek zorunda değildir. Sistem, geçersiz kılma yükünü tamamen üstlenir.

• Bütünlük: Veritabanı olaylarını (Eloquent Events) altyapı katmanıyla (Redis) bağladık. Bu, “sistem mühendisliği” anlamına gelir—bir katmandaki değişikliklerin otomatik ve doğru bir şekilde diğerinde yansıtıldığı kapalı bir döngü oluşturmak.

Sonuç: Filament yönetim paneli, yalnızca veritabanına yazmak için bir arayüz haline gelmedi; artık frontend’deki kendi temsili üzerine yaşam döngüsünü otomatik olarak yöneten “Kesin Doğru” haline geldi.

6. Özet: Sayılardaki Sonuçlar

Mühendislik yaklaşımı her zaman kanıtlarla doludur. Aşağıda Redis ve responsecache’i uyguladıktan sonraki performans benchmark sonuçları verilmiştir. TTFB (Time to First Byte) üzerine yoğunlaştık, çünkü bu, uygulamanın yanıtı ne kadar hızlı “ateşleyebildiğini” gösterir ve ağır arka uç mantığını atlayarak gerçekleşir.

Performans Benchmark Kayıtları:

{
  "homepage": {
    "url": "https://oleant.dev",
    "http_code": 200,
    "dns_lookup_ms": 21.46,
    "tcp_connection_ms": 8.26,
    "time_to_first_byte_ms": 195.41,
    "total_time_ms": 225.94
  },
  "blog_post": {
    "url": "https://oleant.dev/blog/jagd-auf-digitale-chamaleons...",
    "http_code": 200,
    "dns_lookup_ms": 1.24,
    "tcp_connection_ms": 17.23,
    "time_to_first_byte_ms": 220.32,
    "total_time_ms": 256.69
  }
}

Veri Analizi:

• TTFB ~200 ms: Bu, Laravel uygulamaları için bir benchmark metriğidir. Sunucu, TCP bağlantısı kurulduktan hemen sonra verileri sunmaya başlıyor.

• Harcamanın Azaltılması: time_to_first_byte ile total_time arasındaki fark minimal, bu da içerik tesliminde “lag” olmadığını gösteriyor (içerik verimli bir şekilde aktarılıyor).

• Stabilite: Büyük bir DOM öğesi sayısına sahip yoğun bir makale sayfasında bile, yanıt süresi kullanışlı bir 250 ms sınırında kaldı.

Sonuç: Redis ile önbellekleme bir “hack” veya bir geçici çözüm değildir; bu temel bir mimari hijyendir. Proje artık kullanıcı deneyimini koruyarak yük büyümesine hazır. Sistem, görevlerle birlikte ölçeklenebilir bir altyapı oluşturacak şekilde yapılandırılmıştır; veritabanı sunucusunun kapasite sınırlarına ulaşmasını beklemeden…

Kaynak: Orijinal Makale