এই ডকুমেন্ট থেকে জানতে পারবেন যে Route Optimization API অনুরোধের জন্য কীভাবে টাইমআউট ও ডেডলাইন সেটিংস কনফিগার করতে হয়। এইসব ভ্যালু সেট না করলে বা ভুলভাবে সেট করলে কানেকশন বা উত্তরের কোয়ালিটি সংক্রান্ত সমস্যা হতে পারে।
আপনি রিকোয়েস্ট বডিতে টাইমআউট এবং রিকোয়েস্ট হেডারে সময়সীমা নির্ধারণ করেন। Route Optimization API, সবচেয়ে কম সময়ের ভ্যালু মেনে, এইসব প্যারামিটার দ্বারা নির্ধারিত সময়সীমার মধ্যে অনুরোধ প্রসেস করে।
টাইম-আউট ও ডেডলাইন কনফিগার করার মাধ্যমে আপনি নিম্নলিখিত উপায়ে প্রসেসিংয়ের সময় ম্যানেজ করতে পারবেন:
- প্রসেসিংয়ের সময় বাড়ানো:
- অত্যন্ত জটিল অনুরোধের সমাধান করা।
- আরও ভালো কোয়ালিটির উত্তর পাওয়া।
- প্রসেসিংয়ের সময় কমানো:
- ডিফল্টের চেয়ে দ্রুত কম জটিল অনুরোধের সমাধান করে।
- কম সময়ে অনুরোধের সমাধান করুন, তবে কম কোয়ালিটির উত্তর পান।
আপনার টাইমআউট ও ডেডলাইন সংক্রান্ত প্রয়োজনীয়তা বোঝা
আপনার এন্ডপয়েন্ট ও প্রোটোকল সংক্রান্ত পছন্দ কীভাবে এইসব সেটিংসকে প্রভাবিত করে তা আপনি বুঝতে পেরেছেন কিনা তা যাচাই করতে, টাইম-আউট ও ডেডলাইন কনফিগার করার আগে এই বিভাগটি পর্যালোচনা করুন।
আপনি নিজের উদ্দেশ্যের জন্য সঠিক সেট-আপ ব্যবহার করছেন কিনা তা কনফার্ম করতে, নিম্নলিখিত নির্দেশিকা আপনাকে সাহায্য করতে পারে।
- ক্রমাগত ও বারবার করা অনুরোধ এবং জটিল অনুরোধের জন্য নন-ব্লকিং এন্ডপয়েন্ট ব্যবহার করুন, যেগুলি সমাধান করতে বেশি সময় লাগে।
- ছোট অনুরোধ এবং ফলাফলের দ্রুত ডেলিভারির জন্য ব্লকিং এন্ডপয়েন্ট ব্যবহার করুন, কোয়ালিটি ট্রেড-অফ গ্রহণ করুন।
- আপনার দৈনন্দিন ওয়ার্কফ্লো, বিশেষ করে প্রোডাকশন অ্যাপ্লিকেশনের জন্য gRPC: ব্যবহার করুন।
- টেস্টিং, এক্সপেরিমেন্ট বা এককালীন অনুরোধের জন্য REST ব্যবহার করুন।
নিচের বোতামে ক্লিক করে একটি ডায়াগ্রাম দেখুন যা আপনাকে এই ডকুমেন্টের কোন অংশটি আপনার সেট-আপের জন্য সবচেয়ে প্রাসঙ্গিক তা নির্ধারণ করতে সাহায্য করবে।
timeout প্যারামিটার সেট করুন
অনুরোধের বডিতে timeout প্যারামিটারের জন্য মান সেট করুন যাতে
উত্তর দেওয়ার আগে সার্ভার কোনও অনুরোধের উপর সর্বাধিক কতক্ষণ কাজ করবে তা নির্দিষ্ট করা যায়। API যদি সর্বাধিক বরাদ্দ সময়ের আগে কোনও
অনুকূল সমাধান খুঁজে পায়, তাহলে
প্রকৃত সময় বরাদ্দ সময়ের চেয়ে কম হতে পারে।
সময়সীমা প্রোটোকল
বাফার ব্যবহার করে 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: বাধার ঝুঁকি স্বীকার করার সাথে সাথে টাইমআউট এবং ডেডলাইন প্যারামিটারের সর্বোচ্চ মান ৩৬০০ সেকেন্ড পর্যন্ত বাড়ায়।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 keepalive
আপনি REST ব্যবহার করার সময় keepalive পিং কনফিগার করা আপনার HTTP ক্লায়েন্ট লাইব্রেরির উপর নির্ভর করে। curl-এর মতো ক্লায়েন্ট লাইব্রেরি ও টুল, নির্দিষ্ট কনফিগারেশন বিকল্প প্রদান করতে
বা অটোমেটিক পিং চালু করতে পারে।
আপনার লাইব্রেরি যদি অন্তর্নিহিত TCP সকেট প্রকাশ করে, তাহলে আপনি SO_KEEPALIVE-এর মতো বিকল্প ব্যবহার করে সরাসরি TCP সকেটে কিপঅ্যালাইভ
পিং কনফিগার করতে পারেন। setsockopt()-এর মতো ফাংশন বা তার সমতুল্য ফাংশন ব্যবহার করে
এটি করুন।
GitHub-এ হোস্ট করা এই ফাংশন দেখায় যে Python-এর বিল্ট-ইন HTTP ক্লায়েন্টের জন্য এটি কীভাবে সঠিকভাবে সেট-আপ করতে হয়।
TLDP keepalive ওভারভিউ বা আপনার HTTP ক্লায়েন্ট লাইব্রেরি ডকুমেন্টেশনে TCP-লেভেল keepalive সম্পর্কে আরও বিবরণ খুঁজুন।
gRPC keepalive
gRPC প্রোটোকলের অংশ হিসেবে নিজস্ব বিল্ট-ইন কিপঅ্যালাইভ মেকানিজম অফার করে। আপনার ক্লায়েন্ট ভাষায় এটি কীভাবে সেট-আপ করবেন সেই সংক্রান্ত নির্দেশাবলীর জন্য gRPC keepalive গাইড দেখুন।
keepalive সহ 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)