Ответ Dawny33 хорош, но я бы начал раньше в процессе разработки.
Очень важно следить за своей облачной средой, чтобы убедиться, что ваши функции работают так, как вы ожидаете (включая ваши «производственные» функции, которые могут работать с другим набором данных), поскольку это может выявить вещи, которые невозможно воспроизвести локально или с тестовый набор данных.
Тем не менее, я бы сказал, что это тестирование производительности, которое вы проводите в целях оптимизации, должно начинаться прямо с компьютера разработчика. Или, по крайней мере, из какой-то локальной среды, прежде чем отправлять в облако.
Причина, по которой я так говорю, заключается в том, что, хотя AWS Lambdas удивительны во многих отношениях, тот факт, что вы не имеете полного контроля над сервером, ограничит ваши возможности в области инструментовки. Я не говорю, что инструментарий невозможен в безсерверном режиме, но попробуйте выяснить, сколько прерываний процессора у вас есть (и сколько вызвано вашим кодом) просто для удовольствия;)
Итак, что я советую, и это на самом деле не ограничивается безсерверным, так это начать раннее профилирование. Профилирование NodeJS может быть выполнено с помощью множества различных инструментов, например, NewRelic, dynatrace и AppDynamic. Также есть проигрыватель меньшего размера, некоторые из них - просто пакет для установки NPM (например, Nodefly). Также возможно обойтись без NodeJS без какого-либо дополнительного инструмента, поскольку в движок V8 встроен профилировщик. Эта документация от NodeJS поможет вам начать.
Какой бы инструмент вы ни выбрали, вы хотите установить его локально и собрать данные профилирования. Это может включать запуск агента или включение пакета в ваш package.json. Инструкции вашего инструмента расскажут вам, как его установить. Хороший профилировщик даст вам знать, сколько памяти и процессора вы используете. Лучшие инструменты помогут вам понять, сколько удаленных вызовов было сделано, сколько времени они заняли.
Используйте данные профилирования, которые предоставляет инструмент, чтобы выявить узкие места и устранить их. Нет предела тому, сколько профилирования вы можете заработать. Некоторые люди (сумасшедшие?) Будут смотреть на системные вызовы своей наиболее важной функции. Возможно, вам придется делать такие вещи, если вы хотите сбрасывать наносекунды своей функции (но тогда, возможно, AWS Lambda - не лучший выбор для начала).
Также стоит отметить, что я не упомянул ничего специфического для AWS Lambda. Это потому, что ваши оптимизации, скорее всего, не будут зависеть от AWS Lambda (в конце концов, в безсерверном режиме вы не должны беспокоиться о сервере / среде).
Убедитесь, что не только ваш код работает, но и работает так, как вы ожидаете. Не переусердствуйте, но внимательно следите за использованием процессора и памяти. Должен ли массив 2 МБ действительно увеличиваться до 10 МБ при его сортировке? Возможно нет.
Затем вы сможете использовать инструменты, упомянутые Dawny33, или некоторые другие инструменты, чтобы подтвердить, что ваши функции работают аналогично при развертывании в Lambda. Однако у вас уже будет очень высокий уровень доверия к вашей функции, и вам нужно будет только подтвердить, что они ведут себя должным образом, а не полностью их профилировать.