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

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

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

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

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

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

আপনার সময়সীমা এবং সময়সীমার প্রয়োজনীয়তা বুঝুন

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

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

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

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

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

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

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

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

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

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

চালান এবং যানবাহনের সংখ্যা	কোন বাধা নেই	শিথিল সময় জানালা এবং লোড সীমাবদ্ধতা বা দীর্ঘ রুট	টাইট টাইম উইন্ডো, লোড সীমাবদ্ধতা, জটিল সীমাবদ্ধতা, বা খুব দীর্ঘ রুট
1 - 8	2 সে	2 সে	5s
9 - 32	5s	10s	20s
33 - 100	15 সেকেন্ড	30s	60 এর দশক
101 - 1,000	45 সে	90 এর দশক	180 এর দশক
1,001 - 10,000	120	360	900 এর দশক
10,001 বা তার বেশি	প্রতি 10k চালানে 60s + 120s	প্রতি 10k চালানে 360s	900s প্রতি 10k চালান

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

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

REST অনুরোধ

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

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

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

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

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

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

allowLargeDeadlineDespiteInterruptionRisk

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

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

দ্রষ্টব্য: 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 : আরও ভাল সমাধান খোঁজার জন্য সমস্ত উপলব্ধ সময় ব্যয় করে৷ এপিআই সমস্ত উপলব্ধ সময় ব্যবহার করে না যদি এটি প্রথম দিকে একটি সর্বোত্তম সমাধান খুঁজে পায়।

Keepalive pings সক্ষম করুন

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

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

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

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

বেঁচে থাকার জন্য বিশ্রাম নিন

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

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

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

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

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

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

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

Keepalive সহ gRPC নমুনা অনুরোধ

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