java - 减少来自 Java Lambda 的 DynamoDB 延迟

Question

如何减少我目前在 Lambda 和 DynamoDB 之间看到的延迟？

这是一个 Java lambda，使用 AWS 提供的 SDK 执行 2 个 DynamoDB 操作中的每一个操作需要 4 秒。我听说这些通常在 <20 毫秒内完成，但对我来说高出 3 个数量级。这些长操作是 (a) 创建 DynamoDB 对象和 (b) 对完全空的表执行表扫描(下面的代码)。

我应该怎么做才能减少延迟？

我尝试过的事情

• lambda 和 DynamoDB 都在同一区域 (eu-west-1)。
• 该表有 5 个 RCU 和 WCU。增加这些没有帮助。
• lambda 使用的最大内存为 92MB。如果我分配最小 128MB，则它会在 15 秒后超时。将内存增加到 512MB 可以实现每次调用 4s 的时间，再次增加到 1GB 可以将每次调用减少到 2s。然而，对于一个普通的 lambda 表达式来说，这是一个荒谬的内存量，并且仍然给我留下了超过 200 倍的预期延迟。
• 表指标显示表扫描时间在 12 毫秒到 15 毫秒之间。这就是我所期待的。即使有建立网络连接的开销，我仍然期待几十毫秒，而不是几秒。
• 我正在使用 AWS 控制台中的测试函数触发 lambda。我也尝试过通过 API 网关触发(这是我最终会做的)，结果相同。
• 我已经尝试快速连续多次调用 lambda(以降低我承受设置成本的可能性)。它没有帮助。
• 日志记录显示 lambda 的所有其他部分运行得非常快(毫秒)。

代码片段

创建 DynamoDB 对象

log("Creating AmazonDynamoDB");
AmazonDynamoDB db = AmazonDynamoDBClientBuilder                        
  .standard()
  .withRegion(Regions.EU_WEST_1)
  .build();

log("Creating DynamoDBMapper");
DynamoDBMapper mapper = new DynamoDBMapper(db);

执行扫描

log("Scanning table");
List<MyItem> items = dbMapper.scan(MyTable.class, new DynamoDBScanExpression());
for (MyItem item : items) {
        // Irrelevant - there aren't any
}
log("Table scan complete");

示例日志

这是运行的日志。

20:07:41 START RequestId: 9d436db7-5d32-11e8-8555-8564d2094ccc Version: $LATEST
20:07:41 Received request: APIGatewayRequest(path=/data/foo, httpMethod=POST, body=)
20:07:41 Creating AmazonDynamoDB
20:07:45 Creating DynamoDBMapper
20:07:45 Creating DataHandler
20:07:45 Handling request
20:07:45 Scanning table
20:07:49 Table scan complete
20:07:49 Request handled - response object: []
20:07:49 APIGatewayResponse(isBase64Encoded=false, statusCode=200, body=[], headers={})
20:07:49 END RequestId: 9d436db7-5d32-11e8-8555-8564d2094ccc
20:07:49 REPORT RequestId: 9d436db7-5d32-11e8-8555-8564d2094ccc Duration: 8256.47 ms Billed Duration: 8300 ms Memory Size: 512 MB Max Memory Used: 85 MB

Answer 1

根据 this post从 AWS 论坛上的 AWS 员工那里得知，AmazonDynamoDB 对象的构造非常昂贵。将构造(返回)移动到静态初始化器中，再加上一点额外的内存(=CPU)分配，基本上可以解决问题。

日志中的数据仍然显示，上面确定的 2 个缓慢步骤中的每一个都花费了大约一半的时间。因此，AmazonDynamoDB 对象的构造和首次使用可能都很慢。

显然这对第一个请求没有帮助，它仍然需要与问题中相同的时间。然而，一旦 lambda 被预热，后续请求需要大约 15 毫秒(远低于 100 毫秒的最低计费阈值)。解决第一个请求问题是 well understood - 例如通过使用 CloudWatch Events 安排对 lambda 的定期调用以使其保持温暖。

2020年编辑:也可以用Provisioned Currency处理冷启动问题。