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

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

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

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

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

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

टाइमआउट और डेडलाइन की ज़रूरत को समझना

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

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

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

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

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

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

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

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

वे पैरामीटर जिनसे टाइमआउट और डेडलाइन पर असर पड़ता है

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

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

allowLargeDeadlineDespiteInterruptionRisk

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

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

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

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

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

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

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

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)