הגבלות קצב של יצירת בקשות
ה-Google Ads API מסווג בקשות להגבלת קצב של יצירת בקשות לפי שאילתות לשנייה (QPS) לכל מספר לקוח (CID) וקוד מפתח. כלומר, מכסת מאמרים ללא תשלום נאכפת באופן בלתי תלוי במספרי ה-CID וגם באסימונים של המפתח. ב-Google Ads API נעשה שימוש באלגוריתם של קטגוריית אסימונים כדי למדוד בקשות ולקבוע מגבלת QPS מתאימה, ולכן המגבלה המדויקת תשתנה בהתאם לעומס הכולל על השרת בכל זמן נתון.
המטרה של הגבלות קצב של יצירת בקשות היא למנוע ממשתמש אחד לשבש את השירות למשתמשים אחרים, על ידי הצפת שרתי Google Ads API בכמות גדולה של בקשות (במתכוון או בטעות).
בקשות שמפרות את הגבלת הקצב של יצירת בקשות יידחו על-ידי השגיאה: RESOURCE_TEMPORARILY_EXHAUSTED.
אפשר לשלוט באפליקציה ולצמצם את מגבלות הקצב על ידי הפחתה אקטיבית של מספר הבקשות וויסות ה-QPS מצד הלקוח.
יש כמה דרכים לצמצם את הסיכוי לחריגה ממגבלת כמות הקצב של יצירת הבקשות. אם תכירו את המושגים של תבניות אינטגרציה בארגון (EIP), כמו העברת הודעות, שליחה מחדש וויסות נתונים, תוכלו ליצור אפליקציית לקוח חזקה יותר.
השיטות המומלצות הבאות מסודרות לפי מורכבות, עם אסטרטגיות פשוטות יותר מובילות וארכיטקטורות מתוחכמות יותר, ואחר כך:
הגבלת משימות בו-זמנית
אחת הסיבות העיקריות לחריגה ממגבלות הקצב של יצירת הבקשות היא שאפליקציית הלקוח מפיקה מספר גדול של משימות מקבילות. אנחנו לא מגבילים את מספר הבקשות המקבילות שאפליקציית לקוח יכולה לקבל, אבל זה יכול בקלות לחרוג מהמגבלה של בקשות לשנייה ברמת קוד המפתח.
מומלץ להגדיר גבול עליון סביר למספר הכולל של המשימות שפועלות בו-זמנית שישלחו בקשות (בכל התהליכים ובכל המכונות), ולשנות כלפי מעלה כדי לשפר את התפוקה בלי לחרוג ממגבלת הקצב של יצירת הבקשות.
בנוסף, תוכלו לשקול לווסת את ה-QPS מצד הלקוח (מידע נוסף זמין במאמר ויסות נתונים ומגבילי קצב של יצירת בקשות).
קיבוץ בקשות
מומלץ לקבץ מספר פעולות בבקשה אחת. הדרך הזו רלוונטית ביותר לשיחות MutateFoo. לדוגמה, אם אתם מעדכנים את הסטטוס של מספר מופעים של AdGroupAd, במקום להפעיל קריאה אחת ל-MutateAdGroupAds פעם אחת לכל AdGroupAd, אפשר להפעיל את MutateAdGroupAds פעם אחת ולהעביר אותו במספר operations. ראו כמה דוגמאות נוספות בהנחיות שלנו לפעולות אצווה.
בקשות אצווה מפחיתות את מספר הבקשות הכולל ומפחיתות את מגבלת הקצב של בקשות לדקה, אבל היא עשויה להפעיל את מגבלת הקצב של הפעולות לדקה אם מבצעים מספר גדול של פעולות בחשבון אחד.
ויסות נתונים והגבלת קצב של יצירת בקשות
בנוסף להגבלת המספר הכולל של השרשורים באפליקציית הלקוח, אפשר גם להטמיע מגבילי קצב של יצירת בקשות בצד הלקוח. כך אפשר להבטיח שכל ה-threads בכל התהליכים ו / או האשכולות יהיו כפופים להגבלת QPS ספציפית מצד הלקוח.
אתם יכולים לבדוק את הגבלת הקצב של יצירת נתוני Guava או להטמיע אלגוריתם משלכם המבוסס על TokenBucket בסביבה מקובצת. לדוגמה, תוכלו ליצור אסימונים ולאחסן אותם באחסון משותף של טרנזקציות כמו מסד נתונים, וכל לקוח יצטרך לקבל אסימון ולצרוך אותו לפני עיבוד הבקשה. אם היו משתמשים באסימונים, הלקוח היה צריך להמתין עד ליצירת אצוות האסימונים הבאה.
הוספה לתור
תור הודעות הוא הפתרון להפצת עומסי התפעול, תוך שליטה על הבקשות ועל התעריפים לצרכנים. יש מספר אפשרויות לתור ההודעות – חלקן בקוד פתוח, חלקן קנייניות – ורבות מהן יכולות לפעול בשפות שונות.
כשמשתמשים בתורי הודעות, יכולים להיות מספר מפיקים שיפעילו את ההודעות בתור וכמה צרכנים יעבדו את ההודעות. ניתן להטמיע ויסות נתונים בצד הצרכן על ידי הגבלת מספר הצרכנים בו-זמנית, או על ידי מגבילי קצב של פעולה או ויסות נתונים עבור היצרנים או הצרכנים.
לדוגמה, אם צרכן נתקל בשגיאה של הגבלת קצב של יצירת תעריפים, אותו צרכן יכול להחזיר את הבקשה לתור ולנסות שוב. במקביל, הצרכן יכול גם להודיע לכל הצרכנים האחרים להשהות את העיבוד למשך מספר שניות כדי להתאושש מהשגיאה.