הגבלות קצב של יצירת בקשות

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

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

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

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

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

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

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

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

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

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

בקשות מקובצות

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

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

ויסות נתונים (throttle) והגבלת קצב

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

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

הוספה לתור

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

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

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

הקודם
ניהול יעיל של נתונים
הבא
כינויים משותפים