CDN Cache Hit Oranını Artırma

CDN'i kurdun, fatura gelmeye başladı, ama sunucundaki yük neredeyse hiç azalmadı. Log dosyalarına bakınca origin'in hâlâ her isteği karşıladığını görüyorsun. Bu durumda elinde çalışan bir CDN değil, araya girmiş fazladan bir ağ atlaması var: istek önce uç sunucuya gidiyor, oradan senin sunucuna geliyor ve aynı yolu geri dönüyor. CDN cache hit oranı düşükse CDN sana hız kazandırmaz, hatta bazı isteklerde birkaç milisaniye kaybettirir.

Bu rehberde hit oranının ne olduğunu ve nasıl doğru ölçüleceğini, oranı düşüren altı yaygın sebebi tek tek, cache key'i nasıl sadeleştireceğini, çerez ve Vary başlığı tuzaklarını, TTL stratejisini, katmanlı önbellek ve origin shield mantığını anlatacağım. Sonunda elinde ölçülebilir bir hedef ve ona ulaşmak için sıralı bir yapılacaklar listesi olacak.

Cache Hit Oranı Nedir, Nasıl Ölçülür#

Hit oranı, uç sunucudan karşılanan isteklerin toplam istekler içindeki payıdır. Formülü basittir:

İstek hit oranı  = HIT / (HIT + MISS + EXPIRED)
Bayt hit oranı   = uçtan sunulan bayt / toplam sunulan bayt

İki oranı ayrı ayrı takip etmelisin çünkü farklı şeyler söylerler. İstek hit oranı sunucunun kaç kez rahatsız edildiğini, bayt hit oranı ise faturanın ve bant genişliğinin ne kadarının uçtan karşılandığını gösterir. Küçük dosyaların çoğu önbellekteyken tek bir büyük video her seferinde origin'den çekiliyorsa istek oranın harika, bayt oranın felaket görünür.

Sağlayıcı panelleri bu oranları hazır gösterir, ama kendi ölçümünü yapmayı da öğren; sorun ararken çok işine yarar. Uç yanıtındaki durum başlığını sayarak hızlı bir tahmin çıkarabilirsin:

# Bir URL listesi uzerinden ornekleme yaparak hit orani tahmini
while read -r url; do
  curl -sSI "$url" | grep -ioE 'HIT|MISS|EXPIRED|DYNAMIC|BYPASS' | head -1
done < urls.txt | sort | uniq -c | sort -rn

# Ornek cikti:
#   142 HIT
#    38 MISS
#    20 DYNAMIC

Origin tarafından bakmak daha da öğreticidir. Access log'unda gün içinde kaç istek gördüğünü sayarsın; CDN çalışıyorsa bu sayı toplam ziyaretçi trafiğinin çok küçük bir bölümü olmalıdır:

# Bugun origin'e ulasan istekleri saydir
awk -v d="$(date +%d/%b/%Y)" '$0 ~ d' /var/log/nginx/access.log | wc -l

# Origin'e en cok ulasan yollar: bunlar onbelleklenemeyenler
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Bu ikinci komut altın değerindedir: origin'i en çok yoran yolları doğrudan listeler ve neredeyse her zaman ilk beş satırda düzeltilebilir bir sorun çıkar.

Hedef olarak neyi makul saymalısın? İçerik tipine bağlı, ama kaba bir ölçek şu şekilde:

Yüzde 30'un altındaysan bir yapılandırma hatası var demektir, içeriğinin doğası değil.

Hit Oranını Düşüren Başlıca Sebepler#

Sahada gördüğüm sebepler neredeyse her zaman aynı altı başlıkta toplanıyor ve etki sırasına göre şöyleler.

Birincisi, sorgu dizesi çeşitliliği. Uç sunucu sayfa.html?utm_source=google ile sayfa.html?utm_source=meta adreslerini iki ayrı dosya sayar. Reklam kampanyası açtığın gün hit oranın çakılır çünkü aynı sayfanın onlarca kopyası oluşur ve hiçbiri yeterince istek almadan süresi dolar.

İkincisi, çerezler. Origin yanıtında Set-Cookie varsa çoğu CDN o yanıtı hiç önbelleğe almaz. WordPress ve benzeri sistemler anonim ziyaretçiye bile gereksiz çerez basabilir.

Üçüncüsü, yanlış Vary başlığı. Vary: User-Agent gönderirsen CDN her farklı tarayıcı sürümü için ayrı kopya tutar; pratikte bu, önbelleği kapatmakla neredeyse eşdeğerdir.

Dördüncüsü, çok kısa TTL. Beş dakikalık bir TTL, saatte birkaç istek alan bir sayfa için hiçbir işe yaramaz; dosya her istendiğinde süresi çoktan dolmuş olur.

Beşincisi, PoP dağılımı. Ziyaretçilerin çok sayıda ülkeye yayılmışsa aynı dosya her PoP'ta ayrı ayrı ısınmak zorundadır. Küçük trafikli bir sitede bu, kalıcı bir MISS akışı yaratır.

Altıncısı, gereksiz purge. Her dağıtımda "her şeyi temizle" diyorsan önbellek hiçbir zaman ısınamaz.

Cache Key'i Sadeleştirmek#

Cache key, uç sunucunun bir isteği önbellekte ararken kullandığı kimliktir. Varsayılan olarak yöntem, host, yol ve sorgu dizesini içerir. Bu anahtarı ne kadar sadeleştirirsen aynı içeriğin o kadar az kopyası oluşur.

Sorgu dizesi için doğru yaklaşım izin listesidir: içeriği gerçekten değiştiren parametreleri anahtara dahil et, gerisini yok say.

Cloudflare tarafında bunu Cache Rules içindeki cache key ayarından yaparsın; ayrıntısını Cloudflare cache kuralları yazısında anlattım. Kendi Nginx önbelleğini yönetiyorsan anahtarı doğrudan tanımlarsın:

# Takip parametrelerini onbellek anahtarindan cikar
map $args $clean_args {
    default                       $args;
    "~^(.*)(&)?(utm_[a-z]+|fbclid|gclid)=[^&]*(.*)$"  "$1$4";
}

proxy_cache_key "$scheme$request_method$host$uri$clean_args";

Vary başlığı da anahtarın parçasıdır ve dikkatli kullanılmalıdır. Meşru tek kullanım genellikle Vary: Accept-Encoding'tir; sıkıştırılmış ve sıkıştırılmamış sürümlerin ayrı tutulması gerekir. Vary: Cookie ve Vary: User-Agent neredeyse her zaman hatadır. Cihaza göre farklı HTML üretiyorsan çözüm Vary: User-Agent değil, duyarlı tasarımdır ya da uç sunucunun sunduğu cihaz sınıfı sinyalleridir.

# Origin gercekten ne gonderiyor, once bunu gor
curl -sSI https://firmaniz.com/ | grep -iE 'vary|set-cookie|cache-control'

Çerez ve Başlık Temizliği#

Statik dosyalara çerez basılması, hit oranını düşüren en kolay düzeltilebilir sorundur. Origin tarafında tek bir blokla halledebilirsin:

# Varliklarda cerez basma, uzun omur ver
location ~* \.(jpg|jpeg|png|webp|avif|gif|svg|ico|css|js|woff2|woff|ttf)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    proxy_hide_header Set-Cookie;
    more_clear_headers 'Set-Cookie';
    access_log off;
}

HTML tarafında ise sorun daha ince: uygulaman anonim ziyaretçiye oturum çerezi başlatıyor olabilir. PHP uygulamalarında session_start() çağrısının koşulsuz yapılması klasik sebeptir. Oturumu yalnızca gerçekten gerektiğinde başlat; giriş yapmamış bir ziyaretçinin oturum çerezine ihtiyacı yoktur.

Analitik çerezleri farklıdır: onlar tarayıcıda JavaScript ile yazılır, yanıt başlığında Set-Cookie olarak gelmez, dolayısıyla önbelleği bozmazlar. Bu ayrımı bilmek gereksiz uğraşı önler.

CDN tarafında da çoğu sağlayıcı "yanıt çerezlerini kaldır" ya da "belirli çerezleri yok say" seçeneği sunar. Bu ayarı kullanırken dikkatli ol: gerçekten oturum kuran bir yanıtın çerezini silmek kullanıcıyı sürekli çıkış yapmış gösterir. Doğru yer neredeyse her zaman origin'dir.

TTL Stratejisi ve Bayat İçerik Sunmak#

Kısa TTL güvenli hissettirir ama önbelleği işlevsiz bırakır. Doğru yaklaşım, TTL'i uzun tutup güncellemeyi purge ya da sürümleme ile yönetmektir.

# Uc sunucuda uzun yasasin, tarayicida kisa dursun,
# suresi dolunca eski kopya sunulup arka planda yenilensin
add_header Cache-Control "public, max-age=120, s-maxage=86400, stale-while-revalidate=600, stale-if-error=86400";

Bu tek satırdaki dört direktifin her biri hit oranına ayrı katkı verir. s-maxage yalnızca CDN'i ilgilendirir ve uzun tutulur. stale-while-revalidate, süresi dolan bir kopyanın kullanıcıya anında sunulmasını ve yenilemenin arka planda yapılmasını sağlar; böylece TTL'in dolduğu an gelen istekler MISS sayılmaz. stale-if-error, origin'e ulaşılamadığında eski kopyanın sunulmasını sağlar ve kesinti sırasında sitenin ayakta kalmasını sağlar. Bu direktiflerin tamamını Cache-Control başlıkları rehberinde tek tek açıkladım.

Statik varlıklarda ise TTL tartışmasını tamamen ortadan kaldırabilirsin: dosya adına içerik hash'i koy. app.a1b2c3d4.js gibi bir isim, içerik değişince zaten değişir, dolayısıyla bir yıllık TTL güvenle verilebilir ve purge etmene hiç gerek kalmaz. Bu yöntemin tarayıcı tarafındaki karşılığını tarayıcı önbelleği nasıl çalışır yazısında bulabilirsin.

Katmanlı Önbellek ve Origin Shield#

Trafiği çok uluslu bir sitede aynı dosya her PoP'ta ayrı ayrı ısınır. Elli PoP varsa origin bir dosya için elli kez rahatsız edilir. Origin shield (ya da katmanlı önbellek), PoP'ların origin'e doğrudan gitmesi yerine ara bir üst katmana gitmesini sağlar; o katman origin'e tek bir istek yapar ve cevabı tüm PoP'lara dağıtır.

Kazanç iki yönlüdür: origin'e ulaşan istek sayısı çarpıcı biçimde düşer ve soğuk PoP'lardaki MISS'ler origin gecikmesi yerine çok daha hızlı olan ara katmandan karşılanır. Küçük trafikli ama coğrafi olarak dağınık sitelerde etkisi en yüksektir; tam da hit oranının en çok battığı senaryodur.

Shield bölgesini seçerken origin'ine ağ olarak en yakın noktayı seç. Sunucun Türkiye'deyse Avrupa'daki bir shield mantıklıdır; ABD'deki bir shield her MISS'e okyanus aşırı bir tur ekler.

Bir de önbelleği önceden ısıtma yöntemi var. Yeni bir dağıtımdan sonra en çok ziyaret edilen adresleri bir betikle çağırırsan, ilk gerçek ziyaretçi MISS yerine HIT alır:

# En cok gezilen adresleri onceden isit
while read -r url; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s $url\n" "$url"
done < populer-adresler.txt

Bunu dağıtım betiğinin son adımı yaparsan, purge sonrası oluşan yük dalgasını da yumuşatırsın.

Sık Yapılan Hatalar#

En yaygın hata, her dağıtımda tüm önbelleği temizlemektir. Önbellek bir daha ısınmaya fırsat bulamaz ve ortalama hit oranı kalıcı olarak düşük kalır. Hedefli purge kullan, mümkünse hiç purge etmeyecek şekilde sürümleme yap.

İkinci hata, hit oranını tek bir sayı olarak takip etmektir. İçerik tipine göre ayırmadan bakarsan hangi grubun sorunlu olduğunu göremezsin. Görseller, betikler, HTML ve API yanıtlarını ayrı ayrı izle.

Üçüncü hata, önbelleklenemeyecek şeyi önbelleklemeye çalışmaktır. Sepet, hesap ve arama sonuçları kişiye özeldir; bunları önbelleğe almak hit oranını yükseltmez, sadece veri sızıntısı riski yaratır.

Dördüncü hata, ölçümü tarayıcıda yapmaktır. Tarayıcının kendi önbelleği araya girer ve yanıltıcı sonuç görürsün; ölçümü curl ile ve arka arkaya iki istekle yap.

Beşinci hata, origin'i düzeltmeden CDN ayarlarıyla oynamaktır. Origin no-store gönderiyorsa hangi kuralı yazarsan yaz sonuç değişmez. Her zaman curl -sSI ile origin'in ne söylediğine bakarak başla.

Sıkça Sorulan Sorular#

İyi bir cache hit oranı kaçtır#

İçerik tipine bağlıdır. Yalnızca statik varlık dağıtan bir CDN'de yüzde 95 üstü beklenir; HTML'i de önbellekleyen bir blogda yüzde 90 makuldür; e-ticarette sepet ve hesap sayfaları dışarıda tutulduğu için yüzde 60-85 arası normaldir. Mutlak sayıdan çok trend önemlidir: oranın zaman içinde düşüyorsa yeni eklenen bir parametre, çerez ya da kısa TTL vardır.

Hit oranım neden reklam kampanyası başlattığımda düştü#

Çünkü kampanya bağlantıları utm_source, gclid, fbclid gibi parametreler taşır ve varsayılan cache key bu parametreleri içerir. Aynı sayfanın onlarca farklı kopyası oluşur, hiçbiri yeterli istek almadan süresi dolar. Çözüm, takip parametrelerini cache key'den çıkarmaktır; kullanıcı bu parametreleri yine görür, analitik yine çalışır, ama önbellek tek kopya tutar.

Vary başlığını tamamen kaldırmalı mıyım#

Hayır, Vary: Accept-Encoding meşru ve gereklidir; sıkıştırılmış ve sıkıştırılmamış sürümlerin ayrı tutulmasını sağlar. Kaldırman gereken Vary: User-Agent ve Vary: Cookie gibi yüksek çeşitlilik üreten değerlerdir. Bunları göndermeye devam edersen uç sunucu neredeyse her istek için ayrı kopya tutar ve önbellek işlevsiz kalır.

Origin shield her sitede işe yarar mı#

Faydası, PoP sayısı ile trafiğin dağınıklığına bağlıdır. Ziyaretçilerinin tamamı tek bir ülkedeyse ve trafik yoğunsa katkısı sınırlı kalır. Ziyaretçilerin çok sayıda ülkeye yayılmış ve her PoP'a düşen istek sayısı azsa etkisi çok belirgindir. Genel kural: hit oranın düşük ve origin log'unda aynı dosya farklı bölgelerden tekrar tekrar isteniyorsa shield açmaya değer.

Önbelleği ısıtmak gerçekten fark yaratır mı#

Purge sonrası ve yeni dağıtımlarda evet. Isıtma yapmazsan ilk gerçek ziyaretçiler MISS alır ve origin ani bir yük dalgası görür. En çok ziyaret edilen elli adresi dağıtım sonrası tek tek çağıran basit bir betik, hem ortalama yanıt süresini düşürür hem de sunucunun zirve yükünü yumuşatır. Karmaşık bir araca ihtiyaç yoktur.

Hit oranını yükseltmek faturamı düşürür mü#

Genellikle evet, ama sağlayıcının fiyatlandırma modeline bağlı. Çoğu CDN aktarılan veri üzerinden ücretlendirir ve toplam aktarılan veri değişmez; asıl tasarruf origin sunucunun bant genişliğinde ve kaynak kullanımında olur. Origin'in trafiği ölçülüyorsa ya da sunucuyu küçültebiliyorsan doğrudan maliyet düşer. Her hâlükârda kullanıcı deneyimi belirgin biçimde iyileşir.

Kapanış#

Düşük hit oranı neredeyse hiçbir zaman "içeriğim önbelleklenemez" demek değildir; genellikle sorgu dizesi çeşitliliği, gereksiz çerezler, yanlış bir Vary ya da çok kısa bir TTL demektir. Aklında tutman gereken dört alışkanlık şu: cache key'i izin listesiyle sadeleştir, statik dosyalara çerez basılmasını origin'de kes, TTL'i uzatıp stale-while-revalidate ile riski azalt, her dağıtımda tüm önbelleği silmek yerine sürümleme kullan. Bu dördü uygulandığında oran genellikle tek seferde belirgin biçimde yükselir.

Origin tarafını da rahatlatmak istersen sunucu seviyesinde önbellekleme büyük fark yaratır; Nginx FastCGI cache ve LiteSpeed Cache yazılarımız bu katmanı kurmanı sağlar. Barındırma tarafında hız arıyorsan web hosting ve e-ticaret hosting paketlerimize, kendi önbellek mimarini kurmak istiyorsan VDS sunucularımıza bakabilirsin. Ayarlarla uğraşmak istemezsen sunucu yönetimi hizmetimiz bu optimizasyonu senin yerine üstlenir.