Google Chat API הוא שירות משותף, ולכן אנחנו מחילים מכסות והגבלות כדי לוודא שכל המשתמשים ישתמשו בו בצורה הוגנת וכדי לשמור על רמת הביצועים הכוללת של Google Workspace.
אם תחרגו מהמכסה, תקבלו תגובת קוד סטטוס HTTP מסוג 429: Too many requests
. גם בדיקות נוספות של הגבלת הקצב של יצירת בקשות בקצה העורפי של Chat עשויות להוביל לשגיאה זהה. אם השגיאה הזו מתרחשת, יש להשתמש באלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ולנסות שוב מאוחר יותר. כל עוד לא חורגים מהמכסות לדקה שמפורטות בטבלאות הבאות, אין הגבלה על מספר הבקשות שאפשר לשלוח ביום.
יש שני סוגי מכסות שחלות על שיטות של Chat API: מכסות למרחב משותף ולפי פרויקט.
מכסות לכל מקום
מכסות לפי מרחב משותף מגבילות את קצב השאילתות במרחב משותף מסוים. המכסות משותפות בין כל אפליקציות Chat שפועלות באותו מרחב משותף וקוראות לשיטות Chat API שצוינו עבור כל מכסה.
בטבלה הבאה מפורטות המגבלות על שאילתות בכל מרחב משותף:
מכסה לכל מקום |
שיטות Chat API |
מגבלה (ל-60 שניות, משותף |
---|---|---|
קריאות בדקה |
|
900 |
כתיבה בדקה |
|
60 |
מכסות לכל פרויקט
המכסות לכל פרויקט מגבילות את קצב השאילתות שקשורות לפרויקט ב-Google Cloud, והן חלות על אפליקציית Chat אחת שקוראת לשיטות Chat API שצוינו עבור כל מכסה.
בטבלה הבאה מפורטות המגבלות על שאילתות לכל פרויקט המגבלות האלה מופיעות גם בדף Quotas.
מכסה לכל פרויקט |
שיטות Chat API |
מגבלה (לכל 60 שניות) |
---|---|---|
נכתבת הודעה בדקה |
|
3,000 |
הקראת הודעות בדקה |
|
3,000 |
כתיבה בדקה |
|
300 |
קריאות לדקה של חברוּת |
|
3,000 |
כתיבה ברווחים בדקה |
|
60 |
קריאות רווח בדקה |
|
3,000 |
כתיבת הקובץ המצורף בדקה |
|
600 |
קריאת קבצים מצורפים בדקה |
|
3,000 |
כתיבת תגובה בדקה |
|
600 |
קריאות תגובה בדקה |
|
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) מבצע ניסיון חוזר של בקשות באופן אקספוננציאלי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים לזמן השהייה המקסימלי. לדוגמה:
- לשלוח בקשה ל-Google Chat API.
- אם הבקשה נכשלת, צריך להמתין 1 +
random_number_milliseconds
ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 2 +
random_number_milliseconds
ולנסות שוב את הבקשה. - אם הבקשה נכשלת, צריך להמתין 4 +
random_number_milliseconds
ולנסות שוב את הבקשה. - וכך הלאה, עד פעם אחת (
maximum_backoff
). - אפשר להמשיך להמתין ולנסות שוב עד למספר המקסימלי של ניסיונות חוזרים, אבל אין להאריך את תקופת ההמתנה בין הניסיונות החוזרים.
איפה:
- זמן ההמתנה הוא
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.
מידע נוסף זמין במקורות המידע הבאים: