Я просмотрел сайт, но не смог найти основную причину моей проблемы.
У нас есть лямбда, которая будет работать каждые 50 секунд. Первый запуск лямбды - это холодный старт. во время запуска готовятся все необходимые зависимости для лямбды (все интерфейсы). Лямбда-обработчик будет иметь свой собственный код для взаимодействия с SQS и SWF. во время первого запуска из журналов наблюдения за облаком ясно, что он читает базовый файл, чтобы получить все службы. тогда лямбда-обработчик запустится. после второго запуска через 50 секунд будет активирован только лямбда-обработчик. Пока все идет гладко. Внезапно мы заметили, что лямбда заняла более 50 секунд (как правило, она заканчивается ниже 10 секунд). Журнал показывает, что время лямбды истекло, и он снова начал инициализировать все зависимости.
Это не дает нам никакой подсказки, так как после тайм-аута последующий прогон работает гладко. Не приятно видеть, что время лямбды истекло. Определенно лямбда-код без ошибок.
Это может быть проблема с контейнером? Есть ли у контейнера период времени, в течение которого он будет сохранять данные активными, пока не истечет время его истечения.
Можем ли мы получить доступ к объекту контейнера, чтобы узнать больше информации? у нас есть 2 или более сред разработки. это поведение отличается для разных сред. для некоторых это случается каждые 3 дня. какое-то время за день это происходит трижды.
если мы хотим понять свойства объекта-контейнера, как мы можем это сделать? Это серая зона, к которой только AWS может получить доступ? Лямбда-код написан на c # с использованием сетевого ядра App 2.0. Мысль о проверке журнала облачного следа для этой лямбды во время вызова. там я тоже не могу найти причину таймаута.
у нас есть более 20 лямбда-выражений для dev и 10 для тестирования в разных регионах. нам не становится ясно, какая лямбда будет превышать время ожидания.
Любые предложения или идеи мне очень помогут ???????
Спасибо.