שיטות מומלצות ומגבלות

חשוב לפעול לפי ההנחיות הבאות כשמשתמשים ב-BatchJobService.

שיפור התפוקה

• עדיף לבצע פחות עבודות גדולות מאשר הרבה עבודות קטנות.

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

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

אטומיות בפיצול אצווה

יכול להיות שממשק Google Ads API יפצל את הפעולות במשימת אצווה שנשלחה לאצווה משנה קטנה יותר לצורך עיבוד. אם לא מקבצים פעולות קשורות, כמו שינויים בקבוצה של כרטיסי מוצר בתוך AssetGroup ו-AdGroup, ברצף בתוך משימה באצווה, יכול להיות ש-Google Ads API יפצל את הפעולות האלה לאצוות משנה שונות. ההפרדה הזו עלולה לגרום לכך שכל השינוי ייכשל, או שהחשבון יישאר במצב לא עקבי.

קיבוץ לוגי

‫AssetGroupListingGroupFilterOperation מנהל קבוצות של כרטיסי מוצר בתוך AssetGroup, וזה נפוץ בקמפיינים למיקסום הביצועים. ‫AdGroupCriterionOperation מנהל קבוצות של כרטיסי מוצר בתוך AdGroup, וזה נפוץ בקמפיינים רגילים של שופינג. שניהם משמשים להגדרת טירגוט מוצרים. אם מבצעים שינויים שמשפיעים על היררכיית הטירגוט של המוצרים בשני ההקשרים, צריך לקבץ את הפעולות האלה ברצף במשימה באצווה כדי לוודא שהן יחולו יחד.

עקביות הנתונים

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

איך למנוע בעיות של בו-זמניות

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

• אל תשלחו כמה פעולות שמשנות את אותו אובייקט באותה משימה, כי התוצאה יכולה להיות בלתי צפויה.

אחזור תוצאות בצורה אופטימלית

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

• אל תאחזרו יותר מ-1,000 תוצאות לכל דף. יכול להיות שהשרת יחזיר פחות מזה בגלל עומס או גורמים אחרים.

• סדר התוצאות יהיה זהה לסדר ההעלאה.

הנחיות נוספות לשימוש

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

• מומלץ להוסיף עד 1,000 פעולות לכל AddBatchJobOperationsRequest ולהשתמש ב-sequence_token כדי להעלות את שאר הפעולות לאותה משימה. בהתאם לתוכן הפעולות, יותר מדי פעולות ב-AddBatchJobOperationsRequest אחד עלולות לגרום לשגיאה REQUEST_TOO_LARGE. כדי לפתור את השגיאה הזו, צריך לצמצם את מספר הפעולות ולנסות שוב את AddBatchJobOperationsRequest.

מגבלות

• כל BatchJob תומך בעד מיליון פעולות.

• בכל חשבון יכולות להיות עד 100 משימות פעילות או בהמתנה בו-זמנית.

• משימות בהמתנה שנוצרו לפני יותר מ-7 ימים מוסרות באופן אוטומטי.

• החל מגרסה v22, כל בקשת AddBatchJobOperations מוגבלת ל-10,000 פעולות שינוי לכל בקשה.

• החל מגרסה 22, בשדה page_size ב-ListBatchJobResultsRequest:

  • אם page_size לא מוגדר או מוגדר כ-0, ברירת המחדל היא 1,000.
  • אם הערך של page_size גדול מ-1,000 או קטן מ-0, ה-API מחזיר שגיאה מסוג INVALID_PAGE_SIZE.

• החל מגרסה 23, הגודל המקסימלי של כל AddBatchJobOperationsRequest הוא 41,937,920 בייטים. אם תחרגו מהמכסה, תקבלו INTERNAL_ERROR. אפשר לקבוע את גודל הבקשה לפני ששולחים אותה ולנקוט פעולה מתאימה אם היא גדולה מדי.

  Java

  
  static final int MAX_REQUEST_BYTES = 41_937_920;
  
  ... (code to get the request object)
  
  int sizeInBytes = request.getSerializedSize();
  

  Python

  
  from google.ads.googleads.client import GoogleAdsClient
  
  MAX_REQUEST_BYTES = 41937920
  
  ... (code to get the request object)
  
  size_in_bytes = request._pb.ByteSize()
  

  Ruby

  
  require 'google/ads/google_ads'
  
  MAX_REQUEST_BYTES = 41937920
  
  ... (code to get the request object)
  
  size_in_bytes = request.to_proto.bytesize
  

  PHP

  
  use Google\Ads\GoogleAds\V16\Resources\Campaign;
  
  const MAX_REQUEST_BYTES = 41937920;
  
  ... (code to get the request object)
  
  $size_in_bytes = $campaign->byteSize() . PHP_EOL;
  

  ‎.NET

  
  using Google.Protobuf;
  const int MAX_REQUEST_BYTES = 41937920;
  
  ... (code to get the request object)
  
  int sizeInBytes = request.ToByteArray().Length;
  

  Perl

  
  use Devel::Size qw(total_size);
  use constant MAX_REQUEST_BYTES => 41937920;
  
  ... (code to get the request object)
  
  my $size_in_bytes = total_size($request);
  

גודל של פעולת שינוי אחת

הגודל של הבקשה הכוללת יכול להיות גדול יותר, אבל הגודל של פעולת שינוי יחידה באצווה מוגבל ל-10,484,488 בייט (כ-10.48MB).