AWS Lambda性能问题

我使用与aws lambda（java）集成的aws api网关，但我在这种方法中看到了一些严重的问题。 删除服务器并让您的应用程序开箱即用的概念非常好，但这是我面临的问题。 我的lambda做了两件简单的事情 – validation从客户端收到的有效负载，然后将其发送到kinesis流，以便从另一个lambda进行进一步处理（你会问为什么我不直接发送到流，只使用1个lambda我只想说我想分离逻辑并有一层抽象，并且能够告诉客户他正在发送无效数据。）

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

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

接下来的事情就是在没有弹簧容器的情况下进行一些测试，因为我的想法是“好的，初始化很重，让我们只做普通的旧java对象初始化”。 不幸的是，同样的事情发生了（可能只是减少了一些请求的3s容器初始化）。 以下是测试数据的更详细截图：

所以我记录了整个lambda执行时间（从构造到结束），kinesis客户端初始化以及实际将数据发送到流，因为这些是lambda中最重的操作。 我们仍然有18岁或者其他什么时候，但有趣的是，时代在某种程度上是成比例的。 因此，如果整个lambda需要18秒，大约7-8s是客户端初始化，6-7用于将数据发送到流，而剩下4-5秒用于lambda中的其他操作，目前只是validation。 另一方面，如果我们采用其中一个小时间（这意味着它重用已经开始的lambda），即820ms，则kinesis客户端初始化需要100ms，数据发送需要340ms，validation需要400ms。 所以这再次推动了我内心因为一些限制而睡觉的想法。 下一个屏幕截图显示了当lamda已经启动时下一轮请求发生的情况：

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

所以我正在寻找一个实际上知道幕后发生了什么的人的澄清，因为对于使用云的严肃应用程序来说这不是一个好的行为，因为它具有“无限”的可能性。

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

Answer 1

lambda执行时间达到18秒，因为AWS会使用您的代码启动新容器来处理传入的请求。 自助时间约为18秒。

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

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

您可以要求AWS Support增加该限制。 我要求将该限制增加到10,000次调用/秒，AWS Support会很快完成！

Answer 2

您可以通过API网关直接代理Kinesis流。 您将在validation和转换方面失去一些控制权，但您不会有从Lambda看到的冷启动延迟。

您可以使用API​​网关映射模板来转换数据，如果validation很重要，您可以在流的另一端处理Lambda时执行此操作。