【发布时间】:2021-09-17 01:04:51
【问题描述】:
我们的技术栈: DynamoDB + Node.js + Aws Lambda + API 网关。
到目前为止,我们的数据库中没有太多数据,总共大约 100 条记录。在获取时,我们使用GSI 和query 而不是scan 以获得快速结果,并且还使用了10 的限制。但它仍然没有快速返回响应。只需10 records 就需要898.50 ms。
任何人都可以帮忙,如何减少响应时间,因为这是开发的初始阶段。
为什么要花这么多钱?我们如何才能获得更快的响应以及影响性能的因素。
示例代码:
const itemParams = {
TableName: CUSTOMER_TABLE,
IndexName: 'companyId-index', // GSI Without range key
KeyConditionExpression: 'companyId = :companyId',
ProjectionExpression: [
'id',
'companyId',
'fullName',
'companyName',
'mobileNumber',
'contactEmail',
'createdAt',
'updatedAt'
],
FilterExpression: 'isDeleted = :isDeleted',
ExpressionAttributeValues: {
':isDeleted': false,
':companyId': authCompanyId
}
};
const customerList = await dynamoUtils.query(itemParams);
注意:函数只是在dynamo中执行查询,在lambda函数本身和dynamo查询中都没有任何复杂的计算。
感谢您的帮助。
【问题讨论】:
-
您可以为 lambda 和 api 网关添加主动跟踪,以调试 X 射线中的延迟瓶颈。延迟通常是由较小的 lambda 大小(小于 1GB 内存)或许多其他因素引起的,例如 lambda 中包含的大包大小。 X 射线无需任何代码更改即可提供洞察力。见docs.aws.amazon.com/lambda/latest/dg/services-xray.html
-
你的lambda函数的配置是什么?使用github.com/alexcasalboni/aws-lambda-power-tuning 之类的工具找出最具成本效益的内存配置
-
@LRutten 感谢您提醒记忆。我们检查了我们正在使用 128MB 内存。还检查通过增加内存和性能提高。但是有疑问,在 cloudwatch 日志中,使用的最大内存小于 100MB,那我们为什么要增加内存呢?
-
内存也会显着增加 CPU 并减少冷启动。通常在 1GB 内存之后它不会再增加太多价值,除非你有巨大的包大小
标签: node.js amazon-web-services aws-lambda amazon-dynamodb dynamodb-queries