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

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

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

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

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

ध्यान दें: टाइम आउट और समयसीमा वाले पैरामीटर सिर्फ़ तब लागू होते हैं, जब solvingMode को इसकी डिफ़ॉल्ट वैल्यू DEFAULT_SOLVE पर सेट किया गया हो. अन्य solvingMode विकल्पों, जैसे कि VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS या TRANSFORM_AND_RETURN_REQUEST के लिए आम तौर पर, टाइमआउट में बदलाव करने की ज़रूरत नहीं होती, क्योंकि ये विकल्प काफ़ी तेज़ होते हैं.

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

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

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

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

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

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

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

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

duration protocol buffer का इस्तेमाल करके, timeout पैरामीटर सेट करें. यह अवधि सेकंड में होती है और इसकी सीमा 1 सेकंड से लेकर 1800 सेकंड तक हो सकती है. allowLargeDeadlineDespiteInterruptionRisk का इस्तेमाल करके, इस वैल्यू को 3600 सेकंड तक बढ़ाया जा सकता है.

timeout के लिए सुझाई गई वैल्यू

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

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

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

REST अनुरोध

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

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

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

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 सेकंड कर देता है. अगर यह पैरामीटर सेट नहीं किया जाता है, तो टाइमआउट और डेडलाइन, दोनों पैरामीटर के लिए ज़्यादा से ज़्यादा वैल्यू 1800 सेकंड होती है.

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

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

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

अगर आपको लगता है कि आपको 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 के बिल्ट-इन एचटीटीपी क्लाइंट के लिए इसे सही तरीके से सेट अप करने का तरीका बताया गया है.

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

gRPC कीपअलाइव

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)