Cache Prewarming: Site Hızını Sürekli Yüksek Tutma Rehberi

Cache prewarming (ön ısıtma), sitenizde cache (bellek/yanıt önbelleği) dolu başlasın diye içerikleri planlı şekilde üretme işlemidir. Özellikle Varnish, CDN (Cloudflare/Fastly), reverse proxy ve uygulama cache (ör. Redis) kullanan yapılarda ilk istek “boş cache” yüzünden gecikir. Bu rehberde; prewarming’in ne zaman işe yaradığını, hangi URL’lerin nasıl ısıtılacağını, tetikleme ve zamanlama stratejilerini, ölçüm metodunu ve pratik bir kontrol listesini net şekilde göreceksiniz.

Cache prewarming neyi çözer?

Cache prewarming’in hedefi tek bir sorun etrafında netleşir: ilk istek gecikmesi.

Bir kullanıcının ilk kez girdiği sayfa veya yeni bir içerik yayınlandığında şu zincir yaşanır: - CDN/reverse proxy cache’te ilgili obje yoktur. - Sistem origin’a (uygulama sunucusu/konuşlandırma) istek yollar. - Uygulama sayfayı üretir (DB sorguları, şablon render, eklenti süreçleri vb.). - Yanıt cache’e yazılır. - Ardından gelen istekler daha hızlı döner.

Prewarming, “cache’e yazma” adımını kullanıcıdan önce başlatır. Böylece kullanıcı gelen ilk istekle birlikte hızlı yanıtı alır.

Prewarming’in fayda verdiği tipik senaryolar

Aşağıdaki senaryolarda prewarming net fayda sağlar: - CDN + origin yapısı: CDN’de cache eksik olduğunda origin gecikmesi görünür olur. - Sayfa sayısı yüksek e-ticaret, katalog, arşiv sistemleri. - Üst düzey dinamik sayfalar (kampanya, kategori sayfaları, arama sonuçları) ama yine de cachelenebilir kurallar varsa. - Güncelleme sonrası cache sürelerinin sıfırlanması (purge) veya versiyonlama.

Prewarming’in tek başına yetmediği durum da açıktır: - Sürekli tamamen dinamik ve cachelenemeyen sayfalar (her istekte kişiselleştirme baskın). - Cache TTL’in çok kısa olması (sürekli tekrar ısıtma maliyeti doğar). - Origin tarafının temel darboğazı (ör. CPU %100, yavaş DB). Bu durumda hız problemi cache ile “örtülür”, kalıcı çözüm değildir.

Hangi cache katmanları prewarming gerektirir?

Bir site çoğu zaman birden fazla cache katmanı kullanır. Prewarming planını buna göre kurmak gerekir.

Katman bazlı hızlı eşleştirme

Aşağıdaki tablo, “hangi katmanda cache var” ile “hangi veriyi ön ısıtmalıyım” ilişkisini netleştirir:

Pratik kural: “Cache yazan” noktayı hedefle

Prewarming’de en kritik karar şudur: Önbelleğe gerçekten yazan yer neresiyse, prewarming tetiklemeyi oraya göre yapın. - CDN cache yazılıyorsa, doğru yaklaşım CDN üzerinden “istek üretmek”tir. - Varnish/Nginx cache yazıyorsa, doğrudan web katmanına istek üreterek cache write mekanizmasını tetiklemek mantıklıdır. - Uygulama cache (Redis) yazılıyorsa, sadece HTTP isteği üretmek yetmeyebilir; uygulama endpoint’leri veya iş kuyruğu üzerinden cache warm stratejisi gerekir.

Prewarming stratejisi: URL seçimi, frekans ve tetikleme

Prewarming “tüm siteni ısıt” şeklinde yapılmaz. Yanlış strateji iki sorun üretir: origin aşırı yüklenmesi ve gereksiz trafik maliyeti.

1) URL seçiminde net kriterler

Aşağıdaki URL grupları genellikle prewarming için ilk adaydır: - En çok trafik alan sayfalar (ilk 100/500 URL). Erişim loglarınızda en çok isabet alanlar. - Promosyon/kampanya sayfaları (yayın tarihiyle eşleşen). - Kategori ve liste sayfaları (ürün listesi yüklü ama cachelenebilir). - Sık güncellenmeyen içerik sayfaları (blog arşivleri gibi) — TTL uygunsa.

Buna karşılık şu tip URL’ler için prewarming çoğu zaman yanlış olur: - Kullanıcıya göre değişen sayfalar (giriş durumuna göre içerik, kişisel bildirimler). - Çok yüksek varyant sayısı olan sayfalar (çok parametre, sınırsız kombinasyon). - Her istek özel iş yapan endpoint’ler (bire bir hesaplama, ödeme adımları).

2) Frekans seçimi: “her gün” yerine “cache invalidation”a göre

Prewarming frekansı için en net model şudur: - Cache TTL uzunsa: günde bir kez ısıtmak yeterli olabilir. - Cache TTL kısaysa: günlük prewarming maliyetli olur; “purge/invalidasyon” sonrası hedefli warm yapmak daha ekonomiktir.

Pratikte şu tetikleyiciler öne çıkar: - Deploy sonrası (ör. yeni sürüm geldi): “en kritik sayfaları” ısıt. - İçerik yayınlandı/güncellendi: ilgili URL’leri ısıt. - Cache purge çalıştı: purge kapsamındaki URL’leri tekrar ısıt. - Mevsimsel değişim: kategori sayfalarını önceden warm et.

3) Zamanlama: Kullanıcıdan önce, origin kontrollü

Prewarming için zamanlama iki hedefi aynı anda tutturmalıdır: - Kullanıcı ilk isteği gelmeden cache hazır olsun. - Origin’e yük bindirilmesin.

Bu nedenle “aynı anda tüm URL’ler” yaklaşımı yerine kademeli ısıtma önerilir: - İlk dal: top 50/100 sayfa (en yüksek etki). - İkinci dal: top 500’e kadar. - Son dal: kalanlar (isterseniz, TTL kısa değilse veya trafiğe etkisi sınırlıysa).

Ölçüm: Prewarming işe yaradı mı, nasıl anlarsınız?

Prewarming planının başarısı “cache doldu” diye tahminle değil, ölçümle doğrulanmalıdır.

Ölçülecek metrikler (net liste)

1. TTFB (Time to First Byte) - Prewarm öncesi ve sonrası karşılaştırın.
2. Cache hit oranı - CDN veya reverse proxy üzerinde “hit/miss” oranı.
3. Origin response süresi - Prewarm ile origin’e düşen istek yükü azaltıldı mı?
4. Uygulama metrikleri - DB sorgu süresi, CPU, bellek, kuyruk gecikmesi.

Basit doğrulama yöntemi

Aşağıdaki adımları uygulayın: - Prewarm yapılacak URL setini belirleyin (ör. 50 URL). - Cache’i bilinçli olarak boşaltın (purge/invalidate) ve kullanıcı trafiği başlamadan warm çalıştırın. - Sonrasında her URL için 10 istek atıp ortalama TTFB’yi karşılaştırın.

Beklenen sonuçlar: - Prewarm sonrası ilk istek TTFB anlamlı şekilde düşer. - CDN/reverse proxy miss sayısı azalır. - Origin’e giden eşzamanlı istek sayısı kontrollü kalır.

Nginx/Varnish/CDN ile prewarming: Net uygulama deseni

Burada belirli bir sağlayıcıya kilitlemeden, uygulanabilir bir tasarım deseni veriyorum.

1) Prewarming isteğini nereden üretmelisiniz?

• CDN üzerinden üretmek genellikle daha doğru sonuç verir: CDN kendi cache’ine yazmış olur.
• Eğer CDN bypass kuralınız varsa (ör. belirli path’ler), prewarming’i doğrudan reverse proxy katmanına göre planlayın.

2) Yeniden deney tasarımı (retry ve limit)

Prewarming job’unuz şu kontrolleri içermeli: - Eşzamanlılık limiti (concurrency cap). Örneğin aynı anda 10-20 URL’den fazlasını tetiklemeyin. - Timeout: origin yavaşsa job uzayıp kaynak tüketmesin. - Retry: 502/503 gibi geçici hatalarda sınırlı retry (örn. 2 deneme).

3) Cache anahtarı (varyant) farkları

Özellikle şu durumlarda URL aynı görünse bile cache anahtarı farklı olabilir: - Dil (lang) parametreleri - Cihaz türü (mobil/desktop varyantları) - Çerez/authorization etkisi

Bu yüzden prewarming setini “tam olarak cache anahtarı üretmeye yetecek” şekilde kurun. Aksi halde warm yaptığınız yanıtlar hiç kullanılmayabilir.

4) Bot etkisi ve güvenlik

Prewarming bot benzeri istek üretir. Bu yüzden WAF/Rate limit kurallarınız: - Prewarming IP aralıklarını veya servis hesabını whitelist’lemeli. - Aksi halde job rate-limit yiyip cache’i dolmadan bırakabilir.

Otomatikleştirme: Prewarming’i deploy ve içerikle bağlayın

Prewarming’i manuel yapmak hem maliyetli hem de hataya açıktır. Net hedef: “olay tabanlı tetikleme”.

Olay tabanlı tetikleme şablonu

Aşağıdaki 4 olay için net iş akışı önerilir: 1. Deploy oldu - Top URL setini (ör. en popüler 100) warm et. 2. Yeni içerik yayınlandı - Yayınlanan sayfanın URL’sini warm et. 3. Kategori/ürün listesi değişti - Etkilenen kategori/list URL’lerini warm et. 4. Cache purge gerçekleşti - Purge edilen URL’leri veya en yakın wildcard alanlarını warm et.

Kademeli iş planı (örnek)

• Job A: Top 100 URL (5-10 dk içinde)
• Job B: Top 500 URL (planlı, 30-60 dk içinde)
• Job C: Geri kalanlar (TTL ve maliyete göre opsiyonel)

Bu kademeli yaklaşım, origin’i tek seferde kilitlemez.

Sık yapılan hatalar (ve net düzeltmeler)

Hata 1: Tüm siteyi tek seferde warm etmek

• Belirti: Origin CPU artar, DB sorguları yükselir, prewarm tamamlanmadan 5xx görülür.
• Düzeltme: URL’leri trafiğe göre sınıflandırın ve concurrency limit ile kademeli ısıtın.

Hata 2: Cache’i ama varyantları düşünmemek

• Belirti: Prewarm trafiği var ama cache hit oranı değişmiyor.
• Düzeltme: Dil/cihaz/authorization gibi cache anahtarı farklarını prewarming setine dahil edin.

Hata 3: Warm ile cache invalidation’ı aynı anda tasarlamamak

• Belirti: Warm yapıldıktan kısa süre sonra purge/invalidate tekrar çalışır, sonuç boşa gider.
• Düzeltme: İnvalidation zamanını ve warm zamanını aynı akışta koordine edin.

Hata 4: Performans problemi cache ile maskeleniyor

• Belirti: Warm sonrası da TTFB yüksek kalır.
• Düzeltme: Kaynak darboğazını ayrı çözün (ör. DB indeksleri, CPU darboğazı). Cache prewarming, üretim süresini düşürmek yerine gecikmeyi “kullanıcı öncesi” tarafına alır.

Uygulama kontrol listesi (kopyala-uygula)

Aşağıdaki liste, bir prewarming projesini başlatırken net yol haritası verir: - [ ] URL’leri trafiğe göre sıralayın (ilk 100/500 set) - [ ] Cache katmanını belirleyin (CDN mi, Varnish/Nginx mi, Redis mi?) - [ ] Cache anahtarı varyantlarını belirleyin (lang/device/route) - [ ] Prewarm’i origin’i ezmeyecek şekilde kademeli ve sınırlı concurrency ile planlayın - [ ] WAF/rate limit için prewarming trafiğini yönetilebilir hale getirin - [ ] Ölçüm planı kurun: TTFB + cache hit + origin response süresi - [ ] Deploy ve içerik yayınlama olaylarına tetikleyin - [ ] Başarısız URL’ler için retry + log tutun

Sonuç: Prewarming’i “hedefli ve ölçümlü” kurun

Cache prewarming, doğru URL seti ve doğru cache katmanı hedeflendiğinde ilk istek gecikmesini kalıcı şekilde düşürür. Aksiyon önerim net: İlk etapta en popüler 100 URL ile başlayın, warm’i deploy ve purge olaylarına bağlayın ve TTFB/cache hit metrikleriyle 2-3 tur ölçüm yaptıktan sonra kapsamı genişletin. Bu yaklaşım hem origin maliyetini kontrol eder hem de site hızını sürekli yüksek tutma hedefini ölçülebilir hale getirir.