সময়সীমা এবং সময়সীমা

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

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

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

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

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

আপনার টাইমআউট এবং সময়সীমার চাহিদাগুলি বুঝুন

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

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

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

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

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

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

সার্ভার কোন অনুরোধে সর্বোচ্চ কত সময় কাজ করবে এবং কোন প্রতিক্রিয়া ফেরত দেবে তা নির্দিষ্ট করার জন্য অনুরোধের বডিতে timeout প্যারামিটারের মান সেট করুন। API যদি সর্বোচ্চ বরাদ্দকৃত সময় পৌঁছানোর আগে একটি সর্বোত্তম সমাধান খুঁজে পায়, তাহলে প্রকৃত ব্যয়িত সময় বরাদ্দকৃত সময়ের চেয়ে কম হতে পারে।

সময়কাল প্রোটোকল বাফার ব্যবহার করে timeout প্যারামিটার সেট করুন, যা সেকেন্ডে একটি সময়কাল যা 1 সেকেন্ড থেকে 1800 সেকেন্ড পর্যন্ত হতে পারে। allowLargeDeadlineDespiteInterruptionRisk ব্যবহার করে এই মানটি 3600 সেকেন্ড পর্যন্ত বাড়ান।

প্রস্তাবিত timeout মান

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

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

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

REST অনুরোধ

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

X-Server-Timeout রিকোয়েস্ট হেডার সেট করে ডিফল্ট সময়সীমা 60 সেকেন্ডের বেশি বাড়ান। রিকোয়েস্ট বডির বিপরীতে, হেডারের মান সেকেন্ডের সংখ্যা, কিন্তু "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 ব্যবহার করার সময় আপনাকে কোনও সময়সীমা কনফিগার করতে হবে না। এগুলি ব্যবহারের সময় ডিফল্ট সময়সীমা হল 3600 সেকেন্ড, এই API-এর জন্য সর্বাধিক অনুরোধের সময়। অনুরোধের মূল অংশে শুধুমাত্র টাইমআউট বৈশিষ্ট্য সেট করে সমাধানের সময় কনফিগার করুন।

সময়সীমা এবং সময়সীমা প্রভাবিত করে এমন পরামিতি

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

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

allowLargeDeadlineDespiteInterruptionRisk

allowLargeDeadlineDespiteInterruptionRisk প্যারামিটার সর্বাধিক অনুরোধের সময়সীমা 3600 সেকেন্ডে বৃদ্ধি করে। যদি এই প্যারামিটারটি সেট না করা থাকে, তাহলে টাইমআউট এবং ডেডলাইন প্যারামিটার উভয়ের জন্য সর্বোচ্চ মান 1800 সেকেন্ড।

টাইমআউট এবং ডেডলাইন প্যারামিটারের মান 3600 সেকেন্ড পর্যন্ত বাড়ানোর জন্য allowLargeDeadline DespiteInterruptionRisk true এ সেট করুন।

allowLargeDeadline DespiteInterruptionRisk এর অনুমোদিত মানগুলি হল:

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

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

searchMode

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

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

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

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

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

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

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

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

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

REST কিপলাইভ

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

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

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

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

জিআরপিসি কিপলাইভ

প্রোটোকলের অংশ হিসেবে gRPC নিজস্ব বিল্ট-ইন keepalive মেকানিজম অফার করে। আপনার ক্লায়েন্ট ভাষায় এটি কীভাবে সেট আপ করবেন তার নির্দেশাবলীর জন্য gRPC keepalive নির্দেশিকাটি দেখুন।

দ্রষ্টব্য: gRPC সার্ভারগুলি অনেক বেশি পিং পাঠায় এমন ক্লায়েন্টদের প্রত্যাখ্যান করতে পারে। Keepalive পিং ফ্রিকোয়েন্সি খুব বেশি সেট করা এড়িয়ে চলুন।

কিপলাইভের সাথে জিআরপিসি নমুনা অনুরোধ

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