टाइम आउट और समयसीमाएं कॉन्फ़िगर करना

इस दस्तावेज़ में, Route Optimization API के अनुरोधों के लिए, टाइम आउट और समयसीमा की सेटिंग कॉन्फ़िगर करने का तरीका बताया गया है. इन वैल्यू को सेट न करने या गलत तरीके से सेट करने पर, कनेक्शन या जवाब की क्वालिटी से जुड़ी समस्याएं हो सकती हैं.

अनुरोध के मुख्य हिस्से में टाइम आउट और अनुरोध के हेडर में समयसीमा तय की जाती है. Route Optimization API, इन पैरामीटर से तय की गई समयसीमा के अंदर अनुरोध को प्रोसेस करता है. इसके लिए, वह सबसे कम समय वाली वैल्यू का इस्तेमाल करता है.

टाइम आउट और समयसीमाएं कॉन्फ़िगर करके, प्रोसेसिंग में लगने वाले समय को इन तरीकों से मैनेज किया जा सकता है:

  • प्रोसेस करने में लगने वाला समय बढ़ाएं:
    • मुश्किल अनुरोधों को पूरा करना.
    • बेहतर क्वालिटी वाला जवाब पाना.
  • प्रोसेस होने में लगने वाला समय कम करना:
    • आसान अनुरोधों को डिफ़ॉल्ट मॉडल की तुलना में तेज़ी से पूरा करना.
    • कम समय में जवाब पाना, लेकिन जवाब की क्वालिटी अच्छी न होना.

टाइम आउट और समयसीमा से जुड़ी अपनी ज़रूरतों को समझना

टाइम आउट और समयसीमाएं कॉन्फ़िगर करने से पहले, इस सेक्शन को पढ़ें. इससे आपको यह समझने में मदद मिलेगी कि एंडपॉइंट और प्रोटोकॉल के विकल्पों का इन सेटिंग पर क्या असर पड़ता है.

यहां दिए गए दिशा-निर्देशों की मदद से, यह पुष्टि की जा सकती है कि आपने अपने लक्ष्यों के लिए सही सेटअप का इस्तेमाल किया है या नहीं.

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

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

डायग्राम को अलग टैब में खोलें

timeout पैरामीटर सेट करना

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

ड्यूरेशन प्रोटोकॉल बफ़र का इस्तेमाल करके, timeout पैरामीटर सेट करें. यह सेकंड में तय की गई अवधि होती है, जो 1 सेकंड से लेकर 1,800 सेकंड तक हो सकती है. allowLargeDeadlineDespiteInterruptionRisk का इस्तेमाल करके, इस वैल्यू को 3,600 सेकंड तक बढ़ाया जा सकता है.

यहां दी गई टेबल में, अनुरोध की जटिलता और शिपमेंट और वाहनों की संख्या के आधार पर, timeout की सुझाई गई वैल्यू दी गई हैं.

शिपमेंट और वाहनों की संख्या कोई सीमा नहीं समयसीमा और लोड की सीमाओं में छूट या लंबे रास्ते कम समय, लोड की सीमाएं, मुश्किल सीमाएं या बहुत लंबे रास्ते
1 - 8 2 सेकंड 2 सेकंड 5 सेकंड
9 - 32 5 सेकंड 10 सेकंड 20 सेकंड
33 - 100 15 सेकंड 30 सेकंड 60 सेकंड
101 से 1,000 45 सेकंड 90s 180 सेकंड
1,001 से 10,000 120 सेकंड 360 सेकंड 900s
10,001 या इससे ज़्यादा हर 10,000 शिपमेंट के लिए 60 सेकंड + 120 सेकंड हर 10 हज़ार शिपमेंट पर 360s हर 10,000 शिपमेंट के लिए 900 सेकंड

समयसीमा सेट करना

अनुरोध के हेडर में समयसीमा सेट करें, ताकि यह तय किया जा सके कि Route Optimization API किसी अनुरोध को प्रोसेस करने में ज़्यादा से ज़्यादा कितना समय लेगा. यहां दिए गए सब-सेक्शन में, REST और gRPC अनुरोधों के लिए समयसीमा सेट करने का तरीका बताया गया है.

REST अनुरोध

ब्लॉक करने वाले एंडपॉइंट को कॉल करने के लिए REST का इस्तेमाल करते समय, समयसीमा को 60 सेकंड की डिफ़ॉल्ट समयसीमा से ज़्यादा बढ़ाया जा सकता है. यह समयसीमा, जटिल अनुरोधों के लिए अक्सर बहुत कम होती है. आपको ऐसा तब भी करना होगा, जब आपने अनुरोध के मुख्य हिस्से में पहले से ही ज़्यादा समयसीमा तय की हो. ऐसा इसलिए, क्योंकि डिफ़ॉल्ट समयसीमा, अनुरोध के मुख्य हिस्से में सेट की गई timeout की उन सभी वैल्यू को बदल देती है जो 60 सेकंड से ज़्यादा होती हैं.

X-Server-Timeout अनुरोध हेडर को सेट करके, समयसीमा को डिफ़ॉल्ट 60 सेकंड से ज़्यादा बढ़ाएं. अनुरोध के मुख्य हिस्से के उलट, हेडर की वैल्यू सेकंड की संख्या होती है. हालांकि, इसमें "s" सफ़िक्स नहीं होता. इस हेडर के लिए सेट की जा सकने वाली ज़्यादा से ज़्यादा वैल्यू, timeout पैरामीटर की पाबंदियों के मुताबिक होती है.

यहां दिए गए कोड सैंपल में, X-Server-Timeout को 1,800 सेकंड पर सेट किया गया एचटीटीपी हेडर दिखाया गया है.

curl -X POST 'https://routeoptimization.googleapis.com/v1/projects/:optimizeTours' \
-H "Content-Type: application/json" \
-H "X-Server-Timeout: 1800" \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
--data @- << EOM
{
  "model": {
    ...
  }
}
EOM

क्लाइंट लाइब्रेरी और gRPC अनुरोध

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

टाइम आउट और समयसीमा पर असर डालने वाले पैरामीटर

यहां दिए गए पैरामीटर से, टाइम आउट और समयसीमा, दोनों के काम करने के तरीके पर असर पड़ता है:

  • allowLargeDeadlineDespiteInterruptionRisk की मदद से, अनुरोध की समयसीमा को कंट्रोल करें.
  • खोज के व्यवहार को तय करें. साथ ही, searchMode का इस्तेमाल करके, जवाब मिलने में लगने वाले समय और जवाब की क्वालिटी के बीच संतुलन बनाएं.

allowLargeDeadlineDespiteInterruptionRisk

allowLargeDeadlineDespiteInterruptionRisk पैरामीटर, अनुरोध की समयसीमा को बढ़ाकर 3,600 सेकंड कर देता है. अगर यह पैरामीटर सेट नहीं है, तो टाइम आउट और समयसीमा, दोनों पैरामीटर की ज़्यादा से ज़्यादा वैल्यू 1,800 सेकंड होती है.

allowLargeDeadline DespiteInterruptionRisk को true पर सेट करें, ताकि टाइम आउट और समयसीमा के पैरामीटर की वैल्यू को 3,600 सेकंड तक बढ़ाया जा सके.

allowLargeDeadline DespiteInterruptionRisk के लिए, इन वैल्यू का इस्तेमाल किया जा सकता है:

  • true: यह रुकावट के जोखिम को स्वीकार करते हुए, टाइम आउट और समयसीमा के पैरामीटर की ज़्यादा से ज़्यादा वैल्यू को 3,600 सेकंड तक बढ़ा देता है.
  • false (डिफ़ॉल्ट): टाइम आउट और समयसीमा के पैरामीटर की ज़्यादा से ज़्यादा वैल्यू को 1,800 सेकंड पर सेट रखता है.

अगर आपको लगता है कि आपको 3,600 सेकंड से ज़्यादा का टाइम आउट चाहिए, तो अपने Google प्रतिनिधि से संपर्क करें.

searchMode

searchMode पैरामीटर यह कंट्रोल करता है कि ऑप्टिमाइज़र, समाधानों को कैसे खोजता है. इससे आपको तुरंत जवाब (कम इंतज़ार का समय) या बेहतर क्वालिटी वाले समाधान को प्राथमिकता देने की सुविधा मिलती है.

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

searchMode के लिए, ये वैल्यू इस्तेमाल की जा सकती हैं:

  • SEARCH_MODE_UNSPECIFIED (डिफ़ॉल्ट): खोज का कोई मोड तय नहीं किया गया है. यह RETURN_FAST के बराबर है.
  • RETURN_FAST: पहला सही समाधान मिलने के बाद, खोज बंद कर देता है.
  • CONSUME_ALL_AVAILABLE_TIME: बेहतर समाधान खोजने के लिए, उपलब्ध समय का पूरा इस्तेमाल करता है. अगर एपीआई को पहले ही कोई बेहतर समाधान मिल जाता है, तो वह उपलब्ध समय का पूरा इस्तेमाल नहीं करता.

कीपअलाइव पिंग की सुविधा चालू करना

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

इस्तेमाल किए जा रहे एपीआई प्रोटोकॉल के आधार पर, इन पैरामीटर को कॉन्फ़िगर करें:

  • REST: टीसीपी कनेक्शन लेवल पर, कीपअलाइव को कॉन्फ़िगर करें.
  • gRPC: टीसीपी सॉकेट या सीधे gRPC प्रोटोकॉल में, कीपअलाइव पिंग कॉन्फ़िगर करें.

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

REST कीपअलाइव

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

अगर आपकी लाइब्रेरी, टीसीपी सॉकेट को एक्सपोज़ करती है, तो SO_KEEPALIVE जैसे विकल्पों का इस्तेमाल करके, टीसीपी सॉकेट पर सीधे कीपअलाइव पिंग कॉन्फ़िगर किए जा सकते हैं. इसके लिए, setsockopt() जैसे फ़ंक्शन या उनके जैसे अन्य फ़ंक्शन का इस्तेमाल करें.

GitHub पर होस्ट किए गए इस फ़ंक्शन से पता चलता है कि Python के पहले से मौजूद एचटीटीपी क्लाइंट के लिए, इसे सही तरीके से कैसे सेट अप किया जाए.

टीसीपी-लेवल कीपअलाइव के बारे में ज़्यादा जानकारी के लिए, टीएलडीपी कीपअलाइव की खास जानकारी या एचटीटीपी क्लाइंट लाइब्रेरी के दस्तावेज़ देखें.

gRPC कीपअलाइव

gRPC, प्रोटोकॉल के हिस्से के तौर पर, पहले से मौजूद कीपअलाइव सुविधा देता है. अपनी क्लाइंट भाषा में इसे सेट अप करने के तरीके के बारे में जानने के लिए, gRPC कीपअलाइव गाइड देखें.

कीपअलाइव के साथ gRPC अनुरोध का सैंपल

इस उदाहरण में, Python क्लाइंट लाइब्रेरी और gRPC-लेवल के कीपअलाइव पिंग का इस्तेमाल करके, optimizeTours अनुरोध करने का तरीका बताया गया है.

from google.maps import routeoptimization_v1 as ro
from google.maps.routeoptimization_v1.services.route_optimization.transports import grpc as grpc_transport
import sys

_REQUEST_TIMEOUT_SECONDS = 1800
_KEEPALIVE_PING_SECONDS = 30

def create_channel(*args, **kwargs):
  raw_options = kwargs.pop("options", ())
  options = dict(raw_options)
  options["grpc.keepalive_time_ms"] = _KEEPALIVE_PING_SECONDS * 1000
  options["grpc.keepalive_timeout_ms"] = 5000
  # Allow any number of pings between the request and the response.
  options["grpc.http2.max_pings_without_data"] = 0
  print(f"Using options: {options}", file=sys.stderr)
  return grpc_transport.RouteOptimizationGrpcTransport.create_channel(
      *args,
      options=list(options.items()),
      **kwargs,
  )

def create_grpc_transport(*args, **kwargs):
  if "channel" in kwargs:
    raise ValueError(
        "`channel` is overridden by this function, and must not be provided."
    )
  return grpc_transport.RouteOptimizationGrpcTransport(
      *args,
      channel=create_channel,
      **kwargs,
  )

def run_optimize_tours(request):
  client = ro.RouteOptimizationClient(transport=create_grpc_transport)
  return client.optimize_tours(request, timeout=_REQUEST_TIMEOUT_SECONDS)