我使用与 aws lambda(java) 集成的 aws api 网关，但我发现这种方法存在一些严重的问题。删除服务器并使您的应用程序开箱即用的概念非常好，但这是我面临的问题。我的 lambda 正在做 2 件简单的事情 - 验证从客户端收到的有效负载，然后将其发送到 kinesis 流以从另一个 lambda 进行进一步处理(您会问为什么我不直接发送到流并且只对所有使用 1 个 lambda的操作。假设我想分离逻辑并有一个抽象层，并且还能够告诉客户端他正在发送无效数据。)。
在 lambda 的实现中，我集成了 spring DI。到现在为止还挺好。我开始做性能测试。我模拟了 50 个并发用户发出 4 个请求，每个请求间隔 5 秒。那么发生了什么 - 在 lambda 的冷启动中，我初始化了 spring 的应用程序上下文，但似乎在 lambda 未启动时有如此多的并发请求正在做一些奇怪的事情。这是上下文初始化时间的屏幕截图。
我们从截图中可以看出，初始化上下文的时间有很大的不同。我对发生的事情的假设是，当收到如此多的请求并且没有“Activity ”的 lambda 时，它会为每个请求初始化一个 lambda 容器，同时它“阻止”其中的一些(那些有大量时间的请求) 18s)直到其他人已经开始准备好。因此，它可能对可以同时启动的容器有一些内部限制。问题是，如果您的流量分布不均，这种情况会不时发生，并且某些请求会超时。我们不希望这种情况发生。
所以接下来的事情是在没有 spring 容器的情况下做一些测试，因为我的想法是“好吧，初始化很重，让我们只做普通的旧 java 对象初始化”。不幸的是，同样的事情发生了(可能只是减少了某些请求的 3s 容器初始化)。下面是更详细的测试数据截图:
因此，我记录了整个 lambda 执行时间(从构造到结束)、kinesis 客户端初始化以及将数据实际发送到流，因为这些是 lambda 中最繁重的操作。我们仍然有 18 岁之类的大时代，但有趣的是，时代在某种程度上是成正比的。因此，如果整个 lambda 需要 18 秒，大约 7-8 秒是客户端初始化，6-7 秒用于将数据发送到流，还有 4-5 秒用于 lambda 中的其他操作，目前只是验证。另一方面，如果我们采取一个小的时间(这意味着它重用已经启动的 lambda)，即820ms，kinesis客户端初始化需要100ms，数据发送需要340ms，验证需要400ms。因此，这再次促使我想到，由于某些限制，它在内部会沉睡。下一个屏幕截图显示了当 lamda 已经启动时下一轮请求中发生的事情:
所以我们没有这么大的时间，是的，我们在某些请求中仍然有一些相对较大的增量(这对我来说也很奇怪)，但事情看起来好多了。
因此，我正在寻求真正了解幕后情况的人的澄清，因为对于使用云的严肃应用程序来说，这不是一个好的行为，因为它具有“无限”的可能性。
另一个问题与一个区域内一个账户内所有 lambda 表达式中 lambda-200 并发调用的另一个限制有关。对我来说，这对于拥有大量流量的大型应用程序来说也是一个很大的限制。因此，作为我目前的商业案例(我不知道 future )或多或少是火了，忘记了请求。我开始考虑以网关将数据直接发送到流的方式更改逻辑，而另一个 lambda 负责验证和进一步处理。是的，我正在失去当前的抽象(我目前不需要)，但我多次增加了应用程序的可用性。你怎么认为？
最佳答案
lambda 执行时间飙升至 18 秒，因为 AWS 使用您的代码启动新容器来处理传入请求。引导时间约为 18 秒。
分配更多 RAM 可以显着提高 lambda 函数的性能，因为您拥有更多 RAM、CPU 和网络吞吐量!
And another question is related to another limit of the lambda-200 concurrent invocations in all lambdas within an account in a region.
您可以要求 AWS Support 提高该限制。我要求将该限制增加到 10,000 次调用/秒，AWS Support 很快就做到了!
关于java - AWS Lambda 性能问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43089879/