מגבלות שימוש

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

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

יש שני סוגי מכסות שחלות על שיטות של 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	3,000
הקראת הודעות בדקה	spaces.messages.get spaces.messages.list	3,000
כתיבה בדקה	spaces.members.create spaces.members.delete	300
קריאות לדקה של חברוּת	spaces.members.get spaces.members.list	3,000
כתיבה ברווחים בדקה	spaces.setup spaces.create spaces.patch spaces.delete	60
קריאות רווח בדקה	spaces.get spaces.list spaces.findDirectMessage	3,000
כתיבת הקובץ המצורף בדקה	media.upload	600
קריאת קבצים מצורפים בדקה	spaces.messages.attachments.get media.download	3,000
כתיבת תגובה בדקה	spaces.messages.reactions.create spaces.messages.reactions.delete	600
קריאות תגובה בדקה	spaces.messages.reactions.list	3,000

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

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

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

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

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

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

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

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