הגבלות שימוש

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

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

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

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

רנדומיזציה של זמני ההתחלה ומרווחי הזמן

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

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

שימוש בהשהיה מעריכית כדי לנסות שוב לשלוח בקשות

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

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 שנדרשות כדי להשלים פעולות שמיועדות למשתמש בתדירות גבוהה יותר, (למשל, שנייה, שנייה ושנייה).

תהליכים באצווה עם מגבלת תעריפים

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

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

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