Konfigurowanie limitów czasu i terminów

Ten dokument wyjaśnia, jak skonfigurować ustawienia limitu czasu i terminu dla żądań do interfejsu Route Optimization API. Jeśli nie ustawisz tych wartości lub ustawisz je nieprawidłowo, mogą wystąpić problemy z połączeniem lub jakością odpowiedzi.

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

Skonfigurowanie limitów czasu i terminów pozwala zarządzać czasem przetwarzania na te sposoby:

• Wydłużenie czasu przetwarzania:
  • rozwiązywać bardzo złożone problemy;
  • uzyskać odpowiedź wyższej jakości;
• Skrócenie czasu przetwarzania:
  • Szybciej niż domyślnie rozwiązuj proste problemy.
  • Szybsze rozwiązywanie problemów, ale niższa jakość odpowiedzi.

Określanie potrzeb dotyczących limitów czasu i terminów

Zanim skonfigurujesz limity czasu i terminy, zapoznaj się z tą sekcją, aby dowiedzieć się, 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 realizacji 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 na rozwiązanie, używaj nieblokujących punktów końcowych.
• Używaj blokujących punktów końcowych w przypadku małych żądań i szybkiego dostarczania wyników, akceptując kompromis w zakresie jakości.
• Używaj gRPC w codziennej pracy, zwłaszcza w przypadku aplikacji produkcyjnych.
• Używaj REST do testowania, eksperymentów lub jednorazowych żądań.

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

Otwórz diagram w osobnej karcieopen_in_new

Ustawianie parametru timeout

Ustaw wartość parametru timeout w treści żądania, aby określić maksymalny czas, przez jaki serwer ma pracować nad żądaniem, zanim zwróci odpowiedź. Rzeczywisty czas może być krótszy niż przydzielony, jeśli interfejs API znajdzie optymalne rozwiązanie przed upływem maksymalnego przydzielonego czasu.

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

Zalecane wartości timeout

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

Ustawianie terminu

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 poniższych sekcjach opisano, jak ustawić terminy 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 jeśli w treści żądania został już określony 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ć dla tego nagłówka, jest zgodna z ograniczeniami parametru timeout.

Poniższy przykładowy kod pokazuje nagłówek HTTP z parametrem X-Server-Timeout ustawionym 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

Jeśli używasz bibliotek klienta lub gRPC, nie musisz konfigurować terminu. Domyślny termin ich użycia to 3600 sekund, czyli maksymalny czas żądania dla tego interfejsu 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 limitów czasu i terminów wpływają te parametry:

• Maksymalny termin żądania możesz kontrolować za pomocą allowLargeDeadlineDespiteInterruptionRisk.
• Zdefiniuj zachowanie wyszukiwania, równoważąc jakość rozwiązania i opóźnienie za pomocą searchMode.

allowLargeDeadlineDespiteInterruptionRisk

Parametr allowLargeDeadlineDespiteInterruptionRisk zwiększa maksymalny termin żądania do 3600 sekund. Jeśli ten parametr nie jest ustawiony, maksymalna wartość parametrów limitu czasu i terminu wynosi 1800 sekund.

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

Dozwolone wartości parametru allowLargeDeadline DespiteInterruptionRisk to:

• true: zwiększa maksymalną wartość parametrów limitu czasu i terminu do 3600 sekund, jednocześnie potwierdzając ryzyko przerwania.
• false (domyślna): zachowuje maksymalną wartość parametrów limitu czasu i terminu wynoszącą 1800 sekund.

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

searchMode

Parametr searchMode określa, jak optymalizator wyszukuje rozwiązania, dzięki czemu możesz nadać priorytet szybszej odpowiedzi (mniejsze opóźnienie) lub rozwiązaniu o wyższej jakości.

Gdy priorytetem jest wyższa jakość rozwiązania, optymalizator poświęca sporo czasu na znalezienie rozwiązania wysokiej jakości. W przypadku dłuższych żądań rozważ ustawienie dłuższego limitu czasu i użycie nieblokujących punktów końcowych, aby uniknąć problemów z połączeniem.

Dozwolone wartości parametru searchMode:

• 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ń. Interfejs API nie wykorzystuje całego dostępnego czasu, jeśli wcześniej znajdzie optymalne rozwiązanie.

Włącz pingi keepalive

Gdy wysyłasz żądania do blokujących punktów końcowych z czasem oczekiwania dłuższym niż 60 sekund, pingi keepalive pomagają zapobiegać utracie połączenia podczas oczekiwania na odpowiedź. Pingi utrzymujące połączenie 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 interfejsu API:

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

W sekcjach poniżej znajdziesz informacje o konfigurowaniu pingów utrzymujących połączenie w przypadku obu protokołów.

Utrzymywanie połączenia REST

Konfigurowanie pingów keepalive podczas korzystania z REST zależy od biblioteki klienta HTTP. Biblioteki klienta i narzędzia, 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 utrzymujące połączenie bezpośrednio na gnieździe TCP, używając opcji takich jak SO_KEEPALIVE. Możesz to zrobić, używając funkcji takich jak setsockopt() lub ich odpowiedników.

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

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

gRPC keepalive

gRPC oferuje własny wbudowany mechanizm utrzymywania połączenia w ramach protokołu. Instrukcje konfigurowania tej funkcji w języku klienta znajdziesz w przewodniku po gRPC keepalive.

Przykładowe żądanie gRPC z keepalive

Poniższy przykład pokazuje, jak wysłać żądanie optimizeTours przy użyciu biblioteki klienta w Pythonie 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)