Меня очень волнует производительность. Если мой код работает быстрее, я счастлив, а метрика успеха тривиальна. Это особенно просто в AWS Lambda, поскольку время выполнения сообщается автоматически. Есть также финансовый стимул, поскольку он связан с биллинговой моделью.
И вот я задался вопросом: Существует ли оптимальная стратегия для моего .NET-кода на AWS Lambda?
AWS Lambda — это свой собственный маленький зверь, которого нужно понять и освоить. Существует множество вариантов развертывания, которые влияют на производительность. В сочетании с различными вариантами компиляции и времени выполнения кода .NET это представляет собой интересную проблему. Существует также фундаментальный вопрос о том, что означает «оптимальный»?
Ну ⟪spoiler alert⟫ не существует одной «оптимальной» стратегии! Вместо этого мы должны выбрать, что мы хотим оптимизировать. Я остановился на рассмотрении двух стратегий. Обе они имеют свое место, и редко (никогда?) возможно достичь обеих. Обратите внимание, что если некоторые термины вам незнакомы, не бойтесь. Я буду объяснять каждое понятие по мере погружения в материал. А если я что-то упустил, пожалуйста, сообщите мне об этом в комментариях, и я внесу поправки.
Стратегия 1: Минимизация продолжительности холодного запуска
Эта стратегия направлена на достижение наименьшего времени отклика при наихудшем сценарии: холодном запуске нашей функции AWS Lambda. В этом случае необходимо создать новую среду выполнения для обработки нашего запроса. Среда выполнения должна быть инициализирована, наш код должен быть загружен в нее, а затем наша логика должна быть запущена для получения ответа. Все это занимает дополнительное время по сравнению с последующими запросами. Соответственно, эта стратегия обменивает более быструю инициализацию на абсолютную производительность при последующих вызовах, что может повлиять на стоимость выполнения.
Стратегия 2: Минимизация стоимости выполнения
Эта стратегия минимизирует стоимость выполнения экземпляра AWS Lambda, включая холодный старт с последующим некоторым пороговым количеством теплых вызовов. В данном случае мы готовы к более медленному холодному старту ради лучшей производительности после прогрева. Эта стратегия использует одну из малоизвестных причуд биллинговой модели AWS Lambda (подробнее об этом позже). Эта стратегия лучше всего работает, когда мы знаем, что наш код будет вызываться часто. Для целей данного исследования я предполагаю, что наша функция Lambda будет вызвана 100 раз после холодного старта.
Выбор стратегии
Предпочтительная стратегия зависит от цели нашего кода. Для обработки синхронных вызовов, таких как запросы API, минимизация холодных запусков может быть предпочтительной. Особенно если на другом конце ожидает человек. Но для асинхронных вызовов, таких как EventBridge, более важна минимизация стоимости выполнения.
Что дальше
В следующем посте я собираюсь погрузиться в жизненный цикл экземпляра AWS Lambda и связанную с ним терминологию. Затем я расскажу о некоторых вариантах компиляции и времени выполнения для кода .NET. Затем я представлю методологию бенчмаркинга. Наконец, я представлю свои выводы и заключение. Как и во всех исследованиях, очень важна экспертная оценка и независимое подтверждение. Поэтому весь мой код также доступен под разрешительной лицензией с открытым исходным кодом в репозитории LambdaSharp.Benchmark на GitHub.
Отказ от ответственности: Это очевидное утверждение, но, пожалуйста, проверьте дату этого сообщения. Если он старше 3 лет, то, скорее всего, он устарел!