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

Siteniz yeniden deploy edildiğinde ya da sunucu yeniden başlatıldığında önbellek (cache) tamamen boşalır. Bu anda gelen ilk ziyaretçiler sayfaları önbellekten değil, doğrudan veritabanı sorgularından ve disk okumalarından alır; yanıt süresi 20 ms'den 2–4 saniyeye fırlayabilir. Cache prewarming (önbellek ön ısıtması) bu durumu tersine çevirir: gerçek kullanıcı gelmeden önce önemli sayfaları otomatik olarak önbelleğe aldırır. Bu rehberde prewarming'in nasıl çalıştığını, hangi araçlarla kurulduğunu ve hangi hosting türünde ne kadar etkin olduğunu somut komutlar ve tablolarla açıklıyoruz.

Cache Miss Storm: Prewarming Olmadan Ne Olur?

Yüksek trafikli anlarda "cache miss storm" denen olgu gerçek bir performans krizi yaratır.

Tipik senaryo şu şekilde işler:

1. Gece 02:00'de yeni bir ürün sayfası deploy edilir, önbellek temizlenir.
2. Sabah 09:00'da e-bülten gönderilir; 5.000 kişi aynı anda sitenize tıklar.
3. Önbellek boştur; her istek MySQL'e ve PHP işlemcisine çarpar.
4. Sunucu eş zamanlı sorgularla boğulur, yanıt süresi 4–8 saniyeye çıkar.
5. Arama motorları bu yavaşlığı crawl loglarına işler, bazı istekler zaman aşımına uğrar.

Prewarming yapılmış olsaydı o 5.000 istek hazır sayfaları alırdı. Ölçüm sonuçları, düzgün ısıtılmış bir önbellekte sunucu yükünün %60–80 daha düşük kaldığını gösteriyor.

Prewarming Ne Zaman Zorunludur?

Her site için aynı aciliyet geçerli değil. Aşağıdaki tablo önceliği netleştirir:

Günde birkaç bin sayfa görüntülemesi olan bir blog için rutin prewarming zorunlu değildir. Ancak e-ticaret siteniz için kampanya öncesi yapılmayan prewarming doğrudan gelir kaybına dönüşür.

Prewarming Yöntemleri: Araçlar ve Kurulum

wget ile Basit Spider Yöntemi

En hızlı başlangıç noktası wget --spider komutudur. Gerçek dosya indirmez; yalnızca HTTP isteği göndererek önbelleği tetikler:

wget --spider --recursive --level=3 --no-verbose \
  --output-file=/var/log/prewarm.log \
  https://siteniz.com/

--level=3 parametresi ana sayfadan 3 bağlantı derinliğine kadar tüm sayfaları ziyaret eder. VPS/VDS ortamında bu scripti deploy hook\'una eklerseniz her güncellemeden sonra otomatik çalışır.

Sitemap Üzerinden Öncelikli URL Prewarming

wget --spider tüm sayfaları ziyaret eder; büyük sitelerde saatler alabilir. Daha verimli yol, sitemap.xml\'den URL listesi çekip yalnızca önemli sayfaları ısıtmaktır:

curl -s https://siteniz.com/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -n1 -P5 curl -s -o /dev/null -w "%{url_effective} %{http_code} %{time_total}s\n"

-P5 parametresi 5 eş zamanlı istek gönderir. Büyük sitelerde bu değeri 10–20\'ye çıkarabilirsiniz; ancak paylaşımlı hostingde 2–3\'te tutun, aksi hâlde kendi sunucunuzu yorarsınız.

WordPress için Cache Eklentisi Prewarming

Sunucuya doğrudan erişiminiz yoksa eklenti tabanlı çözümler devreye girer:

LiteSpeed Cache, LiteSpeed sunucusu kullanan hostinglerde (birçok Türk hosting sağlayıcısı dahil) en verimli sonucu verir; çünkü crawler dışarıdan HTTP isteği atmak yerine sunucunun kendi içinde çalışır.

Varnish ve Nginx FastCGI Cache ile Sunucu Tarafı Prewarming

VDS/VPS kullanıyorsanız ve Varnish Cache kuruluysa varnishadm ile warm-up yapabilirsiniz:

# Mevcut cache\'i temizle
varnishadm "ban req.url ~ ."
# Ardından sitemap spider scriptini tetikle
/usr/local/bin/prewarm.sh

Nginx FastCGI cache kullanıyorsanız önbellek dizinini (/var/run/nginx-cache/) temizleyip sitemap scriptini çalıştırın. Deploy pipeline\'ınıza bu iki adımı sırayla eklemek yeterlidir.

Prewarming Sıklığı ve Zamanlama

Prewarming\'i ne sıklıkla yapmalısınız? Bu, sitenizin güncelleme sıklığına ve cache TTL (yaşam süresi) ayarına bağlıdır:

• Her deploy sonrası: Zorunlu. CI/CD pipeline\'ınıza ekleyin.
• Günlük rutin (gece 03:00–05:00): Cache TTL\'iniz 24 saatten kısaysa önerilir.
• Kampanya öncesi 30 dakika: Manuel tetikleme ile tüm ürün ve kategori sayfaları.
• Sunucu yeniden başlatma sonrası: Systemd servis dosyasına ExecStartPost komutu ekleyerek otomatikleştirin.

Cron ile her gece 03:30\'da sitemap prewarming örneği:

30 3 * * * /usr/local/bin/prewarm.sh >> /var/log/prewarm.log 2>&1

Hosting Türüne Göre Prewarming Kapasitesi

Her hosting ortamı aynı esnekliği sunmaz:

Paylaşımlı hostingde sunucu başlatma olayına (event) erişiminiz olmaz; yalnızca zamanlama tabanlı prewarming yapabilirsiniz. VDS veya dedicated sunucularda bu olayları kendiniz tetikleyebilir, logları izleyebilir ve deploy pipeline\'ına entegre edebilirsiniz.

Prewarming\'in Doğrulanması: Çalışıyor mu?

Script çalıştırdınız; ama sayfalar gerçekten önbelleklendi mi? İki yöntemle doğrulayın.

HTTP başlık (header) kontrolü:

curl -I https://siteniz.com/urun-sayfasi/ | grep -i "x-cache\|cf-cache-status\|age"

Beklenen yanıtlar:

• X-Cache: HIT → Sunucu önbelleğinden geldi
• CF-Cache-Status: HIT → Cloudflare önbelleğinden geldi
• Age: 1840 → 1840 saniye önce önbelleğe alındı; sıfırsa cache miss

Yanıt süresi karşılaştırması:

# İlk istek — miss beklenir
curl -w "%{time_total}s\n" -o /dev/null -s https://siteniz.com/

# İkinci istek — hit beklenir
curl -w "%{time_total}s\n" -o /dev/null -s https://siteniz.com/

İkinci istek birincinin %90 altındaysa prewarming çalışıyordur. Fark yoksa TTL sıfır ayarlanmış, cache bypass header aktif ya da önbellek modülü devre dışı olabilir.

Sonuç: Prewarming\'i Rutin Hâline Getirin

Cache prewarming, bir kez kurulup otomatikleştirilen bir iyileştirmedir; bakım maliyeti düşüktür. Altyapınıza göre şu adımları uygulayın:

• Paylaşımlı hosting: LiteSpeed Cache veya WP Rocket crawler özelliğini aktif edin, tarama sıklığını günlük olarak ayarlayın.
• VPS / VDS: Sitemap tabanlı curl scriptini yazın, deploy pipeline\'ınıza ve bir gece cronu\'na ekleyin.
• Dedicated sunucu / Varnish: Her deploy sonrası ban ve prewarm akışını otomatikleştirin, yanıt sürelerini loglarla izleyin.

İlk kurulum 30–60 dakika alır. Karşılığı her kampanyada, her deploy sonrasında ve her sunucu yeniden başlatmasında kendini gösterir: ilk kullanıcıdan itibaren hızlı sayfa, düşük sunucu yükü ve ölçülebilir biçimde stabil bir kullanıcı deneyimi.