این سند نحوه پیکربندی تنظیمات مهلت و زمان اتمام برای درخواست‌های 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 مطابقت دارد.
نمونه کد زیر سرایند 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 است. زمان حل را فقط با تنظیم ویژگی مهلت زمانی در بدنه درخواست پیکربندی کنید.
پارامترهایی که بر زمان‌بندی‌ها و مهلت‌ها تأثیر می‌گذارند
پارامترهای زیر بر نحوه عملکرد مهلت‌ها و زمان‌های استراحت تأثیر می‌گذارند:
- حداکثر مهلت درخواست را با
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: تمام وقت موجود را صرف جستجوی راه‌حل‌های بهتر می‌کند. اگر میانای برنامه‌سازی کاربردی راه‌حل بهینه را زود پیدا کند، از همه زمان دردسترس استفاده نمی‌کند.
فعال کردن پینگ‌های زنده نگه داشتن
وقتی درخواست‌هایی به نقاط پایانی مسدودکننده با زمان وقفه بیشتر از ۶۰ ثانیه ارسال می‌کنید، پینگ‌های keepalive به جلوگیری از قطع اتصال درحین انتظار برای پاسخ کمک می‌کنند. پینگ‌های Keepalive بسته‌های کوچکی هستند که برای حفظ فعالیت اتصال و شناسایی و جلوگیری از قطع اتصال ارسال می‌شوند.
این پارامترها را براساس پروتکل میانای برنامه‌سازی کاربردی که استفاده می‌کنید پیکربندی کنید:
- REST: keepalive را در سطح اتصال TCP پیکربندی کنید.
- gRPC: پینگ‌های keepalive را در سوکت TCP زیربنایی یا مستقیماً در پروتکل gRPC پیکربندی کنید.
بخش‌های زیر نحوه راه‌اندازی پینگ‌های فعال‌نگهدارنده را برای هر دو پروتکل توضیح می‌دهد.
REST keepalive
پیکربندی کردن پینگ‌های keepalive هنگام استفاده از REST به کتابخانه کارخواه HTTP شما بستگی دارد. کتابخانه‌ها و ابزارهای کارخواه، مانند curl، ممکن است گزینه‌های پیکربندی خاصی ارائه دهند یا پینگ‌ها را به‌طور خودکار فعال کنند.
اگر کتابخانه شما سوکت TCP زیربنایی را افشا می‌کند، می‌توانید پینگ‌های keepalive را مستقیماً روی سوکت TCP بااستفاده از گزینه‌هایی مانند SO_KEEPALIVE پیکربندی کنید. این کار را بااستفاده از توابعی مثل setsockopt() یا معادل آن‌ها انجام دهید.
این تابع میزبانی‌شده در GitHub نشان می‌دهد که چگونه این را به‌درستی برای کارخواه HTTP داخلی Python راه‌اندازی کنید.
جزئیات بیشتر درباره keepalive در سطح TCP را در نمای کلی TLDP keepalive یا در اسناد کتابخانه کارخواه HTTP خود پیدا کنید.
gRPC keepalive
gRPC سازوکار keepalive داخلی خود را به‌عنوان بخشی از پروتکل ارائه می‌دهد. برای دریافت دستورالعمل‌های مربوط به نحوه راه‌اندازی این مورد در زبان کارخواه، راهنمای keepalive در gRPC را ببینید.
درخواست نمونه gRPC با keepalive
مثال زیر نحوه ایجاد درخواست optimizeTours را بااستفاده از کتابخانه کلاینت Python و پینگ‌های keepalive در سطح gRPC نشان می‌دهد.
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)