django - 请求通过 Zappa 部署在 AWS Lambda 中的 Django 应用程序花费的时间太长

Question

我最近使用 Zappa 将 Django 后端应用程序部署到 AWS Lambda .
在一段时间未调用 lambda 函数后，要发出的第一个请求需要从 10 到 15 秒 待处理。起初我以为是因为冷启动，但即使是冷启动，这次也是 Not Acceptable 。然后，通过阅读 Zappa 的文档，我看到它默认启用 keep_warm每 4 分钟向 lambda 函数发送一个虚拟请求以使其保持温暖的功能；因此，响应第一个 lambda 请求的过度延迟不是由于冷启动。
然后，我开始使用 AWS X-Ray 和 Cloudwatch Insights 等工具试图找到延迟的原因。这是我发现的:
需要很长时间来处理的调用如下:

用红色划掉的是应用程序使用的环境变量的名称。它们都是直接在 AWS 控制台中定义和分配的值。我不明白的是，首先，为什么需要这么长时间，其次，为什么它说环境变量被强制转换为 None .该应用程序运行良好(除了第一个请求中的大量延迟)，因此环境变量在某处正确设置。
该请求每两个小时发出一次，并且是一段时间内第一次有人调用 lambda 函数，如下图所示:

x 轴上的点对应于 Zappa 保持服务器温暖的虚拟请求。升高的点对应于上图中显示的调用。最后，峰值对应于用户调用。处理所需的时间是处理长调用(第一个图像中显示的调用)所需的时间与处理客户端向服务器发出的最长 http 请求所需的时间的总和。该请求如下:

这是一个应该更快解决的常规登录请求。其他可能比这个要求更高的请求在不到 100 毫秒内得到解决。
所以，总结一下:

有一个 lambda 调用需要 10 多秒才能解决。这对应于显示的第一个图像。它每 2 小时执行一次，并且在用户空闲一段时间后向服务器发出请求时执行一次。

有些请求需要 2 秒以上才能解决，我不知道为什么会这样。

除了这些先前的函数调用之外，所有其他请求都会在合理的时间范围内解决。

关于为什么这些调用会花费这么多时间的任何想法都非常感谢，因为我花了相当多的时间试图自己解决这个问题，但我已经没有想法了。先感谢您!
编辑 1 (28/07/21):为了进一步支持我的怀疑，此延迟不是由于冷启动，这里是 Cloudwatch/应用程序监控/跟踪中功能的“段时间线”:

如果是冷启动，延迟应该出现在“初始化”部分而不是“调用”部分。
编辑 2 (30/07/21):我忘了提到我之前使用 Elastic Beanstalk 部署了应用程序并且没有遇到任何问题，所以我的代码的性能是 可能 不是这里的问题。
编辑 3 (30/07/21):我找到了 this thread在 2016 年的 AWS 论坛中，关于这个确切问题。一位 AWS 工程师提到，对于 VPC 之外的 Lambda 函数(如我的)，这种行为绝不是预期的。然而，没有提供任何答案来解释 10-15 秒延迟的原因。
编辑 4 (03/08/21):我尝试将函数的分配内存(从 512 MB 增加到 1024 MB)加倍，但没有帮助。

Answer 1

我还在问题中添加了一些评论，以解释这可能不是由于冷启动。正如您正确地指出的那样，冷启动被明确指示并且在您的情况下似乎只需要大约 500 毫秒。
冷启动这么长时间通常只在 lambda 表达式在 VPC 中运行时才会出现。 AWS 已经改变了 lambdas 获取其网络接口(interface)的方式，这大大加快了这个过程。
话虽如此，在 Google 上的快速搜索让我在其他网站上找到了一些关于 Django 应用程序和延迟加载的有趣讨论。我将在这里分享一些链接(即使它们与 Lambda 无关)，希望它们可以帮助您找到解决方案:
https://community.webfaction.com/questions/11560/django-app-seems-very-slow-to-start-up-10-seconds
https://ses4j.github.io/2015/11/23/optimizing-slow-django-rest-framework-performance/
作为关于 keep_warm 的最后说明。发送这些请求是书中的一个老技巧。但是，请注意，AWS 无法保证 lambda 保持温暖的时间。如果 Init duration已在日志中指明，但是，您可以确定这是一个冷启动。
如果你需要确保一个 lambda 函数是温暖的并且能够快速响应传入的请求，你必须使用 provisioned concurrency ，当然有自己的价格标签。