增加 Lambda 函数的内存答案

【问题标题】：Increasing the Memory of a Lambda Function增加 Lambda 函数的内存
【发布时间】：2021-10-21 10:31:00
【问题描述】：

我们有一个内存为 128 MB 的 Lambda 函数，

我们在生产中使用它，我们每天收到数千 (3-4K) 个请求。

Lambda 通过区域性 API 网关对外公开，类型为 REST。

我可以清楚地捕捉 API Gateway 和 Lambda Function 的 Metrics。

API 网关指标：

 Latency 2000 ms on an  Average,
 Integration Latency 2300ms on an Average.

Lambda 平均持续时间为 3 秒。

有时我们甚至会遇到 504 网关超时异常，一天一次或两次。

如果我们增加内存大小，我预计延迟会降低，根据AWS Blog

所以，如果我们将 Lambda 内存大小增加到 1 GB（1024 MB）左右，504 网关超时异常会消失吗？

或者每天 10K 请求的理想内存大小是多少？

【问题讨论】：

在不知道您的 Lambda 函数的样子（即，您是否在每次处理函数调用时也都进行 初始化 工作？）以及实际瓶颈在哪里（即它是我/ O，因为您正在对需要很长时间的外部系统进行网络调用）不可能告诉您为什么您的函数需要这么长时间。您需要提供更多信息。

【解决方案1】：

是因为增加了额外的冷启动延迟而仅达到 3000 毫秒，还是在有可用实例时也会发生这种情况？

使用 3000 毫秒，您可以跳过各种循环，以便通过内存大小、预置并发等来解决它。但我建议尝试改进代码/流程，使其运行这么长时间。我会假设您的客户也不热衷于调用在 3000 毫秒后响应的 API？

如果您可以摆脱它作为 API，请尝试将 API 网关与 SQS 交换，并使其更像一个“工作者”。

【讨论】：

【解决方案2】：

值得知道的是，增加 lambda 的 RAM 也会增加可用 CPU。因此，在很多情况下期待更好的性能是合理的。事实上，将 CPU 翻倍往往会使每毫秒的价格翻倍，同时也会将每 2 的调用时间分开。同样的价格，一半的延迟，很划算！

然而

这些经验法则有时根本不适用。你的 lambda 实际上在做什么？

这可能值得进行基准测试，但正如其他人所说，您可能应该先找到瓶颈，然后再花更多的钱购买 CPU。

至于找到最适合您的 RAM 值，只需慢慢增加它，然后观察变化，直到找到满意的值。每天的请求数量并不重要，更多的是微调您的平均调用次数。

【讨论】：