İster yeni ortaya çıkan bir uygulamayı büyütüyor ister halihazırda yüksek trafik alan bir hizmet kullanıyor olun, bu rehberde yer alan analizlerden ve pazarlama materyallerinin sorun yok. Bu kavram ve uygulamalar, olumsuz durumlardan bu durum, yüksek hacimde ileti göndermenizin gerekli olacağı zamanı etkiler.
Anahtar terimler ve kavramlar
Mesaj İsteği: FCM mesaj isteği; "request" ile birbirinin yerine kullanılır. "mesaj" veya "sorgu".
Saniye başına istek (RPS): Gelen aramalarınızın oranını açıklayan bir metrik FCM'ye yapılan talepler; sorgu sayısı (QPS) ile birbirinin yerine kullanılır.
Kota Jetonları, Jeton Paketleri ve Yedekler: FCM HTTP v1 API, her istek belirli bir zamanda kendisine tahsis edilen bir Kota Jetonu tüketir penceresini kapatın. "Jeton Paketi" adı verilen bu pencere yeniden doldurulacak seçilebilir. Örneğin, HTTP v1 API her biri için 600 bin Kota Jetonu ayırır Her 1 dakikalık sürenin sonunda doldurulacak şekilde, 1 dakikalık Jeton Paketi.
Sunucu tarafı sınırlama: Trafik hacmi FCM hizmetinin
kapasite, sunma kapasitesini aşan istekler hız sınırı girişi için reddedilir
akışı sağlar. Şunları belirtmek için retry-after üst bilgi içeren 429 hata yanıtı döndürülebilir
bir süre beklemenizi öneririz.
İstemci Tarafı Kısıtlama: İstemciler istek hataları, yüksek gecikme ve
veya 429 hatalarının şiddetlenmesinden kaçınmak için çıkış akışlarının isteğe bağlı olarak hız sınırlaması yapması gerekir.
tıkanıklık.
Üstel geri yükleme: Hatalı işlemleri yeniden denerken, katlanarak artan süre gecikmelerini ekleyin. Örneğin: 1s, 2 sn., 4 sn., 8 sn., 16 sn., 32 sn.
Ses dalgalanması: Tam aralıklarda yeniden deneme yapmaktan kaçınma. Titremeyle, Yeniden deneme gecikmelerini rastgele bir işlemden geçirerek bunları eşit şekilde dağıtmanız gerekir (örneğin: 0,9 sn., 2,3 sn, 4,1 sn., 8,5 sn, 17,9 sn, 34,7 sn).
Yeniden deneme güçlendirmesi: Başarısız istekler üstel olmadan yeniden denendiğinde genellikle birikerek devam eden trafik yükünü artırır. "güçlendirme" potansiyeli ve trafik tıkanıklığı sorunlarını şiddetlendirir.
Sorun: ani trafik artışları
FCM, saniyede milyonlarca isteği (RPS) işler. Projeye en çok katkıda bulunan sistematik tıkanıklık, gecikme sorunları ve kesintiler trafikteki ani artışlardır.
Ani trafik artışı nedir?
Birkaç farklı türde trafik artışı vardır.
Saat içi artışlar: FCM, ilk 30 dönemde iki kattan fazla trafik alır 2-2 dakika arasında değişir. Daha az olsa da artışlar da benzer düzeyde yarım ve çeyrek saat işaretlerinde gözlemlenen (örnekler: 00:15, 00:30, 00:45)
Yükseltmeyi yeniden deneme: Başarısız olan veya zaman aşımına uğrayan istekleri, şu olmadan yeniden deneme: Üstel geri yükleme üstünde, tekrar eden trafik dalgaları halinde birikmelidir.
Ani trafik kalıbı değişiklikleri: Yeni trafiği FCM'ye yönlendirme veya trafiği taşıma kademeli artış gibi düzeltici faktörler olmadan bölgeler genelinde FCM'ye ani artışlara neden olabilir.
Önden yükleme kota jetonu kullanımı: Başlangıcında tüm kota jetonlarının tükenmesi istekleri kotaya eşit olarak yaymak yerine kota aralıkları çok zor ve pahalı olan açma/kapatma salınımları bulunur.
Özel etkinlikler: Tatiller veya spor etkinlikleri sırasında ani trafik artışları (FIFA Dünya Kupası).
"Eğriyi düzleştirerek" trafikteki ani artışları düzeltme
Bu bölümde, ani trafik artışlarını azaltmaya yönelik stratejiler açıklanmaktadır: olası "eğriyi düzleştirme" stratejileridir.
FCM">FCM özelliğini yalnızca uygun kullanım alanları için kullanın
Bildirim göndermek için FCM'nin kullanılmasının mümkün olmadığı bazı kullanım alanları vardır. emin olmanız gerekir.
Örneğin, takvim etkinliği bildirimleri için şurada yerel görev planlayabilirsiniz: göndermek yerine uygun zamanlarda bir bildirim görüntülemesini uygulama sunucunuzdan yükleyebilirsiniz. FCM iletilerini takvim senkronizasyonlarıyla sınırlandırın.
Ani artışlardan kaçının
Ölçeklendirme karşıtı kalıplardan biri, FCM bildirimlerini sistemlerin yapacağı kadar hızlı göndermektir. izin verdiğinden emin olun. Aşağıdakileri göz önünde bulundurun:
- Tüm müşterilerinizin aynı bildirimi 1 dakikalık süre içinde alması gerekiyor mu? Örneğin, 5 dakikalık bir teslimat aralığı işletmenizin ihtiyaçlarını yine de karşılar mı?
- Müşterileriniz, ani artışları sorunsuz hale getirme önceliğine göre segmentlere ayrılabilir mi?
- Bildirimlerinizi önceden planlayabilir misiniz?
Mümkün olduğunda: FCM gönderme kotanızın hemen tükenmesine neden olan stratejilerden kaçının. Jeton paketiniz dolduğunda kalıbı tekrar edin. Bu erişim desen, FCM ve bağımlılığı için yük dengeleme problemleri oluşturur sistemlerdir. Trafiği mümkün olduğunca kademeli olarak artırın. En azından, 0'dan yönünde rampa maksimum RPS'yi öğrenebilirsiniz. Daha yüksek performans için daha uzun aralıkları tercih et RPS'ye dokunun.
"Çalışma saatleri içinde" kullanmaktan kaçının trafik
Mümkünse: Her iletiden sonra 2 dakikalık süre içinde ileti göndermekten :00, :15, :30 ve :45 dakika işaretleriyle gösteriliyor.
Sunucu tarafı kısıtlama uygulama
FCM'ye giden trafik akışını izlemek ve yönetmek için sunucu tarafı kısıtlama uygulayın.
Yeniden denemeleri işleme
FCM, yüksek düzeyde erişilebilir olmak için çalışsa da bazen bazı istekler zaman aşımına uğrayabilir test edebilirsiniz. Nedenler değişiklik gösterse de aşağıdaki en iyi uygulamalardan yararlanarak yeniden deneme optimizasyonu mümkün olan en kısa sürede teslim ederek içeriğin etkisini trafik sıkışıklığı.
Engelleme
Şu tarihten önce gönderme isteklerinde en az 10 saniyelik bir zaman aşımı ayarlayın: yeniden deneniyor. FCM'nin dahili Uzak Prosedür Çağrılarının çoğu 10 saniyelik zaman aşımını kullanır.
Hatalar
- 400, 401, 403, 404 hataları için: İşlemi iptal edin ve yeniden denemeyin.
- 429 hataları için: Yeniden deneme bölümünde ayarlanan süreyi bekledikten sonra yeniden deneyin kullanabilirsiniz. Yeniden deneme üstbilgisi ayarlanmazsa varsayılan olarak 60 saniyeye ayarlanır.
- 500 hataları için: Eksponansiyel geri yükleme ile tekrar deneyin.
Eksponansiyel geri yükleme
Yeniden yükseltmenin yeniden denemesini önlemek için eksponansiyel uygulama uygulayın titremeyle geri çekilir. Firebase Admin SDK'sı, eksponansiyel geri yükleme uygular.
Önerilen diğer ayarlardan bazıları şunlardır:
- Minimum Aralık: Başarısız bir isteği FCM ile hemen yeniden denemeyin. Başarısız bir isteği yeniden denemeden önce en az 10 saniye bekleyin.
- Maksimum Aralık: Süresiz olarak yeniden denemek yerine, artık zamanında gelmeyen isteklerin düşülmesi için maksimum aralık belirleyin.
Bir istek üstel geri yükleme ile sürekli olarak yeniden deneniyorsa ve hâlâ devam ediyorsa hata, 60 dakika sonra başarısız olursa, yanlış bir şekilde yeniden denenebilir hata kategorisinde değerlendirilir veya FCM, yeniden deneme işlemlerinin yanlışlıkla hızlandırabileceği bir hizmet kesintisi yaşıyor durum.
Kullanıma sunma ve geri alma planları oluşturup kademeli değişiklikler yapın
FCM'ye giden trafiği artırmak gibi büyük ölçekli trafik değişiklikleri yaparken kullanıma sunma/geri alma planı hazırlama, trafiği bölgeler veya ağlar arasında kaydırma ve kademeli değişiklikler uygulamak kullanıcılarınızı, hizmetinizi ve FCM'yi koruyacaktır.
- Kullanıma sunma planı, paydaşların beklentilerini birbiriyle uyumlu hale getirir. Bazı durumlarda (aşağıda açıklanmıştır) sürprizlerin önüne geçmek için kullanıma sunma planınızı FCM ekibiyle önceden paylaşabilirsiniz.
- Geri alma planı, beklenmedik durumları hesaba katabilmenizi ve öngörülemeyen arızalardan hızlı ve güvenli bir şekilde kurtulmak için mekanizmalar hazırlamanızı sağlar.
- Kademeli değişiklikler yapmanın iki yönü vardır:
- "Adım adım" artışlar: Adımlar %1 olmalıdır -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 veya daha hassas. "Salama" (yükleme altındaki sistem davranışını gözlemleyin) ve her bir adımı 1 gün ila 1 hafta arasında bir süre boyunca çalıştırın. Bu, bir sonraki "adım artışı"ndan önce olası sorunları tespit etmenize olanak tanır.
- Kademeli trafik artışları: Her "adımı" uygularken trafiği artırmak için en az bir saatlik bir süre boyunca trafiği sadeleştirin. Bu, FCM'nin yük dengeleme altyapısının yeni trafiğinizi uygun şekilde ölçeklendirmesini sağlarken hotspot ve tıkanıklık olasılığını en aza indirir.
Aşağıda,dünya çapında 500.000 RPS'nin FCM HTTP v1 API'ye FCM Eski HTTP API:
| Hafta | Step | Kademeli Artış Stratejisi |
|---|---|---|
| 0 | %1 artış | Bir saat içinde 0'dan 5.000 RPS'den FCM HTTP v1'e sorunsuz şekilde yükselin. |
| 1 | %5 artış | 2 saatte 5.000 RPS'den 25.000 RPS'ye sorunsuz şekilde başlayın. |
| 2 | %10 artış | 2 saatte 25.000'den 50.000 RPS'ye sorunsuz şekilde artış |
| 3 | %25 artış | 3 saatte 50.000 RPS'den 125.000 RPS'ye artış |
| 4 | %50 artış | 6 saatte 125.000 RPS'den 250.000 RPS'ye artış |
| 5 | %75 artış | 6 saatte 250.000 RPS'den 375.000 RPS'ye yükselme |
| 6 | %100 artış | 6 saatte 375.000 RPS'den 500.000 RPS'ye yükselme |
Varsayımsal geri alma planı:
- Herhangi bir adımda 95 yüzdelik gecikme 500 ms'nin üzerine çıkarsa veya hata oranı bir saatten uzun bir süre boyunca% 1'i aşarsa hemen önceki adıma dönmek için dinamik yapılandırmayı kullanın.
- Gecikme ve hata oranı nominal düzeylere dönene kadar önceki adımlara geri alma işlemine devam edin.
FCM ile ne zaman iletişime geçmelisiniz?
Firebase Desteği üzerinden FCM ile iletişime geçin şu durumlardan biri geçerliyse:
- Varsayılan kotalar artık kullanım alanınızı karşılamıyor
- Gönderme kalıplarınızı 3 aylık bir zaman aralığı içinde şu adresten değiştiriyorsunuz: global ölçekte 100.000 RPS veya kıtasal 30.000 RPS.