מגבלות קצב

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

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

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

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

יש כמה דרכים לצמצם את הסיכוי לחרוג ממגבלת הקצב. כדאי להכיר את המושגים של Enterprise Integration Patterns (EIP), כמו Messaging,‏ Redelivery ו-Throttling, כדי ליצור אפליקציית לקוח חזקה יותר.

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

• הגבלת מספר המשימות בו-זמנית
• צבירה של בקשות
• ויסות קצב שליחת הבקשות ומגבילי קצב
• הוספה לתור

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

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

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

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

קיבוץ בקשות

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

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

הגבלת קצב שליחת הבקשות ומגבילי קצב

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

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

הוספה לתור

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

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

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