介绍

在使用 Spring Boot 3 和 GraalVM 本机映像开发 Web 应用程序一文中，我们探讨了如何使用包含从 Spring Cloud Function（及其 AWS 适配器）创建的 GraalVM 本机映像（使用 GraalVM 22 运行时）的自定义运行时来开发和部署 Lambda 函数） 应用。

在本文中，我们将使用这种方法测量 Lambda 函数的冷启动和热启动。

使用包含 GraalVM Native Image 的自定义运行时测量 Lambda 函数的冷启动和热启动

对于我们的测量，我们将使用第 2 部分中的示例应用程序，并为所有 Lambda 函数提供 1024 MB 内存。

下面的实验结果基于使用 Lambda 函数 GetProductByIdWithSpringBoot32GraalVMNative 在 1 小时内重现超过 100 次冷启动和大约 100.000 次热启动，该函数映射到负责检索产品的 Lambda 处理程序类（存储在DynamoDB）通过其 id。为此，我使用了负载测试工具，但是您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。

冷 (c) 和暖 (m) 开始时间（以毫秒为单位）：

c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
1051.03	1061.58	1080.86	1119.34	1149.45	1230.28	6.45	6.77	7.33	12.50	90.92	218.17

结论

在本文中，使用自定义运行时测量了具有 1024 MB 内存的 Lambda 函数的冷启动和热启动，该运行时包含从使用 Spring Boot 3 和 GraalVM 本机映像开发 Web 应用程序一文中介绍的 Spring Cloud Function 应用程序创建的 GraalVM 本机映像。

将本文中的这些性能测量值与我们对 AWS Serverless Java Container、AWS Lambda Web Adapter 和 Spring Cloud Function 所做的测量值进行比较，我们发现使用 GraalVM Native Image 的热启动时间最短。 GraalVM Native Image 的冷启动时间通常低于所有其他方法的测量值。唯一的期望是使用支持 SnapStart 的 Lambda 函数的 AWS Web Adaptor 进行冷启动，并额外启动 DynamoDB 请求，我们测量到的冷启动时间略短。

当我们将冷启动时间与使用不同 Lambda 内存设置（其中我们的 Lambda 函数不使用 Spring Boot 等任何框架）的 GraalVM Native Image 测量纯 Lambda 函数的冷启动和热启动一文中测量的时间进行比较时，我们看到对于具有相同 1024 MB 内存的 Lambda 函数，使用纯 Lambda 函数时每个百分位数的值要低约 0.5-0.6 秒。我个人认为我的示例 Spring Boot 3 应用程序具有一定的优化潜力，因为我无法解释它们之间的冷启动时间如此大的差异。也许作为读者的您可以帮助我优化我的代码，因为我的（也许是天真的）期望是，与 AWS Lambda 和 GraalVM Native 映像一起使用 Spring Boot 3 框架可能会比之前的冷启动时间高大约 0.2-0.3 秒使用纯 Lambda 函数，但不是 0.5-0.6 秒。

在发布本文时，新版本已经可用（GraalVM 23 运行时、Spring Boot 3.4 和 Spring Cloud Function 库的小更新），因此您可以对 pom.xml 进行版本更改并重新编译 GraalVM Native 映像按照本系列第 2 部分的说明重新测量性能。
在本系列的下一篇文章中，我们将探讨不同 Lambda 内存设置（从 256 到 1536 MB）对冷启动和热启动时间的影响，因为内存设置也会严重影响运行 Lambda 函数的成本。

以上就是AWS Lambda 上的 Spring Boot 应用程序 - 使用 GraalVM Native Image 测量冷启动和热启动的部分的详细内容，更多请关注php中文网其它相关文章！