Limity czasu i terminy

W tym dokumencie wyjaśniamy, jak skonfigurować ustawienia limitu czasu i terminu dla żądań interfejsu Route Optimization API. Nieustawienie tych wartości lub ich nieprawidłowe ustawienie może powodować problemy z połączeniem lub jakością odpowiedzi.

Limit czasu określasz w treści żądania, a termin w nagłówku żądania. Interfejs Route Optimization API przetwarza żądanie w ramach limitu czasu określonego przez te parametry, uwzględniając najkrótszy czas.

Konfigurowanie limitów czasu i terminów pozwala zarządzać czasem przetwarzania w następujący sposób:

  • Wydłużenie czasu przetwarzania:
    • rozwiązywać złożone prośby,
    • uzyskać odpowiedź wyższej jakości,
  • Skróć czas przetwarzania:
    • Rozwiązuj proste żądania szybciej niż domyślnie.
    • Rozwiązywanie żądań w krótszym czasie, ale uzyskiwanie odpowiedzi o niższej jakości.

Uwaga: parametry limitu czasu i terminu mają zastosowanie tylko wtedy, gdy parametr solvingMode ma wartość domyślną DEFAULT_SOLVE. Inne opcje solvingMode, takie jak VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS lub TRANSFORM_AND_RETURN_REQUEST, zwykle nie wymagają dostosowania limitu czasu, ponieważ są znacznie szybsze.

Określanie potrzeb związanych z czasem oczekiwania i terminem

Przed skonfigurowaniem limitów czasu i terminów zapoznaj się z tą sekcją, aby sprawdzić, czy rozumiesz, jak wybór punktu końcowego i protokołu wpływa na te ustawienia.

Poniższe wskazówki pomogą Ci sprawdzić, czy używasz odpowiedniej konfiguracji do osiągania swoich celów.

  • W przypadku ciągłych i powtarzających się żądań oraz złożonych żądań, które wymagają dłuższego czasu przetwarzania, używaj nieblokujących punktów końcowych.
  • W przypadku małych żądań i szybkiego dostarczania wyników używaj punktów końcowych blokowania, akceptując kompromis w zakresie jakości.
  • W codziennej pracy, zwłaszcza w przypadku aplikacji produkcyjnych, używaj gRPC.
  • Do testowania, eksperymentów i jednorazowych żądań używaj interfejsu REST.

Kliknij przycisk poniżej, aby wyświetlić diagram, który pomoże Ci określić, które sekcje tego dokumentu są najbardziej istotne w Twojej konfiguracji.

Otwórz diagram w osobnej karcie

Ustaw parametr timeout.

Ustaw wartość parametru timeout w treści żądania, aby określić maksymalny czas, przez jaki serwer przetwarza żądanie przed zwróceniem odpowiedzi. Rzeczywisty czas może być krótszy niż przydzielony, jeśli interfejs API znajdzie optymalne rozwiązanie przed osiągnięciem maksymalnego przydzielonego czasu.

Ustaw parametr timeout za pomocą protokołu czasu trwania bufor, który jest czasem trwania w sekundach i może wynosić od 1 sekundy do 1800 sekund. Zwiększ tę wartość do 3600 sekund za pomocą polecenia allowLargeDeadlineDespiteInterruptionRisk.

W tabeli poniżej znajdziesz zalecane wartości timeout w zależności od złożoności żądania oraz liczby przesyłek i pojazdów.

Liczba przesyłek i pojazdów Brak ograniczeń Elastyczne przedziały czasowe i ograniczenia dotyczące załadunku lub długie trasy krótkie przedziały czasowe, ograniczenia dotyczące ładunku, złożone ograniczenia lub bardzo długie trasy;
1–8 2 s 2 s 5 s
9–32 5 s 10 s 20 s
33–100 15 s 30 s 60 s
101–1000 45 s 90s 180 s
1001–10 000 120 s 360s 900s
10 001 lub więcej 60 s + 120 s na 10 tys. przesyłek 360s na 10 tys. przesyłek 900 s na 10 tys. przesyłek

Ustaw termin

Ustaw termin w nagłówku żądania, aby określić maksymalny czas, jaki interfejs Route Optimization API może poświęcić na przetwarzanie żądania. W podsekcjach poniżej znajdziesz opis ustawiania terminów dla żądań REST i gRPC.

Żądania REST

Gdy używasz REST do wywoływania blokującego punktu końcowego, możesz wydłużyć termin poza domyślne 60 sekund, co często jest zbyt krótkim czasem w przypadku złożonych żądań. Musisz to zrobić nawet wtedy, gdy w treści żądania podasz dłuższy termin, ponieważ domyślny termin zastępuje wszystkie wartości timeout ustawione w treści żądania, które są dłuższe niż 60 sekund.

Wydłuż termin poza domyślne 60 sekund, ustawiając nagłówek żądania X-Server-Timeout. W przeciwieństwie do treści żądania wartość nagłówka to liczba sekund, ale bez sufiksu „s”. Maksymalna wartość, jaką możesz ustawić w tym nagłówku, jest zgodna z ograniczeniami parametru timeout.

Poniższy przykładowy kod pokazuje nagłówek HTTP z wartością X-Server-Timeout ustawioną na 1800 sekund.

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

Biblioteki klienta i żądania gRPC

Podczas korzystania z bibliotek klienta lub gRPC nie musisz konfigurować terminu. Domyślny termin w przypadku korzystania z nich to 3600 sekund, czyli maksymalny czas żądania w tym interfejsie API. Skonfiguruj czas rozwiązywania, ustawiając tylko właściwość limitu czasu w treści żądania.

Parametry wpływające na limity czasu i terminy

Na działanie zarówno limitów czasu, jak i terminów wpływają te parametry:

  • Kontroluj maksymalny termin realizacji żądania za pomocą parametru allowLargeDeadlineDespiteInterruptionRisk.
  • Określ sposób działania wyszukiwania, równoważąc jakość rozwiązania z opóźnieniem za pomocą parametru searchMode.

allowLargeDeadlineDespiteInterruptionRisk

Parametr allowLargeDeadlineDespiteInterruptionRisk wydłuża maksymalny termin żądania do 3600 sekund. Jeśli ten parametr nie jest ustawiony, maksymalna wartość zarówno parametru limitu czasu, jak i parametru terminu to 1800 sekund.

Ustaw wartość allowLargeDeadline DespiteInterruptionRisk na true, aby zwiększyć wartość parametrów czasu oczekiwania i terminu do 3600 sekund.

Dozwolone wartości parametru allowLargeDeadline DespiteInterruptionRisk to:

  • true: zwiększa maksymalną wartość parametrów czasu oczekiwania i terminu do 3600 sekund, przy jednoczesnym uwzględnieniu ryzyka przerwania.
  • false (domyślnie): zachowuje maksymalną wartość limitu czasu i parametrów terminu wynoszącą 1800 sekund.

Jeśli uważasz, że potrzebujesz dłuższego czasu oczekiwania niż 3600 sekund, skontaktuj się z przedstawicielem Google.

searchMode

Parametr searchMode określa, w jaki sposób optymalizator wyszukuje rozwiązania. Umożliwia on nadanie priorytetu szybszej odpowiedzi (mniejsze opóźnienie) lub rozwiązaniu o wyższej jakości.

Jeśli priorytetem jest wyższa jakość rozwiązania, optymalizator potrzebuje sporo czasu, aby znaleźć rozwiązanie o wysokiej jakości. W przypadku dłuższych żądań rozważ ustawienie dłuższego limitu czasu i używanie nieblokujących punktów końcowych, aby uniknąć problemów z połączeniem.

Dozwolone wartości parametru searchMode to:

  • SEARCH_MODE_UNSPECIFIED (domyślny): nieokreślony tryb wyszukiwania, odpowiednik RETURN_FAST.
  • RETURN_FAST: zatrzymuje wyszukiwanie po znalezieniu pierwszego dobrego rozwiązania.
  • CONSUME_ALL_AVAILABLE_TIME: Poświęca cały dostępny czas na szukanie lepszych rozwiązań. Jeśli interfejs API szybko znajdzie optymalne rozwiązanie, nie będzie wykorzystywać całego dostępnego czasu.

Włącz pingi keepalive

Gdy wysyłasz żądania do punktów końcowych blokowania z limitem czasu dłuższym niż 60 sekund, pingi keepalive pomagają zapobiegać utracie połączenia podczas oczekiwania na odpowiedź. Pakiety keepalive to małe pakiety wysyłane w celu utrzymania aktywności połączenia oraz wykrywania i zapobiegania utracie połączenia.

Skonfiguruj te parametry na podstawie używanego protokołu API:

  • REST: skonfiguruj keepalive na poziomie połączenia TCP.
  • gRPC: skonfiguruj pingi keepalive na bazowym gnieździe TCP lub bezpośrednio w protokole gRPC.

W sekcjach poniżej znajdziesz informacje o tym, jak skonfigurować pingi keepalive w przypadku obu protokołów.

Utrzymywanie aktywności w REST

Konfigurowanie pingów keepalive podczas korzystania z REST zależy od biblioteki klienta HTTP. Biblioteki i narzędzia klienta, takie jak curl, mogą udostępniać określone opcje konfiguracji lub automatycznie włączać pingi.

Jeśli biblioteka udostępnia bazowe gniazdo TCP, możesz skonfigurować pingi keepalive bezpośrednio w gnieździe TCP za pomocą opcji takich jak SO_KEEPALIVE. Możesz to zrobić, używając funkcji takich jak setsockopt() lub ich odpowiedników.

Ta funkcja hostowana w GitHubie pokazuje, jak prawidłowo skonfigurować wbudowanego klienta HTTP w Pythonie.

Więcej informacji o utrzymywaniu aktywności na poziomie TCP znajdziesz w omówieniu utrzymywania aktywności w TLDP lub w dokumentacji biblioteki klienta HTTP.

Utrzymywanie aktywności gRPC

gRPC oferuje własny wbudowany mechanizm utrzymywania połączenia w ramach protokołu. Instrukcje konfiguracji w języku klienta znajdziesz w przewodniku po utrzymywaniu połączenia gRPC.

Uwaga: serwery gRPC mogą odrzucać klientów, którzy wysyłają zbyt wiele pingów. Unikaj ustawiania zbyt wysokiej częstotliwości pingów keepalive.

Przykładowe żądanie gRPC z funkcją keepalive

Poniższy przykład pokazuje, jak wysłać żądanie optimizeTours przy użyciu biblioteki klienta w języku Python i pingów keepalive na poziomie 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)