Loadtesting - высокий параллелизм = высокая задержка при использовании лямбды?

Question

Я создал функцию lamdba, которая выбирает запись из DynamoDB.

Теперь я пытаюсь получить некоторые данные о производительности архитектуры (которая будет включать DAX на более поздней итерации).

Для теста я использую пакет loadtest . Ниже приведены подробности 2 моих тестов

Тест № 1

Конфигурация AWS Lambda

• Время ожидания: 30 с
• Память: 1024 МБ
• Резервный параллелизм: 900

Тестовые входы

• Макс. Запросов: 1000
• Параллельность: 100

Результат теста

• totalRequests: 1000
• totalTimeSeconds: 15.028303200999997
• meanLatencyMs: 1385,2
• maxLatencyMs: 6536
• minLatencyMs: 197

Тест № 2

Конфигурация AWS Lambda

• Время ожидания: 30 с
• Память: 1024 МБ
• Резервный параллелизм: 900

Тестовые входы

• Макс. Запросов: 1000
• Параллелизм: 1000

Результат теста

• totalRequests: 1000
• totalTimeSeconds: 19.298303200999997
• meanLatencyMs: 8648,2
• maxLatencyMs: 18749
• minLatencyMs: 832

---

Вопросы

1. Почему средняя задержка так сильно возрастает, когда я изменяю уровень параллелизма со 100 на 1000, когда я настроил резервный параллелизм лямбда-функции для запуска 900 параллельных экземпляров?
2. Мне не хватает конфигурации AWS, которая могла бы улучшить показатели?

Answer 1

Тест 1 имеет в 10 раз больше запросов, чем одновременных выполнений, что помогает амортизировать стоимость любых холодных запусков. С другой стороны, результаты теста 2 хуже, потому что тест 2 полностью холодный.

Прямо сейчас ваши тесты не обязательно являются честным сравнением (в зависимости от того, что вы пытаетесь измерить). Вы можете попробовать повторить Тест 2 с числом запросов, в 10 раз превышающим параллелизм, чтобы увидеть, получаете ли вы результаты, аналогичные Тесту 1.

Answer 2

Вы проверили, не регулировалась ли лямбда? Существует лямбда-параллелизм по умолчанию для учетной записи около <= 1000 (которую вы используете при нагрузочном тестировании) Есть ли какие-либо ошибки http для API Gateway или в Lambda? </p>

AWS: «AWS Lambda будет поддерживать нерезервированный пул параллелизма как минимум на 100 одновременных выполнений, поэтому функции, для которых не установлены конкретные ограничения, могут обрабатывать запросы. Таким образом, на практике, если общий лимит учетной записи равен 1000, вы ограничены распределением 900 для отдельных функций. "

Проверить: https://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits-d64f144129e5