Yetenek

Yanıt Önbellekleme

Sık istenen yanıtları kurum servisine gitmeden döndürün; gecikmeyi azaltın, kapasiteyi rahatlatın.

Bir uygulamanın en hızlı yanıtı, kurum servisine hiç gitmeyen yanıttır. TR7 Yanıt Önbellekleme, statik içerikleri, nadiren değişen API yanıtlarını ve belirli koşullarda tekrar üretilebilen dinamik çıktıları ADC katmanında saklayarak kullanıcıya daha hızlı cevap verir. Cache profilleriyle boyut, süre, ETag davranışı ve debug başlığı merkezi olarak tanımlanır. Path, method, header, cookie veya FX koşullarıyla hangi yanıtların cache'e alınacağı belirlenir; aynı servis içinde ürün katalogları cache'lenirken sepet, ödeme veya kullanıcıya özel kritik akışlar dışarıda bırakılabilir. Dinamik cache key modeli, aynı URL için farklı cache slot'ları oluşturmayı sağlar. Ülke, cihaz tipi, tenant ID, A/B test grubu veya özel header değeri cache anahtarına eklenebilir; böylece hız kazanırken yanlış kullanıcıya yanlış içerik dönme riski azaltılır. Sonuç: TR7, yanıt önbelleklemesini ayrı bir cache sunucusu projesi olmaktan çıkarır; vService seviyesinde, koşullu, denetlenebilir ve operasyon panelinden yönetilen bir performans katmanına dönüştürür.

2048 MB
Profil başına maksimum cache boyutu
10 sn
Minimum cache timeout — thrash önleme garantisi
6
Override toggle: Host / Query / Request / Response / Method / Dynamic

HTTP cache basit görünür; production ortamında doğru cache key ve doğru istisna yönetimi zordur.

HTTP cache teoride kolaydır: Cache-Control, ETag ve süre değerleri doğruysa istemci veya ara katman aynı cevabı tekrar kullanır. Production ortamında ise uygulamalar çoğu zaman bu başlıkları eksik, yanlış veya aşırı korumacı gönderir. Sonuç olarak cache'lenebilecek içerikler kurum servisine tekrar tekrar gider.

Statik içeriklerde bile küçük URL farkları cache verimini düşürür. Aynı ürün görseli veya katalog sayfası, takip parametreleri yüzünden farklı nesne gibi davranabilir. Host, query string, istemci header'ı veya yanlış Cache-Control başlığı cache hit oranını gereksiz yere azaltır.

Dinamik içerikte problem daha büyüktür. Aynı path mobil ve masaüstü için farklı cevap döndürebilir; ülkeye göre fiyat değişebilir; tenant'a göre aynı endpoint farklı veri üretebilir. Cache key bu bağlamı taşımazsa yanlış içerik dönebilir. Çok fazla header cache key'e eklenirse bu kez cache neredeyse hiç çalışmaz.

Harici cache veya CDN çözümleri internet edge trafiğinde faydalıdır; fakat kurum içi, on-prem, private API ve sovereign cloud trafiğinde her zaman uygun değildir. ADC seviyesinde cache yapmak ise çoğu zaman konfigürasyon dosyası, özel kural dili veya ayrı ürün bilgisi gerektirir.

TR7 Yanıt Önbellekleme, cache profilini, koşullu cache kurallarını, dinamik cache key'lerini ve standart override seçeneklerini tek vService yönetim modeli altında sunar.

Yaklaşımımız

TR7, cache davranışını profil, koşul, dinamik anahtar ve kontrollü override katmanlarıyla yönetir.

İsimli cache profilleri servis bazlı kota sağlar

Cache profili; ad, boyut, süre, ETag ve debug başlığı gibi ayarları tek yerde toplar. Aynı profil birden fazla vService üzerinde kullanılabilir. Her servis kendi cache sınırlarıyla yönetilir.

Koşullu cache kuralları endpoint bazlı karar verir

Her cache kuralı FX koşul motoruyla path, method, header, cookie veya diğer değişkenlere bağlanabilir. Böylece aynı kurum servisinde public katalog cache'lenirken kullanıcı sepeti dışarıda bırakılır. Cache kararı kod değişmeden ADC katmanında verilir.

Dinamik cache key yanlış içerik dönüşünü engeller

Cache anahtarına ülke, cihaz tipi, tenant ID, kullanıcı segmenti veya özel header gibi değişkenler eklenebilir. Aynı URL farklı bağlama göre ayrı cache slot'larına ayrılır. Bu, cache hızını korurken içerik güvenliğini güçlendirir.

Standart override seçenekleri cache verimini artırır

Host, query string, request header ve response header kontrolleri gerektiğinde bilinçli şekilde yok sayılabilir. Bu sayede yanlış yapılandırılmış kurum servisleri veya takip parametreleri cache hit oranını düşürmez. Operatör hangi standardı ne zaman aşacağını açıkça belirler.

Yetenekler

Yanıt Önbellekleme, cache profilinden dinamik anahtara kadar tüm davranışı vService seviyesinde yapılandırılabilir hale getirir.

İsimli cache profili boyut ve süre ayarını merkezileştirir

Her cache profili ad, maksimum boyut ve timeout bilgisiyle tanımlanır. Boyut sınırı servis başına cache kullanımını kontrol altında tutar. Timeout saniye, dakika veya saat seviyesinde ayarlanabilir. Aynı profil farklı vService'lere uygulanarak operasyon tekrarı azaltılır.

Cache hit ve miss bilgisi response header ile görülebilir

TR7, cache davranışını debug etmek için yanıt başlığı ekleyebilir. Geliştirici veya operatör tarayıcı Network ekranından yanıtın cache'den mi kurum servisinden mi geldiğini görebilir. Ek log aracı gerektirmeden hızlı doğrulama yapılır. Bu, devreye alma ve tuning sürecini hızlandırır.

Koşullu cache kural listesi endpoint bazlı kontrol sağlar

Cache profili içinde birden fazla kural tanımlanabilir. Her kural path, method, header, cookie veya FX koşullarıyla tetiklenir. `/assets/*` uzun süre cache'lenirken `/api/cart` cache dışı bırakılabilir. Aynı vService içinde farklı cache davranışları tek panelden yönetilir.

ETag desteği gereksiz veri transferini azaltır

Kural bazında ETag etkinleştirilebilir. İstemci aynı nesneyi tekrar istediğinde, içerik değişmediyse tam gövde yerine doğrulama yanıtı alabilir. Bu bant genişliği tüketimini azaltır. Özellikle statik asset ve nadir değişen API yanıtlarında etkilidir.

Dinamik cache key bağlama göre ayrı slot oluşturur

Dinamik önbellekleme açıkken cache anahtarına özel değişkenler eklenebilir. Ülke, cihaz tipi, tenant ID, A/B test grubu veya JWT içinden çıkarılan değer cache key parçası olabilir. Aynı URL farklı bağlamlarda güvenli şekilde ayrışır. Bu, modern API ve SaaS senaryolarında cache'i kullanılabilir hale getirir.

Host ignore farklı domainlerde aynı içeriği tek cache'te toplar

Aynı kurum servisi birden fazla domain altında aynı içeriği sunuyorsa Host bilgisini cache key'den çıkarmak mümkündür. Böylece `a.example` ve `b.example` gibi domainler aynı nesneyi paylaşabilir. Cache duplikasyonu azalır. Bu seçenek yalnızca içerik gerçekten ortaksa kullanılmalıdır.

Query ignore takip parametrelerinin cache'i bozmasını engeller

`utm_source`, kampanya kodları veya analitik parametreleri aynı içeriği farklı URL gibi gösterebilir. Query ignore açıkken bu parametreler cache key'e dahil edilmez. Böylece aynı sayfanın takip parametreli versiyonları kurum servisine tekrar tekrar gitmez. Public içeriklerde hit oranı belirgin artar.

Request check ignore istemci kaynaklı cache busting'i sınırlar

Bazı istemciler veya botlar her isteğe cache'i devre dışı bırakmaya çalışan header'lar ekleyebilir. Request check ignore ile bu davranış bilinçli şekilde yok sayılabilir. Statik içerik ve public API yanıtlarında kurum servisi gereksiz yükten korunur. Güvenlik hassas endpoint'lerde bu ayar dikkatle kullanılmalıdır.

Response check ignore yanlış kurum servisi header'larını aşabilir

Kurum servisi yanlışlıkla `no-store` veya aşırı korumacı cache başlıkları gönderebilir. Response check ignore ile operatör bu başlıkları bilinçli şekilde aşabilir. Böylece uygulama kodu değişmeden cache faydası alınır. Bu seçenek yalnızca deterministik ve güvenli yanıtlar için kullanılmalıdır.

Tüm methodları cache etme GraphQL POST senaryosunu destekler

Standart HTTP cache davranışı çoğunlukla GET ve HEAD yanıtlarına odaklanır. TR7, operatör isterse POST gibi methodların yanıtlarını da cache davranışına dahil edebilir. Bu özellikle GraphQL sorgu isteklerinin POST üzerinden geldiği yapılarda değerlidir. Cache key'e body hash veya ilgili FX değişkenleri eklenerek güvenli ayrım sağlanabilir.

Memory tabanlı cache yumuşak yeniden yüklemeyle yönetilir

Cache çalışma zamanı belleğinde tutulur. Konfigürasyon değişiklikleri soft-reload modeliyle uygulanır; runtime invalidation endpoint iddiası yoktur. Cache profilini veya kuralını değiştirmek ilgili cache davranışını yeniler. Cihaz yeniden başladığında cache tekrar dolmaya başlar.

En az kullanılan nesneler otomatik çıkarılır

Cache boyutu dolduğunda en az kullanılan veya eskimiş nesneler çıkarılır. Operatör her nesneyi manuel yönetmek zorunda kalmaz. Boyut sınırı, bir vService'in cache kullanımının diğer servisleri etkilemesini engeller. Büyük asset katalogları için profil boyutu ayrıca artırılabilir.

Operasyonel derinlik

Yanıt Önbellekleme; cache süresi, nesne boyutu, key tasarımı, invalidation modeli ve güvenlik sınırlarıyla birlikte planlanmalıdır.

01

Cache boyutu

Cache profili için maksimum boyut MB seviyesinde tanımlanır; profil başına en fazla 2048 MB desteklenir. Büyük asset katalogları için daha geniş profil kullanılabilir. Küçük API yanıtları için daha düşük limit yeterlidir.

02

Minimum timeout

Çok kısa timeout cache thrash'e neden olur ve cache faydasını azaltır. TR7 cache süresini 10 saniyenin altında tutmayarak gereksiz dol-boş davranışını sınırlar. Süre endpoint karakterine göre ayarlanmalıdır.

03

Cache key güvenliği

Cache key yanlış tasarlanırsa kullanıcıya veya tenant'a özel içerik başka bağlamda dönebilir. Tenant, ülke, cihaz tipi veya kullanıcı segmenti gibi ayrıştırıcılar gerekiyorsa dinamik cache key içine alınmalıdır. Hassas endpoint'ler varsayılan olarak cache dışı bırakılmalıdır.

04

Restart davranışı

Cache bellek tabanlıdır; cihaz veya servis yeniden başladığında cache boş başlar. Bu davranış persistent disk cache karmaşıklığını ortadan kaldırır. İlk trafik dalgasında cache yeniden ısınır.

05

Kural bazlı yenileme

Runtime invalidation endpoint'i iddia edilmez. Cache davranışı profil veya kural düzenleme ve soft-reload akışıyla yönetilir. Tek endpoint'in davranışını değiştirmek için ilgili cache kuralı güncellenir.

06

Audit ve operasyon

Cache profili, timeout, ignore seçenekleri ve dinamik key değişiklikleri audit log'a alınmalıdır. Kim hangi endpoint için cache davranışını değiştirdi görülebilir. Bu özellikle uyumluluk ve olay analizi için önemlidir.

Hangi senaryolarda kullanılır

E-ticaret ürün kataloglarını ülke bazlı cache'leme

Ürün sayfaları ve katalog API'leri belirli süre cache'e alınır. Ülke bilgisi cache key'e eklenerek fiyat veya stok farkı olan pazarlarda doğru içerik döner.

Public API yanıtlarını kısa süreli cache'leme

Haber, duyuru veya public içerik endpoint'leri birkaç dakika cache'lenebilir. Query ignore ile takip parametreleri cache hit oranını düşürmez.

Multi-tenant SaaS içeriklerini tenant bazlı ayırma

Tenant ID veya özel header cache key'e eklenir. Aynı path farklı tenant'larda güvenli şekilde ayrı cache slot'larına gider.

GraphQL POST sorgu yanıtlarını kontrollü cache'leme

GraphQL sorguları POST ile gelse bile deterministik sorgular cache'e alınabilir. Body hash veya ilgili FX değişkenleri cache key'e eklenerek yanlış yanıt riski azaltılır.

Statik asset trafiğini kurum servisinden uzaklaştırma

CSS, JS, görsel ve font dosyaları uzun timeout ile cache'lenir. ETag açıkken istemciler değişmeyen içerik için tam gövde indirmez.

Mobil ve masaüstü için ayrı render cache'i

User-Agent ailesi veya cihaz sınıfı cache key'e eklenir. Aynı URL mobil ve masaüstü için farklı cache slot'larında tutulur.

Sık sorulanlar

Cache-Control ve ETag gibi standart başlıklar TR7 ile nasıl çalışır?
TR7 RFC-tabanlı cache davranışını varsayılan olarak uygular: Cache-Control yönergelerine, ETag doğrulama akışına ve Vary başlığına saygı gösterir. Gerektiğinde operatör bu kontrolleri bilinçli şekilde aşabilir; örneğin yanlış yapılandırılmış kurum servisi `no-store` gönderdiğinde response check ignore ile cache çalıştırılabilir.
Dinamik cache key ile Vary başlığı arasındaki fark nedir?
Vary başlığı her header farkı için ayrı slot açar; bu cache hit oranını ciddi ölçüde düşürebilir. TR7'nin dinamik cache key modeli, operatörün yalnızca ihtiyaç duyduğu değişkenleri (ülke, cihaz, tenant ID) anahtara eklemesini sağlar. Böylece cache verimliliği korunurken yanlış içerik dönme riski azaltılır.
Aynı vService'te bazı endpoint'leri cache'leyip bazılarını dışarıda bırakmak mümkün mü?
Evet. Cache profili içinde birden fazla kural tanımlanabilir; her kural FX koşul motoruyla path, method, header veya cookie değerine bağlanır. Örneğin `/assets/*` uzun timeout ile cache'lenirken `/api/cart` veya `/api/checkout` kurallarla cache dışında tutulabilir. Bu kararlar kod değişikliği gerektirmeden ADC katmanında verilir.
Cache invalidation nasıl çalışır; runtime API var mı?
TR7, runtime invalidation endpoint iddiasında bulunmaz. Cache davranışı profil veya kural düzenleme ve soft-reload akışıyla yönetilir. Belirli bir endpoint'in cache davranışını değiştirmek için ilgili cache kuralı güncellenir ve soft-reload tetiklenir. Cache bellek tabanlıdır; cihaz veya servis yeniden başladığında cache boş başlar.
GraphQL POST yanıtları cache'lenebilir mi?
Evet. `allowCacheAllMethods` seçeneği açıldığında POST yanıtları da cache kapsamına girer. GraphQL senaryolarında body hash veya ilgili FX değişkenleri cache key'e eklenerek farklı sorgular ayrı slot'lara ayrılabilir. Bu sayede deterministik GraphQL yanıtları kurum servisine tekrar tekrar gitmeden sunulur.
Cache boyutu ve timeout için önerilen değerler nelerdir?
Cache profili başına en fazla 2048 MB desteklenir; büyük statik asset katalogları için daha yüksek değer, küçük API yanıt cache'leri için daha düşük değer uygundur. Minimum timeout 10 saniyedir; bu sınır cache thrash'i önlemek için zorunludur. Timeout endpoint'in güncellenme sıklığına göre — örneğin ürün kataloğu için 30 dakika, duyuru feed'i için 5 dakika — ayarlanmalıdır.

Kurum servisi yükünü önbellekle azaltın

Cache profili, koşullu kural, dinamik key ve RFC-uyumlu override seçenekleriyle yanıt önbellekleme. Kendi servislerinizle canlı bir kurulumda gezdirelim.