מגבלת שימוש

הגבלת ברירת המחדל של Google Play EMM API היא 60,000 שאילתות לדקה לכל EMM.

אם תחרגו מהמכסה, המערכת תחזיר את הערך HTTP 429 Too Many Requests ב-Google Play EMM API. כדי לוודא שלא תחרגו ממגבלות השימוש שצוינו ותציעו חוויה אופטימלית למשתמשים, מומלץ ליישם כמה מהשיטות המומלצות שמתוארות בהמשך.

המלצות לשימוש במגבלות השימוש ב-API

כשמשתמשים ב-Google Play EMM API, יש כמה שיטות מומלצות שאפשר ליישם כדי לחלק את הבקשות ולהפחית את הסיכון לחריגה ממגבלות השימוש.

בחירת זמני התחלה ומרווחי זמן באופן אקראי

פעילויות כמו סנכרון מכשירים או צ'ק-אין בו-זמנית צפויות להוביל לעלייה משמעותית בנפח הבקשות. במקום לבצע את הפעילויות האלה במרווחי זמן קבועים, תוכלו לחלק את עומס הבקשות על ידי רנדומיזציה של המרווחים האלה. לדוגמה, במקום לסנכרן כל מכשיר כל 24 שעות, אפשר לסנכרן כל מכשיר בפרק זמן שנקבע באופן אקראי, בין 23 ל-25 שעות. כך אפשר לפזר את מספר הבקשות.

באופן דומה, אם מריצים משימה יומית שמבצעת הרבה קריאות ל-API ברצף, מומלץ להתחיל את המשימה בשעה אקראית בכל יום כדי למנוע שליחה של כמות גדולה של בקשות לכל הלקוחות בארגון בו-זמנית.

שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לנסות שוב את הבקשות

אם אתם מריצים משימות שמכילות הרבה קריאות ל-API, כדאי להשתמש באסטרטגיית השהיה מעריכית בתגובה להגעה למכסה. השהיה מעריכית לפני ניסיון חוזר (exponential backoff) היא אלגוריתם שמבצע ניסיונות חוזרים של בקשות באופן מעריכי. תהליך לדוגמה להטמעה של השהיה מעריכית פשוטה לפני ניסיון חוזר:

1. שולחים בקשה ל-Google Play EMM API.
2. מקבלים תגובה מסוג HTTP 429.
3. ממתינים 2 שניות + random_time ואז מנסים שוב את הבקשה.
4. מקבלים תגובה מסוג HTTP 429.
5. ממתינים 4 שניות + random_time ואז מנסים שוב את הבקשה.
6. מקבלים תגובה מסוג HTTP 429.
7. ממתינים 8 שניות + random_time ואז מנסים שוב את הבקשה.

הערך של random_time הוא בדרך כלל מספר אקראי שנמצא בטווח שבין -0.5 * זמן ההמתנה לבין +0.5 * זמן ההמתנה. צריך להגדיר מחדש את random_time בכל פעם שמנסים שוב את הבקשה. אפשר לנסות שוב לשלוח קריאות ל-API שנדרשות להשלמת פעולות גלויות למשתמשים בתזמון תדיר יותר (למשל, 0.5 שניות, שנייה ו-2).

תהליכי אצווה עם הגבלת קצב

בכל פעם שתהליך באצווה מגיע למכסה, זמן האחזור של פעולות משתמש שקוראים ל-API גדל. במצבים כאלה, יכול להיות ששיטות כמו זמן אחזור חזרה (backoff) מעריכי לא יהיו יעילות מספיק כדי לשמור על זמן אחזור קצר לפעולות של המשתמשים.

כדי להימנע מחריגה חוזרת ונשנית ממגבלות השימוש של ה-API ולהקטין את זמן האחזור של פעולות שגלויות למשתמשים, מומלץ להשתמש במגבלת קצב לעיבוד קבוצות של בקשות (ראו RateLimiter של Google). באמצעות מגביל קצב של יצירת בקשות אפשר לשנות את קצב הבקשות ל-API כך שתמיד תישארו מתחת למגבלות השימוש.

לדוגמה, מתחילים תהליך באצווה עם הגבלת קצב ברירת מחדל של 50 בקשות לשנייה. כל עוד ה-API לא מחזיר שגיאה, צריך להגדיל את המגבלה על קצב הבקשות לאט (1% בכל דקה). בכל פעם שתגיעו למכסה, הורידו את קצב הבקשות ב-20%. הגישה ההסתגלותית הזו מובילה לשיעור בקשות אופטימלי יותר, תוך צמצום זמן האחזור של פעולות שמוצגות למשתמשים.