在系列的第 7 部分中,使用适用于 Java 的 AWS 开发工具包的 Amazon Aurora Serverless v2 的数据 API - 数据 API 与 SnapStart 的结合,我们使用 Data 测量了连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数的冷启动时间和热启动时间3 个用例的 API :
在本文中,我们希望将这些测量值与使用 DynamoDB 而不是 Amazon Aurora Serverless v2 的 Data API 时的测量值进行比较。
在我关于 Lambda SnapStart 的文章系列中,我们已经对类似的应用程序进行了此类测量,但在文章中使用不同的 Lambda 内存设置测量 Java 21 的热启动。
Amazon Aurora Serverless v2 和 DynamoDB 的应用程序数据 API 非常相似:
现在让我们将所有测量值放在一起。
冷 (c) 和热 (m) 启动时间(以毫秒为单位):
方法 | c p50 | c p75 | c p90 | c p99 | c p99.9 | c 最大 | w p50 | w p75 | w p90 | w p99 | w p99.9 | w 最大值 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
数据 API,未启用 SnapStart | 3154.35 | 3237 | 3284.91 | 3581.49 | 3702.12 | 3764.92 | 104.68 | 173.96 | 271.32 | 572.11 | 1482.89 | 2179.7 |
DynamoDB,未启用 SnapStart | 3157.6 | 3213.85 | 3270.8 | 3428.2 | 3601.12 | 3725.02 | 5.77 | 6.50 | 7.81 | 20.65 | 90.20 | 1423.63 |
数据 API,无需启动即可启用 SnapStart | 1856.11 | 1994.61 | 2467.83 | 3229.11 | 3238.80 | 3241.75 | 61.02 | 113.32 | 185.37 | 639.35 | 1973.30 | 2878.5 |
DynamoDB、SnapStart 无需启动即可启用 | 1626.69 | 1741.10 | 2040.99 | 2219.75 | 2319.54 | 2321.64 | 5.64 | 6.41 | 7.87 | 21.40 | 99.81 | 1355.09 |
数据 API,通过启动启用 SnapStart | 990.84 | 1069.04 | 1634.84 | 2120.00 | 2285.03 | 2286.9 | 60.06 | 106.35 | 185.37 | 581.27 | 1605.37 | 2658.24 |
DynamoDB、SnapStart 通过启动启用 | 702.55 | 759.52 | 1038.50 | 1169.66 | 1179.05 | 1179.36 | 5.73 | 6.51 | 7.87 | 21.75 | 92.19 | 328.41 |
在本文中,我比较了使用 Data API 连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数与连接到 DynamoDB 数据库的 3 个用例的冷启动时间和热启动时间的测量结果:
我们观察到,在 Lambda 函数上未启用 SnapStart 的情况下,两者的冷启动时间相当相似。 如果启用了 SnapStart(没有启动,尤其是启动启动),Amazon Aurora Serverless v2 的数据 API 的冷启动时间明显更长,特别是对于 >= 90 的百分位数。我需要更深入地挖掘以了解这种差异,因为我没有预计它会那么大,尤其是在使用底漆的情况下。也许原因是像 DynamoDB 这样的 AWS 原生服务更能感知 SnapStart,我可以更好地处理连接恢复。
与 DynamoDB 相比,Amazon Aurora Serverless v2 的数据 API 的热启动(执行)时间始终要高得多,我也预计 DynamoDB 以其单位数或两位数毫秒响应时间而闻名。
免责声明: 提供的所有资源部分来自互联网,如果有侵犯您的版权或其他权益,请说明详细缘由并提供版权或权益证明然后发到邮箱:[email protected] 我们会第一时间内为您处理。
Copyright© 2022 湘ICP备2022001581号-3