מגבלות שימוש

ה-API ל-REST של Google Meet הוא שירות משותף, ולכן אנחנו מחילים מכסות והגבלות כדי לוודא שכל המשתמשים ישתמשו בו בצורה הוגנת וכדי להגן על הביצועים הכוללים של מערכת Google Workspace.

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

בטבלה הבאה מפורטות המגבלות על שאילתות:

מכסות
בקשות קריאה
לדקה לכל פרויקט 6000
לדקה למשתמש לפרויקט 600
כתיבת בקשות
לדקה לכל פרויקט 1,000
לדקה למשתמש לפרויקט 100
בקשות מצומצמות לכתיבה

(משמש לבקשות spaces.create.)

לדקה לכל פרויקט 100
לדקה למשתמש לפרויקט 10

פתרון שגיאות שקשורות למכסות מבוססות-זמן

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

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

אלגוריתם לדוגמה

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

  1. לשלוח בקשה ל-Google Meet API.
  2. אם הבקשה נכשלת, צריך להמתין 1 + random_number_milliseconds ולנסות שוב את הבקשה.
  3. אם הבקשה נכשלת, צריך להמתין 2 + random_number_milliseconds ולנסות שוב את הבקשה.
  4. אם הבקשה נכשלת, צריך להמתין 4 + random_number_milliseconds ולנסות שוב את הבקשה.
  5. וכך הלאה, עד פעם אחת (maximum_backoff).
  6. אפשר להמשיך להמתין ולנסות שוב עד למספר המקסימלי של ניסיונות חוזרים, אבל אין להאריך את תקופת ההמתנה בין הניסיונות החוזרים.

איפה:

  • זמן ההמתנה הוא 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 לאורך הזמן, יכול להיות שתצטרכו להגדיל את המכסות שלכם. אם צפויה עלייה משמעותית בשימוש, אתם יכולים לבקש באופן יזום שינויים במכסות בדף Quotas במסוף Google Cloud.

מידע נוסף זמין במקורות המידע הבאים: