השימוש ב-Gmail API כפוף למגבלות שימוש שמגבילות את הקצב שבו אפשר לקרוא לשיטות של ה-API. המגבלות מוגדרות במונחים של יחידות מכסה, יחידת מידה מופשטת שמייצגת את השימוש במשאבי Gmail. יש שתי מגבלות שימוש שחלות בו-זמנית: מגבלת קצב לכל פרויקט ומגבלת קצב לכל משתמש.
בטבלה הבאה מפורטות המגבלות האלה:
| סוג מכסת השימוש | מגבלה | קוד שגיאה |
|---|---|---|
| מגבלת קצב לכל פרויקט | 1,200,000 יחידות מכסה לדקה | rateLimitExceeded |
| הגבלת קצב לכל משתמש | 15,000 יחידות מכסה לדקה לכל משתמש | userRateLimitExceeded |
מידע על טיפול בשגיאות שקשורות למגבלות זמין במאמר פתרון שגיאות.
ניצול המכסה לכל שיטה
מספר יחידות המכסה שנצרכות על ידי בקשה משתנה בהתאם לשיטה שנקראת. בטבלה הבאה מפורט השימוש ביחידות המכסה לכל שיטה:
| שיטה | יחידות מיכסה |
|---|---|
drafts.create |
10 |
drafts.delete |
10 |
drafts.get |
5 |
drafts.list |
5 |
drafts.send |
100 |
drafts.update |
15 |
getProfile |
1 |
history.list |
2 |
labels.create |
5 |
labels.delete |
5 |
labels.get |
1 |
labels.list |
1 |
labels.update |
5 |
messages.attachments.get |
5 |
messages.batchDelete |
50 |
messages.batchModify |
50 |
messages.delete |
10 |
messages.get |
5 |
messages.import |
25 |
messages.insert |
25 |
messages.list |
5 |
messages.modify |
5 |
messages.send |
100 |
messages.trash |
5 |
messages.untrash |
5 |
settings.delegates.create |
100 |
settings.delegates.delete |
5 |
settings.delegates.get |
1 |
settings.delegates.list |
1 |
settings.filters.create |
5 |
settings.filters.delete |
5 |
settings.filters.get |
1 |
settings.filters.list |
1 |
settings.forwardingAddresses.create |
100 |
settings.forwardingAddresses.delete |
5 |
settings.forwardingAddresses.get |
1 |
settings.forwardingAddresses.list |
1 |
settings.getAutoForwarding |
1 |
settings.getImap |
1 |
settings.getPop |
1 |
settings.getVacation |
1 |
settings.sendAs.create |
100 |
settings.sendAs.delete |
5 |
settings.sendAs.get |
1 |
settings.sendAs.list |
1 |
settings.sendAs.update |
100 |
settings.sendAs.verify |
100 |
settings.updateAutoForwarding |
5 |
settings.updateImap |
5 |
settings.updatePop |
100 |
settings.updateVacation |
5 |
stop |
50 |
threads.delete |
20 |
threads.get |
10 |
threads.list |
10 |
threads.modify |
10 |
threads.trash |
10 |
threads.untrash |
10 |
watch |
100 |
כשמשתמשים ב-Gmail API, יש גם מגבלה של 500 נמענים לכל הודעת אימייל.
פתרון שגיאות שקשורות למכסת זמן
לגבי כל השגיאות שמבוססות על זמן (מקסימום N בקשות לכל X דקות), מומלץ שהקוד יזהה את החריג וישתמש בהשהיה מעריכית קטומה לפני ניסיון חוזר כדי לוודא שהמכשירים לא יוצרים עומס מוגזם.
השהיה מעריכית לפני ניסיון חוזר היא אסטרטגיה סטנדרטית לטיפול בשגיאות באפליקציות רשת. אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באמצעות הגדלה אקספוננציאלית של זמני ההמתנה בין הבקשות, עד למשך ההשהיה המקסימלי. אם הבקשות עדיין לא מצליחות, חשוב שההשהיות בין הבקשות יגדלו עם הזמן עד שהבקשה תצליח.
אלגוריתם לדוגמה
אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מבצע ניסיון חוזר של בקשות באופן אקספוננציאלי, ומגדיל את זמן ההמתנה בין הניסיונות החוזרים עד למשך ההשהיה המקסימלי. לדוגמה:
- שליחת בקשה ל-Gmail 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 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלת זמן.
זמן ההמתנה בין ניסיונות חוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.
תמחור
כל השימוש ב-Gmail API זמין ללא עלות נוספת. אם חורגים מהמכסה או ממגבלות הבקשות, לא יחויבו חיובים נוספים והחשבון לא יחויב.
איך מבקשים להגדיל את המכסות
יכול להיות שתרצו לבקש שינוי במכסות בהתאם לשימוש במשאבים בפרויקט. קריאות ל-API על ידי חשבון שירות נחשבות לשימוש בחשבון יחיד. הגשת בקשה להתאמת המכסה לא מבטיחה שהבקשה תאושר. יכול להיות שיעבור יותר זמן עד שנאשר בקשות להתאמת מכסות שיובילו להגדלה משמעותית של ערך המכסה.
המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם אתם צופים עלייה משמעותית בשימוש בקרוב, תוכלו לבקש התאמות במכסות מראש בדף Quotas במסוף Google Cloud.
מידע נוסף זמין במקורות המידע הבאים:
נושאים קשורים
- שיפור הביצועים
- מגבלות לשליחה וקבלה של אימיילים
- מגבלות שליחה שמוגדרות למשתמשי Gmail ב-Google Workspace