Динамодб простое время выполнения запроса

Question

У меня есть лямбда-функция Python AWS, которая запрашивает AIM DynamodB. Поскольку мой API теперь занимает около 1 секунды, чтобы ответить на очень простую настройку запроса / таблицы, я хотел понять, где я могу оптимизировать.

На данный момент в таблице всего 3 элемента (пользователей) и структура:

user_id (Primary Key, String),
details ("[{
      "_nested_atrb1_str": "abc",
      "_nested_atrb2_str": "def",
      "_nested_map": [nested_item1,nested_item2]},
      {..}]

Запрос очень прост:

response = table.query(
        KeyConditionExpression=Key('userid').eq("xyz")
    )

Запрос занимает 0,8-0,9 секунды.

• Это нормальное время запроса для таблицы, содержащей только 3 элемента, где каждый пользователь имеет максимум 5 атрибутов (включая вложенные)?
• Если да, могу ли я ожидать аналогичные времена, если структура остается той же, но количество элементов (пользователи) увеличивается в сто раз?

Answer 1

Для тех, у кого похожий опыт, я получил приведенный ниже ответ службы поддержки AWS с некоторыми полезными ссылками. Это не решило мою проблему, но теперь я понимаю, что это в основном связано с низким (тестовым) объемом и временем запуска лямбды.

1) Является ли это обычным временем запроса для таблицы, содержащей только 3 элемента, где у каждого пользователя есть максимум 5 атрибутов (включая вложенные)?

Время медленное, но может быть связано с рядом факторов, основанных на вашей настройке. Поскольку вы используете лямбду, вы должны помнить, что каждый раз, когда вы запускаете лямбда-функцию, она настраивает вашу среду, а затем выполняет код. Лямбда-функция AWS выполняется в контейнере - среде выполнения, изолированной от других функций. Когда вы запускаете функцию в первый раз, AWS Lambda создает новый контейнер и начинает выполнять код функции. Лямбда-функция имеет обработчик, который выполняется один раз за вызов. После выполнения функции AWS Lambda может выбрать повторное использование контейнера для последующих вызовов этой функции. В этом случае ваш обработчик функций может повторно использовать ресурсы, которые вы определили в своем коде инициализации. (Обратите внимание, что вы не можете контролировать, как долго AWS Lambda будет удерживать контейнер или будет ли контейнер повторно использоваться.) Ваш стол действительно маленький, я посмотрел на него. [1]

2) Можно ли ожидать аналогичного времени, если структура останется прежней, но количество элементов (пользователей) увеличится в сто раз?

Если выполнение кода занимает больше времени и у вас есть больше данных в DynamoDB, со временем он может замедлиться, опять же в зависимости от ваших настроек.

Некоторые из моих рекомендаций по оптимизации вашей настройки.

1) Иметь Lambda и DynamoDB в одном и том же VPC. Вы можете запросить свой DynamoDB через конечную точку VPC. Это исключит сетевые задержки. [2] [3]

2) Увеличение памяти лямбды для ускорения запуска и выполнения.

3) По мере масштабирования вашего приложения. Обязательно включите автоматическое масштабирование в таблице DynamoDB, а также увеличьте RCU и WCU, чтобы улучшить производительность DynamoDB при обработке запросов. [4]

Кроме того, ознакомьтесь с рекомендациями DynamoDB. [5]

Пожалуйста, не стесняйтесь обращаться ко мне с любыми дополнительными вопросами и для дальнейшего руководства. Спасибо. Хорошего вам дня. Хорошего дня.

Ссылки

1. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.BestPracticesWithDynamoDB.html
2. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
3. https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
4. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html
5. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

Answer 2

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

Answer 3

Я предполагаю, что вы повторно используете ваши соединения, поскольку это сокращает время выполнения на несколько миллисекунд. Если нет, то это поможет вам достичь этого. Любая переменная вне функции lambda_handler будет заморожена между вызовами Lambda и, возможно, повторно использована. В документации говорится, что «не следует предполагать, что AWS Lambda всегда повторно использует контейнер, поскольку AWS Lambda может предпочесть не использовать контейнер повторно». Однако отмечается, что в зависимости от объема выполнений контейнер почти всегда используется повторно.

Answer 4

Есть несколько вещей, которые нужно исследовать. Во-первых, ваше время составляет 0,8 - 0,9 секунд, основанное на временной привязке запроса напрямую, оборачивая запрос во время или время, как таймер? Если этот запрос действительно требует времени, то определенно что-то не так с взаимодействием с «Динамо» из Lambda.

Если время, которое вы видите, на самом деле происходит из-за вызова вашей лямбды (я предполагаю, что это через API-шлюз как REST API, так как вы упомянули «api»), то время, которое вы видите, может быть обусловлено многими факторами , Можете ли вы профилировать вызов API? Я бы проверил в Postman или даже в инструментах браузера, можете ли вы профилировать, чтобы увидеть время для поиска DNS, настройки SSL и т. Д. Кроме того, CloudWatch предоставит вам метрики, специфичные для времени вызова вашей Lambda, как только запрос достигнет Lambda. Вы также можете посмотреть на включение X-Ray, который даст вам больше деталей относительно выполнения вашей лямбды. Если ваша Lambda работает в VPC, вы также можете столкнуться с холодными запусками, которые приводят к задержке, которую вы видите.

X-Ray: https://aws.amazon.com/xray/

Холодные запуски: просто Google "AWS Lambda холодные запуски", и вы найдете все виды информации