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