Quarkus - DynamoDB HTTP lambda缓慢的首次响应
我创建了一个测试项目，其中我结合了两个指南：Quarkus-DynamoDB和Quarkus-HTTP lambda。这样做的最终目标是有一个lambda与DynamoDB通信的示例项目，这一切都是本机编译的（使用GraalVM）。
这运行得相对较好。我设法使用第二个指南中的工具将项目部署到AWS lambda，并且在调用endpoint时得到的响应与预期一致。
然而，我对性能有一些疑问，尤其是在创业之后。
当点击第一个指南中的简单“hello”endpoint时，时间如下：
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秒才能收到响应（我认为这是可以预料的，我真的没有这方面的经验）。但是，当命中endpoint“水果”（返回水果列表（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
我们可以看到，在得到响应之前，第一个请求占用了一秒钟的时间(我观察到它占用了更长的时间)。之后的请求到达同一个endpoint，但是非常快(快得多，即使您在它上面加上启动时间)。
所以我想知道的是这里的时间。为什么从DynamoDB的第一个请求得到响应需要这么长时间，我有什么方法可以改进这一点？
共有1个答案
对“新”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
第一行的末尾是这样的：初始化持续时间：404.57 毫秒。第二个没有这个，因为它不需要初始化。
关键是：当一个新的Lambda实例启动时，它需要初始化，这需要时间。你对此无能为力，除非在延迟是你的最高优先级时尝试尽可能快地进行初始化。你可以尝试减小包大小（越小越好），你应该避免初始化代码中任何不必要的工作，也许这有助于增加你的Lambda内存。
另一方面，在Lambda的初始化阶段，有很多事情是你绝对应该做的，比如创建服务客户端，从SSM或S3或DynamoDB读取配置，等等。但所有这些都在延长你的Lambda的初始化。好处是所有后续请求都更快，因为它们不必这样做。
如果你不能进一步改进初始化，但是你仍然不满意第一次调用的延迟，那么据我所知，你有两个选择:
- 选择另一个冷启动时间更快的运行时。
- 使用预配的并发。
请注意，预配的并发确实需要额外付费。
-
我不熟悉vertx和RxJava。我正在尝试实现一个简单的测试程序。然而，我无法理解这个项目的动态。为什么有些请求需要10秒钟以上才能响应？ 下面是我的示例测试应用程序 我想知道的是，是什么让我的响应时间变慢了？
-
我已将自动完成功能应用于两个。为此，我使用了自动完成计算器。我观察到它的速度减慢到我甚至无法输入一个字符的程度。有什么解决办法吗？ 谢谢
-
我们正在Azure应用服务上运行WebJob和Api。一些WebJob执行对第三方服务（如ebay）的REST呼叫。所有这些都很好，直到几天前，服务开始随机抛出这个错误： 调用有时工作，但非常慢，有时会返回错误。运行服务的本地实例不会导致失败。只有在正式生产环境中，我们才会遇到这些问题。 我们使用HttpClient的一个单例实例来执行调用。 我们这样使用客户端调用endpoint： GetMes
-
我在Spring Boot MVC 2.1项目中使用WebClient，发现客户端发出的第一个请求需要6秒。后续请求的速度要快得多（~30ms）。 在Spring的JIRA中有一个封闭的问题，建议使用Jetty作为WebClient Http连接器。我已经尝试了这种方法，改进了数字，第一个请求约为800ms。这次是一个改进，但它仍然远离RestTemplate，它通常采取 Netty 方法（5 秒
-
在我们的一个java应用程序中，我们有很多协议缓冲区类，jar本质上公开了一个接口和另一个应用程序使用的一种方法。我们注意到第一次调用这个方法的调用时间相当高（ 这一点在另一个应用程序中得到进一步证实，该应用程序的工作方式完全不同，但也使用协议缓冲区，表现出相同的行为。此外，我们还尝试创建一个虚拟实例（）以及我们添加的每个proto buffer类，我们都可以注意到第一次调用丢弃的开销。 在里面N
-
Im使用RCONE在微型存储桶和共享存储之间传输数据。我正在迁移一个商店，数据量约为200GB的产品图片。每个图片都有自己的文件夹/路径。因此，有很多文件夹需要创建来保存。Rclone安装在新服务器上，存储通过san连接到服务器。传输已经进行了一个多星期，我们现在的容量是170GB。一切都很好，但在我看来它真的很慢。从bucket到经典文件系统的传输有这么慢，这正常吗？