使用适用于 Java 的 AWS 开发工具包实现 Amazon Aurora Serverless 的数据 API - 冷启动和热启动的部分比较：数据 API 与 DynamoDB

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《使用适用于 Java 的 AWS 开发工具包实现 Amazon Aurora Serverless 的数据 API - 冷启动和热启动的部分比较：数据 API 与 DynamoDB》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

介绍

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

• 未在 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 以其单位数或两位数毫秒响应时间而闻名。

到这里，我们也就讲完了《使用适用于 Java 的 AWS 开发工具包实现 Amazon Aurora Serverless 的数据 API - 冷启动和热启动的部分比较：数据 API 与 DynamoDB》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！