מגבלות שימוש

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

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

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

מכסות לכל מקום

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

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

מכסה לשטח	שיטות ב-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 אחת ששולחת קריאה שיטות ה-API של Chat לכל מכסה.

בטבלה הבאה מפורטות המגבלות הבאות של שאילתות לכל פרויקט. אפשר גם למצוא המגבלות האלה מופיעות בדף 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 מרחבים בדקה ו-210 מרחבים בכל פעם שעה מהסוגים האלה. מרחבים מסוג DIRECT_MESSAGE לא כפופים למרחבים האלה מגבלות נוספות במכסות.

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

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

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

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

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

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