מגבלות שימוש

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

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

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

המכסות לכל פרויקט מגבילות את קצב השאילתות בפרויקט ב-Google Cloud, ולכן חלות על אפליקציה אחת שקוראת ל-methods API שצוינו ב-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 דקות), מומלץ שהקוד יתפוס את החריגה וישתמש בהשהיה מעריכית קטועה כדי לוודא שהמכשירים לא ייצרו עומס יתר.

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

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

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

  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 או שווה לו. כך ניתן למנוע מקרים שבהם לקוחות רבים מסונכרנים במצבים מסוימים, וכולם מנסים שוב בבת אחת, ושולחים בקשות בפרסומי wave מסונכרנים. הערך של random_number_milliseconds מחושב מחדש אחרי כל בקשה לניסיון חוזר.
  • משך הזמן של maximum_backoff הוא בדרך כלל 32 או 64 שניות. הערך המתאים תלוי בתרחיש לדוגמה.

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

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

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

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

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

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