מגבלות שימוש

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

אם תחרגו ממכסה, תקבלו תשובה עם קוד הסטטוס 429: Too many requests‏ HTTP. בדיקות נוספות של מגבלת הקצב בקצה העורפי של Google Workspace Events API עשויות גם הן לגרום לאותה תגובת שגיאה. אם השגיאה הזו מתרחשת, צריך להשתמש באלגוריתם השהיה מעריכית לפני ניסיון חוזר ולנסות שוב מאוחר יותר. כל עוד אתם לא חורגים מהמכסות לדקה שמפורטות בטבלאות הבאות, אין מגבלה על מספר הבקשות שתוכלו לשלוח ביום.

מכסות לכל פרויקט

מכסות לכל פרויקט מגבילות את קצב השאילתות בפרויקט ב-Google Cloud, ולכן הן חלות על אפליקציה אחת שמפעילה את השיטות שצוינו של Google Workspace Events API לכל מכסה.

בטבלה הבאה מפורטות המגבלות על שאילתות לכל פרויקט. אפשר למצוא את המגבלות האלה גם בדף Quotas במסוף Google Cloud.

מכסה לכל פרויקט

שיטות של Google Workspace Events API

מגבלה

פעולות כתיבה בדקה

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

פעולות כתיבה בדקה לכל משתמש

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

קריאות בדקה

Subscriptions.get

Subscriptions.list

600

מספר הקריאות בדקה לכל משתמש

Subscriptions.get

Subscriptions.list

100

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

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

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

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

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

  1. שולחים בקשה ל-Google Workspace Events 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 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלת זמן.

משך ההמתנה בין הניסיונות החוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.

בקשה להגדלת מכסה לכל פרויקט

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

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

מידע נוסף זמין במשאבים הבאים: