Dynamo Db Accelerator должен сократить время отклика на микросекунды

Question

Я использую функцию AWS Lamda и шлюз DynamodB и API для моего приложения

и нагрузочный тест с использованием Apache Bench, и я успешно выполнил тест

для 1000 запросов и 100 одновременных

и вот результат

Тест № 1

Уровень параллелизма: 100

Время, затраченное на тесты: 0,920 секунд

Заполнено запросов: 1000

Неудачные запросы: 0

запросов в секунду: 1086,60 [# / сек] (среднее значение)

Время на запрос: 92,030 [мс] (среднее)

Время на запрос: 0,920 [мс] (среднее для всех одновременных запросов)

После этого я добавил DAX (DynamodB ускоритель), чтобы уменьшить время отклика до микросекунд, как и ожидалось

но я получил те же результаты

Тест № 2

Уровень параллелизма: 100

Время, затраченное на испытания: 0,853 секунды

Полные запросы: 1000

Сбой запросов: 0

запросов в секунду: 1172,12 [# / сек] (среднее значение)

Время на запрос: 85,315 [мс] (среднее)

Время на запрос: 0,853 [мс] (среднее для всех одновременных запросов)

Answer 1

Лямбда и API-шлюз сами несут значительные накладные расходы, которые, вероятно, составляют большую часть этих 85 мс. Единственная часть, которую DAX может ускорить - это чтение из DynamoDB.

Например, допустим, что обычное чтение (GetItem) из DynamoDB занимает 2,5 мс, а кэшированное чтение из DAX - 500 мкс, а ваша лямбда выполняет 5 последовательных GetItems. В этом случае DynamoDB потребует 12,5 мс, а DAX потребует 2,5 мс, сэкономив 10 мс времени в Lambda - но вам все равно придется заплатить стоимость API Gateway и Lambda, которая может легко составить 50+ мс.

(Я рекомендую прочитать Закон Амдала , если вы не знакомы с ним, чтобы понять ограничения оптимизации производительности.)

Возможно, все еще имеет смысл использовать DAX для вашего случая использования, поскольку это может позволить вам снизить пропускную способность DynamoDB или запросы по требованию, но при использовании Lambda улучшение задержки будет заметно только в том случае, если каждая Lambda делает много запросов.