מגבלות המכסה
כדי להבטיח שימוש הוגן ולהגן על יציבות המערכת, ממשקי Google Business Profile (GBP) API אוכפים מכסות על בקשות ל-API. אם הבקשה חורגת ממגבלת מכסה, ה-API מגיב עם קוד סטטוס של 429 Too Many Requests HTTP (או RESOURCE_EXHAUSTED ל-gRPC).
מגבלות ברירת מחדל במכסות
בטבלה הבאה מפורטות הגבלות המכסה הרגילות ל-Google Business Profile APIs. המגבלות מוגדרות בשני מאפיינים:
- שאילתות לדקה (QPM): הגנה על יציבות ה-Backend על ידי הגבלת תנועה לפרקי זמן קצרים.
- שאילתות ביום (QPD): ניהול השימוש הכולל בפלטפורמה ביום.
| API | מגבלות |
|---|---|
| Business Information API |
|
| Account Management API | 300 QPM |
| Performance API | 300 QPM |
| Verifications API | 300 QPM |
| Lodging API | 300 QPM |
| Place Actions API | 300 QPM |
| Notifications API | 300 QPM |
שיטות מומלצות למניעת שגיאות שקשורות למכסת השימוש
פיזור הבקשות באופן רציף ושווה לאורך היום מונע את רוב שגיאות המכסה. כדי לוודא שהנתונים יסונכרנו בצורה מהימנה, מומלץ לפעול לפי השיטות המומלצות הבאות.
הגשת הבקשות בקצב אחיד
במקום לשלוח כמות גדולה של בקשות בו-זמנית, כדאי לפזר את הבקשות על פני תקופה ארוכה יותר. לדוגמה, מגבלה של 300 QPM מתורגמת לממוצע של 5 בקשות בשנייה. הוספת השהיה קצרה בין הבקשות מונעת עליות חדות בתעבורת הנתונים.
Traffic distribution patterns:
Spiky traffic (Discouraged): High burst of requests followed by an idle period
Requests | ||| |||
| ||| |||
+---------------------------------
Time ──>
Even traffic (Recommended): Consistent rate of requests over time
Requests | | | | | | | | | |
| | | | | | | | | |
+---------------------------------
Time ──>import time # Pace requests to stay within the 300 QPM limit (5 requests/sec) for request in batch_requests: send_request(request) time.sleep(0.2) # 200ms delay ensures a smooth distribution
הטמעה של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) עם רעידות
כשמקבלים שגיאה 429 Too Many Requests, צריך להשתמש בהשהיה מעריכית לפני ניסיון חוזר עם רעידות כדי לנסות שוב את הבקשה באופן אוטומטי. השיטה המקובלת היא להמתין פרק זמן קצר ואקראי לפני שמנסים שוב, ולהגדיל בהדרגה את ההשהיה בניסיונות חוזרים.
import random import time from googleapiclient.errors import HttpError def call_api_with_retry(api_method, max_retries=5): base_delay = 1.0 for attempt in range(max_retries): try: return api_method.execute() except HttpError as e: if e.resp.status == 429: if attempt == max_retries - 1: raise e # Retry with exponential backoff and jitter sleep_time = random.uniform(0, base_delay * (2 ** attempt)) time.sleep(sleep_time) else: raise e
אופטימיזציה של הגישה לנתונים
- שמירת נתונים סטטיים במטמון: אחסון נתונים שלא משתנים לעיתים קרובות באופן מקומי במקום לשלוח שאילתות חוזרות ל-API.
- שימוש בהתראות Pub/Sub: אפשר להירשם כמנויים להתראות Pub/Sub כדי לעדכן את מסדי הנתונים בזמן אמת בלי לבצע שאילתות ל-API.
-
עיבוד נקודות קצה (endpoint) עם פעולות קריאה רבות באופן רציף: מומלץ להימנע מהפעלת בקשות מקבילות מרובות
לנקודות קצה (endpoint) עם פעולות קריאה רבות כמו
SearchListings. במקום זאת, צריך לעבד את המשימות ברצף באמצעות טוקנים של חלוקה לעמודים.
איך מבקשים להגדיל את המכסות
לפני שמבקשים להגדיל את המכסה, כדאי לבדוק את דפוסי השימוש במסוף Google Cloud כדי לוודא שנפח הבקשות לא מקובץ שלא לצורך.
הצוות של פרופיל העסק ב-Google עוקב אחרי השימוש הממוצע שלכם במכסת המשאבים כדי לוודא שאתם משתמשים במגבלות הנוכחיות בצורה יעילה. בקשות להגדלת מכסות נדחות בדרך כלל אם:
- הבקשה שלך לא מגיעה באופן עקבי למגבלת השאילתות לדקה הנוכחית.
- השימוש הממוצע שלכם נמוך מ-50% מהמכסה הנוכחית שלכם ל-QPM.
- האפליקציה שלך מציגה דפוס בקשות עם עליות וירידות חדות במקום התפלגות חלקה.
Submit a request
אם הטמעתם את השיטות המומלצות האלה ועדיין אתם צריכים מכסה גדולה יותר, אתם יכולים לשלוח בקשה להגדלת המכסה.
- בתפריט הנפתח, בוחרים באפשרות בקשה להגדלת מכסה.
- מציינים את שם החברה, כתובת האימייל של איש הקשר ומספר הפרויקט.
אחרי שליחת הטופס, הצוות של פרופיל העסק ב-Google יבדוק את הבקשה ויקבע אם הגדלת המכסה מתאימה. אם הבקשה תאושר, המכסה תוגדל. אם הבקשה תידחה, תקבלו את הסיבה לדחייה.