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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समयसीमा खत्म होने की तारीख सेट करना

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

REST के अनुरोध

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

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

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

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

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

searchMode

The 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)