המטרה שלנו היא תמיד למסור כל הודעה שנשלחת באמצעות FCM. עם זאת, שליחת כל הודעה לפעמים פוגעת בחוויית המשתמש הכוללת. במקרים אחרים, אנחנו צריכים לספק גבולות כדי להבטיח ש-FCM יספק שירות ניתן להרחבה לכל השולחים. סוגי המגבלות והמכסות שמתוארים בקטע הזה עוזרים לנו לשמור על איזון בין הגורמים החשובים האלה.
הגבלת קצב של הודעות שמועברות בהמשך השרשרת
ב-HTTP v1 API הוספנו מכסות לכל פרויקט ולכל דקה לשליחת הודעות במורד הזרם. מכסת ברירת המחדל של 600,000 הודעות לדקה מכסה יותר מ-99% מהמפתחיםFCM, תוך שמירה על יציבות המערכת ומזעור ההשפעה של פרויקטים עם עליות חדות.
דפוסי תנועה עם עליות חדות עלולים לגרום לשגיאות שקשורות לחריגה מהמכסה. במקרה של חריגה מהמכסה, המערכת מציגה את קוד הסטטוס 429 RESOURCE_EXHAUSTED HTTP (QUOTA_EXCEEDED) עד שהמכסה מתמלאת מחדש בדקה הבאה. יכול להיות שיוחזרו גם תשובות 429 במצבי עומס יתר, ולכן מומלץ מאוד לטפל בתשובות 429 בהתאם להמלצות שפורסמו.
חשוב לזכור:
- המכסה במורד הזרם מתייחס להודעות ולא לבקשות.
- שגיאות לקוח (קוד סטטוס של HTTP 400-499) נספרות (לא כולל 429).
- המכסות הן לדקה, אבל הדקות האלה לא תואמות לשעון.
מכסת ניטור
אפשר לראות את המכסה, השימוש והשגיאות במסוף Google Cloud:
עוברים אל מסוף Google Cloud.
לוחצים על APIs & Services (ממשקי API ושירותים).
ברשימת הטבלאות, בוחרים באפשרות Firebase Cloud Messaging API.
בוחרים באפשרות QUOTA & SYSTEM LIMITS (מכסות ומגבלות מערכת).
שליחת בקשה להגדלת המכסה
לפני ששולחים בקשה להגדלת המכסה, חשוב לוודא:
- השימוש שלכם הוא באופן קבוע ≥ 80% מהמכסה למשך 5 דקות רצופות לפחות בכל יום.
- שיעור השגיאות בצד הלקוח נמוך מ-5%, במיוחד בזמן שיא התנועה.
- אתם פועלים לפי השיטות המומלצות לשליחת הודעות בהיקף גדול.
אם אתם עומדים בקריטריונים האלה, תוכלו להגיש בקשה להגדלת המכסה בשיעור של עד 25% במסוף Google Cloud באמצעות האפשרויות הבאות:
- עוברים אל QUOTA & SYSTEM LIMITS.
- בטבלה, בוחרים את השורה Send requests per minute (שליחת בקשות לדקה).
- לוחצים על הלחצן עריכה.
- פועלים לפי ההוראות כדי לשלוח את הבקשה.
FCM נשתדל מאוד למלא את הבקשה (אין אפשרות להבטיח הגדלה).
אם אתם צריכים מכסה גדולה יותר של הודעות נכנסות בגלל השקה קרובה או אירוע זמני, אתם צריכים לשלוח בקשה להגדלת המכסה דרך התמיכה של Firebase. כדי שהבקשה תטופל בזמן, מומלץ לשלוח אותה לפחות 15 ימים מראש. לגבי בקשות גדולות (יותר מ-18 מיליון הודעות בדקה), נדרש לפחות 30 יום מראש. אנחנו יכולים לאשר רק 2 אירועים של מכסה זמנית בשנה. המשך הכולל של תקופת המכסה הזמנית במהלך השנה לא יכול להיות יותר מ-30 ימים. הדרישות בנוגע ליחס שגיאות הלקוח והשיטות המומלצות עדיין חלות על בקשות להשקות ולאירועים מיוחדים.
מידע נוסף זמין במאמר בנושא מכסות של FCM.
מגבלות על הודעות בנושאים וויסות של העברת הודעות
פרטים נוספים זמינים במאמר בנושא מכסות ומגבלות של הודעות בנושאים.
הגבלת קצב השליחה של הודעות מתקפלות
כפי שמתואר במאמר בנושא הודעות שניתנות לכיווץ, הודעות שניתנות לכיווץ הן התראות ללא תוכן שמיועדות להתכווץ אחת על גבי השנייה. אם מפתח חוזר על אותה הודעה באפליקציה בתדירות גבוהה מדי, אנחנו מעכבים את ההודעות כדי לצמצם את ההשפעה על הסוללה של המשתמש.
לדוגמה, אם אתם שולחים מספר גדול של בקשות חדשות לסנכרון אימייל למכשיר יחיד, יכול להיות שנשהה את הבקשה הבאה לסנכרון אימייל למשך כמה דקות, כדי שהמכשיר יוכל לבצע סנכרון בקצב ממוצע נמוך יותר. ההגבלה הזו מתבצעת אך ורק כדי לצמצם את ההשפעה על הסוללה שהמשתמש חווה.
אם תרחיש השימוש שלכם דורש דפוסי שליחה של פרצי תנועה גבוהים, יכול להיות שהודעות לא מצומצמות הן הבחירה הנכונה. בהודעות כאלה, חשוב לכלול את התוכן כדי להפחית את עלות הסוללה.
אנחנו מגבילים את מספר ההודעות שניתן לכווץ ל-20 הודעות לכל אפליקציה לכל מכשיר, עם מילוי מחדש של הודעה אחת כל 3 דקות.
קצב ההודעות המקסימלי למכשיר יחיד
ב-Android, אפשר לשלוח עד 240 הודעות לדקה ו-5,000 הודעות בשעה למכשיר יחיד. הסף הגבוה הזה נועד לאפשר פרצי תנועה לטווח קצר, למשל כשמשתמשים מנהלים אינטראקציה מהירה בצ'אט. המגבלה הזו מונעת שגיאות בלוגיקת השליחה שעלולות לגרום לניקוז הסוללה במכשיר.
ב-iOS, אנחנו מחזירים שגיאה כשהקצב חורג מהמגבלות של APNs.