介绍
在使用 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 函数的成本。
