ל-יומן Google API יש מכסות כדי לוודא שכל המשתמשים משתמשים בו בצורה הוגנת. יש שלוש מגבלות חשובות שכדאי לקחת בחשבון כשמשתמשים ב-Calendar API:
- מכסות השימוש בממשקי API נאכפות לכל פרויקט ולכל משתמש. מידע נוסף מופיע בקטע הבא.
- מכסות שימוש כלליות ביומן: כדאי להימנע ממכסות שימוש ביומן.
- מגבלות תפעוליות: יכול להיות שתחול עליכם הגבלת קצב בכל שלב. לדוגמה, אם מנסים לכתוב ליומן יחיד ברצף מהיר.
סוגי מכסות השימוש ב-Calendar API
יש שני סוגים של מכסות:
- לדקה לכל פרויקט: זהו מספר הבקשות שבוצעו על ידי הפרויקט שלכם ב-Google Cloud.
- לדקה לכל פרויקט לכל משתמש: זהו מספר הבקשות שמשתמש מסוים בפרויקט בענן שלכם יכול לשלוח. המגבלה הזו נועדה לעזור לכם לוודא שהשימוש יתחלק באופן הוגן בין המשתמשים.
המכסות מחושבות לדקה באמצעות חלון הזזה, ולכן אם תהיה עלייה מהירה בתעבורת נתונים שתחרוג מהמכסה לדקה במהלך דקה אחת, תהיה הגבלת קצב של יצירת בקשות במהלך החלון הבא כדי להבטיח שהשימוש הממוצע יישאר במסגרת המכסות.
אם תחרגו מאחת המכסות, תוגבלו בקצב יצירת הבקשות ותקבלו קוד סטטוס 403 usageLimits או קוד סטטוס 429 usageLimits לשאילתות שלכם. במקרה כזה, אפשר:
- חשוב להקפיד על כל השיטות המומלצות: שימוש בהשהיה מעריכית לפני ניסיון חוזר, הוספת אקראיות לדפוסי התנועה, שימוש בהתראות פוש.
- אם הפרויקט שלכם גדל ויש לכם יותר משתמשים, אתם יכולים לבקש הגדלה של המכסה לכל פרויקט.
- אם מגיעים למכסת השימוש לכל משתמש, אפשר לבצע את הפעולות הבאות:
- אם משתמשים בחשבון שירות, צריך להקצות את העומס למשתמשים או לפצל אותו בין כמה חשבונות שירות.
- אפשר לבקש להגדיל את המכסה לכל משתמש, אבל בדרך כלל לא מומלץ להגדיל אותה מעבר לערך ברירת המחדל, כי יכול להיות שהאפליקציה תתחיל להגיע לסוגים אחרים של מגבלות, למשל מגבלות כלליות על השימוש ביומן או מגבלות תפעוליות.
בקשה להגדלת מכסה
כדי לראות או לשנות את מגבלות השימוש בפרויקט, או כדי לבקש להגדיל את המכסה:
- אם עדיין אין לכם חשבון לחיוב לפרויקט, אתם צריכים ליצור חשבון כזה.
- נכנסים לדף Enabled APIs (ממשקי API מופעלים) ב-API library ב-קונסולה לממשקי API ובוחרים API מהרשימה.
- כדי לראות ולשנות הגדרות שקשורות למכסות, בוחרים באפשרות מכסות. כדי לראות את נתוני השימוש, בוחרים באפשרות שימוש.
שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff)
אם נרצה שתאטו את קצב הבקשות, נחזיר תגובה 403 usageLimits או תגובה 429 (ראו תיעוד מלא של השגיאות). זו לא שגיאה קריטית, ואנחנו מצפים שתנסו לשלוח את הבקשה שוב אחרי פרק זמן קצר. אם הבקשות ימשיכו להגיע מהר מדי, נבקש שוב, וכן הלאה. כדי שהשיטה הזו תפעל בצורה תקינה, חשוב שההשהיות בין הבקשות יגדלו עם הזמן.
בדרך כלל, כדאי להשתמש בהשהיה מעריכית לפני ניסיון חוזר עם קיטוע. במסמכי Cloud Storage יש הסבר טוב על אופן הפעולה של ההשהיה הזו ועל האלגוריתם המועדף. אם אתם משתמשים בספריית לקוח של Google, בדרך כלל הטיפול בזה מתבצע בשבילכם. כדאי לעיין במסמכי התיעוד של הספרייה. בדרך כלל, מומלץ להשתמש בהטמעה של הספרייה ולא לכתוב הטמעה משלכם.
יצירת דפוסי תנועה אקראיים
לקוחות של יומנים נוטים ליצור דפוסי תנועה עם עליות חדות שנגרמות מכך שכמה לקוחות מבצעים פעולות בו-זמנית. לדוגמה, שיטה לא מומלצת ללקוח של יומן היא לבצע סנכרון מלא בחצות. הסיכוי גבוה מאוד שתחרגו מהמכסה לדקה ותיתקלו בהגבלת קצב של יצירת בקשות ובנסיגות.
כדי להימנע מכך, חשוב לוודא שתנועת הגולשים מתפרסת על פני היום, בכל מקום שאפשר. אם הלקוח צריך לבצע סנכרון יומי, צריך לבקש ממנו לקבוע שעה אקראית (שונה לכל לקוח). אם אתם צריכים לבצע פעולה באופן קבוע, כדאי לשנות את המרווח בטווח של +/- 25%. כך התנועה תתחלק בצורה שווה יותר ותספק חוויית משתמש טובה הרבה יותר.
שימוש בהתראות
תרחיש שימוש נפוץ הוא הרצון לבצע פעולה בכל פעם שמשהו משתנה ביומן של המשתמש. דוגמה לאנטי-תבנית היא שליחת בקשות חוזרות ונשנות לכל לוח שנה שמעניין אתכם. הפעולה הזו תגרום לניצול מהיר של כל המכסה. לדוגמה, אם יש לאפליקציה 5,000 משתמשים והיא שולחת שאילתה ליומן של כל משתמש פעם בדקה, היא תדרוש מכסה של לפחות 5,000 לדקה עוד לפני שהיא מבצעת פעולה כלשהי.
אפליקציות בצד השרת יכולות להירשם לקבלת התראות פוש, וכך נוכל להודיע לכם כשקורה משהו שמעניין אתכם. ההגדרה שלהם דורשת יותר עבודה, אבל הם מאפשרים שימוש יעיל יותר במכסת השימוש ומספקים חוויית משתמש טובה יותר. חשוב לציין את eventType שרוצים לקבל עליה התראה. מידע נוסף זמין במאמר בנושא התראות פוש.
ניהול חשבונות תקין באמצעות חשבונות שירות
אם האפליקציה מבצעת בקשות באמצעות הענקת גישה ברמת הדומיין, כברירת מחדל חשבון השירות מחויב בהתאם למכסות 'לכל דקה לכל פרויקט לכל משתמש', ולא המשתמש שאליו מתבצעת ההתחזות. המשמעות היא שסביר להניח שחשבון השירות יגיע למכסה המקסימלית ויחול עליו הגבלת קצב, גם אם הוא פועל ביומנים של כמה משתמשים. כדי להימנע מכך, אפשר להשתמש בפרמטר quotaUser של כתובת ה-URL (או בכותרת x-goog-quota-user HTTP) כדי לציין איזה משתמש יחויב. הערך הזה משמש רק לחישובים של מכסת השימוש. מידע נוסף זמין במאמר הגבלת בקשות לכל משתמש במאמרי העזרה של Cloud.
בדיקה של טיפול במגבלות מכסה
כדי לוודא שהאפליקציה שלך יכולה להתמודד בצורה חלקה עם הגעה למגבלות מכסת השימוש בפועל (לדוגמה, על ידי השהיה מעריכית לפני ניסיון חוזר (exponential backoff)) וכדי לצמצם את הסיכוי לשיבושים אצל המשתמשים, מומלץ מאוד לבדוק את התרחיש הזה בסביבה אמיתית.
כדי שהבדיקה לא תשפיע על השימוש באפליקציה האמיתית, מומלץ לרשום פרויקט נפרד לבדיקה בלבד ב-Google API Console ולהגדיר אותו באופן דומה לפרויקט הייצור. לאחר מכן תוכלו להגדיר מכסות נמוכות באופן מלאכותי לפרויקט הזה ולבחון את התנהגות האפליקציה.
תמחור
כל השימוש ב-Google Calendar API זמין ללא עלות נוספת. אם חורגים מהמכסה או ממגבלות הבקשות, לא יחויבו חיובים נוספים והחשבון לא יחויב.