מגבלות שימוש

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

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

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

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

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

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

מכסה לכל מרחב משותף	שיטות של Chat API	מגבלה (לכל 60 שניות, משותפת בין כל האפליקציות של Chat במרחב)
קריאות בדקה	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
פעולות כתיבה בדקה	media.upload spaces.delete spaces.patch spaces.messages.create (רלוונטי גם לwebhooks נכנסים) spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

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

מכסות לכל פרויקט מגבילות את קצב השאילתות בפרויקט ב-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

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

יש מגבלות מכסה נוספות ליצירת מרחבים משותפים מסוג GROUP_CHAT או SPACE (באמצעות השיטה spaces.create או השיטה spaces.setup). אפשר ליצור פחות מ-35 מרחבים משותפים מהסוגים האלה בדקה ו-800 מרחבים משותפים מהסוגים האלה בשעה. מרחבים משותפים מסוג DIRECT_MESSAGE לא כפופים למגבלות המכסות הנוספות האלה.

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

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

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

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

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

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

1. שולחים בקשה ל-Google Chat 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.

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

• מידע על בקשות להגדלת מכסות
• הצגת המגבלות והשימוש הנוכחי במכסות
• איך מבקשים להגדיל את המכסות