介绍

在系列的第 7 部分中，使用适用于 Java 的 AWS 开发工具包的 Amazon Aurora Serverless v2 的数据 API - 数据 API 与 SnapStart 的结合，我们使用 Data 测量了连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数的冷启动时间和热启动时间3 个用例的 API ：

• 未在 Lambda 函数上启用 SnapStart
• 在 Lambda 函数上启用 SnapStart，但没有启动优化
• 在 Lambda 函数上启用 SnapStart 并进行启动优化（在 PostgreSQL 数据库上预热 SQL 语句执行）。

在本文中，我们希望将这些测量值与使用 DynamoDB 而不是 Amazon Aurora Serverless v2 的 Data API 时的测量值进行比较。

比较 Lambda 冷启动和热启动：Amazon Aurora Serverless v2 的数据 API 与 DynamoDB

在我关于 Lambda SnapStart 的文章系列中，我们已经对类似的应用程序进行了此类测量，但在文章中使用不同的 Lambda 内存设置测量 Java 21 的热启动。

Amazon Aurora Serverless v2 和 DynamoDB 的应用程序数据 API 非常相似：

• 它们提供从数据库存储和检索产品的逻辑
• 两个项目的 Lambda 函数都有 1024 MB 内存设置
• 两者的部署工件大小均为 18 MB 左右
• 两个项目中的 Lambda 函数都使用默认同步 HTTP Apache 客户端与数据库进行通信
• 两个项目的 Lambda 函数都使用 x86_64 架构

现在让我们将所有测量值放在一起。

冷 (c) 和热 (m) 启动时间（以毫秒为单位）：

结论

在本文中，我比较了使用 Data API 连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数与连接到 DynamoDB 数据库的 3 个用例的冷启动时间和热启动时间的测量结果：

• 未在 Lambda 函数上启用 SnapStart
• 在 Lambda 函数上启用 SnapStart，但没有启动优化
• 在 Lambda 函数上启用 SnapStart 并启动数据库请求

我们观察到，在 Lambda 函数上未启用 SnapStart 的情况下，两者的冷启动时间相当相似。 如果启用了 SnapStart（没有启动，尤其是启动启动），Amazon Aurora Serverless v2 的数据 API 的冷启动时间明显更长，特别是对于 >= 90 的百分位数。我需要更深入地挖掘以了解这种差异，因为我没有预计它会那么大，尤其是在使用底漆的情况下。也许原因是像 DynamoDB 这样的 AWS 原生服务更能感知 SnapStart，我可以更好地处理连接恢复。

与 DynamoDB 相比，Amazon Aurora Serverless v2 的数据 API 的热启动（执行）时间始终要高得多，我也预计 DynamoDB 以其单位数或两位数毫秒响应时间而闻名。