我们有一个内存为128 MB的Lambda函数，
我们在生产中使用它，我们每天收到成千上万(3-4K)的请求。
Lambda通过一个API网关对外公开，该网关是区域的，类型是REST。
我可以清楚地捕捉API网关和Lambda函数的度量。
API Gateway Metrics:
Latency 2000 ms on an Average,
Integration Latency 2300ms on an Average.
Lambda平均持续时间为3秒。
有时我们甚至遇到504网关超时异常，一天一次或两次。
我希望延迟减少如果我们增加内存大小，根据AWS博客
,如果我们将Lambda内存大小增加到1 GB(1024 MB)左右，504网关超时异常会消失吗?
或每天10 K个请求的理想内存大小是多少?
是否由于添加了额外的冷启动延迟而仅达到3000ms，或者当有可用实例时也会发生这种情况?
对于3000ms，您可以跳过各种各样的环和循环，以解决内存大小，预置并发性等问题。但我建议尝试改进代码/流程，使其运行如此长时间。我假设您的客户端也不热衷于调用在3000ms后响应的API ?
如果你可以摆脱它作为一个API，试着用SQS交换API网关，使它更像一个'worker'。
值得知道的是，增加lambda的RAM也会增加可用的CPU。因此，期望在很多情况下有更好的表现是合理的。事实上，将CPU增加一倍通常会使每毫秒的价格增加一倍，同时也会减少每2毫秒的调用时间。同样的价格，一半的延迟，划算!
然而这些经验法则有时根本不适用。你的lambda到底在做什么?
- 计算量大吗?然后增加CPU (，即。RAM(因为它们一起成长)肯定会有帮助 发送大量连续http请求并等待远程服务响应?那么你没有改善任何与更多的内存
这可能值得进行基准测试，但正如其他人所说，在花更多钱在CPU上之前，您可能应该首先找到您的瓶颈。
要找到最适合您的RAM值，只需缓慢地增加它，并观察变化，直到找到满意的值。每天请求的数量并不重要，更重要的是对平均调用进行微调。