Azure 应用服务上的 FastAPI-Docker 映像引发 [严重] 工作超时

Question

我正在 Azure 应用服务（2 核、3.5 GB 内存、操作系统：Linux）上运行自定义 FastAPI-Docker 映像（更具体地说是 python3.7 ）。该映像使用 Azure 容器注册表托管。

容器服务附加了 PDF 文件的请求，处理 PDF 文件并将结果返回到网站。然后，用户可以验证结果是否正确。如果结果正确，网站就会向 FastAPI 服务发送第二个 POST 请求，将结果存储在 AtlasDB 中。

最初，当Azure应用服务刚刚启动时，一切正常。然而，一段时间后，文件无法再使用该网站上传。服务崩溃并出现以下错误：

2020-11-02T14:21:40.225130726Z [2020-11-02 14:21:40 +0000] 1 [严重] 工作线程超时 (pid:9)

然而，这仅在上传一些文档后才会发生。引发错误所需的时间是不确定的。有时大约需要 90 秒，有时需要长达 3 分钟才能达到超时。其他可以在 90 秒内处理的文档仍然处理得很好。

起初，我以为这与gunicorn工人有关。我创建了一个自定义的 Gunicorn_conf.py（使用标准配置）并将 WORKERS_PER_CORE 增加到 3，并将 GRACEFUL_TIMEOUT 和 TIMEOUT 增加到 180 秒。 但错误仍然存在。此外，我还升级了应用服务计划，看看更多的计算能力是否可以解决问题。不幸的是，事实并非如此。

每当我在本地启动 docker-image 时，一切都会完美运行。 我的猜测是，该错误仍然与gunicorn-worker相关，但我找不到任何解决该问题的方法。我还下载了应用程序服务日志和容器日志，但没有任何进一步的信息或提示说明工作线程崩溃的原因。

有人对如何查找问题有一些建议吗？

预先感谢您，祝您有美好的一天！

Answer 1

在我正在从事的项目中遇到类似的问题，我在 main.py 文件中手动增加 guvicorn 超时，如下所示：

uvicorn.run(app, host="0.0.0.0", port=8000, env_file=".env", workers=workers, timeout=600)

修复方法是通过环境变量设置它，而不是对其进行硬编码。

硬编码时，当我检查应用程序服务日志时，它会显示为设置为 timeout=120 - 我认为这是默认值。

通过环境变量设置它后，这帮助我克服了超时问题，并成功覆盖了它。

这是更新后的代码。

确保您的 Web 应用程序中有一个名为 TIMEOUT 的环境变量。

使用以下代码修改您的 .py 文件：

import os
timeout = int(os.getenv("TIMEOUT", "600"))

uvicorn.run(app, host="0.0.0.0", port=8000, env_file=".env", workers=workers, timeout=timeout, log_level=log_level)

这将从 Azure 中获取您的环境变量并将其设置为您想要的值。

请务必更新适用的任何工作流程。