Zeitüberschreitungen und Fristen

In diesem Dokument wird beschrieben, wie Sie Zeitlimit- und Deadline-Einstellungen für Route Optimization API-Anfragen konfigurieren. Wenn Sie diese Werte nicht oder falsch festlegen, kann es zu Problemen mit der Verbindung oder der Qualität der Antworten kommen.

Sie definieren das Zeitlimit im Anfragetext und die Frist im Anfrageheader. Die Route Optimization API verarbeitet die Anfrage innerhalb des Zeitlimits, das durch diese Parameter definiert wird, wobei der kürzeste Zeitwert berücksichtigt wird.

Durch das Konfigurieren von Zeitüberschreitungen und Fristen können Sie die Verarbeitungszeit auf folgende Weise verwalten:

  • Verarbeitungszeit verlängern:
    • Anfragen mit hoher Komplexität beantworten
    • Sie erhalten eine Antwort von höherer Qualität.
  • Verarbeitungszeit verkürzen:
    • Anfragen mit geringer Komplexität schneller als standardmäßig beantworten.
    • Eine Anfrage in kürzerer Zeit bearbeiten, aber eine Antwort von geringerer Qualität erhalten.

Hinweis:Die Parameter für Zeitüberschreitung und Frist gelten nur, wenn solvingMode auf den Standardwert DEFAULT_SOLVE festgelegt ist. Für andere solvingMode-Optionen wie VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS oder TRANSFORM_AND_RETURN_REQUEST sind in der Regel keine Timeout-Anpassungen erforderlich, da sie deutlich schneller sind.

Timeout- und Fristanforderungen verstehen

Lesen Sie sich diesen Abschnitt durch, bevor Sie Ihre Zeitüberschreitungen und Fristen konfigurieren, um zu verstehen, wie sich Ihre Endpunkt- und Protokollauswahl auf diese Einstellungen auswirkt.

Anhand der folgenden Richtlinien können Sie prüfen, ob Sie die richtige Einrichtung für Ihre Zielvorhaben verwenden.

  • Verwenden Sie nicht blockierende Endpunkte für kontinuierliche und wiederholte Anfragen sowie für komplexe Anfragen, die von längeren Lösungszeiten profitieren.
  • Verwenden Sie blockierende Endpunkte für kleine Anfragen und die schnelle Bereitstellung von Ergebnissen, wobei Sie einen Qualitätskompromiss eingehen.
  • Verwenden Sie gRPC für Ihren täglichen Workflow, insbesondere für Produktionsanwendungen.
  • Verwenden Sie REST für Tests, Experimente oder einmalige Anfragen.

Klicken Sie auf die Schaltfläche unten, um ein Diagramm aufzurufen, das Ihnen hilft, die für Ihre Einrichtung relevantesten Abschnitte dieses Dokuments zu ermitteln.

Diagramm in separatem Tab öffnen

Parameter timeout festlegen

Legen Sie den Wert für den Parameter timeout im Anfragetext fest, um die maximale Zeit anzugeben, die der Server für die Bearbeitung einer Anfrage benötigt, bevor er eine Antwort zurückgibt. Die tatsächlich benötigte Zeit kann kürzer sein als die zugewiesene Zeit, wenn die API eine optimale Lösung findet, bevor die maximal zugewiesene Zeit erreicht ist.

Legen Sie den Parameter timeout mit dem duration protocol buffer fest. Das ist eine Dauer in Sekunden, die zwischen 1 und 1.800 Sekunden liegen kann. Sie können diesen Wert mit allowLargeDeadlineDespiteInterruptionRisk auf bis zu 3.600 Sekunden erhöhen.

In der folgenden Tabelle sind die empfohlenen timeout-Werte basierend auf der Komplexität der Anfrage und der Anzahl der Sendungen und Fahrzeuge aufgeführt.

Anzahl der Sendungen und Fahrzeuge Keine Einschränkungen Großzügige Zeitfenster und Ladebeschränkungen oder lange Routen Enge Zeitfenster, Ladungsbeschränkungen, komplexe Einschränkungen oder sehr lange Routen
1–8 2s 2s 5 s
9–32 5 s 10 s 20 s
33–100 15 s 30 s 60s
101–1.000 45 s 90er 180s
1.001–10.000 120 Sekunden 360s 900er
10.001 oder mehr 60 Sekunden + 120 Sekunden pro 10.000 Sendungen 360 pro 10.000 Sendungen 900 Sekunden pro 10.000 Sendungen

Frist festlegen

Legen Sie die Frist im Anfrageheader fest, um die maximale Zeit zu definieren, die die Route Optimization API für die Verarbeitung einer Anfrage benötigt. In den folgenden Unterabschnitten wird beschrieben, wie Sie Fristen für REST- und gRPC-Anfragen festlegen.

REST-Anfragen

Wenn Sie mit REST einen blockierenden Endpunkt aufrufen, können Sie die Frist über den Standardwert von 60 Sekunden hinaus verlängern. Dieser Wert ist oft zu kurz für komplexe Anfragen. Das müssen Sie auch dann tun, wenn Sie im Anfragetext bereits ein längeres Zeitlimit angegeben haben, da das Standardzeitlimit alle timeout-Werte im Anfragetext überschreibt, die größer als 60 Sekunden sind.

Sie können die Frist über die standardmäßigen 60 Sekunden hinaus verlängern, indem Sie den Anfrageheader X-Server-Timeout festlegen. Im Gegensatz zum Anfragetext ist der Wert des Headers die Anzahl der Sekunden, aber ohne das Suffix „s“. Der maximale Wert, den Sie für diesen Header festlegen können, entspricht den Einschränkungen des Parameters timeout.

Das folgende Codebeispiel zeigt einen HTTP-Header, in dem X-Server-Timeout auf 1.800 Sekunden festgelegt ist.

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

Clientbibliotheken und gRPC-Anfragen

Wenn Sie Clientbibliotheken oder gRPC verwenden, müssen Sie keine Frist konfigurieren. Die Standardfrist bei der Verwendung beträgt 3.600 Sekunden, die maximale Anfragezeit für diese API. Sie können die Lösungszeit konfigurieren, indem Sie nur das Attribut „timeout“ im Anfragetext festlegen.

Parameter, die sich auf Zeitüberschreitungen und Fristen auswirken

Die folgenden Parameter wirken sich auf die Funktionsweise von Zeitlimits und Fristen aus:

  • Mit allowLargeDeadlineDespiteInterruptionRisk können Sie die maximale Frist für Anfragen festlegen.
  • Mit searchMode können Sie das Verhalten der Suche definieren und dabei die Latenz gegen die Qualität der Lösung abwägen.

allowLargeDeadlineDespiteInterruptionRisk

Mit dem Parameter allowLargeDeadlineDespiteInterruptionRisk wird die maximale Frist für Anfragen auf 3.600 Sekunden erhöht. Wenn dieser Parameter nicht festgelegt ist, beträgt der Höchstwert für die Parameter „timeout“ und „deadline“ 1.800 Sekunden.

Legen Sie allowLargeDeadline DespiteInterruptionRisk auf true fest, um den Wert der Parameter „timeout“ und „deadline“ auf bis zu 3.600 Sekunden zu erhöhen.

Die zulässigen Werte für allowLargeDeadline DespiteInterruptionRisk sind:

  • true: Erhöht den Maximalwert für Zeitlimit- und Deadline-Parameter auf 3.600 Sekunden, wobei das Unterbrechungsrisiko berücksichtigt wird.
  • false (Standard): Der maximale Wert für die Parameter „timeout“ und „deadline“ bleibt bei 1.800 Sekunden.

Wenn Sie der Meinung sind, dass Sie ein Zeitlimit von mehr als 3.600 Sekunden benötigen, wenden Sie sich an Ihren Google-Ansprechpartner.

searchMode

Mit dem Parameter searchMode wird gesteuert, wie der Optimierer nach Lösungen sucht. So können Sie entweder eine schnellere Antwort (geringere Latenz) oder eine Lösung mit höherer Qualität priorisieren.

Wenn Sie eine höhere Lösungsqualität priorisieren, benötigt der Optimierer eine angemessene Zeit, um eine hochwertige Lösung zu finden. Für diese längeren Anfragen sollten Sie ein längeres Zeitlimit festlegen und nicht blockierende Endpunkte verwenden, um Verbindungsprobleme zu vermeiden.

Die zulässigen Werte für searchMode sind:

  • SEARCH_MODE_UNSPECIFIED (Standard): Ein nicht angegebener Suchmodus, der RETURN_FAST entspricht.
  • RETURN_FAST: Die Suche wird beendet, nachdem die erste gute Lösung gefunden wurde.
  • CONSUME_ALL_AVAILABLE_TIME: Verwendet die gesamte verfügbare Zeit, um nach besseren Lösungen zu suchen. Die API nutzt nicht die gesamte verfügbare Zeit, wenn sie frühzeitig eine optimale Lösung findet.

Keep-Alive-Pings aktivieren

Wenn Sie Anfragen an blockierende Endpunkte mit einem Zeitlimit von mehr als 60 Sekunden senden, helfen Keepalive-Pings, Verbindungsverluste zu vermeiden, während Sie auf eine Antwort warten. Keep-Alive-Pings sind kleine Pakete, die gesendet werden, um die Verbindungsaktivität aufrechtzuerhalten und Verbindungsverluste zu erkennen und zu verhindern.

Konfigurieren Sie diese Parameter basierend auf dem verwendeten API-Protokoll:

  • REST:Konfigurieren Sie Keepalive auf der Ebene der TCP-Verbindung.
  • gRPC:Konfigurieren Sie Keep-Alive-Pings für den zugrunde liegenden TCP-Socket oder direkt im gRPC-Protokoll.

In den folgenden Abschnitten wird beschrieben, wie Sie Keep-Alive-Pings für beide Protokolle einrichten.

REST-Keepalive

Die Konfiguration von Keep-Alive-Pings bei Verwendung von REST hängt von Ihrer HTTP-Clientbibliothek ab. Clientbibliotheken und Tools wie curl bieten möglicherweise spezifische Konfigurationsoptionen oder aktivieren Pings automatisch.

Wenn Ihre Bibliothek den zugrunde liegenden TCP-Socket verfügbar macht, können Sie Keep-Alive-Pings direkt auf dem TCP-Socket mit Optionen wie SO_KEEPALIVE konfigurieren. Verwenden Sie dazu Funktionen wie setsockopt() oder das Äquivalent.

Diese auf GitHub gehostete Funktion zeigt, wie Sie dies für den integrierten HTTP-Client von Python richtig einrichten.

Weitere Informationen zu TCP-Level-Keepalive finden Sie in der Übersicht zu TLDP-Keepalive oder in der Dokumentation Ihrer HTTP-Clientbibliothek.

gRPC-Keepalive

gRPC bietet einen eigenen integrierten Keep-Alive-Mechanismus als Teil des Protokolls. Eine Anleitung zum Einrichten in Ihrer Clientsprache finden Sie im gRPC-Keep-Alive-Leitfaden.

Hinweis:gRPC-Server lehnen möglicherweise Clients ab, die zu viele Pings senden. Vermeiden Sie es, die Häufigkeit von Keep-Alive-Pings zu hoch einzustellen.

gRPC-Beispielanfrage mit Keep-Alive

Das folgende Beispiel zeigt, wie Sie eine optimizeTours-Anfrage mit der Python-Clientbibliothek und Keep-Alive-Pings auf gRPC-Ebene stellen.

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)