AWS Lambda性能问题

Question

我使用了与aws lambda（java）集成的aws api网关，但是我发现这种方法存在一些严重的问题。删除服务器并开箱即用地扩展应用程序的概念确实不错，但这是我面临的问题。我的lambda正在做2件简单的事情-验证从客户端收到的有效负载，然后将其发送到kinesis流以从另一个lambda进行进一步处理（您会问为什么我不直接发送到该流，而仅对所有lambda使用假设我们要分离逻辑并具有抽象层，并且还能够告诉客户端他正在发送无效数据。）

在执行lambda时，我集成了弹簧DI。到目前为止，一切都很好。我开始进行性能测试。我模拟了50个并发用户，每个用户发出4个请求，每个请求之间间隔5秒。所以发生了什么-在lambda的冷启动中，我初始化了spring的应用程序上下文，但似乎在未启动lambda时有这么多同时请求正在做一些奇怪的事情。这是上下文初始化时间的屏幕截图。

从屏幕截图中我们可以看到，初始化上下文的时间有很大的不同。我对发生的事情的假设是，当接收到如此多的请求并且没有“活动的” lambda时，它将为每个请求初始化一个lambda容器，并同时“阻止”其中的一些请求（时间很长的请求）。 18s），直到其他已经准备就绪。因此，也许它具有可以同时启动的容器的一些内部限制。问题是，如果您没有平均分配的流量，那么这将不时发生，并且某些请求将超时。我们不希望这种情况发生。

因此，接下来的事情是在没有spring容器的情况下进行一些测试，因为我的想法是“好的，初始化很繁重，让我们简单地对旧的Java对象进行初始化”。不幸的是，发生了同样的事情（也许只是减少了某些请求的3s容器初始化）。这是测试数据的更详细的屏幕截图：

因此，我记录了整个lambda执行时间（从构造到结束），kinesis客户端初始化以及将数据实际发送到流的过程，因为这些是lambda中最繁重的操作。我们仍然有18s左右的大时光，但有趣的是，时间以某种方式成比例。因此，如果整个lambda花费18s，则大约7-8s是客户端初始化，而6-7是用于将数据发送到流，而lambda中的其他操作还剩下4-5秒，目前仅是验证。另一方面，如果我们花一小段时间（这意味着它重用了已经启动的lambda），即820毫秒，则kinesis客户端初始化需要100毫秒，数据发送需要340毫秒，验证需要400毫秒。因此，这又使我再次想到这样的想法：由于某些限制，它在内部使一些睡眠。下一个屏幕截图显示了在启动lamda之后下一轮请求发生的情况：

所以我们没有那么大的时间，是的，我们在某些请求中仍然有一些相对较大的增量（对我来说这也很奇怪），但是情况看起来要好得多。

因此，我正在寻找一个真正了解实际情况的人进行澄清，因为对于使用云的严肃应用程序来说，这不是好行为，因为它存在“无限”的可能性。

另一个问题与区域内帐户中所有lambda中的lambda-200并发调用的另一个限制有关。对我来说，这对于流量很大的大型应用程序也是一个很大的限制。因此，就目前而言（我不知道未来），我的业务案例或多或少引起了人们的注意，忘记了请求。我开始考虑更改逻辑，以使网关将数据直接发送到流，而另一个lambda负责验证和进一步处理。是的，我正在失去当前的抽象（目前不需要），但是我在提高应用程序的可用性很多次。你怎么看？

Answer 1

lambda 执行时间飙升至 18 秒，因为 AWS 启动了带有您的代码的新容器来处理传入请求。自举时间约为 18 秒。

分配更多 RAM 可以显着提高 lambda 函数的性能，因为您拥有更多 RAM、CPU 和网络吞吐量！

另一个问题与某个区域账户内所有 lambda 的 lambda-200 并发调用的另一个限制有关。

您可以请求 AWS Support 提高该限制。我要求将该限制增加到每秒 10,000 次调用，AWS 支持很快就做到了！