מכיוון שה-API ל-REST של Google Meet הוא שירות משותף, אנחנו מיישמים מכסות והגבלות כדי לוודא שכל המשתמשים משתמשים בו בצורה הוגנת וכדי להגן על הביצועים הכוללים של מערכת Google Workspace.
אם תחרגו ממכסה, בדרך כלל תקבלו תשובה עם קוד הסטטוס 429: Too many requests של HTTP. במקרה כזה, צריך להשתמש באלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ולנסות שוב מאוחר יותר. כל עוד לא חורגים מהמכסות לדקה, אין הגבלה על מספר הבקשות שאפשר לשלוח ביום.
בטבלה הבאה מפורטות המגבלות על שאילתות:
| מכסות | |||||
|---|---|---|---|---|---|
| בקשות קריאה |
|
||||
| כתיבת בקשות |
|
||||
|
הפחתת מספר בקשות הכתיבה
(משמש לבקשות של |
|
||||
פתרון שגיאות שקשורות למכסות מבוססות-זמן
בכל השגיאות מבוססות הזמן (עד N בקשות ל-X דקות), אנחנו ממליצים שהקוד יזהה את החריג וישתמש בהשהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) כדי לוודא שהמכשירים לא ייצרו עומס יתר.
השהיה מעריכית לפני ניסיון חוזר היא אסטרטגיה סטנדרטית לטיפול בשגיאות באפליקציות רשת. אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באמצעות הגדלה אקספוננציאלית של זמני ההמתנה בין הבקשות, עד למשך ההשהיה המקסימלי. אם הבקשות עדיין נכשלות, חשוב להגדיל את ההשהיות בין הבקשות עם הזמן עד שהבקשה תצליח.
דוגמה לאלגוריתם
אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיונות חוזרים של בקשות באופן מעריכי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים עד למשך ההשהיה המקסימלי. לדוגמה:
- לשלוח בקשה ל-Google Meet API.
- אם הבקשה נכשלת, צריך להמתין 1 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 2 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 4 +
random_number_milliseconds שניות ולנסות שוב את הבקשה. - וכן הלאה, עד
maximum_backoffפעמים. - ממשיכים להמתין ולנסות שוב עד למספר ניסיונות חוזרים מקסימלי, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.
כאשר:
- זמן ההמתנה הוא
min(((2^n)+random_number_milliseconds), maximum_backoff), ו-nגדל ב-1 בכל איטרציה (בקשה). random_number_millisecondsהוא מספר אקראי של אלפיות שנייה שקטן מ-1,000 או שווה לו. כך אפשר למנוע מקרים שבהם הרבה לקוחות מסונכרנים בגלל מצב מסוים, וכולם מנסים שוב בו-זמנית ושולחים בקשות בגל מסונכרן. הערך שלrandom_number_millisecondsמחושב מחדש אחרי כל בקשה לניסיון חוזר.maximum_backoffהוא בדרך כלל 32 או 64 שניות. הערך המתאים תלוי בתרחיש לדוגמה.
הלקוח יכול להמשיך לנסות שוב אחרי שיסתיים הזמן של maximum_backoff.
ניסיונות חוזרים לאחר השלב הזה לא צריכים להמשיך להגדיל את זמן ההשהיה לפני ניסיון חוזר. לדוגמה, אם לקוח משתמש בזמן maximum_backoff של 64 שניות, אחרי שהוא מגיע לערך הזה, הלקוח יכול לנסות שוב כל 64 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלת זמן.
משך ההמתנה בין הניסיונות החוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.
תמחור
כל השימוש ב-Google Meet API זמין ללא עלות נוספת. אין חיובים נוספים על חריגה ממגבלות הבקשות במכסה, והחשבון לא מחויב.
שליחת בקשה להגדלת מכסה
בהתאם לשימוש במשאבים בפרויקט, יכול להיות שתרצו לבקש הגדלה של המכסה. קריאות ל-API שמתבצעות על ידי חשבון שירות נחשבות כמשתמשים בחשבון יחיד. שליחת בקשה להגדלת המכסה לא מבטיחה אישור. אישור של הגדלות מכסות גדולות עשוי להימשך זמן רב יותר.
לא לכל הפרויקטים יש את אותן מכסות. ככל שתשתמשו יותר ב-Google Cloud עם הזמן, יכול להיות שתצטרכו להגדיל את המכסות. אם אתם מצפים לעלייה משמעותית בשימוש בעתיד, תוכלו לבקש התאמות למכסות מראש דרך דף המכסות במסוף Google Cloud.
מידע נוסף זמין במשאבים הבאים: