Настройте тайм-ауты и крайние сроки.

В этом документе объясняется, как настроить параметры тайм-аута и крайнего срока для запросов API оптимизации маршрутизации. Отсутствие этих значений или их неправильная настройка могут привести к проблемам с качеством соединения или ответа.

Тайм-аут задается в теле запроса, а крайний срок — в заголовке запроса. API оптимизации маршрутизации обрабатывает запрос в течение времени, определенного этими параметрами, соблюдая кратчайшее значение времени.

Настройка тайм-аутов и крайних сроков позволяет управлять временем обработки следующими способами:

• Увеличьте время обработки:
  • Решать сложные задачи.
  • Получите ответ более высокого качества.
• Сократить время обработки:
  • Обрабатывайте запросы низкой сложности быстрее, чем по умолчанию.
  • Вы решаете запрос за меньшее время, но получаете ответ более низкого качества.

Примечание: Параметры тайм-аута и крайнего срока применяются только в том случае, если для solvingMode установлено значение по умолчанию DEFAULT_SOLVE . Другие параметры solvingMode , такие как VALIDATE_ONLY , DETECT_SOME_INFEASIBLE_SHIPMENTS или TRANSFORM_AND_RETURN_REQUEST обычно не требуют корректировки тайм-аута, поскольку они значительно быстрее.

Разберитесь в своих потребностях, связанных с тайм-аутом и крайним сроком.

Перед настройкой тайм-аутов и крайних сроков ознакомьтесь с этим разделом, чтобы убедиться, что вы понимаете, как выбор конечной точки и протокола влияет на эти параметры.

Следующие рекомендации помогут вам убедиться, что вы используете правильную конфигурацию для достижения поставленных целей.

• Для непрерывных и повторяющихся запросов, а также для сложных запросов, требующих более длительного времени решения, используйте неблокирующие конечные точки .
• Используйте блокирующие конечные точки для небольших запросов и быстрой доставки результатов, идя на компромисс в отношении качества.
• Используйте gRPC для повседневной работы, особенно в производственных приложениях.
• Используйте REST для тестирования, экспериментов или разовых запросов.

Нажмите на кнопку ниже, чтобы увидеть диаграмму, которая поможет вам определить, какие разделы этого документа наиболее актуальны для вашей системы.

Открыть диаграмму в отдельной вкладке open_in_new

Установите параметр timeout

Укажите значение параметра timeout в теле запроса, чтобы задать максимальное время, в течение которого сервер обрабатывает запрос до возврата ответа. Фактическое затраченное время может быть меньше отведенного, если API найдет оптимальное решение до достижения максимального отведенного времени.

Установите параметр timeout , используя буфер протокола длительности , который представляет собой длительность в секундах, варьирующуюся от 1 секунды до 1800 секунд. Увеличьте это значение до 3600 секунд, используя allowLargeDeadlineDespiteInterruptionRisk .

Рекомендуемые значения timeout

В таблице ниже приведены рекомендуемые значения timeout в зависимости от сложности запроса, количества отправок и транспортных средств.

Установите крайний срок

Установите крайний срок в заголовке запроса, чтобы определить максимальное время, которое API оптимизации маршрутизации тратит на обработку запроса. В следующих подразделах описано, как установить крайние сроки для запросов REST и gRPC.

REST-запросы

При использовании REST для вызова блокирующей конечной точки можно продлить время ожидания сверх установленного по умолчанию значения в 60 секунд, которое часто оказывается слишком коротким для сложных запросов. Это необходимо сделать, даже если вы уже указали более длительное время ожидания в теле запроса, поскольку значение по умолчанию переопределяет любые значения timeout , установленные в теле запроса и превышающие 60 секунд.

Увеличьте время ожидания сверх стандартных 60 секунд, установив заголовок запроса X-Server-Timeout . В отличие от тела запроса, значение заголовка — это количество секунд, но без суффикса «s». Максимальное значение, которое можно установить для этого заголовка, соответствует ограничениям параметра timeout .

Приведённый ниже пример кода демонстрирует HTTP-заголовок с X-Server-Timeout установленным на 1800 секунд.

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

Клиентские библиотеки и запросы gRPC

При использовании клиентских библиотек или gRPC устанавливать крайний срок не требуется. По умолчанию он составляет 3600 секунд, что соответствует максимальному времени выполнения запроса для этого API. Настроить время решения можно, просто задав свойство timeout в теле запроса.

Параметры, влияющие на тайм-ауты и крайние сроки.

На работу тайм-аутов и дедлайнов влияют следующие параметры:

• Управляйте максимальным сроком выполнения запроса с помощью allowLargeDeadlineDespiteInterruptionRisk .
• Определите поведение поиска, сбалансировав качество решения и задержку с помощью searchMode .

allowLargeDeadlineDespiteInterruptionRisk

Параметр allowLargeDeadlineDespiteInterruptionRisk увеличивает максимальный срок выполнения запроса до 3600 секунд. Если этот параметр не задан, максимальное значение для параметров timeout и deadline составляет 1800 секунд.

Установите allowLargeDeadline DespiteInterruptionRisk в true , чтобы увеличить значения параметров timeout и deadline до 3600 секунд.

Допустимые значения для allowLargeDeadline DespiteInterruptionRisk следующие:

• true : Увеличивает максимальное значение параметров тайм-аута и крайнего срока до 3600 секунд, учитывая при этом риск прерывания.
• false (по умолчанию): Сохраняет максимальное значение параметров тайм-аута и крайнего срока равным 1800 секундам.

Если вы считаете, что вам требуется тайм-аут более 3600 секунд, свяжитесь со своим представителем Google.

searchMode

Параметр searchMode управляет тем, как оптимизатор ищет решения, позволяя отдавать приоритет либо более быстрому отклику (меньшей задержке), либо более качественному решению.

Когда вы отдаете приоритет более высокому качеству решения, оптимизатору требуется довольно много времени для поиска высококачественного решения. Для таких длительных запросов рекомендуется установить более длительный тайм-аут и использовать неблокирующие конечные точки, чтобы избежать проблем с подключением.

Допустимые значения для searchMode следующие:

• SEARCH_MODE_UNSPECIFIED (по умолчанию): Неуказанный режим поиска, эквивалентный RETURN_FAST .
• RETURN_FAST : Останавливает поиск после нахождения первого подходящего решения.
• CONSUME_ALL_AVAILABLE_TIME : Тратит все доступное время на поиск лучших решений. API не использует все доступное время, если находит оптимальное решение на ранней стадии.

Включить пинги поддержания соединения

При отправке запросов к блокирующим конечным точкам с таймаутом более 60 секунд, пинги поддержания соединения помогают предотвратить потерю соединения во время ожидания ответа. Пинги поддержания соединения — это небольшие пакеты, отправляемые для поддержания активности соединения, а также для обнаружения и предотвращения потери соединения.

Настройте эти параметры в соответствии с используемым вами протоколом API:

• REST: Настройте механизм keepalive на уровне TCP-соединения.
• gRPC: Настройка запросов keepalive на базовом TCP-сокете или непосредственно в протоколе gRPC.

В следующих разделах объясняется, как настроить пинги keepalive для обоих протоколов.

REST keepalive

Настройка пингов keepalive при использовании REST зависит от используемой вами библиотеки HTTP-клиента. Клиентские библиотеки и инструменты, такие как curl , могут предоставлять определенные параметры конфигурации или включать пинги автоматически.

Если ваша библиотека предоставляет доступ к базовому TCP-сокету, вы можете настроить пинги keepalive непосредственно на TCP-сокете, используя такие параметры, как SO_KEEPALIVE . Для этого используйте функции, например, setsockopt() или их аналоги.

Эта функция, размещенная на GitHub, демонстрирует, как правильно настроить встроенный HTTP-клиент Python.

Более подробную информацию о механизме поддержания соединения на уровне TCP можно найти в обзоре механизма поддержания соединения TLDP или в документации вашей библиотеки HTTP-клиента.

gRPC keepalive

gRPC предлагает собственный встроенный механизм поддержания соединения (keepalive) в рамках протокола. Инструкции по настройке этого механизма в языке вашего клиента см. в руководстве по механизму поддержания соединения gRPC.

Примечание: gRPC-серверы могут отклонять запросы клиентов, отправляющих слишком много пингов. Избегайте установки слишком высокой частоты отправки пингов для поддержания соединения.

Пример запроса gRPC с использованием keepalive

В следующем примере показано, как выполнить запрос optimizeTours , используя клиентскую библиотеку Python и пинги keepalive на уровне 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)