Bant genişliğinden tasarruf etmek için birden fazla HTTP isteğini birleştirmek iyi bir fikir mi?

Bazen yavaş mobil bağlantı üzerinden kullanılacak tek sayfalık bir uygulama hazırlıyorum. Bazı kısımları API talepleri açısından oldukça ağırdır (yeni bir ekran görüntüsü için on farklı kaynak getiriliyor).

Şimdi, bu hizmetleri gerekli tüm verileri sağlayan, ancak REST ilkeleri açısından "saf" olmayan bir hizmetle birleştirmek iyi bir fikir mi? Beklenecek önemli performans kazanımları var mı?

REST'in avantajlarından biri, geleneksel http önbellekleri aracılığıyla istekleri önbelleğe alma yeteneğidir (bunların önbelleğe alınabilir istekler olduğu varsayılarak).

Tek, daha büyük, daha az sıklıkta kullanılan ve muhtemelen farklı istekleriniz olduğunda ( a,b,c,dbu sefer öğeleri ve bir a,b,d,edahaki sefere öğeleri getireceğim), isteği önbellek kaçırma ve süresi dolabilecek bir önbellekten alma olasılığınızı artırırsınız kaynak ile aranızda bir yerde oturuyor.

Yukarıda belirtilen iki istek kümesi göz önüne alındığında, ikinci istek önbellek isabet oranının % 75'ine sahip olabilir ve edört şeyin hepsinden ziyade çok daha hızlı getirilebilir .

İlk önbellek özlem isteklerini yapan kişi önbellek özledikleri almaya devam edeceğinden, bunu kullanan kişiler için hemen anlaşılmayabilir.

Bu, yerel olmayan önbellek isabetlerinin alınma olasılığının düşük olduğu bir mobil ağ bağlantısında ideal olacağı anlamına gelmez. Ancak sıcak noktalar veya diğer wifi durumları için önbellek isabetleri çok daha yararlı olabilir.

Bunların çoğu tekrar başvurunuzun nasıl çalıştığına bağlıdır. Başlangıçta tüm bu verileri mi istiyor? veya yanıt süresi beklentilerinin farklı olduğu bir sayfa yükünden mi bahsediyoruz?

Yapılacak en ideal şey, uygulamanızın çeşitli durumlarda nasıl performans gösterdiğini görmek için bunu test etmek olacaktır. Mobil cihazınızı izleyebileceğiniz yerel bir kablosuz ağa bağladığınız bir durumu ayarlamayı (Google'da sadece ilk hit olur) ve işlerin gerçekte nasıl çalıştığını (veya çalışmadığını) görmek için kötü bir internet bağlantısı simüle etmeyi düşünün ve hangisinin en iyi performansa sahip olduğu.

Sezginiz biraz doğrudur - daha az talepte bulunmak kesinlikle tercih edilir; tıknaz API'lar daha iyi olma eğilimindedir. Özellikle bazı işleri görebileceğiniz sivilceli bağlantı ve bazılarının hiçbir şey hiçbir şeye güvenemeyeceği için kabus düşme senaryoları yaratmakta başarısız olduğu.

Büyük bir uyarı var - çok tıknaz olabilir ve çağrılarınız ve yanıtlarınız şişirilir. Örneğin, bir sayfaya ilk kez vurduğunuzda ve ardından her veri istediğinizde büyük bir sayfayı yenilemeye zorlamak yerine daha küçük ısırıklarla güncelleme akışına sahip olmak için büyük bir çağrı yapmanız mantıklı olabilir.

Ya da, her iki şekilde de yapmak isteyeceksiniz.

Bu Dropbox Tech Blog makalesine göz atın .

Burada, tüm resimleriniz için küçük resimleri almak için önerdiğiniz çözümü tam olarak neden ve nasıl uyguladıklarını ayrıntılı olarak açıklarlar. Soruna değip değmeyeceğini görmek için performansı ölçtükleri söylenmelidir ve görünüşe göre öyle.

Kısa özet:

Dropbox web sitesi yüzlerce küçük resim yüklemelidir. Bazı tarayıcılardaki sınırlamalar nedeniyle, tüm küçük resimler paralel olarak yüklenmez (istekler sıraya alınır). SPDY'yi kullanmak istiyorlardı , ancak sistemlerinin bir kısmı henüz desteklemediğinden bunu yapamadılar. Sonunda, HTTP üzerinden toplu istekler kullandılar, bu da yanıt başına sıkıştırılmış bir formda birden fazla küçük resim döndürdü. Toplam sayfa yükleme süresi artışı sonuçlarına göre% 40 idi.

Kısacası: Yaklaşımınız biraz doğru ve bir sargı Hizmetinden yararlanabilir.

Bu hizmet mevcut tek aramaları tek bir hizmet tarafı yönteminde birleştirir. Bunu, istemciden servis tarafına çağrıları birleştirerek ve şimdiye kadar muhtemelen sahip olduğunuz tüm tek, atomik, huzurlu çağrıları kullanarak yapın.

Böylece, istekleri önbelleğe alma özelliği olarak REST'ten yararlanmaya devam edersiniz.

Ancak, son noktada her şey onu tüketmesi gereken hizmet / sunucu altyapı performansı ve istemci ortamına kadar kaybolacaktır.