Tiempos de espera y plazos

En este documento, se explica cómo configurar los parámetros de configuración de tiempo de espera y fecha límite para las solicitudes a la API de Route Optimization. No establecer estos valores o hacerlo de forma incorrecta puede causar problemas de conexión o de calidad de la respuesta.

El tiempo de espera se define en el cuerpo de la solicitud y la fecha límite 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 tiempos de espera y plazos te permite administrar el tiempo de procesamiento de las siguientes maneras:

• Aumenta el tiempo de procesamiento:
  • Resolver solicitudes de alta complejidad
  • Obtener una respuesta de mayor calidad
• Disminuye el tiempo de procesamiento:
  • Resuelve solicitudes de baja complejidad más rápido que la configuración predeterminada.
  • Resolver una solicitud en menos tiempo, pero obtener una respuesta de menor calidad

Nota: Los parámetros de tiempo de espera y fecha límite 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 fecha límite

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

Los siguientes lineamientos pueden ayudarte a confirmar si estás usando la configuración adecuada para tus objetivos.

• Usa extremos no bloqueantes 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 en la 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 te ayudará a determinar qué secciones de este documento son más relevantes para tu configuración.

Abrir el diagrama en una pestaña separada

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 devolver una respuesta. El tiempo real empleado puede ser menor que el tiempo asignado si la API encuentra una solución óptima antes de alcanzar el tiempo máximo asignado.

Establece el parámetro timeout 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 de timeout recomendados

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

Cantidad de envíos y vehículos	Sin restricciones	Intervalos de tiempo y restricciones de carga flexibles, o rutas largas	Ventanas de tiempo ajustadas, restricciones de carga, restricciones complejas o rutas muy largas
1 - 8	2 s	2 s	5 s
9 - 32	5 s	10 s	20 s
33 a 100	15 s	30 s	60 s
De 101 a 1,000	45 s	años 90	180
1,001 a 10,000	120 s	360s	900
10,001 o más	60 s + 120 s por cada 10,000 envíos	360s por cada 10,000 envíos	900s por cada 10,000 envíos

Establece la fecha límite

Configura la fecha límite 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 las 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 de timeout establecido en el cuerpo de la solicitud que sea superior a 60 segundos.

Extiende el plazo más allá de los 60 segundos predeterminados configurando el encabezado de 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 restricciones del parámetro timeout.

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 una fecha límite 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. Configura el tiempo de resolución estableciendo solo 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 configura este parámetro, el valor máximo para los parámetros de tiempo de espera y fecha límite es de 1,800 segundos.

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

Nota: Si configuras allowLargeDeadline DespiteInterruptionRisk en true, se reconoce que las solicitudes más largas conllevan un mayor riesgo de interrupción, lo que puede generar un error en lugar de un resultado válido.

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, al mismo tiempo que reconoce el riesgo de interrupción.
• false (predeterminado): Mantiene el valor máximo para los parámetros de tiempo de espera y fecha límite 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 considerable 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 no bloqueantes para evitar problemas de conexión.

Los valores permitidos para searchMode son los siguientes:

• SEARCH_MODE_UNSPECIFIED (predeterminado): Es 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 Keep-Alive

Cuando realizas solicitudes a extremos de bloqueo con un tiempo de espera superior a 60 segundos, los pings 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 la 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 a nivel de la 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 Keep-Alive 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 pings automáticamente.

Si tu biblioteca expone el socket TCP subyacente, puedes configurar 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.

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

Keepalive de gRPC

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

Nota: Es posible que los servidores de gRPC rechacen a los clientes que envían demasiados pings. Evita establecer una frecuencia demasiado alta para los pings de Keep-Alive.

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 actividad 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)