টাইম-আউট ও ডেডলাইন কনফিগার করা

এই ডকুমেন্টে Route Optimization API অনুরোধের জন্য কীভাবে টাইম-আউট ও ডেডলাইন সেটিংস কনফিগার করতে হয় তা ব্যাখ্যা করা হয়েছে। এইসব ভ্যালু সেট না করলে বা ভুলভাবে সেট করলে কানেকশন বা উত্তরের কোয়ালিটি সংক্রান্ত সমস্যা হতে পারে।

আপনি রিকোয়েস্ট বডিতে টাইমআউট এবং রিকোয়েস্ট হেডারে ডেডলাইন নির্ধারণ করেন। Route Optimization API, সবচেয়ে কম সময়ের ভ্যালু মেনে, এইসব প্যারামিটার দ্বারা নির্ধারিত সময়সীমার মধ্যে অনুরোধ প্রসেস করে।

টাইম-আউট ও ডেডলাইন কনফিগার করলে, আপনি নিম্নলিখিত উপায়ে প্রসেসিং টাইম ম্যানেজ করতে পারবেন:

• প্রসেসিংয়ের সময় বাড়ানো:
  • অত্যন্ত জটিল অনুরোধের সমাধান করা।
  • আরও ভালো কোয়ালিটির উত্তর পান।
• প্রসেসিংয়ের সময় কমানো:
  • ডিফল্টের চেয়ে দ্রুত কম জটিল অনুরোধের সমাধান করে।
  • কম সময়ে কোনও অনুরোধ সমাধান করা যায়, তবে উত্তরটি কম কোয়ালিটির হয়।

মনে রাখবেন: টাইমআউট ও ডেডলাইন প্যারামিটার তখনই প্রযোজ্য হয় যখন solvingMode-এর ডিফল্ট ভ্যালু DEFAULT_SOLVE সেট করা থাকে। অন্যান্য solvingMode বিকল্প, যেমন VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS বাTRANSFORM_AND_RETURN_REQUEST-এর ক্ষেত্রে সাধারণত টাইমআউট অ্যাডজাস্ট করার প্রয়োজন হয় না, কারণ সেগুলি অনেক দ্রুত কাজ করে।

আপনার টাইমআউট ও ডেডলাইন সংক্রান্ত প্রয়োজনীয়তা বোঝা

আপনার এন্ডপয়েন্ট ও প্রোটোকল সংক্রান্ত পছন্দ কীভাবে এইসব সেটিংসকে প্রভাবিত করে তা আপনি বুঝতে পেরেছেন কিনা তা যাচাই করতে, টাইম-আউট ও ডেডলাইন কনফিগার করার আগে এই বিভাগটি পর্যালোচনা করুন।

আপনি নিজের উদ্দেশ্যের জন্য সঠিক সেট-আপ ব্যবহার করছেন কিনা তা কনফার্ম করতে, নিম্নলিখিত নির্দেশিকা আপনাকে সাহায্য করতে পারে।

• ক্রমাগত ও বারবার করা অনুরোধ এবং জটিল অনুরোধের জন্য নন-ব্লকিং এন্ডপয়েন্ট ব্যবহার করুন, যেগুলি সমাধান করতে বেশি সময় লাগে।
• ছোট অনুরোধ এবং ফলাফলের দ্রুত ডেলিভারির জন্য ব্লকিং এন্ডপয়েন্ট ব্যবহার করুন, কোয়ালিটি ট্রেড-অফ গ্রহণ করুন।
• আপনার দৈনন্দিন ওয়ার্কফ্লো, বিশেষ করে প্রোডাকশন অ্যাপ্লিকেশনের জন্য gRPC: ব্যবহার করুন।
• টেস্টিং, এক্সপেরিমেন্ট বা এককালীন অনুরোধের জন্য REST ব্যবহার করুন।

নিচে দেওয়া বোতামে ক্লিক করে একটি ডায়াগ্রাম দেখুন যা আপনাকে বুঝতে সাহায্য করবে যে এই ডকুমেন্টের কোন বিভাগ আপনার সেট-আপের সাথে সবচেয়ে প্রাসঙ্গিক।

আলাদা ট্যাবে ডায়াগ্রাম খুলুন

timeout প্যারামিটার সেট করুন

উত্তর দেওয়ার আগে সার্ভার কোনও অনুরোধের উপর সর্বাধিক কতক্ষণ কাজ করবে তা নির্দিষ্ট করতে অনুরোধের বডিতে timeout প্যারামিটারের মান সেট করুন। API যদি সর্বাধিক বরাদ্দ সময়ের আগেই কোনও অনুকূল সমাধান খুঁজে পায়, তাহলে প্রকৃত ব্যয় করা সময় বরাদ্দ সময়ের চেয়ে কম হতে পারে।

duration protocol buffer, ব্যবহার করে timeout প্যারামিটার সেট করুন, এটি হল সেকেন্ডে সময়সীমা যা ১ সেকেন্ড থেকে ১৮০০ সেকেন্ড পর্যন্ত হতে পারে। allowLargeDeadlineDespiteInterruptionRisk ব্যবহার করে এই ভ্যালু ৩৬০০ সেকেন্ড পর্যন্ত বাড়ান।

সাজেস্ট করা timeoutটি ভ্যালু

নিচের সারণীতে অনুরোধের জটিলতা এবং শিপমেন্ট ও গাড়ির সংখ্যার উপর ভিত্তি করে সাজেস্ট করা timeout ভ্যালু তালিকাভুক্ত করা হয়েছে।

শিপমেন্ট ও গাড়ির সংখ্যা	কোনও বাধা নেই	লুজ টাইম উইন্ডো এবং লোড সংক্রান্ত সীমাবদ্ধতা বা দীর্ঘ রুট	খুব কম সময়ের মধ্যে ডেলিভারি, লোড সংক্রান্ত বিধিনিষেধ, জটিল বিধিনিষেধ বা খুব দীর্ঘ রুট
১ - ৮	২সেঃ	২সেঃ	৫সে
৯ - ৩২	৫সে	১০সে	২০সে
৩৩ - ১০০	১৫ সেকেন্ড	৩০ সেকেন্ড	৬০সে
১০১ - ১,০০০ জন	৪৫সে	৯০-এর দশক	১৮০সে
১,০০১ - ১০,০০০ জন	১২০সে	৩৬০-এর দশক	৯০০সে
১০,০০১ বা তার বেশি	প্রতি ১০ হাজার শিপমেন্টে ৬০ সেকেন্ড + ১২০ সেকেন্ড	প্রতি ১০ হাজার শিপমেন্টে ৩৬০টি	প্রতি ১০,০০০ শিপমেন্টে ৯০০ সেকেন্ড

ডেডলাইন সেট করুন

Route Optimization API কোনও অনুরোধ প্রসেস করার জন্য সর্বাধিক কত সময় নেবে তা নির্ধারণ করতে, অনুরোধের হেডারে সময়সীমা সেট করুন। REST এবং gRPC অনুরোধের জন্য কীভাবে সময়সীমা সেট করতে হয় তা নিম্নলিখিত উপবিভাগে বর্ণনা করা হয়েছে।

REST অনুরোধ

ব্লকিং এন্ডপয়েন্ট কল করার জন্য REST ব্যবহার করার সময়, আপনি ডিফল্ট ৬০ সেকেন্ডের চেয়ে বেশি সময়সীমা সেট করতে পারেন, যা জটিল অনুরোধের ক্ষেত্রে প্রায়ই খুব কম সময় হয়। আপনি অনুরোধের বডিতে আরও বেশি সময়সীমা উল্লেখ করে থাকলেও আপনাকে এটি করতে হবে, কারণ অনুরোধের বডিতে সেট করা ৬০ সেকেন্ডের বেশি যেকোনও timeout ভ্যালুকে ডিফল্ট সময়সীমা ওভাররাইড করে।

X-Server-Timeout রিকোয়েস্ট হেডার সেট করে ডিফল্ট ৬০ সেকেন্ডের বেশি সময়সীমা বাড়ান। অনুরোধের বডির মতো নয়, হেডার ভ্যালু হল সেকেন্ডের সংখ্যা, তবে "s" সাফিক্স থাকে না। এই হেডারের জন্য আপনি যে সর্বাধিক ভ্যালু সেট করতে পারবেন তা timeout প্যারামিটারের সীমাবদ্ধতার সাথে সামঞ্জস্যপূর্ণ।

নিচের কোড স্যাম্পেলটি X-Server-Timeout-এর মান ১৮০০ সেকেন্ড সেট করা একটি HTTP হেডার দেখায়।

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 ব্যবহার করার সময় আপনাকে কোনও সময়সীমা কনফিগার করতে হবে না। এগুলি ব্যবহার করার সময় ডিফল্ট সময়সীমা হল ৩৬০০ সেকেন্ড, এই API-এর জন্য সর্বাধিক অনুরোধের সময়। অনুরোধের বডিতে শুধু টাইমআউট প্রপার্টি সেট করে সমাধান করার সময় কনফিগার করুন।

টাইম-আউট ও ডেডলাইনকে প্রভাবিত করে এমন প্যারামিটার

নিম্নলিখিত প্যারামিটারগুলি টাইমআউট এবং ডেডলাইন কীভাবে কাজ করে তা প্রভাবিত করে:

• allowLargeDeadlineDespiteInterruptionRisk-এর মাধ্যমে সর্বাধিক অনুরোধের সময়সীমা নিয়ন্ত্রণ করুন।
• searchMode-এর সাথে লেটেন্সির বিপরীতে সমাধানের কোয়ালিটির ভারসাম্য বজায় রেখে, সার্চের আচরণ নির্ধারণ করুন।

allowLargeDeadlineDespiteInterruptionRisk

allowLargeDeadlineDespiteInterruptionRisk প্যারামিটারটি অনুরোধের সর্বোচ্চ সময়সীমা বাড়িয়ে ৩৬০০ সেকেন্ড করে দেয়। এই প্যারামিটার সেট করা না থাকলে, টাইমআউট ও ডেডলাইন প্যারামিটার, উভয়েরই সর্বাধিক ভ্যালু হল ১৮০০ সেকেন্ড।

টাইমআউট ও ডেডলাইন প্যারামিটারের ভ্যালু ৩৬০০ সেকেন্ড পর্যন্ত বাড়াতে allowLargeDeadline DespiteInterruptionRisk-কে true-এ সেট করুন।

মনে রাখবেন: allowLargeDeadline DespiteInterruptionRisk-কে true-এ সেট করার অর্থ হল, আপনি স্বীকার করছেন যে দীর্ঘ অনুরোধে বাধা পাওয়ার ঝুঁকি বেশি থাকে, যার ফলে সঠিক ফলাফলের পরিবর্তে কোনও সমস্যা দেখা দিতে পারে।

allowLargeDeadline DespiteInterruptionRisk-এর জন্য অনুমোদিত ভ্যালুগুলি নিম্নলিখিত:

• true: বাধার ঝুঁকি স্বীকার করার সাথে সাথে টাইমআউট এবং ডেডলাইন প্যারামিটারের সর্বোচ্চ মান ৩৬০০ সেকেন্ড পর্যন্ত বাড়ায়।
• false (ডিফল্ট): টাইম-আউট ও ডেডলাইন প্যারামিটারের জন্য সর্বাধিক মান ১৮০০ সেকেন্ড রাখে।

আপনার যদি মনে হয় যে ৩৬০০ সেকেন্ডের বেশি টাইমআউট প্রয়োজন, তাহলে Google প্রতিনিধির সাথে যোগাযোগ করুন।

searchMode

searchMode প্যারামিটারটি কীভাবে অপ্টিমাইজার সমাধান খোঁজে তা নিয়ন্ত্রণ করে, এর ফলে আপনি দ্রুত উত্তর (কম লেটেন্সি) অথবা আরও ভালো কোয়ালিটির সমাধানকে অগ্রাধিকার দিতে পারেন।

আপনি যখন আরও ভাল কোয়ালিটির সমাধানকে অগ্রাধিকার দেন, তখন অপ্টিমাইজার একটি ভাল কোয়ালিটির সমাধান খুঁজে পেতে যথেষ্ট সময় নেয়। এইসব দীর্ঘ অনুরোধের জন্য, কানেকশন সংক্রান্ত সমস্যা এড়াতে, আরও বেশি সময়সীমা সেট করা এবং নন-ব্লকিং এন্ডপয়েন্ট ব্যবহার করার কথা বিবেচনা করুন।

searchMode-এর জন্য অনুমোদিত ভ্যালুগুলি হল:

• SEARCH_MODE_UNSPECIFIED (ডিফল্ট): অনির্দিষ্ট সার্চ মোড, RETURN_FAST-এর সমতুল্য।
• RETURN_FAST: প্রথম ভাল সমাধান খুঁজে পাওয়ার পরে সার্চ করা বন্ধ করে দেয়।
• CONSUME_ALL_AVAILABLE_TIME: আরও ভালো সমাধান খুঁজতে উপলভ্য সব সময় ব্যয় করে। API যদি খুব তাড়াতাড়ি কোনও অপ্টিমাল সমাধান খুঁজে পায়, তাহলে উপলভ্য সব সময় ব্যবহার করে না।

কিপঅ্যালাইভ পিং চালু করুন

আপনি ৬০ সেকেন্ডের বেশি টাইমআউট সহ ব্লকিং এন্ডপয়েন্টে অনুরোধ করলে, কিপঅ্যালাইভ পিং আপনাকে উত্তরের জন্য অপেক্ষা করার সময় কানেকশন লস প্রতিরোধ করতে সাহায্য করে। কানেকশন অ্যাক্টিভিটি বজায় রাখতে এবং কানেকশন লস শনাক্ত ও প্রতিরোধ করতে কিপঅ্যালাইভ পিং ছোট প্যাকেট পাঠায়।

আপনার ব্যবহার করা API প্রোটোকলের ভিত্তিতে এইসব প্যারামিটার কনফিগার করুন:

• REST: TCP কানেকশন লেভেলে কিপঅ্যালাইভ কনফিগার করুন।
• gRPC: অন্তর্নিহিত TCP সকেট বা সরাসরি gRPC প্রোটোকলে কীপঅ্যালাইভ পিং কনফিগার করুন।

নিচের বিভাগে, কীভাবে দুটি প্রোটোকলের জন্য কিপঅ্যালাইভ পিং সেট-আপ করতে হয় তা ব্যাখ্যা করা হয়েছে।

REST keepalive

REST ব্যবহার করার সময় কিপঅ্যালাইভ পিং কনফিগার করা আপনার HTTP ক্লায়েন্ট লাইব্রেরির উপর নির্ভর করে। curl-এর মতো ক্লায়েন্ট লাইব্রেরি ও টুল, নির্দিষ্ট কনফিগারেশন বিকল্প প্রদান করতে পারে অথবা অটোমেটিক পিং চালু করতে পারে।

আপনার লাইব্রেরি যদি অন্তর্নিহিত TCP সকেট প্রকাশ করে, তাহলে আপনি SO_KEEPALIVE-এর মতো বিকল্প ব্যবহার করে সরাসরি TCP সকেটে কিপঅ্যালাইভ পিং কনফিগার করতে পারেন। setsockopt() বা এর সমতুল্য ফাংশন ব্যবহার করে এটি করুন।

এই GitHub-এ হোস্ট করা ফাংশন দেখায় যে Python-এর বিল্ট-ইন HTTP ক্লায়েন্টের জন্য এটি কীভাবে সঠিকভাবে সেট-আপ করতে হয়।

TLDP keepalive ওভারভিউ অথবা আপনার HTTP ক্লায়েন্ট লাইব্রেরি ডকুমেন্টেশনে TCP-লেভেল কিপঅ্যালাইভ সম্পর্কে আরও বিবরণ দেখুন।

gRPC keepalive

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)