बेहतर इस्तेमाल के लिए

इस गाइड में, Java क्लाइंट लाइब्रेरी के ज़्यादा बेहतर पहलुओं को पसंद के मुताबिक बनाने का तरीका बताया गया है. आम तौर पर, इनमें से कई सुविधाएं स्टैंडर्ड तरीकों के बजाय, Callable पर निर्भर होती हैं. कॉल करने की सुविधा, आम तौर पर हर आरपीसी सुविधा के लिए इस्तेमाल की जाने वाली ऐसी सुविधाओं के बारे में बताती है जिनके बारे में यहां नहीं बताया गया है.

टाइम आउट की संख्या

Java लाइब्रेरी, हर कॉल के लेवल पर टाइम आउट सेट करने के लिए एक प्लैटफ़ॉर्म उपलब्ध कराती है. डिफ़ॉल्ट वैल्यू, googleads_grpc_service_config.json में method_config/timeout सेटिंग के हिसाब से सेट की जाती है. अगर आपको एपीआई कॉल के लिए ज़्यादा से ज़्यादा समयसीमा की कम समयसीमा लागू करनी है, तो कम वैल्यू सेट करें.

इस सुविधा का इस्तेमाल करने के लिए, आपको कॉल किए जा सकने वाले ऑब्जेक्ट का इस्तेमाल करना चाहिए. उदाहरण के लिए, GoogleAdsService.searchStream() को कॉल करने पर, टाइम आउट इस तरह सेट होगा:

try (GoogleAdsServiceClient googleAdsServiceClient =
    googleAdsClient.getLatestVersion().createGoogleAdsServiceClient()) {
  // Constructs the SearchGoogleAdsStreamRequest.
  SearchGoogleAdsStreamRequest request = ...

  // Executes the API call, with a timeout of 5 minutes.
  ServerStream<SearchGoogleAdsStreamResponse> result = googleAdsServiceClient
      .searchStreamCallable()
      .call(request,
          GrpcCallContext.createDefault().withTimeout(Duration.of(5, ChronoUnit.MINUTES)));
}

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

सेटिंग का फिर से प्रयास करें

Java लाइब्रेरी, हर कॉल लेवल पर फिर से कोशिश करने की सेटिंग कॉन्फ़िगर करने के लिए एक प्लैटफ़ॉर्म भी उपलब्ध कराती है. इस सुविधा का इस्तेमाल करने के लिए, आपको कॉल किए जा सकने वाले ऑब्जेक्ट का इस्तेमाल करना चाहिए. उदाहरण के लिए, GoogleAdsService.searchStream() को कॉल करने पर, फिर से कोशिश करने की सेटिंग इस तरह से कॉन्फ़िगर की जाएंगी:

// Creates a context object with the custom retry settings.
GrpcCallContext context = GrpcCallContext.createDefault()
    .withRetrySettings(RetrySettings.newBuilder()
    .setInitialRetryDelay(Duration.ofMillis(10L))
    .setMaxRetryDelay(Duration.ofSeconds(10L))
    .setRetryDelayMultiplier(1.4)
    .setMaxAttempts(10)
    .setLogicalTimeout(Duration.ofSeconds(30L))
    .build());

// Creates and issues a search Google Ads stream request.
ServerStream<SearchGoogleAdsStreamResponse> stream =
    googleAdsServiceClient.searchStreamCallable().call(request, context);

स्टार्टअप समय की परफ़ॉर्मेंस का ऑप्टिमाइज़ेशन

पहली बार GoogleAdsClient इंस्टेंस बनाने पर, आपको थोड़ी देरी हो सकती है. ऐसा सेवाओं (GoogleAdsClient.getVersionXX()) के लिए बेहतर इंटरफ़ेस की वजह से होता है. यह सभी एपीआई क्लास को एक साथ लोड करता है, ताकि सेवा क्लास बनाने के लिए ज़्यादा आसानी से काम किया जा सके.

अगर आपके ऐप्लिकेशन के लिए ज़रूरी पाथ में पहले अनुरोध की परफ़ॉर्मेंस ही है, तो आपको यह तरीका अपनाना चाहिए:

  1. उपयोगकर्ताओं के अनुरोधों को पूरा करने से पहले, स्टार्टअप पर GoogleAdsClient बनाएं.

  2. प्रोसेस पहली बार शुरू होने पर, Google Ads API को कुछ वॉर्म-अप अनुरोध भेजें. उदाहरण के लिए:

    // Runs some warm-up requests.
    try (GoogleAdsServiceClient googleAdsServiceClient =
        googleAdsClient.getLatestVersion().createGoogleAdsServiceClient()) {
      // Runs 5 warm-up requests. In our profiling we see that 90% of performance
      // loss is only experienced on the first API call. After 3 subsequent calls we
      // saw a negligible improvement in performance.
      for (int i = 0; i < 5;   i) {
        // Warm-up queries are run with a nonexistent CID so the calls will fail. If
        // you have a CID that you know will be accessible with the OAuth
        // credentials provided you may want to provide that instead and avoid the
        // try-catch.
        try {
          googleAdsServiceClient.search("-1", "Warm-up query");
        } catch (GoogleAdsException ex) {
          // Do nothing, we're expecting this to fail.
        }
      }
    }
    

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

सर्विस क्लाइंट का फिर से इस्तेमाल

आपको सर्विस क्लाइंट के उन इंस्टेंस का फिर से इस्तेमाल करना चाहिए जो काम के हों, क्योंकि GoogleAdsClient.getVersionXXX().createYYYServiceClient() को किए गए हर कॉल से नया टीसीपी कनेक्शन बन जाएगा.

आपको यह पक्का करना होगा कि जब क्लाइंट की ज़रूरत न हो, तब उसे बंद कर दें. संसाधनों की मदद से कोशिश करें ब्लॉक में या सर्विस क्लाइंट पर close() को कॉल करके ऐसा किया जा सकता है.

अगर एपीआई अनुरोध करने के लिए, किसी क्लोज़्ड सर्विस क्लाइंट का इस्तेमाल किया जाता है, तो सर्विस क्लाइंट वाला तरीका java.util.concurrent.RejectedExecutionException दिखाएगा.

अगर JAR > 32 एमबी है, तो ऐप्लिकेशन इंजन डिप्लॉय नहीं होता

अपलोड की गई हर फ़ाइल के लिए App Engine का 32 एमबी का कोटा होता है. google-ads के लिए JAR इससे काफ़ी बड़ा होगा. ऐसा करने के लिए शेड/शैडो जार डिप्लॉयमेंट का भी इस्तेमाल किया जाएगा. अगर जार को मैन्युअल तरीके से डिप्लॉय किया जाता है, तो आपको इस तरह की गड़बड़ियां दिख सकती हैं:

ERROR: (gcloud.app.deploy) Cannot upload file [<your-app>/WEB-INF/lib/google-ads-14.0.0.jar],
which has size [66095767] (greater than maximum allowed size of [33554432])

इसके बजाय, AppEngine Gradle प्लग इन या Maven प्लगिन का इस्तेमाल करके डिप्लॉय करें. हर जार में enableJarSplitting के लिए विकल्प होता है. इसे इस्तेमाल करने पर, हर जार को 10 एमबी के हिस्सों में बांट दिया जाएगा और उन्हें अपलोड कर दिया जाएगा.

शैडो डिपेंडेंसी

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

Maven

mvn dependency:tree

ग्रेडल

./gradlew dependencies

अगर डिपेंडेंसी से जुड़े विवादों को हल नहीं किया जा सकता, तो लाइब्रेरी के shaded वर्शन का इस्तेमाल किया जा सकता है.

Maven

<dependency>
  <groupId>com.google.api-ads</groupId>
  <artifactId>google-ads-shadowjar</artifactId>
  <version>31.0.0</version>
</dependency>

ग्रेडल

implementation 'com.google.api-ads:google-ads-shadowjar:31.0.0'