Лямбда холодного пуска возможное решение?

Является ли планирование лямбда-функции для вызова каждые 20 минут с CloudWatch лучшим способом избавиться от времени холодного запуска лямбда? (не полностью избавиться от)...

Будет ли это дорогостоящим или есть что-то, что я пропускаю, потому что я настроил это прямо сейчас, и я думаю, что это работает.

До моего холодного запуска время составляло бы около 10 секунд, а каждый последующий вызов завершался примерно за 80 мс. Теперь каждый звонок, независимо от того, как часто это происходит, составляет около 80 мс. Является ли это хорошим методом до тех пор, пока ваша пользовательская база не вырастет, тогда вы можете отключить это?

Мой второй вариант - просто использовать beanstalk и иметь сервер, работающий 24/7, но это звучит дорого, поэтому я не предпочитаю его.

Ответ 1

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

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

Но раз каждые 20 минут это примерно как 2000 раз в месяц, поэтому, если вы используете, например, 128 МБ и сделать их законченными до 100 мс, тогда вы могли бы сохранить довольно много таких функций в живых с 20-минутными интервалами и все еще находиться под свободным уровнем - это будет 20 секунд в месяц за каждую функцию. Вам даже не нужно отключать его после того, как вы получите большую нагрузку, потому что на данный момент это будет неактуально. Кроме того, вы никогда не можете быть уверены, что будете получать равномерную нагрузку все время, чтобы вы могли еще больше активировать ваш сердечный код.

Хотя я предполагаю, что так дешево поддерживать функцию (особенно если у вас есть специальный аргумент, который заставляет их сразу возвращаться) и что разница настолько велика (10 секунд против 80 мс), то в значительной степени все это сделают - почти нечего оправдать. В этом случае я ожидаю, что Amazon либо будет бороться с этой практикой (сделав ее трудной или дорогой, чем сейчас, - что не будет разумным шагом), или сделать это не нужно в будущем. Если разница между горячим и холодным пуском составляла 100 мс, никто бы не стал беспокоиться. Если это 10 секунд, все должны обходиться вокруг.

Всегда существовала бы разница между запуском кода, который был запущен второй раз, и кода, который был запущен месяц назад, потому что все из них в ОЗУ и готовы к работе будут тратить много ресурсов, но Я не вижу причин, почему это различие не могло быть менее заметным или даже иметь несколько шагов вместо горячего и холодного старта.

Ответ 2

Вы можете улучшить время холодного запуска, выделив больше памяти для вашей лямбда-функции. По умолчанию 512 МБ, я вижу время холодного запуска 8-10 секунд для функций, написанных на Java. Это улучшает до 2-3 секунд с 1536 МБ памяти.

Amazon говорит, что на самом деле имеет значение распределение ЦП, но напрямую изменить его невозможно. Выделение ЦП увеличивается пропорционально памяти.

И если вы хотите, чтобы время холодного запуска было близко к нулю, поддержание функции в теплом состоянии - это то, что вам нужно, как описано в разделе rsp.

Ответ 3

Помимо добавления дополнительной памяти для лямбды, существует также еще один подход для уменьшения холодных запусков: используйте инструмент Graal native-image. Баночка переводится в байт-код. По сути, мы будем выполнять часть работы, которая выполняется на AWS. Когда вы создаете свой код, при загрузке в AWS - выберите "Custom runtime", а не java8.

Полезная статья: https://engineering.opsgenie.com/run-native-java-using-graalvm-in-aws-lambda-with-golang-ba86e27930bf

Осторожно:

но это также имеет свои ограничения; он не поддерживает динамическую загрузку классов, а поддержка отражений также ограничена

Ответ 4

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

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