Konfigurowanie limitów czasu i terminów

Z tego dokumentu dowiesz się, jak skonfigurować ustawienia czasu oczekiwania i terminu dla żądań interfejsu Route Optimization API. Nieustawienie tych wartości lub ich nieprawidłowe ustawienie może spowodować problemy z połączeniem lub jakością odpowiedzi.

Czas oczekiwania określasz w treści żądania, a termin w nagłówku żądania. Interfejs Route Optimization API przetwarza żądanie w czasie określonym przez te parametry, przy czym uwzględnia najkrótszą wartość czasu.

Konfigurowanie czasu oczekiwania i terminów umożliwia zarządzanie czasem przetwarzania w następujący sposób:

• Wydłużenie czasu przetwarzania:
  • Rozwiązywanie żądań o wysokim stopniu złożoności.
  • Uzyskiwanie odpowiedzi wyższej jakości.
• Skrócenie czasu przetwarzania:
  • Szybsze niż domyślne rozwiązywanie żądań o niskim stopniu złożoności.
  • Rozwiązywanie żądania w krótszym czasie, ale uzyskiwanie odpowiedzi niższej jakości.

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

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

Zanim skonfigurujesz czas oczekiwania i terminy, zapoznaj się z tą sekcją, aby sprawdzić, czy rozumiesz, jak wybór punktu końcowego i protokołu wpływa na te ustawienia.

Te wskazówki pomogą Ci sprawdzić, czy używasz odpowiedniej konfiguracji do osiągnięcia 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 rozwiązywania, używaj punktów końcowych nieblokujących.
• W przypadku małych żądań i szybkiego dostarczania wyników, przy jednoczesnym zaakceptowaniu kompromisu w zakresie jakości, używaj punktów końcowych blokujących.
• W codziennej pracy, zwłaszcza w przypadku aplikacji produkcyjnych, używaj gRPC.
• Do testowania, eksperymentów lub jednorazowych żądań używaj REST.

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

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 będzie pracować nad żądaniem, zanim zwróci odpowiedź. Rzeczywisty czas spędzony na przetwarzaniu 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 jest czasem trwania w sekundach i może wynosić od 1 do 1800 sekund. Za pomocą parametru allowLargeDeadlineDespiteInterruptionRisk możesz zwiększyć tę wartość do 3600 sekund.

Zalecane wartości parametru timeout

W tabeli poniżej znajdziesz zalecane wartości parametru timeout w zależności od 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, przez jaki interfejs Route Optimization API będzie przetwarzać żądanie. W podsekcjach poniżej opisujemy, jak ustawić terminy dla żądań REST i gRPC.

Żądania REST

Gdy używasz REST do wywoływania punktu końcowego blokującego, możesz wydłużyć termin poza domyślne 60 sekund, które często są zbyt krótkie w przypadku złożonych żądań. Musisz to zrobić nawet wtedy, gdy w treści żądania podasz już 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.

Aby wydłużyć termin poza domyślne 60 sekund, ustaw nagłówek żądania X-Server-Timeout. W przeciwieństwie do treści żądania wartość nagłówka jest liczbą sekund, ale bez sufiksu „s”. Maksymalna wartość jaką możesz ustawić dla tego nagłówka, jest zgodna z timeout parametru's ograniczeniami.

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

Gdy używasz bibliotek klienta lub gRPC, nie musisz konfigurować terminu. Domyślny termin w przypadku korzystania z nich to 3600 sekund, czyli maksymalny czas żądania dla tego interfejsu API. Skonfiguruj czas rozwiązywania, ustawiając tylko właściwość czasu oczekiwania w treści żądania.

Parametry wpływające na czas oczekiwania i terminy

Na działanie czasu oczekiwania i terminów wpływają te parametry:

• Za pomocą parametru allowLargeDeadlineDespiteInterruptionRisk możesz kontrolować maksymalny termin żądania.
• Za pomocą parametru searchMode możesz określić sposób działania wyszukiwania, równoważąc jakość rozwiązania i czas oczekiwania.

allowLargeDeadlineDespiteInterruptionRisk

Parametr allowLargeDeadlineDespiteInterruptionRisk zwiększa maksymalny termin żądania do 3600 sekund. Jeśli ten parametr nie jest ustawiony, maksymalna wartość parametrów czasu oczekiwania i terminu wynosi 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): utrzymuje maksymalną wartość parametrów czasu oczekiwania i terminu na poziomie 1800 sekund.

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

searchMode

Parametr searchMode określa, jak optymalizator wyszukuje rozwiązania, co pozwala ustalić priorytet szybszej odpowiedzi (krótszy czas oczekiwania) lub rozwiązania wyższej jakości.

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

Dozwolone wartości parametru searchMode to:

• SEARCH_MODE_UNSPECIFIED (domyślnie): nieokreślony tryb wyszukiwania, odpowiednik RETURN_FAST.
• RETURN_FAST: zatrzymuje wyszukiwanie po znalezieniu pierwszego dobrego rozwiązania.
• CONSUME_ALL_AVAILABLE_TIME: wykorzystuje cały dostępny czas na wyszukiwanie lepszych rozwiązań. Jeśli interfejs API znajdzie optymalne rozwiązanie wcześniej, nie wykorzysta całego dostępnego czasu.

Włączanie pingów utrzymywania aktywności

Gdy wysyłasz żądania do punktów końcowych blokujących z czasem oczekiwania dłuższym niż 60 sekund, pingi utrzymywania aktywności pomagają zapobiegać utracie połączenia podczas oczekiwania na odpowiedź. Pingi utrzymywania aktywności 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 utrzymywanie aktywności na poziomie połączenia TCP.
• gRPC: skonfiguruj pingi utrzymywania aktywności na bazowym gnieździe TCP lub bezpośrednio w protokole gRPC.

W sekcjach poniżej opisujemy, jak skonfigurować pingi utrzymywania aktywności w obu protokołach.

Utrzymywanie aktywności w REST

Konfigurowanie pingów utrzymywania aktywności w przypadku 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 utrzymywania aktywności bezpośrednio w gnieździe TCP za pomocą opcji takich jak SO_KEEPALIVE. Aby to zrobić, użyj funkcji takich jak setsockopt() lub ich odpowiedników.

Ta funkcja hostowana na GitHubie pokazuje, jak prawidłowo skonfigurować tę opcję w przypadku 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 w gRPC

gRPC oferuje własny wbudowany mechanizm utrzymywania aktywności w ramach protokołu. Instrukcje dotyczące konfigurowania tej opcji w języku klienta znajdziesz w przewodniku po utrzymywaniu aktywności w 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 utrzymywania aktywności.

Przykładowe żądanie gRPC z utrzymywaniem aktywności

Poniższy przykład pokazuje, jak wysłać żądanie optimizeTours za pomocą biblioteki klienta Pythona i pingów utrzymywania aktywności 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)