- Konu sahibi
- #1
App cache, bir uygulamanın daha önce ürettiği veya dış bir kaynaktan aldığı verileri geçici olarak saklayarak sonraki istekte aynı işi daha hızlı tamamlamasını sağlayan önbellektir. Örneğin bir uygulama ürün listesini veritabanından her istekte yeniden oluşturmak yerine sonucu bellekte, disk üzerinde veya Redis gibi bir önbellek hizmetinde tutabilir. Böylece yanıt süresi ve veritabanı yükü azalır; ancak önbellekteki veri güncel olmayabileceği için geçerlilik süresi ve temizleme davranışı doğru tasarlanmalıdır.
Burada uygulama seviyesinde önbellek anlatılır. Eski HTML5 AppCache tarayıcı özelliği ayrı bir teknolojidir ve modern tarayıcılardan kaldırılmıştır; yeni çevrimdışı web uygulaması için onun manifest akışını bu kavramla karıştırmayın.
Uygulama önce istenen veriye karşılık gelen bir cache anahtarı oluşturur. Bu anahtarla önbelleğe bakılır:
Örneğin
App cache tek bir teknoloji değildir. Uygulamanın çalışma şekline göre bellek içi, dosya tabanlı veya ayrı bir cache servisi kullanılabilir. Kararı verirken uygulamanın tek sunucuda mı, birden fazla sunucuda mı çalıştığı ve verinin ne kadar hızlı güncellenmesi gerektiği önemlidir.
Tek sunuculu, düşük trafik alan bir uygulamada bellek içi veya dosya tabanlı yaklaşım yeterli olabilir. Birden fazla sunucunun aynı veriyi görmesi gerekiyorsa her sunucunun kendi yerel cache'ine güvenmek tutarsız sonuçlara yol açabilir; bu durumda paylaşımlı bir cache katmanı veya açık bir geçersizleştirme mekanizması gerekir.
İkinci çağrıda süre dolmadığı için kayıt kullanılır. Üçüncü çağrı süre dolduğu için yeniler. Örnek yalnız hit/miss kararını döndürür; gerçek ürün nesnesini istemciye gönderen bir API değildir. Üretimde kapasite sınırı, eşzamanlama ve veri değişince ilgili anahtarı geçersiz kılma ayrıca tasarlanır.
En yaygın hata, cache'e yazmayı kolaylaştırıp geçersizleştirmeyi tasarlamamaktır. Özellikle fiyat, stok, oturum, yetki ve kullanıcıya özel içerikler ortak anahtarla saklanmamalıdır. Anahtara dil, bölge, kullanıcı veya sürüm gibi sonucu etkileyen bağlamlar eklenmezse bir isteğin sonucu başka bir isteğe dönebilir.
Bir diğer hata, cache miss anında çok sayıda isteğin aynı pahalı işlemi eşzamanlı başlatmasıdır. Trafik arttığında bu durum veritabanına ani yük bindirebilir. Kritik ve pahalı işlemlerde kilitleme, istek birleştirme veya kontrollü yenileme yaklaşımı değerlendirilmelidir. Önbelleği sınırsız büyütmek de doğru değildir; bellek veya disk sınırı, silme politikası ve başarısız olma davranışı önceden tanımlanmalıdır.
Sonuç olarak app cache, veriyi kalıcı olarak saklayan ana sistemin yerine geçmez. Performansı artıran yardımcı bir katmandır. Önce güvenle önbelleğe alınabilecek pahalı sorguyu belirleyin, sonra anahtar kapsamını, geçerlilik süresini ve veri değiştiğinde silme kuralını birlikte tasarlayın.
Burada uygulama seviyesinde önbellek anlatılır. Eski HTML5 AppCache tarayıcı özelliği ayrı bir teknolojidir ve modern tarayıcılardan kaldırılmıştır; yeni çevrimdışı web uygulaması için onun manifest akışını bu kavramla karıştırmayın.
Nasıl çalışır?
Uygulama önce istenen veriye karşılık gelen bir cache anahtarı oluşturur. Bu anahtarla önbelleğe bakılır:
- Anahtar bulunursa cache hit oluşur ve uygulama veriyi hızlıca önbellekten döndürür.
- Anahtar bulunamazsa cache miss oluşur. Uygulama veriyi veritabanı, API veya dosya sisteminden alır.
- Alınan sonuç, belirlenen süre veya koşul boyunca önbelleğe yazılır.
- Kayıt süresi dolduğunda ya da ilgili veri değiştiğinde kayıt silinir veya yenisiyle değiştirilir.
Örneğin
product:42 anahtarı, 42 numaralı ürünün ayrıntısını temsil edebilir. İlk istekte veritabanına gidilir ve sonuç önbelleğe konur. Sonraki istekler aynı anahtarı kullandığı sürece veritabanına gitmeden yanıtlanabilir. Ürünün fiyatı değiştiğinde bu anahtar temizlenmezse kullanıcı eski fiyatı görebilir.Hangi önbellek yaklaşımı seçilmeli?
App cache tek bir teknoloji değildir. Uygulamanın çalışma şekline göre bellek içi, dosya tabanlı veya ayrı bir cache servisi kullanılabilir. Kararı verirken uygulamanın tek sunucuda mı, birden fazla sunucuda mı çalıştığı ve verinin ne kadar hızlı güncellenmesi gerektiği önemlidir.
| Yaklaşım | Uygun olduğu durum | Dikkat edilmesi gereken |
|---|---|---|
| Bellek içi cache | Tek süreçte hızlı ve küçük veriler | Uygulama yeniden başlayınca kayıtlar kaybolabilir |
| Dosya tabanlı cache | Kalıcı yerel sonuçlar ve basit kurulum | Disk erişimi ve birden fazla çalışan süreçte eşzamanlama |
| Paylaşımlı cache servisi | Birden fazla uygulama sunucusu | Ağ bağlantısı, erişilebilirlik ve anahtar tasarımı |
Tek sunuculu, düşük trafik alan bir uygulamada bellek içi veya dosya tabanlı yaklaşım yeterli olabilir. Birden fazla sunucunun aynı veriyi görmesi gerekiyorsa her sunucunun kendi yerel cache'ine güvenmek tutarsız sonuçlara yol açabilir; bu durumda paylaşımlı bir cache katmanı veya açık bir geçersizleştirme mekanizması gerekir.
Küçük bir hit/miss denemesi
Şu bağımsız JavaScript örneğinde dış servis veya gerçek veritabanı yoktur. simdi parametresi milisaniye cinsinden temsilî saat değeridir; bekleme yapmadan süre sınırını denetler:
JavaScript:
const kaynak = new Map([[42, { ad: "Defter" }]]);
const cache = new Map();
function urunGetir(id, simdi) {
const kayit = cache.get(id);
if (kayit && kayit.son > simdi) return "hit";
if (!kaynak.has(id)) return "bulunamadi";
cache.set(id, { veri: { ...kaynak.get(id) }, son: simdi + 1000 });
return "miss";
}
console.log(urunGetir(42, 0)); // miss
console.log(urunGetir(42, 500)); // hit
console.log(urunGetir(42, 1500)); // missUygulanabilir cache tasarımı
- Önbelleğe alınacak veriyi seçin. Sık okunan ve üretimi pahalı olan, fakat kısa süre eski kalması kabul edilebilen sonuçlarla başlayın.
- Her veri türü için çakışmayan bir anahtar biçimi belirleyin. Kullanıcıya özel verilerde kullanıcı veya yetki bağlamını anahtara dahil edin; ortak anahtarda kişisel veri paylaşmayın.
- Bir geçerlilik süresi belirleyin. Süre, verinin ne kadar eski olabileceğine göre seçilmelidir; sabit bir değer her veri türü için doğru değildir.
- Veri değiştiğinde ilgili anahtarı silin veya yeni değerle güncelleyin. Yalnızca süre dolmasını beklemek, kritik değişikliklerde eski sonuçların görünmesine neden olabilir.
- Cache miss durumunda asıl kaynağa gidin ve hata halinde uygulanacak davranışı belirleyin. Önbellek zorunlu veri deposu değilse, erişilemediğinde uygulamanın kontrollü biçimde asıl kaynağa dönebilmesi gerekir.
- Hit, miss, doluluk, silme ve hata durumlarını izleyin. Hit oranını, yanıt gecikmesini, yükü ve sonuçların doğruluğunu birlikte ölçün; tek bir oran her iş yükü için yeterli karar değildir.
Sık yapılan hatalar
En yaygın hata, cache'e yazmayı kolaylaştırıp geçersizleştirmeyi tasarlamamaktır. Özellikle fiyat, stok, oturum, yetki ve kullanıcıya özel içerikler ortak anahtarla saklanmamalıdır. Anahtara dil, bölge, kullanıcı veya sürüm gibi sonucu etkileyen bağlamlar eklenmezse bir isteğin sonucu başka bir isteğe dönebilir.
Bir diğer hata, cache miss anında çok sayıda isteğin aynı pahalı işlemi eşzamanlı başlatmasıdır. Trafik arttığında bu durum veritabanına ani yük bindirebilir. Kritik ve pahalı işlemlerde kilitleme, istek birleştirme veya kontrollü yenileme yaklaşımı değerlendirilmelidir. Önbelleği sınırsız büyütmek de doğru değildir; bellek veya disk sınırı, silme politikası ve başarısız olma davranışı önceden tanımlanmalıdır.
Sonuç olarak app cache, veriyi kalıcı olarak saklayan ana sistemin yerine geçmez. Performansı artıran yardımcı bir katmandır. Önce güvenle önbelleğe alınabilecek pahalı sorguyu belirleyin, sonra anahtar kapsamını, geçerlilik süresini ve veri değiştiğinde silme kuralını birlikte tasarlayın.
