Zeitlimits und Fristen konfigurieren

In diesem Dokument wird erläutert, wie Sie die Einstellungen für Zeitlimit und Frist für Anfragen an die Route Optimization API konfigurieren. Wenn Sie diese Werte nicht festlegen oder falsch festlegen, kann dies zu Problemen mit der Verbindung oder der 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 festgelegten Zeitlimits, wobei der kürzere Zeitwert berücksichtigt wird.

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

• Verarbeitungszeit verlängern:
  • Anfragen mit hoher Komplexität lösen.
  • Eine Antwort mit höherer Qualität erhalten.
• Verarbeitungszeit verkürzen:
  • Anfragen mit geringer Komplexität schneller als mit der Standardeinstellung lösen.
  • Eine Anfrage in kürzerer Zeit lösen, aber eine Antwort mit geringerer Qualität erhalten.

Hinweis: Die Parameter für Zeitlimit 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 Anpassungen des Zeitlimits erforderlich, da sie deutlich schneller sind.

Anforderungen an Zeitlimit und Frist verstehen

Lesen Sie diesen Abschnitt, bevor Sie Ihre Zeitlimits und Fristen konfigurieren, um zu prüfen, ob Sie verstanden haben, wie sich Ihre Endpunkt- und Protokollauswahl auf diese Einstellungen auswirkt.

Die folgenden Richtlinien können Ihnen helfen, zu prüfen, ob Sie die richtige Einrichtung für Ihre Ziele 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 eine geringere Qualität in Kauf nehmen.
• 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 ermitteln können, welche Abschnitte dieses Dokuments für Ihre Einrichtung am relevantesten sind.

Diagramm in separatem Tab öffnenopen_in_new

Parameter timeout festlegen

Legen Sie im Anfragetext den Wert für den timeout Parameter 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ächliche Zeit kann kürzer als die zugewiesene Zeit sein, wenn die API eine optimale Lösung findet, bevor die maximal zugewiesene Zeit erreicht ist.

Legen Sie den timeout Parameter mit dem Protocol Buffer für die Dauer fest, das ist eine Dauer in Sekunden, die zwischen 1 und 1.800 Sekunden liegen kann. Mit allowLargeDeadlineDespiteInterruptionRisk können Sie diesen Wert auf bis zu 3.600 Sekunden erhöhen.

Empfohlene timeout-Werte

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

Frist festlegen

Legen Sie im Anfrageheader die Frist 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 REST verwenden, um einen blockierenden Endpunkt aufzurufen, können Sie die Frist über die Standardeinstellung von 60 Sekunden hinaus verlängern. Diese ist oft zu kurz für komplexe Anfragen. Sie müssen dies auch dann tun, wenn Sie im Anfragetext bereits eine längere Frist angegeben haben, da die Standardfrist alle timeout-Werte überschreibt, die im Anfragetext festgelegt wurden und länger als 60 Sekunden sind.

Verlängern Sie die Frist über die Standardeinstellung von 60 Sekunden hinaus, indem Sie den Anfrageheader X-Server-Timeout festlegen. Anders als im 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, 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 beträgt 3.600 Sekunden, die maximale Anfragezeit für diese API. Konfigurieren Sie die Lösungszeit, indem Sie nur die Eigenschaft für das Zeitlimit im Anfragetext festlegen.

Parameter, die sich auf Zeitlimits 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 steuern.
• Mit searchMode können Sie das Verhalten der Suche definieren und die Qualität der Lösung gegen die Latenz abwägen.

allowLargeDeadlineDespiteInterruptionRisk

Der allowLargeDeadlineDespiteInterruptionRisk Parameter erhöht die maximale Frist für Anfragen auf 3.600 Sekunden. Wenn dieser Parameter nicht festgelegt ist, beträgt der Maximalwert für die Parameter für Zeitlimit und Frist 1.800 Sekunden.

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

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

• true: Erhöht den Maximalwert für die Parameter für Zeitlimit und Frist auf 3.600 Sekunden, wobei das Risiko für Unterbrechungen berücksichtigt wird.
• false (Standard): Behält den Maximalwert für die Parameter für Zeitlimit und Frist von 1.800 Sekunden bei.

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

searchMode

Mit dem searchMode Parameter wird gesteuert, wie der Optimizer 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 Optimizer 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: 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 Sie mit Keepalive-Pings Verbindungsverluste vermeiden, 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 verwendeten API-Protokoll:

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

In den folgenden Abschnitten wird erläutert, 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 ähnliche.

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

Weitere Informationen zu Keepalive auf TCP-Ebene finden Sie in der TLDP-Übersicht zu Keepalive 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-Leitfaden zu Keepalive.

Hinweis:gRPC-Server lehnen möglicherweise Clients ab, die zu viele Pings senden. Legen Sie die Häufigkeit von Keepalive-Pings nicht zu hoch fest.

gRPC-Beispielanfrage mit Keepalive

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

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)