מגבלות שימוש

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

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

יכול להיות שסוגים שונים של מכסות יחולו על שיטות של Chat API: מכסות לכל פרויקט, לכל מרחב ולכל משתמש.

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

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

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

מכסה לכל פרויקט	שיטות של Chat API	מגבלה (לכל 60 שניות)
כתיבת הודעות לדקה	`spaces.messages.create` `spaces.messages.patch` `spaces.messages.delete`	3000
הודעות שנקראו לדקה	`spaces.messages.get` `spaces.messages.list`	3000
מספר הכתיבות בדקה של חברי מועדון	`spaces.members.create` `spaces.members.delete`	300
קריאות בדקה של חברים במועדון	`spaces.members.get` `spaces.members.list`	3000
כתיבות במרחב לדקה	`spaces.setup` `spaces.create` `spaces.patch` `spaces.delete`	60
קריאות של מקום בדקה	`spaces.get` `spaces.list` `spaces.findDirectMessage`	3000
כתיבות של קבצים מצורפים לדקה	`media.upload`	600
קריאת קבצים מצורפים בדקה	`spaces.messages.attachments.get` `media.download`	3000
מספר פעולות כתיבה של תגובות באמוג'י לדקה	`spaces.messages.reactions.create` `spaces.messages.reactions.delete`	600
מספר התגובות באמוג'י לדקה	`spaces.messages.reactions.list`	3000

מכסות לכל מרחב

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

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

מכסה לכל מרחב	שיטות של Chat API	מגבלה (לשנייה)
קריאות בשנייה	`media.download` `spaces.get` `spaces.members.get` `spaces.members.list` `spaces.messages.get` `spaces.messages.list` `spaces.messages.attachments.get` `spaces.messages.reactions.list`	15
פעולות כתיבה לשנייה	`media.upload` `spaces.delete` `spaces.patch` ‫`spaces.messages.create` (חלות מגבלות נוספות על webhooks נכנסים) `spaces.messages.delete` `spaces.messages.patch` `spaces.messages.reactions.delete`	1
יצירת כתיבות של תגובות בשנייה	`spaces.messages.reactions.create`	5
מספר הפעמים שההודעה נכתבת בשנייה בזמן ייבוא נתונים ל-Google Chat	`spaces.messages.create`	10

מכסות לכל משתמש

מכסות לכל משתמש מגבילות את קצב השאילתות של משתמש ב-Google Chat. השאילתות מתייחסות לכל אפליקציות Chat שקוראות לשיטת Chat API בשם משתמש (באמצעות אימות משתמש).

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

מכסה לכל משתמש	שיטות של Chat API	מגבלה (לשנייה)
קריאות בשנייה	`customEmojis.get` `customEmojis.list`	15
פעולות כתיבה לשנייה	`customEmojis.create` `customEmojis.delete`	1

מכסה לכל משתמש

שיטות של Chat API

מגבלה (לשנייה)

קריאות בשנייה

customEmojis.get

customEmojis.list

פעולות כתיבה לשנייה

customEmojis.create

customEmojis.delete

מגבלות שימוש נוספות

תנועה גבוהה של API שמטרגטת את אותו מרחב יכולה להפעיל מגבלות פנימיות נוספות שלא מוצגות בדף Quotas.

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

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

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

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

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

שולחים בקשה ל-Google Chat API.
אם הבקשה נכשלת, צריך להמתין ‎1 + random_number_milliseconds‎ ולנסות שוב את הבקשה.
אם הבקשה נכשלת, צריך להמתין ‎2 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
אם הבקשה נכשלת, צריך להמתין ‎4 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
וכך הלאה, עד maximum_backoff פעמים.
ממשיכים להמתין ולנסות שוב עד שמגיעים למספר מקסימלי של ניסיונות חוזרים, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.

where:

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

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

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