Zeitlimits und Fristen konfigurieren

In diesem Dokument wird erläutert, wie Sie Zeitlimit- und Fristeinstellungen für Route Optimization API-Anfragen konfigurieren. Wenn Sie diese Werte nicht oder falsch festlegen, kann dies zu Problemen mit der Verbindungs- oder Antwortqualität führen.

Sie definieren das Zeitlimit im Anfragetext und die Frist im Anfrageheader. Die Route Optimization API verarbeitet die Anfrage innerhalb des durch diese Parameter definierten Zeitlimits und berücksichtigt dabei den kürzesten Zeitwert.

Durch das Konfigurieren von Zeitlimits und Fristen können Sie die Verarbeitungszeit so verwalten:

• Verarbeitungszeit erhöhen:
  • Anfragen mit hoher Komplexität lösen
  • Eine Antwort von höherer Qualität erhalten.
• Verarbeitungszeit verkürzen:
  • Anfragen mit geringer Komplexität schneller als standardmäßig lösen.
  • Eine Anfrage schneller lösen, 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. Andere solvingMode-Optionen wie VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS oder TRANSFORM_AND_RETURN_REQUEST erfordern in der Regel keine Zeitüberschreitungsanpassungen, da sie deutlich schneller sind.

Anforderungen an Zeitüberschreitungen und Fristen verstehen

Lesen Sie diesen Abschnitt, bevor Sie Zeitlimits und Fristen konfigurieren, um sicherzustellen, dass Sie verstehen, wie sich die Auswahl von Endpunkt und Protokoll 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 eine schnelle Bereitstellung von Ergebnissen, wobei Sie einen Qualitätskompromiss akzeptieren.
• 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, mit dem Sie feststellen können, welche Abschnitte dieses Dokuments für Ihre Einrichtung am relevantesten sind.

Diagramm in separatem Tab öffnen

Legen Sie den Parameter timeout fest.

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 Dauer-Protokollzwischenspeicher fest. Dies ist eine Dauer in Sekunden, die zwischen 1 Sekunde und 1.800 Sekunden liegen kann. Erhöhen Sie diesen Wert mit allowLargeDeadlineDespiteInterruptionRisk auf bis zu 3.600 Sekunden.

Empfohlene timeout-Werte

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 Beladungseinschränkungen oder lange Routen	Knappe Zeitfenster, Lastbeschränkungen, komplexe Einschränkungen oder sehr lange Routen
1–8	2 s	2 s	5 s
9–32	5 s	10 s	20 s
33–100	15 s	30 s	60s
101–1.000	45 s	90er	180 Sek.
1.001–10.000	120 Sek.	360er	900er
10.001 oder mehr	60 Sek. + 120 Sek. pro 10.000 Sendungen	360er-Packungen 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 aufwendet. In den folgenden Unterabschnitten wird beschrieben, wie Sie Fristen für REST- und gRPC-Anfragen festlegen.

REST-Anfragen

Wenn Sie REST verwenden, um einen blockierenden Endpunkt aufzurufen, können Sie die Frist über den Standardwert von 60 Sekunden hinaus verlängern. Dieser ist für komplexe Anfragen oft zu kurz. Das müssen Sie auch dann tun, wenn Sie im Anfragetext bereits eine längere Frist angegeben haben, da die Standardfrist alle im Anfragetext festgelegten timeout-Werte überschreibt, die länger 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, jedoch 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, bei 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. Konfigurieren Sie die Lösungszeit, indem Sie im Anfragetext nur das Attribut „timeout“ 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 Anfragefrist festlegen.
• Definieren Sie das Verhalten der Suche und wägen Sie mit searchMode die Lösungsqualität gegen die Latenz ab.

allowLargeDeadlineDespiteInterruptionRisk

Mit dem Parameter allowLargeDeadlineDespiteInterruptionRisk wird die maximale Anfragefrist 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.

Setzen Sie allowLargeDeadline DespiteInterruptionRisk auf true, um den Wert der Parameter für Zeitlimit und Frist auf bis zu 3.600 Sekunden zu erhöhen.

Hinweis: Wenn Sie allowLargeDeadline DespiteInterruptionRisk auf true setzen, bestätigen Sie, dass längere Anfragen ein höheres Risiko für Unterbrechungen bergen, was zu einem Fehler anstelle eines gültigen Ergebnisses führen kann.

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

• true: Erhöht den Höchstwert für die Parameter „timeout“ und „deadline“ auf 3.600 Sekunden und bestätigt das Risiko einer Unterbrechung.
• false (Standard): Behält den Höchstwert für die Parameter „timeout“ und „deadline“ von 1.800 Sekunden bei.

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

Der Parameter searchMode steuert, wie der Optimierer nach Lösungen sucht. Sie können 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 gewisse Zeit, um eine qualitativ 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, entspricht RETURN_FAST.
• RETURN_FAST: Beendet die Suche, 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 verwendet nicht die gesamte verfügbare Zeit, wenn sie frühzeitig eine optimale Lösung findet.

Keepalive-Pings aktivieren

Wenn Sie Anfragen an blockierende Endpunkte mit einem Zeitlimit von mehr als 60 Sekunden senden, können Keepalive-Pings dazu beitragen, dass die Verbindung nicht unterbrochen wird, während Sie auf eine Antwort warten. Keepalive-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 von Ihnen verwendeten API-Protokoll:

• REST: Konfigurieren Sie Keepalive auf der TCP-Verbindungsebene.
• gRPC: Konfigurieren Sie Keepalive-Pings auf dem zugrunde liegenden TCP-Socket oder direkt im gRPC-Protokoll.

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

REST-Keepalive

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

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

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

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

gRPC-Keepalive

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

Hinweis: gRPC-Server können Clients ablehnen, die zu viele Pings senden. Vermeiden Sie es, die Keepalive-Ping-Frequenz zu hoch einzustellen.

gRPC-Beispielanfrage mit Keepalive

Im folgenden Beispiel wird gezeigt, wie Sie eine optimizeTours-Anfrage mit der Python-Clientbibliothek und gRPC-Keepalive-Pings 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)