Тайм-аут шлюза API Amazon

У меня есть некоторые проблемы с шлюзом API. Я сделал несколько методов API, иногда они работают дольше 10 секунд, и Amazon возвращает ошибку 504. Вот скриншот ниже:

enter image description here

Пожалуйста помоги! Как я могу увеличить время ожидания?

Спасибо!

ОТВЕТЫ

Ответ 2

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

http://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html

Ответ 4

Лямбда-функции прекратят работу после макс. 5 мин; Время ожидания запросов к API-шлюзу истекает через 29 секунд. Вы не можете это изменить, но вы можете обойти это с помощью асинхронного шаблона выполнения, о котором я писал в своем блоге:

https://joarleymoraes.com/serverless-long-running-http-requests/

Ответ 5

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

Использование aws sdk:

var aws = require('aws-sdk');
var lambda = new aws.Lambda({
  region: 'us-west-2' //change to your region
});

lambda.invoke({
  FunctionName: 'name_of_your_lambda_function',
  Payload: JSON.stringify(event, null, 2) // pass params
}, function(error, data) {
  if (error) {
    context.done('error', error);
  }
  if(data.Payload){
   context.succeed(data.Payload)
  }
});

Источник: может ли функция AWS Lambda вызвать другую документацию AWS: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Lambda.html

Ответ 6

Тайм-ауты могут быть уменьшены, но не могут быть увеличены более чем на 29 секунд. Бэкэнд вашего метода должен вернуть ответ до 29 секунд, иначе шлюз API выдаст ошибку 504 тайм-аута.

В качестве альтернативы, как предложено в некоторых ответах выше, вы можете изменить бэкэнд для отправки кода состояния 202 (Принят), что означает, что запрос был успешно принят, и бэкэнд затем продолжает дальнейшую обработку. Конечно, мы должны рассмотреть вариант использования и его требования перед внедрением обходного пути.

Ответ 7

Я хотел прокомментировать пост "joarleymoraes", но мне не хватает репутации. Единственное, что нужно добавить, это то, что вы НЕ ДОЛЖНЫ рефакторизовать использование async, это просто зависит от вашего бэкэнда и того, как вы можете его разделить + ваши попытки на стороне клиента.

Если вы не видите высокий процент 504 и не готовы к асинхронной обработке, вы можете реализовать на клиентской стороне повторные попытки с экспоненциальной задержкой, чтобы они не были постоянными сбоями.

AWS SDK автоматически реализует повторные попытки с откатом, поэтому он может помочь сделать это проще, особенно потому, что Lambda Layers позволит вам поддерживать SDK для ваших функций без необходимости постоянного обновления пакетов развертывания.

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

Другое преимущество повторных попыток состоит в том, что если вы повторите все ответы 5xx из приложения, это может охватить множество различных проблем, которые могут возникнуть при обычном выполнении. Во всех приложениях обычно считается, что этих проблем никогда не избежать на 100%, поэтому лучше всего идти вперед и планировать худшее!

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