Как провести тестирование производительности AWS Lambda функций?

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

Как настроить лямбда-функцию Node.js для увеличения скорости и небольшого объема памяти, чтобы сэкономить на затратах?

Есть ли другие аспекты лямбды, которые выгодно улучшить?

Ответ Dawny33 хорош, но я бы начал раньше в процессе разработки.

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

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

Причина, по которой я так говорю, заключается в том, что, хотя AWS Lambdas удивительны во многих отношениях, тот факт, что вы не имеете полного контроля над сервером, ограничит ваши возможности в области инструментовки. Я не говорю, что инструментарий невозможен в безсерверном режиме, но попробуйте выяснить, сколько прерываний процессора у вас есть (и сколько вызвано вашим кодом) просто для удовольствия;)

Итак, что я советую, и это на самом деле не ограничивается безсерверным, так это начать раннее профилирование. Профилирование NodeJS может быть выполнено с помощью множества различных инструментов, например, NewRelic, dynatrace и AppDynamic. Также есть проигрыватель меньшего размера, некоторые из них - просто пакет для установки NPM (например, Nodefly). Также возможно обойтись без NodeJS без какого-либо дополнительного инструмента, поскольку в движок V8 встроен профилировщик. Эта документация от NodeJS поможет вам начать.

Какой бы инструмент вы ни выбрали, вы хотите установить его локально и собрать данные профилирования. Это может включать запуск агента или включение пакета в ваш package.json. Инструкции вашего инструмента расскажут вам, как его установить. Хороший профилировщик даст вам знать, сколько памяти и процессора вы используете. Лучшие инструменты помогут вам понять, сколько удаленных вызовов было сделано, сколько времени они заняли.

Используйте данные профилирования, которые предоставляет инструмент, чтобы выявить узкие места и устранить их. Нет предела тому, сколько профилирования вы можете заработать. Некоторые люди (сумасшедшие?) Будут смотреть на системные вызовы своей наиболее важной функции. Возможно, вам придется делать такие вещи, если вы хотите сбрасывать наносекунды своей функции (но тогда, возможно, AWS Lambda - не лучший выбор для начала).

Также стоит отметить, что я не упомянул ничего специфического для AWS Lambda. Это потому, что ваши оптимизации, скорее всего, не будут зависеть от AWS Lambda (в конце концов, в безсерверном режиме вы не должны беспокоиться о сервере / среде).

Убедитесь, что не только ваш код работает, но и работает так, как вы ожидаете. Не переусердствуйте, но внимательно следите за использованием процессора и памяти. Должен ли массив 2 МБ действительно увеличиваться до 10 МБ при его сортировке? Возможно нет.

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

Возможно, я не смогу ответить на него полностью, но вот мои взгляды из моего ограниченного опыта с лямбда:

1. Скорость-производительность . Продолжительность одного запуска лямбда-функции будет отображаться на панели инструментов monitoringвкладки лямбда , которая выглядит примерно так:

То же самое можно сказать о дросселях / ошибках / количестве вызовов.

2. Можно также настроить фильтры CloudWatch для использования памяти лямбда-функцией, данные которой можно использовать для дальнейшей оптимизации вашего обработчика. Это достойный пост о том, как его настроить.
3. Кроме того, настройте правильное ведение журнала , чтобы позже можно было просматривать журналы в CloudWatch. Это не оптимизация как таковая, а скорее лучшая практика
4. Тестирование : тщательно протестируйте лямбда-функции, чтобы не пропустить крайние случаи. Это важно, так как лямбда повторяет сбойные функции, прежде чем сдаться. Таким образом, вы можете сэкономить время заранее, если вы правильно протестировали функцию. Руководство по тестированию лямбда-функций

Проверьте профилировщик IOpipe, чтобы получить полные дампы профилировщика v8 от вызовов Lambda. Вы можете загрузить их в Chrome Devtools, чтобы точно узнать, на что тратится время процессора и как используется память для ваших функций.

Отказ от ответственности: я работаю на IOpipe

Используйте StackImpact agent, чтобы получить профили процессора и памяти. Подробнее в блоге: AWS Lambda CPU и профилирование памяти (Node.js) . Поскольку процесс Lambda Node.js зависает между запросами, большинство других инструментов, вероятно, не будут работать из коробки.

Отказ от ответственности: я работаю на StackImpact