קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מכסות מגינות על התשתית של Google מפני תהליכים אוטומטיים שמשתמשים ב-Google Bid Manager API באופן בלתי הולם. הם מבטיחים שהפעולות של מפתח אחד לא ישפיעו לרעה על הקהילה הרחבה יותר.
מגבלות המכסה
מגבלות המכסות הבאות שמוגדרות כברירת מחדל משותפות לכל המשאבים והשיטות של Bid Manager API.
במסוף Google API, המכסה הזו נקראת שאילתות לדקה לכל משתמש, והיא מוגדרת ל-240.
חריגה מהמכסות המותרות
במקרה הלא סביר שבו הבקשה תיכשל עקב חריגה מהמכסה, ה-API יחזיר קוד סטטוס HTTP ואת הסיבה לשגיאה. בנוסף, גוף התגובה מכיל תיאור מפורט של הגורם לשגיאה. אפשר לעיין במדריך הודעות שגיאה כדי לראות דוגמה לתגובת שגיאה.
ברשימה הבאה מפורטות השגיאות האפשריות והפעולות המומלצות במקרה של כשל בבקשות שנגרמו עקב חריגה ממגבלות המכסה.
קוד
הסיבה
מסר
מה מומלץ לעשות?
403
dailyLimitExceeded
חרגת מהמגבלה היומית
אין לנסות שוב בלי לפתור את הבעיה. כדאי לבדוק את השימוש שלכם מתוך Google API Console ולשנות את תהליך העבודה כך שיפחית את מספר הבקשות. אתם יכולים לבקש מכסה נוספת אם לדעתכם השימוש שלכם סביר.
מהי השהיה מעריכית לפני ניסיון חוזר (exponential backoff)?
השהיה מעריכית היא אסטרטגיה סטנדרטית לטיפול בשגיאות עבור אפליקציות רשת, שבה הלקוח מנסה שוב ושוב לשלוח בקשה שנכשלה בפרק זמן הולך וגדל. אם נפח גדול של בקשות או תנועה כבדה ברשת גורמים לשרת להחזיר שגיאות, השהיה מעריכית יכולה להיות שיטה טובה לטיפול בשגיאות האלה. לעומת זאת, זו לא אסטרטגיה רלוונטית לטיפול בשגיאות שאינן קשורות לנפח הרשת או לזמני התגובה, כמו פרטי כניסה לא חוקיים להרשאה או שגיאות מסוג 'לא נמצא קובץ'.
כשמשתמשים בה כראוי, השהיה מעריכית מגדילה את יעילות השימוש ברוחב הפס, מפחיתה את מספר הבקשות הנדרשות לקבלת תגובה מוצלחת ומגדילות את תפוקת הבקשות בסביבות בו-זמניות.
כך מטמיעים השהיה מעריכית פשוטה:
שליחת בקשה ל-API.
מתקבלת תגובה HTTP 503, שלפיה צריך לנסות לשלוח שוב את הבקשה.
יש להמתין שנייה אחת +ran_number_milliseconds ולנסות שוב.
מתקבלת תגובה HTTP 503, שלפיה צריך לנסות לשלוח שוב את הבקשה.
ממתינים 2 שניות +ran_number_milliseconds ומנסים שוב לבצע את הבקשה.
מתקבלת תגובה HTTP 503, שלפיה צריך לנסות לשלוח שוב את הבקשה.
מחכים 4 שניות +ran_number_milliseconds ומנסים שוב לבצע את הבקשה.
מתקבלת תגובה HTTP 503, שלפיה צריך לנסות לשלוח שוב את הבקשה.
יש להמתין 8 שניות +ran_number_milliseconds ולנסות שוב.
מתקבלת תגובה HTTP 503, שלפיה צריך לנסות לשלוח שוב את הבקשה.
ממתינים 16 שניות +ran_number_milliseconds ומנסים שוב.
Stop. דיווח על שגיאה או רישום שגיאה.
בתהליך הנ"ל, ran_number_milliseconds הוא מספר אקראי של אלפיות השנייה שקטן מ-1000 או שווה לו. הפעולה הזו הכרחית, כי יצירת עיכוב אקראי קטן עוזרת לחלק את העומס בצורה שווה יותר ולמנוע את האפשרות להחתים את השרת. יש להגדיר מחדש את הערך שלran_number_milliseconds לאחר כל המתנה.
הערה: ההמתנה היא תמיד (2 ^ n) +ran_number_milliseconds, כאשר n הוא מספר שלם שגדל באופן מונוטוני שמוגדר בתחילה כ-0. המספר השלם n עולה ב-1 לכל איטרציה (כל בקשה).
האלגוריתם מוגדר להסתיים כאשר n הוא 5. תקרה זו מונעת מלקוחות לנסות שוב ושוב באופן אינסופי, והתוצאה היא עיכוב כולל של כ-32 שניות לפני שבקשה נחשבת ל "שגיאה בלתי הפיכה". אפשר ליצור מספר מרבי של ניסיונות חוזרים, במיוחד אם מתבצעת העלאה ארוכה. אבל, חשוב להגביל את ההשהיה לפני ניסיון חוזר למשך זמן סביר, למשל פחות מדקה.
בקשה למכסה יומית נוספת
אם לדעתך נדרשת לך מכסה יומית נוספת עבור האפליקציה, אפשר לבקש עוד לפי ההוראות שבהמשך.
ההוראות הבאות רלוונטיות רק לפרויקטים שיש בהם שגיאת dailyLimitExceeded. בטבלה שלמעלה מפורטות הפעולות המומלצות לשגיאות אחרות שקשורות למכסות.
בודקים את סטטיסטיקות השימוש בדף מדדים כדי לוודא שהאפליקציה שלכם פועלת כצפוי. חשוב לשים לב במיוחד לשיטות שהופעלו ולטפל בכל שימוש מוגזם או בלתי צפוי לפני שממשיכים.
אם השימוש נראה רגיל, נכנסים לדף Quotas, לוחצים על סמל העריכה לצד שאילתות ליום ולוחצים על הקישור 'החלת בקשה להגדלת מכסה'.
חשוב לקרוא את המידע ולפעול לפי ההוראות שמפורטות בטופס הבקשה למכסה לפני ששולחים בקשה להגדלת המכסה.
