Yüksek frekanslı yayıncılık çağında ön uç dağıtımın, önbelleğe alma ve sıkıştırma işbirliğini yeniden tasarlaması gerekiyor

Ön uç kaynaklar yüksek frekanslı bir yayın ritmine girdiğinde performans sorunları artık “Brotli’yi açmak” kadar basit olmayacak. İlk ekran yavaşlar, kaynağa dönüş trafiği artar ve uç düğüm CPU’su titrer. Görünüşte sıkıştırmanın yeterince agresif olmadığı görülüyor. Daha derine bakıldığında, genellikle önbelleğe alma ve sıkıştırma ayrı ayrı optimize edilir ve sonunda yayınlama bağlantısında birbirini zayıflatır.

Bu tür bir sorun genellikle ilk versiyonda ortaya çıkmaz. Başlangıçta ekip yalnızca bazı dağınık sinyaller görüyordu: küçük bir değişiklik, statik kaynakların isabet oranında bir bozulmaya neden oldu, büyük bir promosyonun arifesinde uç sıkıştırma CPU’sunda anormal bir artış oldu ve gri tonlama aşamasındaki dönüş paketi hacmi, resmi trafikle eşleşmedi. Kontrol etmeye devam ederseniz, ipuçları genellikle aynı şeye yaklaşır: kaynak içeriği çok az değişmiş olsa da, önbellek anahtarı, parça bölme ve sıkıştırılmış girdi farklı şeyler haline gelmiştir ve taşıma katmanı yeniden tüm maliyeti üstlenmek zorunda kalır.

Kaynak karması stabil olana kadar sıkıştırmanın faydaları kesinlikle savunulamaz.

Ön uç projeler birden çok sayfa, birden çok rota ve birden çok ekiple paralel olarak yayınlandıktan sonra en kolay gözden kaçırılan husus, dosya adı istikrarıdır. Parça segmentasyonu biraz saptığı sürece, iş kodu yalnızca bir düğmenin kopyasını değiştirse bile, nihai ürün aynı zamanda bir dizi genel paketin karmasını da yeniden yazabilir. Önbelleğe alma sisteminin gördüğü şey, bir grup yepyeni nesnedir ve sıkıştırma sisteminin gördüğü şey, ilk kez ortaya çıkan bir grup girdidir.

Şu anda sıkıştırma oranı ne kadar yüksek olursa olsun isabet oranını çökmekten kurtaramaz. Eski dosyalar hâlâ uç düğümlerde duruyor ve yeni dosyalar yeniden anahtarlandı; tarayıcının yerel önbelleği tamamen geçersizdir ve CDN’nin kaynağı yeniden çekmesi, yeniden sıkıştırması ve yeniden dağıtması gerekir. Küçük işletmedeki bir değişiklik, tüm iletim bağlantısı için tekrarlanan çalışmalara dönüştürülür.

Gerçekten yararlı olan eylem genellikle sıkıştırma düzeyini ayarlamaya devam etmek değil, ilk olarak serbest bırakılan ürünün kararlılığını kontrol etmektir:

• İş değişikliklerini azaltmak ve hash’i değiştirmek için temel paketleri bir araya getirmek için genel bağımlılıklar ayrı katmanlara bölünür.
• Zaman damgaları ve yapı numaraları gibi yüksek sıklıkta yapılan değişiklikleri doğrudan ürün içeriğine karıştırmaktan kaçının
• Her derlendiğinde yeniden karıştırılmak yerine, aynı rotaya yakın olan kodun mümkün olduğunca kararlı parçalara ayrılmasına izin verin.

Yalnızca kaynak kimliği sabitlendiğinde önbellek sürekli olarak yeniden kullanılabilir ve sıkıştırma sonuçları kümülatif değere sahip olur.

Yüksek frekanslı basın toplantısı, sıkıştırma sorununu sözlük sürümü sorununa dönüştürüyor

Kaynaklar giderek daha fazla parçalandıkça, tek dosya Brotli veya gzip hala önemlidir, ancak artık her şey değildir. Gerçek maliyet yinelenen parçalara doğru kaymaya başlar: çerçeve çalışma zamanı kodu, stil şablonları, arayüz türü bildirimleri, paketleyiciler tarafından oluşturulan paketleme katmanları genellikle sürüm grupları arasında oldukça benzerdir. Hızlı bir çıkış temposuyla bu riffler tekrar tekrar aktarılacak.

Sorun, sıkıştırma sözlüğünün, sürüm temposuyla birlikte yönetilmemesi durumunda kolayca bir optimizasyondan kesintiye dönüşebilmesidir. Sözlük önceden değiştirilirse eski sayfanın referans verdiği yeni sözlük uyumsuz olacaktır; sözlük çok fazla parçaya bölünüyor ve uç düğümler tarafından sürdürülecek versiyonların sayısı keskin bir şekilde artıyor; sözlük güncellemesi çevrimiçi kaynakla senkronize edilmez ve vurulması gereken nesneler tam iletime geri döndürülür.

Bu aynı zamanda son zamanlardaki ön uç dağıtımında da oldukça pratik bir değişikliktir: önbelleğe alma stratejileri ve sıkıştırma protokolleri artık farklı ekipler tarafından sürdürülemez. Kaynak sürümleri, sözlük sürümleri ve önbellek anahtarı alanları aslında aynı yayınlama sorunudur.

Aşağıdaki gibi hiyerarşik bir yaklaşım genellikle "tüm site için birleşik güçlü sıkıştırma"dan daha kararlıdır:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

Önemli olan, bu üç satırın konfigürasyonunun kendisi değil, ifade ettiği kısıtlamalardır: uzun yaşam döngüsü kaynakları, kısa yaşam döngüsü listesi ve sıkıştırılmış sözlük sürümü, aynı yayın ritmine göre birlikte gelişmelidir.

Kaynağa dönme baskısı genellikle dosyanın çok büyük olmasından değil, başarısızlık yönteminin çok kaba olmasından kaynaklanır.

Bir diğer çok yaygın yanlış değerlendirme ise bant genişliğindeki artışı doğrudan sayfanın ağırlığına bağlamaktır. Sayfalar kesinlikle ağırlaşıyor, ancak çevrimiçi olarak daha tehlikeli amfiler genellikle gidilecek yol.

Her yayınladığınızda dizine, öneke ve hatta sitenin tamamına göre temizlerseniz, önbellek katmanı hafızasını anında kaybeder. Şu anda, dosya boyutu artmaya devam etmese bile, kaynağa dönüş tepe değeri kendiliğinden yukarı çekilecektir. Kaynak döndürülür döndürülmez kenarlar yeniden sıkıştırılır, nesneler yeniden ısıtılır ve tarayıcı yeniden indirilir. Yayımlama penceresi küçük bir adım değişikliğinden tam site değişikliğine dönüşecektir.

Bu tür senaryolarda en değerli şey kontrol edilebilir arıza yarıçapıdır:

• Yalnızca gerçekten değişen bildirimi, HTML’yi ve değiştirilebilir kaynakları geçersiz kılın
• Statik dosyaları hash ile temizlememeye çalışın ve doğal geçiş için bunları yeni referanslara aktarın.
• Hepsini bir kerede temizlemek yerine, sürümü “önce yeni kaynaklar yükleyin, ardından referansları kesin, ardından eski kaynakları geri dönüştürün” sırasına göre bölün

Aktarım maliyeti konusunda gerçekten hassas olan şey yalnızca dosya boyutu değil, aynı zamanda sistemin hangi içeriğin yeniden getirilmesi gerektiğine nasıl karar verdiğidir.

Uygulanabilir sınır, kaynak ölçeği ve sürüm sıklığı ile birlikte belirlenir.

Bu ortak tasarım seti tüm siteler için gerekli değildir. Az sayıda statik sayfaya, küçük bir kaynak paketine ve haftalık, hatta aylık yayın sıklığına sahip projeler için, geleneksel karma dosya adlarının yanı sıra Brotli ön sıkıştırmasının kullanılması genellikle yeterince kararlıdır.

Önbelleğe alma ve sıkıştırma birlikte, bu özellikler yerine getirildiğinde hızla bir dağıtım altyapısı haline gelir:

• Gri tonlamalı, geri alma veya bölgesel lansmanlarla günde birden çok kez yayınlandı
• Ön uç ürünün boyutu büyüktür, birçok genel bağımlılığa sahiptir ve karmaşık yığın ilişkilerine sahiptir.
• CDN, nesne depolama, kenar sıkıştırma ve tarayıcı önbelleğe alma, iletim bağlantısına aynı anda katılır
• Trafik o kadar yüksek ki, önbellek isabet oranı ve başlangıç noktasına dönüş tepe değeri doğrudan maliyet ve istikrarı yansıtacaktır.

Ön uç dağıtım bu aşamaya girdikten sonra, sıkıştırma artık yalnızca “dosyaları küçültmek” değildir ve önbellekleme artık yalnızca “içeriğin daha fazla kopyasını depolamak” değildir. İkisi birlikte karar verir: Küçük işletme değişikliği için, sadece bir parça daha göndermek mi, yoksa tüm iletim bağlantısının yeniden çalıştırılması gerekip gerekmediği. Ne kadar sık ​​yayın yaparsanız bu fark o kadar pahalı olur.