Configura tiempos de espera y plazos

En este documento, se explica cómo configurar los parámetros de configuración de tiempo de espera y plazo para las solicitudes a la API de Route Optimization. Si no estableces estos valores o lo haces de forma incorrecta, se pueden generar problemas de conexión o de calidad de respuesta.

Defines el tiempo de espera en el cuerpo de la solicitud y el plazo en el encabezado de la solicitud. La API de Route Optimization procesa la solicitud dentro del límite de tiempo definido por estos parámetros, respetando el valor de tiempo más corto.

Configurar los tiempos de espera y los plazos te permite administrar el tiempo de procesamiento de las siguientes maneras:

• Aumentar el tiempo de procesamiento:
  • Resuelve solicitudes de alta complejidad.
  • Obtén una respuesta de mayor calidad.
• Disminuir el tiempo de procesamiento:
  • Resuelve solicitudes de baja complejidad más rápido que el valor predeterminado.
  • Resuelve una solicitud en menos tiempo, pero obtén una respuesta de menor calidad.

Nota: Los parámetros de tiempo de espera y plazo solo se aplican cuando solvingMode se establece en su valor predeterminado de DEFAULT_SOLVE. Otras opciones de solvingMode, como VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS o TRANSFORM_AND_RETURN_REQUEST, por lo general, no requieren ajustes de tiempo de espera porque son mucho más rápidas.

Comprende tus necesidades de tiempo de espera y plazo

Revisa esta sección antes de configurar tus tiempos de espera y plazos para verificar que comprendes cómo afectan estas opciones a tu extremo y protocolo.

Los siguientes lineamientos pueden ayudarte a confirmar si usas la configuración correcta para tus objetivos.

• Usa extremos sin bloqueo para solicitudes continuas y repetidas, y para solicitudes complejas que se benefician de tiempos de resolución más largos.
• Usa extremos de bloqueo para solicitudes pequeñas y entrega rápida de resultados, y acepta una compensación de calidad.
• Usa gRPC para tu flujo de trabajo diario, en especial para las aplicaciones de producción.
• Usa REST para pruebas, experimentos o solicitudes únicas.

Haz clic en el botón que aparece a continuación para ver un diagrama que puede ayudarte a determinar qué secciones de este documento son más relevantes para tu configuración.

Abrir diagrama en una pestaña separadaopen_in_new

Establece el parámetro timeout

Establece el valor del parámetro timeout en el cuerpo de la solicitud para especificar el tiempo máximo que el servidor trabaja en una solicitud antes de mostrar una respuesta. El tiempo real que se dedica puede ser más corto que el tiempo asignado si la API encuentra una solución óptima antes de alcanzar el tiempo máximo asignado.

Establece el timeout parámetro con el búfer de protocolo de duración, que es una duración en segundos que puede oscilar entre 1 y 1,800 segundos. Aumenta este valor hasta 3,600 segundos con allowLargeDeadlineDespiteInterruptionRisk.

Valores timeout recomendados

En la siguiente tabla, se enumeran los valores timeout recomendados según la complejidad de la solicitud y la cantidad de envíos y vehículos.

Establece el plazo

Establece el plazo en el encabezado de la solicitud para definir el tiempo máximo que la API de Route Optimization dedica a procesar una solicitud. En las siguientes subsecciones, se describe cómo establecer plazos para solicitudes de REST y gRPC.

Solicitudes de REST

Cuando usas REST para llamar a un extremo de bloqueo, puedes extender el plazo más allá del valor predeterminado de 60 segundos, que suele ser demasiado corto para solicitudes complejas. Debes hacerlo incluso si ya especificaste un plazo más largo en el cuerpo de la solicitud, ya que el plazo predeterminado anula cualquier valor timeout establecido en el cuerpo de la solicitud que sea superior a 60 segundos.

Para extender el plazo más allá de los 60 segundos predeterminados, establece el encabezado de la solicitud X-Server-Timeout. A diferencia del cuerpo de la solicitud, el valor del encabezado es la cantidad de segundos, pero sin el sufijo "s". El valor máximo que puedes establecer para este encabezado se alinea con las timeout restricciones del parámetro's.

En el siguiente ejemplo de código, se muestra un encabezado HTTP con X-Server-Timeout establecido en 1,800 segundos.

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

Bibliotecas cliente y solicitudes de gRPC

No es necesario configurar un plazo cuando se usan bibliotecas cliente o gRPC. El plazo predeterminado cuando se usan es de 3,600 segundos, el tiempo máximo de solicitud para esta API. Para configurar el tiempo de resolución, solo debes establecer la propiedad de tiempo de espera en el cuerpo de la solicitud.

Parámetros que afectan los tiempos de espera y los plazos

Los siguientes parámetros afectan el funcionamiento de los tiempos de espera y los plazos:

• Controla el plazo máximo de la solicitud con allowLargeDeadlineDespiteInterruptionRisk.
• Define el comportamiento de la búsqueda y equilibra la calidad de la solución con la latencia con searchMode.

allowLargeDeadlineDespiteInterruptionRisk

El parámetro allowLargeDeadlineDespiteInterruptionRisk aumenta el plazo máximo de la solicitud a 3,600 segundos. Si no se establece este parámetro, el valor máximo para los parámetros de tiempo de espera y plazo es de 1,800 segundos.

Establece allowLargeDeadline DespiteInterruptionRisk en true para aumentar el valor de los parámetros de tiempo de espera y plazo hasta 3,600 segundos.

Los valores permitidos para allowLargeDeadline DespiteInterruptionRisk son los siguientes:

• true: Aumenta el valor máximo para los parámetros de tiempo de espera y plazo a 3,600 segundos y reconoce el riesgo de interrupción.
• false (predeterminado): Mantiene el valor máximo para los parámetros de tiempo de espera y plazo de 1,800 segundos.

Si crees que necesitas un tiempo de espera superior a 3,600 segundos, comunícate con tu representante de Google.

searchMode

El parámetro searchMode controla la forma en que el optimizador busca soluciones, lo que te permite priorizar una respuesta más rápida (menor latencia) o una solución de mayor calidad.

Cuando priorizas una mayor calidad de la solución, el optimizador tarda una cantidad razonable de tiempo en encontrar una solución de alta calidad. Para estas solicitudes más largas, considera establecer un tiempo de espera más largo y usar extremos sin bloqueo para evitar problemas de conexión.

Los valores permitidos para searchMode son los siguientes:

• SEARCH_MODE_UNSPECIFIED (predeterminado): Un modo de búsqueda no especificado, equivalente a RETURN_FAST.
• RETURN_FAST: Detiene la búsqueda después de encontrar la primera solución adecuada.
• CONSUME_ALL_AVAILABLE_TIME: Dedica todo el tiempo disponible a buscar mejores soluciones. La API no usa todo el tiempo disponible si encuentra una solución óptima antes.

Habilita los pings de keepalive

Cuando realizas solicitudes a extremos de bloqueo con un tiempo de espera superior a 60 segundos, los pings de keepalive ayudan a evitar la pérdida de conexión mientras esperas una respuesta. Los pings de keepalive son paquetes pequeños que se envían para mantener la actividad de conexión y detectar y evitar la pérdida de conexión.

Configura estos parámetros según el protocolo de API que uses:

• REST: Configura keepalive en el nivel de conexión TCP.
• gRPC: Configura los pings de keepalive en el socket TCP subyacente o directamente en el protocolo gRPC.

En las siguientes secciones, se explica cómo configurar los pings de keepalive para ambos protocolos.

Keepalive de REST

La configuración de los pings de keepalive cuando usas REST depende de tu biblioteca cliente de HTTP. Las bibliotecas cliente y las herramientas, como curl, pueden proporcionar opciones de configuración específicas o habilitar los pings automáticamente.

Si tu biblioteca expone el socket TCP subyacente, puedes configurar los pings de keepalive directamente en el socket TCP con opciones como SO_KEEPALIVE. Para ello, usa funciones como setsockopt() o su equivalente.

Esta función alojada en GitHub muestra cómo configurar esto correctamente para el cliente HTTP integrado de Python.

Obtén más detalles sobre keepalive a nivel de TCP en la descripción general de TLDP keepalive o en la documentación de tu biblioteca cliente de HTTP.

Keepalive de gRPC

gRPC ofrece su propio mecanismo de keepalive integrado como parte del protocolo. Consulta la guía de keepalive de gRPC para obtener instrucciones sobre cómo configurar esto en el lenguaje de tu cliente.

Nota: Es posible que los servidores gRPC rechacen a los clientes que envían demasiados pings. Evita establecer la frecuencia de ping de keepalive demasiado alta.

Solicitud de muestra de gRPC con keepalive

En el siguiente ejemplo, se muestra cómo realizar una solicitud optimizeTours con la biblioteca cliente de Python y los pings de keepalive a nivel de 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)