Trang này được dịch bởi Cloud Translation API.

Thời gian chờ và thời hạn

Tài liệu này giải thích cách định cấu hình chế độ cài đặt thời gian chờ và thời hạn cho các yêu cầu Route Optimization API. Việc không đặt các giá trị này hoặc đặt sai có thể gây ra các vấn đề về chất lượng kết nối hoặc phản hồi.

Bạn xác định thời gian chờ trong nội dung yêu cầu và thời hạn trong tiêu đề yêu cầu. Route Optimization API xử lý yêu cầu trong giới hạn thời gian được xác định bằng các thông số này, tuân theo giá trị thời gian ngắn nhất.

Việc định cấu hình thời gian chờ và thời hạn cho phép bạn quản lý thời gian xử lý theo những cách sau:

Tăng thời gian xử lý:
- Giải quyết các yêu cầu có độ phức tạp cao.
- Nhận được câu trả lời chất lượng cao hơn.
Giảm thời gian xử lý:
- Giải quyết các yêu cầu có độ phức tạp thấp nhanh hơn so với mặc định.
- Giải quyết yêu cầu trong thời gian ngắn hơn nhưng nhận được phản hồi có chất lượng thấp hơn.

Lưu ý: Các tham số thời gian chờ và thời hạn chỉ áp dụng khi solvingMode được đặt thành giá trị mặc định là DEFAULT_SOLVE. Các lựa chọn solvingMode khác, chẳng hạn như VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS hoặc TRANSFORM_AND_RETURN_REQUEST thường không yêu cầu điều chỉnh thời gian chờ vì chúng nhanh hơn đáng kể.

Hiểu rõ nhu cầu về thời gian chờ và thời hạn

Hãy xem lại phần này trước khi định cấu hình thời gian chờ và thời hạn để xác minh rằng bạn hiểu cách các lựa chọn về giao thức và điểm cuối ảnh hưởng đến các chế độ cài đặt này.

Các nguyên tắc sau đây có thể giúp bạn xác nhận xem bạn có đang sử dụng chế độ thiết lập phù hợp với mục tiêu của mình hay không.

Sử dụng các điểm cuối không chặn cho các yêu cầu liên tục và lặp lại cũng như cho các yêu cầu phức tạp có lợi từ thời gian giải quyết lâu hơn.
Sử dụng các điểm cuối chặn cho các yêu cầu nhỏ và việc phân phối kết quả nhanh chóng, chấp nhận sự đánh đổi về chất lượng.
Sử dụng gRPC: cho quy trình làm việc hằng ngày, đặc biệt là đối với các ứng dụng sản xuất.
Sử dụng REST cho hoạt động kiểm thử, thử nghiệm hoặc các yêu cầu một lần.

Nhấp vào nút bên dưới để xem sơ đồ có thể giúp bạn xác định những phần nào trong tài liệu này phù hợp nhất với chế độ thiết lập của bạn.

Mở sơ đồ trong thẻ riêng biệt

Đặt tham số `timeout`

Đặt giá trị cho tham số timeout trong phần nội dung yêu cầu để chỉ định thời gian tối đa mà máy chủ xử lý một yêu cầu trước khi trả về phản hồi. Thời gian thực tế đã sử dụng có thể ngắn hơn thời gian được phân bổ nếu API tìm thấy một giải pháp tối ưu trước khi đạt đến thời gian được phân bổ tối đa.

Đặt tham số timeout bằng cách sử dụng bộ đệm giao thức thời lượng. Đây là thời lượng tính bằng giây, có thể dao động từ 1 giây đến 1800 giây. Tăng giá trị này lên tối đa 3.600 giây bằng cách sử dụng allowLargeDeadlineDespiteInterruptionRisk.

Giá trị `timeout` được đề xuất

Bảng sau đây liệt kê các giá trị timeout được đề xuất dựa trên độ phức tạp của yêu cầu và số lượng lô hàng và xe.

Số lượng lô hàng và xe	Không có ràng buộc	Khung thời gian và các hạn chế về tải trọng không chặt chẽ hoặc tuyến đường dài	Khung thời gian chặt chẽ, hạn chế về tải trọng, hạn chế phức tạp hoặc tuyến đường rất dài
1 – 8	2 giây	2 giây	5 giây
9 – 32	5 giây	10 giây	20 giây
33 – 100	15 giây	30 giây	60 giây
101 – 1.000	45 giây	thập niên 90	180 giây
1.001 – 10.000	120 giây	360s	900 giây
Từ 10.001 trở lên	60 giây + 120 giây cho mỗi 10.000 lô hàng	360 lần trên 10.000 lượt vận chuyển	900 giây trên 10.000 lô hàng

Đặt thời hạn

Đặt thời hạn trong tiêu đề yêu cầu để xác định thời gian tối đa mà Route Optimization API dành để xử lý một yêu cầu. Các mục con sau đây mô tả cách đặt thời hạn cho các yêu cầu REST và gRPC.

Yêu cầu REST

Khi sử dụng REST để gọi một điểm cuối chặn, bạn có thể kéo dài thời hạn vượt quá thời hạn mặc định là 60 giây. Thời hạn này thường quá ngắn đối với các yêu cầu phức tạp. Bạn phải thực hiện việc này ngay cả khi đã chỉ định thời hạn dài hơn trong nội dung yêu cầu, vì thời hạn mặc định sẽ ghi đè mọi giá trị timeout được đặt trong nội dung yêu cầu lớn hơn 60 giây.

Gia hạn thời gian vượt quá 60 giây mặc định bằng cách đặt tiêu đề yêu cầu X-Server-Timeout. Không giống như trong nội dung yêu cầu, giá trị của tiêu đề là số giây, nhưng không có hậu tố "s". Giá trị tối đa mà bạn có thể đặt cho tiêu đề này tuân theo các hạn chế của tham số timeout.

Mẫu mã sau đây cho thấy một tiêu đề HTTP có X-Server-Timeout được đặt thành 1800 giây.

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

Thư viện ứng dụng và yêu cầu gRPC

Bạn không cần định cấu hình thời hạn khi sử dụng thư viện ứng dụng hoặc gRPC. Thời hạn mặc định khi sử dụng các API này là 3.600 giây, thời gian yêu cầu tối đa cho API này. Định cấu hình thời gian giải bằng cách chỉ đặt thuộc tính thời gian chờ trong nội dung yêu cầu.

Các tham số ảnh hưởng đến thời gian chờ và thời hạn

Các tham số sau đây ảnh hưởng đến cách hoạt động của cả thời gian chờ và thời hạn:

Kiểm soát thời hạn tối đa của yêu cầu bằng allowLargeDeadlineDespiteInterruptionRisk.
Xác định hành vi của cụm từ tìm kiếm, cân bằng chất lượng giải pháp với độ trễ bằng searchMode.

`allowLargeDeadlineDespiteInterruptionRisk`

Tham số allowLargeDeadlineDespiteInterruptionRisk sẽ tăng thời hạn tối đa của yêu cầu lên 3600 giây. Nếu bạn không đặt thông số này, giá trị tối đa cho cả thông số thời gian chờ và thời hạn là 1800 giây.

Đặt allowLargeDeadline DespiteInterruptionRisk thành true để tăng giá trị của các tham số thời gian chờ và thời hạn lên tối đa 3.600 giây.

Các giá trị được phép cho allowLargeDeadline DespiteInterruptionRisk là:

true: Tăng giá trị tối đa cho các tham số thời gian chờ và thời hạn lên 3600 giây trong khi thừa nhận rủi ro gián đoạn.
false (mặc định): Giữ giá trị tối đa cho các tham số thời gian chờ và thời hạn là 1800 giây.

Nếu bạn cho rằng mình cần thời gian chờ lâu hơn 3.600 giây, hãy liên hệ với người đại diện của Google.

`searchMode`

Tham số searchMode kiểm soát cách trình tối ưu hoá tìm kiếm các giải pháp, cho phép bạn ưu tiên phản hồi nhanh hơn (độ trễ thấp hơn) hoặc giải pháp chất lượng cao hơn.

Khi bạn ưu tiên chất lượng giải pháp cao hơn, trình tối ưu hoá sẽ mất một khoảng thời gian hợp lý để tìm ra một giải pháp chất lượng cao. Đối với những yêu cầu dài hơn này, hãy cân nhắc việc thiết lập thời gian chờ lâu hơn và sử dụng các điểm cuối không chặn để tránh các vấn đề về kết nối.

Các giá trị được phép cho searchMode là:

SEARCH_MODE_UNSPECIFIED (mặc định): Chế độ tìm kiếm không xác định, tương đương với RETURN_FAST.
RETURN_FAST: Dừng tìm kiếm sau khi tìm thấy giải pháp phù hợp đầu tiên.
CONSUME_ALL_AVAILABLE_TIME: Dành toàn bộ thời gian có thể để tìm kiếm các giải pháp tốt hơn. API này không sử dụng toàn bộ thời gian có sẵn nếu tìm thấy giải pháp tối ưu sớm.

Bật lệnh ping duy trì kết nối

Khi bạn gửi yêu cầu đến các điểm cuối chặn có thời gian chờ lâu hơn 60 giây, các lệnh ping duy trì hoạt động sẽ giúp ngăn chặn tình trạng mất kết nối trong khi bạn chờ phản hồi. Keepalive ping là các gói nhỏ được gửi để duy trì hoạt động kết nối, cũng như để phát hiện và ngăn chặn tình trạng mất kết nối.

Định cấu hình các tham số này dựa trên giao thức API mà bạn sử dụng:

REST: Định cấu hình keepalive ở cấp kết nối TCP.
gRPC: Định cấu hình lệnh ping duy trì hoạt động trên ổ cắm TCP cơ bản hoặc trực tiếp trong giao thức gRPC.

Các phần sau đây giải thích cách thiết lập ping duy trì hoạt động cho cả hai giao thức.

REST duy trì hoạt động

Việc định cấu hình lệnh ping keepalive khi bạn sử dụng REST phụ thuộc vào thư viện ứng dụng HTTP. Các thư viện và công cụ ứng dụng, chẳng hạn như curl, có thể cung cấp các lựa chọn cấu hình cụ thể hoặc tự động bật ping.

Nếu thư viện của bạn hiển thị ổ cắm TCP cơ bản, bạn có thể định cấu hình các lệnh ping keepalive trực tiếp trên ổ cắm TCP bằng cách sử dụng các lựa chọn như SO_KEEPALIVE. Hãy làm việc này bằng cách sử dụng các hàm như setsockopt() hoặc hàm tương đương.

Hàm này được lưu trữ trên GitHub và minh hoạ cách thiết lập đúng cách cho ứng dụng HTTP tích hợp sẵn của Python.

Tìm thêm thông tin chi tiết về tính năng duy trì hoạt động ở cấp TCP trong Tổng quan về tính năng duy trì hoạt động TLDP hoặc trong tài liệu về thư viện ứng dụng HTTP.

gRPC duy trì hoạt động

gRPC cung cấp cơ chế duy trì kết nối tích hợp sẵn của riêng mình trong giao thức. Hãy xem hướng dẫn về tín hiệu duy trì hoạt động gRPC để biết hướng dẫn về cách thiết lập tín hiệu này bằng ngôn ngữ của máy khách.

Lưu ý: Các máy chủ gRPC có thể từ chối những máy khách gửi quá nhiều lệnh ping. Tránh đặt tần suất ping keepalive quá cao.

Yêu cầu mẫu gRPC có tính năng duy trì hoạt động

Ví dụ sau đây cho biết cách thực hiện yêu cầu optimizeTours bằng cách sử dụng thư viện ứng dụng Python và các lệnh ping duy trì hoạt động ở cấp 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)