সময়সীমা এবং সময়সীমা কনফিগার করুন

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

আপনি রিকোয়েস্ট বডিতে টাইমআউট এবং রিকোয়েস্ট হেডারে ডেডলাইন নির্ধারণ করেন। রাউট অপটিমাইজেশন এপিআই এই প্যারামিটারগুলো দ্বারা নির্ধারিত সময়সীমার মধ্যে সর্বনিম্ন সময় মানটিকে সম্মান করে রিকোয়েস্টটি প্রসেস করে।

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

• প্রক্রিয়াকরণের সময় বৃদ্ধি করুন:
  • উচ্চ-জটিল অনুরোধগুলি সমাধান করুন।
  • আরও উন্নত মানের প্রতিক্রিয়া অর্জন করুন।
• প্রক্রিয়াকরণের সময় কমানো:
  • ডিফল্টের চেয়ে দ্রুত কম জটিল অনুরোধগুলি সমাধান করুন।
  • কম সময়ে অনুরোধের সমাধান করুন কিন্তু নিম্নমানের প্রতিক্রিয়া পান।

দ্রষ্টব্য: টাইমআউট এবং ডেডলাইন প্যারামিটারগুলো শুধুমাত্র তখনই প্রযোজ্য হয় যখন 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 মানগুলি তালিকাভুক্ত করা হয়েছে।

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

সময়সীমা নির্ধারণ করুন

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

REST অনুরোধগুলি

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

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

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

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-এর জন্য সর্বোচ্চ রিকোয়েস্ট টাইম। শুধুমাত্র রিকোয়েস্ট বডিতে timeout প্রপার্টি সেট করার মাধ্যমে সলভিং টাইম কনফিগার করুন।

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

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

• allowLargeDeadlineDespiteInterruptionRisk ব্যবহার করে সর্বোচ্চ অনুরোধের সময়সীমা নিয়ন্ত্রণ করুন।
• searchMode ব্যবহার করে সমাধানের গুণমান এবং লেটেন্সির মধ্যে ভারসাম্য রেখে সার্চের আচরণ নির্ধারণ করুন।

allowLargeDeadlineDespiteInterruptionRisk

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

timeout এবং deadline প্যারামিটারগুলোর মান সর্বোচ্চ ৩৬০০ সেকেন্ড পর্যন্ত বাড়াতে allowLargeDeadline DespiteInterruptionRisk true তে সেট করুন।

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

allowLargeDeadline DespiteInterruptionRisk জন্য অনুমোদিত মানগুলি নিম্নরূপ:

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

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

searchMode

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

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

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

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

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

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

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

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

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

REST keepalive

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

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

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

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

gRPC কিপঅ্যালাইভ

gRPC প্রোটোকলের অংশ হিসেবে নিজস্ব একটি বিল্ট-ইন কিপঅ্যালাইভ ব্যবস্থা প্রদান করে। আপনার ক্লায়েন্ট ল্যাঙ্গুয়েজে এটি কীভাবে সেট আপ করবেন, তার নির্দেশাবলীর জন্য gRPC কিপঅ্যালাইভ গাইডটি দেখুন।

দ্রষ্টব্য: যেসব ক্লায়েন্ট অতিরিক্ত পিং পাঠায়, gRPC সার্ভার তাদের পরিষেবা প্রত্যাখ্যান করতে পারে। কিপঅ্যালাইভ পিং ফ্রিকোয়েন্সি খুব বেশি সেট করা থেকে বিরত থাকুন।

কিপঅ্যালাইভ সহ gRPC নমুনা অনুরোধ

নিম্নলিখিত উদাহরণে দেখানো হয়েছে কিভাবে পাইথন ক্লায়েন্ট লাইব্রেরি এবং 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)