מגבלות שימוש

ל-יומן Google API יש מכסות כדי לוודא שכל המשתמשים משתמשים בו בצורה הוגנת. יש שלוש מגבלות חשובות שצריך לקחת בחשבון כשמשתמשים ב-Calendar API:

  • מכסות שימוש ב-API: נאכפות לכל פרויקט ולכל משתמש. מידע נוסף זמין במאמר בנושא סוגי מכסות לשימוש ב-Calendar API.

  • מגבלות כלליות על השימוש ב-Google Calendar: ‏Google Calendar API הוא שירות משותף עם מגבלות שנועדו להגן על הביצועים הכוללים של מערכת Google Workspace. מידע נוסף מופיע במאמר בנושא איך להימנע ממגבלות על השימוש ביומן

  • מגבלות תפעוליות: יכול להיות שהמגבלות האלה יהיו מוגבלות בכל שלב. לדוגמה, אם מנסים לכתוב ליומן יחיד ברצף מהיר.

מכסות ל-Calendar API

יש שני סוגים של מכסות:

  • לכל דקה לכל פרויקט: זהו מספר הבקשות שפרויקט Google Cloud יכול לשלוח בדקה אחת.

  • לדקה לכל משתמש לכל פרויקט: זהו מספר הבקשות שכל משתמש יכול לשלוח בפרויקט בענן. המגבלה הזו נועדה לעזור לכם לוודא שהשימוש יתחלק באופן הוגן בין המשתמשים.

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

בטבלה הבאה מפורטות המגבלות האלה:

סוג מכסת השימוש מגבלה
לדקה לכל פרויקט ‫10,000 בקשות
לדקה לכל משתמש לכל פרויקט ‫600 בקשות

סף החיוב היומי

המגבלה הזו לכל פרויקט ביום מגדירה את המספר המקסימלי של בקשות שפרויקט Google Cloud יכול להשתמש בהן בפרק זמן של 24 שעות לפני שמתחילים לחייב עליהן.

אם השימוש שלכם נמוך מהסף הזה, לא תחויבו בחשבון Google Cloud. פרטי החיוב המלאים ישותפו בהמשך בשנת 2026, לפחות 90 יום לפני ששינויים ייכנסו לתוקף.

אי אפשר לבקש להגדיל את מגבלת הסף היומית הזו.

בטבלה הבאה מפורטת המגבלה:

סוג מגבלת הסף מגבלה
לכל פרויקט ביום ‫1,000,000 בקשות

מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.

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

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

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

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

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

  1. שליחת בקשה ל-Google Calendar API.
  2. אם הבקשה נכשלת, צריך להמתין ‎1 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
  3. אם הבקשה נכשלת, צריך להמתין ‎2 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
  4. אם הבקשה נכשלת, צריך להמתין ‎4 + random_number_milliseconds‎ שניות ולנסות שוב את הבקשה.
  5. וכך הלאה, עד maximum_backoff פעמים.
  6. ממשיכים להמתין ולנסות שוב עד שמגיעים למספר מקסימלי מסוים של ניסיונות חוזרים, אבל לא מגדילים את תקופת ההמתנה בין הניסיונות החוזרים.

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 שניות. בשלב מסוים, צריך למנוע מהלקוחות לנסות שוב ללא הגבלה.

זמן ההמתנה בין ניסיונות חוזרים ומספר הניסיונות החוזרים תלויים בתרחיש לדוגמה ובתנאי הרשת.

תמחור

כל השימוש הרגיל ב-Google Calendar API זמין ללא עלות נוספת. אנחנו מתכננים להתחיל לחייב את החשבון שלכם לחיוב ב-Google Cloud על חריגה ממגבלות הבקשות של המכסה בהמשך שנת 2026. מידע נוסף זמין במאמר בנושא מודל סטנדרטי של Google Workspace לכלי סוכנים וממשקי API.

שליחת בקשה להגדלת המכסה

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

המכסות לא זהות בכל הפרויקטים. ככל שהשימוש שלכם ב-Google Cloud יגדל עם הזמן, יכול להיות שתצטרכו להגדיל את ערכי המכסות. אם צפויה עלייה משמעותית בשימוש, אפשר לבקש התאמות של המכסות מראש בדף Quotas & System Limits (מכסות ומגבלות מערכת) במסוף Google Cloud.

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

פתרון בעיות

אם תחרגו מאחת מהמכסות, תוגבלו בקצב השליחה ותקבלו קוד סטטוס 403 usageLimits או קוד סטטוס 429 usageLimits בתגובה לשאילתות שלכם.

אם זה קורה, אפשר לנסות את הפעולות הבאות:

  1. חשוב לפעול לפי כל השיטות המומלצות: להשתמש בנסיגה אקספוננציאלית, לערבב את דפוסי התנועה ולהשתמש בהתראות פוש.

  2. אם הפרויקט שלכם גדל ויש לכם יותר משתמשים, אתם יכולים לבקש הגדלה של המכסה.

  3. אם מגיעים למכסות לכל משתמש, אפשר לבצע את הפעולות הבאות:

    • אם משתמשים בחשבון שירות, צריך להקצות את העומס למשתמשים או לפצל אותו בין כמה חשבונות שירות.

    • אפשר לבקש להגדיל את המכסה לכל משתמש, אבל בדרך כלל לא מומלץ להגדיל אותה מעבר לערך ברירת המחדל, כי יכול להיות שהאפליקציה תתחיל לחרוג מסוגים אחרים של מגבלות, למשל מגבלות כלליות על השימוש ביומן או מגבלות תפעוליות.

  4. כדי לבדוק את מגבלות המכסה, צריך לרשום פרויקט נפרד לבדיקה בלבד עם הגדרה דומה לזו של פרויקט הייצור. מידע נוסף זמין במאמר בנושא בדיקת הטיפול במגבלות המכסה.

יצירת דפוסי תנועה אקראיים

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

כדי להימנע מכך, חשוב לוודא שהתנועה מתפרסת על פני כל היום, בכל מקום שאפשר. אם הלקוח צריך לבצע סנכרון יומי, הלקוח צריך להגדיר זמן אקראי (שונה לכל לקוח). אם אתם צריכים לבצע פעולה באופן קבוע, כדאי לשנות את המרווח בטווח של ‎+/- 25%. כך התנועה תתחלק בצורה שווה יותר וחוויית המשתמש תהיה טובה יותר.

שימוש בהתראות

תרחיש נפוץ לשימוש הוא ביצוע פעולה בכל פעם שמשהו משתנה ביומן של המשתמש. דוגמה לאנטי-תבנית היא שליחת בקשות חוזרות לכל היומנים שמעניינים אתכם. הפעולה הזו תגרום לניצול מהיר מאוד של כל המכסה. לדוגמה, אם לאפליקציה שלכם יש 5,000 משתמשים והיא שולחת שאילתה ליומן של כל משתמש פעם בדקה, אז נדרשת מכסה של 5,000 לפחות לדקה, עוד לפני שמתבצעת עבודה כלשהי.

אפליקציות בצד השרת יכולות להירשם לקבלת התראות פוש, וכך נוכל להודיע לכם כשקורה משהו שמעניין אתכם. ההגדרה שלהם דורשת יותר עבודה, אבל הם מאפשרים שימוש יעיל יותר במכסת השימוש ומספקים חוויית משתמש טובה יותר. חשוב לציין את eventType שרוצים לקבל עליהם התראות. מידע נוסף זמין במאמר בנושא התראות Push.

הקצאה נכונה באמצעות חשבונות שירות

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

כדי להימנע מכך, אפשר להשתמש בפרמטר quotaUser של כתובת ה-URL (או בכותרת ה-HTTP‏ x-goog-quota-user) כדי לציין איזה משתמש מחויב. הערך הזה משמש רק לחישוב מכסת השימוש. מידע נוסף זמין במאמר בנושא הגבלת מספר הבקשות לכל משתמש.

בדיקה של טיפול במגבלות מכסה

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

כדי לבדוק בלי להפריע לשימוש באפליקציה האמיתית, מומלץ לרשום פרויקט נפרד למטרות בדיקה בלבד ב-מסוף Google Cloud ואז להגדיר את מסך ההסכמה ל-OAuth באופן דומה לפרויקט הייצור. אחרי כן תוכלו להגדיר מכסות נמוכות באופן מלאכותי לפרויקט הזה ולבחון את ההתנהגות של האפליקציה.

מכסות של שרת ה-MCP של היומן

שרת ה-MCP של Calendar משתמש במדד להקצאת עלויות של שאילתות. בטבלאות הבאות מפורטת עלות השאילתה לכל שיטה של שרת MCP של Calendar לפי קטע:

מכסות של תוכנית השותפים של Microsoft Cloud (MCP) ביומן

יש שני סוגים של מכסות:

  • לדקה לכל פרויקט בענן: זו העלות של השאילתה לפרויקט ב-Google Cloud למשך דקה אחת.

  • לדקה לכל משתמש לכל פרויקט: זו העלות של שאילתה לפרויקט בענן ב-Google Cloud למשך דקה אחת שכל משתמש יכול להשתמש בה.

בטבלה הבאה מפורטות המכסות האלה:

סוג מכסת השימוש עלות שאילתה
לדקה לכל פרויקט 10,000
לדקה לכל משתמש לכל פרויקט 600

מכסות של כלי MCP ליומן

בטבלה הבאה מפורטות עלויות השאילתות לכל calendarmcp.googleapis.comערכת כלים:

נקודת קצה כלי עלות שאילתה

/mcp/v1

create_event

1

delete_event

10

get_event

1

list_events

1

respond_to_event

1

search_events

1

update_event

1

suggest_time

1

list_calendars

1

מידע נוסף זמין במאמר Calendar MCP API Reference.