Как исправить тайм-ауты aws лямбда при синхронных вызовах с помощью C ++ SDK? - PullRequest
Новая
       38

Как исправить тайм-ауты aws лямбда при синхронных вызовах с помощью C ++ SDK?

0 голосов
/ 13 июля 2020

Когда я вызываю свою лямбда-функцию, ее выполнение занимает от 1 до 15 секунд. Если я вызываю функцию через C ++ SKD, я получаю таймауты. Кажется, что эти таймауты происходят через несколько секунд (это только человеческое суждение, на самом деле я не измерял время).

Вопрос: Как мне сказать SDK ждать медленных лямбда-выражений чтобы вернуться, а не по таймауту?

Что не сработало:

В SDK JS вы можете изменить это в настройках HTTP . В C ++ SDK такой опции нет. HTTPOptions .

Это не помогает дать лямбда-клиенту config с большим connectionTimeoutMS (таймаут сокета). Кроме того, для httpRequestTimeoutMs клиента по умолчанию установлено значение 0, что означает, что он будет ждать вечно.

Я использую синхронные запросы , которые, похоже, не имеют дополнительной опции для тайм-аутов.

Дополнительная информация:

Я использую один клиент для параллельного выполнения нескольких запросов.

Ошибка также возникает, если я использую asyn c запросы.

Связано:

Как устранить проблемы с повторными попытками и тайм-аутом при вызове функции Lambda с помощью AWS SDK?

1 Ответ

0 голосов
/ 03 сентября 2020

Однажды то же самое доставило мне неприятности. Возможно, у вас есть решение, но для других вот что я сделал. Существует конфигурация клиента , которая может редактировать время соединения по умолчанию . Время соединения по умолчанию для отправки запроса составляет 1 сек c, а для получения - 3 сек c, если вы получите запрос, выполненный в этот период времени, это хорошо, в противном случае будет вызвана повторная попытка в соответствии с настройкой лямбда. Поведение этих двух хорошо объяснено в их соответствующем заголовочном файле. вы также можете поиграть с размером памяти лямбда, выше память лямбда, меньше времени отклика для того же. 

             Aws::Client::ClientConfiguration m_ClientConfig;
             m_ClientConfig.requestTimeoutMs = 300000; // i.e. 300 seconds
             m_ClientConfig.connectTimeoutMs = 300000; 


            /**
             * Socket read timeouts for HTTP clients on Windows. Default 3000 ms. This should be more than adequate for most services. However, if you are transfering large amounts of data
             * or are worried about higher latencies, you should set to something that makes more sense for your use case.
             * For Curl, it's the low speed time, which contains the time in number milliseconds that transfer speed should be below "lowSpeedLimit" for the library to consider it too slow and abort.
             */
            long requestTimeoutMs;
            /**
             * Socket connect timeout. Default 1000 ms. Unless you are very far away from your the data center you are talking to. 1000ms is more than sufficient.
             */
            long connectTimeoutMs;
...