تایم اوت ها و ضرب الاجل ها

این سند نحوه پیکربندی تنظیمات مهلت و مهلت زمانی را برای درخواست‌های API بهینه‌سازی مسیر توضیح می‌دهد. تنظیم نکردن این مقادیر یا تنظیم نادرست آنها می تواند باعث ایجاد مشکلات کیفیت اتصال یا پاسخ شود.

شما مدت زمان را در بدنه درخواست و مهلت را در هدر درخواست تعریف می کنید. Route Optimization API درخواست را در محدوده زمانی تعیین شده توسط این پارامترها با رعایت کمترین مقدار زمان پردازش می کند.

پیکربندی مهلت‌ها و مهلت‌ها به شما امکان می‌دهد زمان پردازش را به روش‌های زیر مدیریت کنید:

• افزایش زمان پردازش:
  • درخواست های با پیچیدگی بالا را حل کنید.
  • پاسخ با کیفیت بالاتری دریافت کنید.
• کاهش زمان پردازش:
  • درخواست های کم پیچیدگی را سریعتر از پیش فرض حل کنید.
  • یک درخواست را در زمان کمتری حل کنید اما پاسخی با کیفیت پایین‌تر دریافت کنید.

توجه: پارامترهای مهلت زمانی و مهلت زمانی اعمال می‌شوند که solvingMode روی مقدار پیش‌فرض DEFAULT_SOLVE تنظیم شده باشد. سایر گزینه‌های solvingMode ، مانند VALIDATE_ONLY ، DETECT_SOME_INFEASIBLE_SHIPMENTS ، یا TRANSFORM_AND_RETURN_REQUEST معمولاً به تنظیمات مهلت زمانی نیاز ندارند، زیرا بسیار سریع‌تر هستند.

نیازهای تایم اوت و ضرب الاجل خود را درک کنید

این بخش را قبل از پیکربندی مهلت‌های زمانی و ضرب‌الاجل‌های خود مرور کنید تا بررسی کنید که متوجه شده‌اید انتخاب‌های نقطه پایانی و پروتکل شما چگونه بر این تنظیمات تأثیر می‌گذارند.

دستورالعمل‌های زیر می‌توانند به شما کمک کنند تا مطمئن شوید که از تنظیمات مناسب برای اهداف خود استفاده می‌کنید یا خیر.

• از نقاط پایانی غیرمسدود برای درخواست‌های مداوم و مکرر و برای درخواست‌های پیچیده که از زمان‌های حل طولانی‌تری بهره می‌برند، استفاده کنید.
• از نقاط پایانی مسدود کننده برای درخواست های کوچک و تحویل سریع نتایج استفاده کنید، با پذیرش یک معاوضه با کیفیت.
• از gRPC استفاده کنید: برای گردش کار روزانه خود، به ویژه برای برنامه های تولید.
• از REST برای آزمایش، آزمایش یا درخواست های یکبار استفاده کنید.

روی دکمه زیر کلیک کنید تا نموداری را مشاهده کنید که می تواند به شما کمک کند تعیین کنید کدام بخش از این سند با تنظیمات شما مرتبط است.

نمودار را در تب جداگانه باز کنید

پارامتر timeout تنظیم کنید

مقدار پارامتر timeout را در بدنه درخواست تنظیم کنید تا حداکثر زمانی را که سرور بر روی یک درخواست کار می کند قبل از بازگرداندن پاسخ مشخص کنید. اگر API قبل از رسیدن به حداکثر زمان تخصیص داده شده، راه حل بهینه را بیابد، زمان واقعی صرف شده ممکن است کمتر از زمان اختصاص داده شده باشد.

پارامتر timeout با استفاده از بافر پروتکل مدت زمان تنظیم کنید، که مدت زمانی بر حسب ثانیه است که می تواند از 1 ثانیه تا 1800 ثانیه متغیر باشد. با استفاده از allowLargeDeadlineDespiteInterruptionRisk ، این مقدار را تا 3600 ثانیه افزایش دهید.

مقادیر timeout توصیه شده

جدول زیر مقادیر timeout توصیه شده را بر اساس پیچیدگی درخواست و تعداد محموله ها و وسایل نقلیه فهرست می کند.

تعداد محموله ها و وسایل نقلیه	بدون محدودیت	شل شدن پنجره های زمانی و محدودیت های بار یا مسیرهای طولانی	پنجره های زمانی تنگ، محدودیت های بار، محدودیت های پیچیده، یا مسیرهای بسیار طولانی
1 - 8	2 ثانیه	2 ثانیه	5 ثانیه
9 - 32	5 ثانیه	دهه 10	دهه 20
33 - 100	15 ثانیه	دهه 30	دهه 60
101 - 1000	45	دهه 90	دهه 180
1001 - 10000	120	دهه 360	دهه 900
10001 یا بیشتر	60s + 120s در هر 10k محموله	360 ثانیه در هر 10 هزار محموله	900 در هر 10 هزار محموله

مهلت تعیین کنید

برای تعیین حداکثر زمانی که Route Optimization API صرف پردازش یک درخواست می کند، ضرب الاجل را در هدر درخواست تنظیم کنید. بخش های فرعی زیر نحوه تعیین ضرب الاجل برای درخواست های REST و gRPC را شرح می دهد.

درخواست های REST

هنگام استفاده از REST برای فراخوانی نقطه پایانی مسدودکننده، می‌توانید مهلت را فراتر از پیش‌فرض 60 ثانیه تمدید کنید، که اغلب برای درخواست‌های پیچیده بسیار کوتاه است. شما باید این کار را انجام دهید، حتی اگر از قبل مهلت طولانی تری را در بدنه درخواست تعیین کرده باشید، زیرا مهلت پیش فرض بر هر مقدار timeout تعیین شده در بدنه درخواست که بزرگتر از 60 ثانیه است، لغو می شود.

با تنظیم هدر درخواست X-Server-Timeout مهلت را فراتر از 60 ثانیه پیش فرض تمدید کنید. برخلاف بدنه درخواست، مقدار هدر تعداد ثانیه است، اما بدون پسوند "s". حداکثر مقداری که می‌توانید برای این سرصفحه تنظیم کنید با محدودیت‌های پارامتر timeout مطابقت دارد.

نمونه کد زیر یک هدر HTTP با X-Server-Timeout تنظیم شده روی 1800 ثانیه را نشان می دهد.

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. زمان حل را فقط با تنظیم ویژگی timeout در بدنه درخواست پیکربندی کنید.

پارامترهایی که بر مهلت‌ها و مهلت‌ها تأثیر می‌گذارند

پارامترهای زیر بر نحوه عملکرد هر دو زمان و سررسید تأثیر می‌گذارند:

• حداکثر مهلت درخواست را با 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 : تمام زمان موجود را صرف جستجوی راه حل های بهتر می کند. API اگر زودتر راه حل بهینه را پیدا کند از تمام زمان موجود استفاده نمی کند.

پینگ های نگهدارنده را فعال کنید

وقتی برای مسدود کردن نقاط پایانی با بازه زمانی بیش از 60 ثانیه درخواست می‌کنید، پینگ‌های نگهدارنده به جلوگیری از قطع شدن اتصال در زمانی که منتظر پاسخ هستید کمک می‌کنند. پینگ های Keepalive بسته های کوچکی هستند که برای حفظ فعالیت اتصال و شناسایی و جلوگیری از قطع شدن اتصال ارسال می شوند.

این پارامترها را بر اساس پروتکل API که استفاده می کنید پیکربندی کنید:

• REST: keepalive را در سطح اتصال TCP پیکربندی کنید.
• gRPC: پینگ های keepalive را روی سوکت TCP زیرین یا مستقیماً در پروتکل gRPC پیکربندی کنید.

بخش‌های زیر نحوه تنظیم پینگ‌های نگهدارنده را برای هر دو پروتکل توضیح می‌دهند.

REST keepalive

پیکربندی پینگ‌های نگهدارنده هنگام استفاده از REST به کتابخانه سرویس گیرنده HTTP شما بستگی دارد. کتابخانه ها و ابزارهای کلاینت، مانند curl ، ممکن است گزینه های پیکربندی خاصی را ارائه دهند یا پینگ ها را به طور خودکار فعال کنند.

اگر کتابخانه شما سوکت TCP زیرین را نشان می‌دهد، می‌توانید پینگ‌های نگهدارنده را مستقیماً روی سوکت TCP با استفاده از گزینه‌هایی مانند SO_KEEPALIVE پیکربندی کنید. این کار را با استفاده از توابعی مانند setsockopt() یا معادل آنها انجام دهید.

این تابع میزبانی شده در GitHub نحوه تنظیم صحیح آن را برای کلاینت HTTP داخلی پایتون نشان می دهد.

جزئیات بیشتر در مورد نگهدارنده سطح TCP را در نمای کلی TLDP keepalive یا در اسناد کتابخانه مشتری HTTP خود بیابید.

gRPC نگهدارنده

gRPC مکانیزم نگهدارنده داخلی خود را به عنوان بخشی از پروتکل ارائه می دهد. راهنمای gRPC keepalive را برای دستورالعمل‌هایی در مورد نحوه تنظیم آن در زبان مشتری خود ببینید.

توجه: سرورهای gRPC ممکن است کلاینت هایی را که پینگ های زیادی ارسال می کنند، رد کنند. از تنظیم فرکانس پینگ نگهدارنده خیلی زیاد خودداری کنید.

درخواست نمونه gRPC با Kealive

مثال زیر نحوه ایجاد یک درخواست optimizeTours با استفاده از کتابخانه کلاینت پایتون و پینگ‌های نگهدارنده سطح 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)