FastAPI：一些请求由于 10 秒超时而失败

Question

我们在生产环境中部署了一个使用 FastAPI 的模型预测服务，不幸的是，一些请求由于 10 秒超时而失败。在并发请求方面，我们通常每秒只加载大约 2/3 个请求，所以我认为这不会对 FastAPI 造成太大压力。我们尝试做的第一件事是将 FastAPI 框架与模型本身隔离开来，当我们执行一些跟踪时，我们注意到在此段上花费了很多时间（6 秒）：starlette.exceptions:ExceptionMiddleware.__call__。

我们使用的 gunicorn 配置似乎也没有帮助：

"""gunicorn server configuration."""
import os
​
threads = 2
workers = 4
timeout = 60
keepalive = 1800
graceful_timeout = 1800
bind = f":{os.environ.get('PORT', '80')}"
worker_class = "uvicorn.workers.UvicornWorker"

非常感谢您就上述部分的含义以及在不太剧烈的负载下导致某些请求出现超时问题的原因提供一些指导。

Answer 1

关于上述部分含义的指导

here 你有官方的 gunicorn 配置文件，里面有很多解释。

由于您使用 gunicorn 来管理 uvicorn 工作人员，因此将超时设置为 60 秒对于 lnog 正在运行的任务应该可以正常工作（您应该考虑使用异步任务队列或像 celery 这样的作业队列）

但是返回您的路线的是什么？ 首先是查看您的 api 引发的错误

starlette.exceptions:ExceptionMiddleware.调用

由于您已扩展列表，您可以看到花费最多时间（如预期）的不是 fastapi 也不是 starlette，而是您在 app.api.routes.predictions 中运行。

所以我认为这不会对 FastAPI 造成太大压力

fastapi 并没有太大的压力，因为它不参与您的请求处理。请记住，fastapi“只是”一个框架，因此当您的功能需要时间时，问题出在您的功能/开发上。

这里它可以是导致长时间运行任务的那些事情之一或组合：

• 同步路由
• 在你的路由函数中阻塞 I/O 函数或处理
• 需要大量时间（可能太多）的预测算法
• 不适合您的治疗类型的工人阶级配置

当你经常做 AI 或 nlp 的事情时，如果需要大量的处理时间，关于在 api 中集成这些模型，你会使用像 celery 这样的任务队列。如果您的 api 没有错误并且您的路由没有返回错误，那么您应该花很多时间来看看实现任务队列。