Quarkus - DynamoDB + HTTP慢第一响应
我创建了一个测试项目，其中我组合了两个指南：Quarkus-DynamoDB和Quarkus-HTTP。这样做的最终目标是有一个示例项目，其中一个lambda与DynamoDB通信，所有这些都是本地编译的(使用GraalVM)。
这样做的效果比较好。我成功地使用第二个指南中的工具将项目部署到AWS，并且我在调用端点时得到的响应与预期的一样。
然而，我对公司的表现有一些疑问，尤其是在创业之后。
当点击第一个指南中简单的"hello“端点时，”时代“看起来如下所示：
2021-05-09T20:41:06.986+02:00 START RequestId: ccc69797-3e58-47b1-a475-f2b0cc93cd7d Version: $LATEST
2021-05-09T20:41:06.986+02:00 __ ____ __ _____ ___ __ ____ ______
2021-05-09T20:41:06.986+02:00 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
2021-05-09T20:41:06.986+02:00 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
2021-05-09T20:41:06.986+02:00 --\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2021-05-09T20:41:06.986+02:00 2021-05-09 18:41:06,980 INFO [io.quarkus] (main) quarkus-amazon-lambda-http-archetype 1.0-SNAPSHOT native (powered by Quarkus 1.13.3.Final) started in 0.239s.
2021-05-09T20:41:06.986+02:00 2021-05-09 18:41:06,985 INFO [io.quarkus] (main) Profile prod activated.
2021-05-09T20:41:06.986+02:00 2021-05-09 18:41:06,985 INFO [io.quarkus] (main) Installed features: [amazon-dynamodb, amazon-lambda, cdi, mutiny, resteasy, resteasy-jackson, resteasy-mutiny, smallrye-context-propagation]
2021-05-09T20:41:07.225+02:00 END RequestId: ccc69797-3e58-47b1-a475-f2b0cc93cd7d
2021-05-09T20:41:07.225+02:00 REPORT RequestId: ccc69797-3e58-47b1-a475-f2b0cc93cd7d Duration: 237.21 ms Billed Duration: 623 ms Memory Size: 128 MB Max Memory Used: 92 MB Init Duration: 385.04 ms从这一点我们可以看到，在启动后接收响应需要0.25秒(我认为，我对此完全没有经验)。但是，当命中返回水果列表(duh)的端点“成果”时，时间看上去有点不同：
2021-05-09T20:23:00.521+02:00 START RequestId: 1ee2002c-15ad-491e-b24a-591b8d371bae Version: $LATEST
2021-05-09T20:23:00.521+02:00 __ ____ __ _____ ___ __ ____ ______
2021-05-09T20:23:00.521+02:00 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
2021-05-09T20:23:00.521+02:00 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
2021-05-09T20:23:00.521+02:00 --\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2021-05-09T20:23:00.521+02:00 2021-05-09 18:23:00,516 INFO [io.quarkus] (main) quarkus-amazon-lambda-http-archetype 1.0-SNAPSHOT native (powered by Quarkus 1.13.3.Final) started in 0.249s.
2021-05-09T20:23:00.522+02:00 2021-05-09 18:23:00,521 INFO [io.quarkus] (main) Profile prod activated.
2021-05-09T20:23:00.522+02:00 2021-05-09 18:23:00,521 INFO [io.quarkus] (main) Installed features: [amazon-dynamodb, amazon-lambda, cdi, mutiny, resteasy, resteasy-jackson, resteasy-mutiny, smallrye-context-propagation]
2021-05-09T20:23:01.657+02:00 END RequestId: 1ee2002c-15ad-491e-b24a-591b8d371bae
2021-05-09T20:23:01.657+02:00 REPORT RequestId: 1ee2002c-15ad-491e-b24a-591b8d371bae Duration: 1133.83 ms Billed Duration: 1539 ms Memory Size: 128 MB Max Memory Used: 103 MB Init Duration: 404.57 ms
2021-05-09T20:23:30.341+02:00 START RequestId: a546afa3-78a2-4219-8cef-075694c320ac Version: $LATEST
2021-05-09T20:23:30.456+02:00 END RequestId: a546afa3-78a2-4219-8cef-075694c320ac
2021-05-09T20:23:30.456+02:00 REPORT RequestId: a546afa3-78a2-4219-8cef-075694c320ac Duration: 111.38 ms Billed Duration: 112 ms Memory Size: 128 MB Max Memory Used: 105 MB
2021-05-09T20:24:53.644+02:00 START RequestId: 65104eb8-1e53-453a-bd67-ef25d3a919af Version: $LATEST
2021-05-09T20:24:53.815+02:00 END RequestId: 65104eb8-1e53-453a-bd67-ef25d3a919af
2021-05-09T20:24:53.815+02:00 REPORT RequestId: 65104eb8-1e53-453a-bd67-ef25d3a919af Duration: 168.10 ms Billed Duration: 169 ms Memory Size: 128 MB Max Memory Used: 107 MB我们可以看到，第一个请求需要超过一个秒(我已经观察到它需要更长的时间)才能得到响应。到达相同端点后的请求，但速度相当快(即使要在其之上添加启动时间，也要快得多)。
所以这是我想知道的时间。为什么从DynamoDB获得第一个请求的响应要花费这么长的时间，我有什么办法可以改进它呢？
回答 1
Stack Overflow用户
发布于 2021-05-10 11:43:09
第一个对“新”Lambda实例的调用需要更长的时间，因为它必须被初始化。这也被称为冷启动。
检查第二个输出示例的以下两行：
Duration: 1133.83 ms Billed Duration: 1539 ms Memory Size: 128 MB Max Memory Used: 103 MB Init Duration: 404.57 ms和
Duration: 111.38 ms Billed Duration: 112 ms Memory Size: 128 MB Max Memory Used: 105 MB第一行的末尾是：Init Duration: 404.57 ms。第二个没有这个，因为它不需要初始化。
关键是:当启动一个新的Lambda实例时，需要初始化它，这需要时间。您不能对此做任何事情，除非尝试使初始化尽可能快，如果延迟是您的最高优先级。您可以尝试减少包的大小(越小越好)，您应该避免任何不必要的工作在您的初始化代码，也许它有助于增加您的Lambdas内存。
另一方面，在Lambda的初始化阶段，有很多事情是绝对应该做的，比如创建服务客户端、从SSM、S3或DynamoDB读取配置等等，但所有这些都延长了Lambda的初始化。好处是，以下所有请求都更快，因为它们不必这样做。
如果您不能进一步改进初始化，但仍然对第一个调用延迟不满意，那么据我所知，您有两个选择：
- 选择另一个具有更快“冷启动”时间的运行时。
- 使用提供的并发。
请注意，提供的并发确实需要额外的费用。
https://stackoverflow.com/questions/67461528
复制相似问题
腾讯云开发者
