टाइम आउट और समयसीमाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

duration प्रोटोकॉल बफ़र का इस्तेमाल करके, timeout पैरामीटर सेट करें. यह अवधि सेकंड में होती है और इसकी सीमा 1 सेकंड से लेकर 1800 सेकंड तक हो सकती है. allowLargeDeadlineDespiteInterruptionRisk का इस्तेमाल करके, इस वैल्यू को 3,600 सेकंड तक बढ़ाएं.

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

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

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

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

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

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

• true: इससे टाइम आउट और समयसीमा के पैरामीटर की ज़्यादा से ज़्यादा वैल्यू 3600 सेकंड तक बढ़ जाती है. हालांकि, इससे रुकावट आने का खतरा बढ़ जाता है.
• 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)