מגבלות קצב

מערכת Google Ads API מחלקת את הבקשות להגבלת קצב השליחה לפי שאילתות לשנייה (QPS) לכל מספר לקוח (CID) וקוד מפתח, כלומר המדידה מתבצעת בנפרד עבור מספרי הלקוח וקודי המפתח. ‫Google Ads API משתמש באלגוריתם Token Bucket כדי למדוד את הבקשות ולקבוע מגבלת QPS מתאימה, ולכן המגבלה המדויקת תשתנה בהתאם לעומס השרת הכולל בכל זמן נתון.

המטרה של הגבלת קצב הבקשות היא למנוע ממשתמש אחד לשבש את השירות למשתמשים אחרים על ידי שליחת נפח גדול של בקשות לשרתים של Google Ads API (בכוונה או שלא בכוונה).

בקשות שמפרות את מגבלות הקצב יידחו עם השגיאה: RESOURCE_TEMPORARILY_EXHAUSTED.

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

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

השיטות המומלצות הבאות מסודרות לפי רמת המורכבות, מהפשוטות ביותר למעלה ועד לארכיטקטורות מורכבות יותר בהמשך:

• הגבלת משימות בו-זמניות
• בקשות באצווה
• הגבלת קצב העברת נתונים (Throttling) ומגבילי קצב (Rate limiters)
• הוספה לתור

הגבלת מספר המשימות בו-זמנית

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

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

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

קיבוץ בקשות באצווה

כדאי לשקול לשלוח כמה פעולות בבקשה אחת. ההגדרה הזו רלוונטית בעיקר לשיחות בMutateFoo. לדוגמה, אם אתם מעדכנים את הסטטוס של כמה מופעים של AdGroupAd – במקום להפעיל את MutateAdGroupAds פעם אחת לכל AdGroupAd, אתם יכולים להפעיל את MutateAdGroupAds פעם אחת ולהעביר כמה operations. דוגמאות נוספות זמינות בהנחיות שלנו לגבי פעולות בכמות גדולה.

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

ויסות נתונים ומגבילי קצב

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

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

הוספה לתור

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

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

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