सबसे सही तरीके और सीमाएं

BatchJobService का इस्तेमाल करते समय, इन दिशा-निर्देशों का ध्यान रखें.

थ्रूपुट को बेहतर बनाना

• कई छोटे-छोटे कामों के बजाय, कम बड़े काम करना बेहतर होता है.

• कार्रवाई के टाइप के हिसाब से, अपलोड की गई कार्रवाइयों को क्रम से लगाएं. उदाहरण के लिए, अगर आपके काम में कैंपेन, विज्ञापन ग्रुप, और विज्ञापन ग्रुप के मानदंड जोड़ने के लिए कार्रवाइयां शामिल हैं, तो अपलोड में कार्रवाइयों को इस तरह से क्रम में लगाएं कि सभी कैंपेन कार्रवाइयां पहले हों. इसके बाद, सभी विज्ञापन ग्रुप कार्रवाइयां और आखिर में सभी विज्ञापन ग्रुप के मानदंड से जुड़ी कार्रवाइयां हों.

• एक ही तरह के ऑपरेशन के लिए, उन्हें पैरंट रिसॉर्स के हिसाब से ग्रुप करने पर परफ़ॉर्मेंस बेहतर हो सकती है. उदाहरण के लिए, अगर आपके पास AdGroupCriterionOperation ऑब्जेक्ट की एक सीरीज़ है, तो विज्ञापन ग्रुप के हिसाब से कार्रवाइयों को ग्रुप करना ज़्यादा असरदार हो सकता है. ऐसा इसलिए, क्योंकि अलग-अलग विज्ञापन ग्रुप में विज्ञापन ग्रुप के मानदंड पर असर डालने वाली कार्रवाइयों को आपस में मिलाने से बेहतर नतीजे मिलते हैं.

बैच स्प्लिट करने की सुविधा में एटॉमिकिटी

Google Ads API, सबमिट किए गए बैच जॉब में मौजूद कार्रवाइयों को प्रोसेस करने के लिए, उन्हें छोटे-छोटे सब-बैच में बांट सकता है. अगर आपने एक जैसी कार्रवाइयों को ग्रुप नहीं किया है, तो Google Ads API इन कार्रवाइयों को अलग-अलग सब-बैच में बांट सकता है. जैसे, AssetGroup और AdGroup में लिस्टिंग ग्रुप में किए गए बदलावों को बैच जॉब में एक साथ नहीं रखा गया है. इस वजह से, हो सकता है कि बदलाव न हो पाए या खाता किसी दूसरी स्थिति में चला जाए.

लॉजिकल ग्रुपिंग

AssetGroupListingGroupFilterOperation किसी AssetGroup में लिस्टिंग ग्रुप मैनेज करता है. यह परफ़ॉर्मेंस मैक्स कैंपेन में आम बात है. AdGroupCriterionOperation, AdGroup में मौजूद लिस्टिंग ग्रुप को मैनेज करता है. यह स्टैंडर्ड शॉपिंग कैंपेन में आम बात है. इन दोनों का इस्तेमाल, प्रॉडक्ट टारगेटिंग को तय करने के लिए किया जाता है. अगर आपको ऐसे बदलाव करने हैं जिनसे दोनों कॉन्टेक्स्ट में प्रॉडक्ट टारगेटिंग के क्रम पर असर पड़ता है, तो इन कार्रवाइयों को अपने बैच जॉब में एक के बाद एक ग्रुप करें. इससे यह पक्का किया जा सकेगा कि ये बदलाव एक साथ लागू हों.

डेटा में एकरूपता

डेटा में एकरूपता बनाए रखने और आंशिक अपडेट को रोकने के लिए, बैच जॉब में एक के बाद एक करके, मिलती-जुलती लिस्टिंग ग्रुप की कार्रवाइयां जोड़ें. इस क्रम से, एपीआई के बैच स्प्लिटिंग लॉजिक के हिसाब से उन्हें एटॉमिक सब-बैच में ग्रुप करने में मदद मिलती है. इससे आपका खाता, किसी भी तरह की गड़बड़ी से बचा रहता है.

एक साथ कई अनुरोध मिलने से जुड़ी समस्याओं से बचना

• एक ही खाते के लिए एक साथ कई जॉब सबमिट करते समय, इस बात का ध्यान रखें कि एक ही समय में एक ही ऑब्जेक्ट पर काम करने वाली जॉब की संख्या कम हो. साथ ही, जॉब का साइज़ बड़ा हो. कई ऐसे जॉब हैं जिन्हें पूरा नहीं किया गया है और जिनका स्टेटस RUNNING है. ये सभी जॉब, एक ही सेट के ऑब्जेक्ट में बदलाव करने की कोशिश करते हैं. इससे डेडलॉक जैसी स्थितियां पैदा हो सकती हैं. इनकी वजह से, प्रोसेस बहुत धीमी हो जाती है और जॉब पूरे नहीं हो पाते.

• एक ही जॉब में, एक ही ऑब्जेक्ट में बदलाव करने वाली कई कार्रवाइयां सबमिट न करें. इससे नतीजे का अनुमान लगाना मुश्किल हो सकता है.

नतीजों को बेहतर तरीके से फ़ेच करना

• जॉब के स्टेटस के बारे में बार-बार जानकारी न मांगें. ऐसा करने पर, आपको दर की सीमा से जुड़ी गड़बड़ियां मिल सकती हैं.

• हर पेज पर 1,000 से ज़्यादा नतीजे न पाएं. सर्वर, लोड या अन्य वजहों से इससे कम नतीजे दिखा सकता है.

• नतीजे, अपलोड किए गए क्रम में ही दिखेंगे.

इस्तेमाल से जुड़ी अन्य जानकारी

• आपके पास यह तय करने का विकल्प होता है कि बैच जॉब को रद्द करने से पहले, उसे ज़्यादा से ज़्यादा कितनी देर तक चलने की अनुमति दी जाए. नया बैच जॉब बनाते समय, metadata.execution_limit_seconds फ़ील्ड को अपनी पसंद के मुताबिक समयसीमा पर सेट करें. यह समयसीमा सेकंड में होनी चाहिए. अगर metadata.execution_limit_seconds सेट नहीं है, तो समयसीमा की कोई डिफ़ॉल्ट वैल्यू नहीं होती.

• हमारा सुझाव है कि हर AddBatchJobOperationsRequest में 1,000 से ज़्यादा कार्रवाइयां न जोड़ें. साथ ही, बाकी कार्रवाइयों को उसी जॉब में अपलोड करने के लिए, sequence_token का इस्तेमाल करें. कार्रवाइयों के कॉन्टेंट के आधार पर, एक AddBatchJobOperationsRequest में बहुत ज़्यादा कार्रवाइयां होने पर, REQUEST_TOO_LARGE गड़बड़ी हो सकती है. इस गड़बड़ी को ठीक करने के लिए, कार्रवाइयों की संख्या कम करें और AddBatchJobOperationsRequest को फिर से आज़माएं.

सीमाएं

• हर BatchJob में ज़्यादा से ज़्यादा 10 लाख कार्रवाइयां की जा सकती हैं.

• हर खाते में एक समय पर ज़्यादा से ज़्यादा 100 नौकरियां चालू या लंबित हो सकती हैं.

• सात दिन से ज़्यादा समय से लंबित जॉब अपने-आप हट जाती हैं.

• v22 के मुताबिक, हर AddBatchJobOperations अनुरोध में, हर अनुरोध के लिए 10,000 बदलाव करने की कार्रवाइयां की जा सकती हैं.

• v22 के मुताबिक, ListBatchJobResultsRequest में मौजूद page_size फ़ील्ड के लिए:

  • अगर page_size को सेट नहीं किया गया है या इसकी वैल्यू 0 है, तो डिफ़ॉल्ट रूप से इसकी वैल्यू 1,000 पर सेट हो जाती है.
  • अगर page_size की वैल्यू 1,000 से ज़्यादा है या 0 से कम है, तो एपीआई INVALID_PAGE_SIZE गड़बड़ी का मैसेज दिखाता है.

• हर AddBatchJobOperationsRequest का साइज़ ज़्यादा से ज़्यादा 10,484,504 बाइट होना चाहिए. इस सीमा से ज़्यादा वीडियो अपलोड करने पर, आपको INTERNAL_ERROR मिलेगा. अनुरोध सबमिट करने से पहले, उसका साइज़ तय किया जा सकता है. अगर अनुरोध बहुत बड़ा है, तो ज़रूरी कार्रवाई की जा सकती है.

  Java

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

  Python

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

  Ruby

  
  require 'google/ads/google_ads'
  
  MAX_REQUEST_BYTES = 10484504
  
  ... (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 = 10484504;
  
  ... (code to get the request object)
  
  $size_in_bytes = $campaign->byteSize() . PHP_EOL;
  

  .NET

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

  Perl

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