Uvicorn 和 Gunicorn+Uvicorn 有什么区别?

Rud*_*tra 9 gunicorn google-cloud-run fastapi uvicorn

部署使用 Uvicorn 和Tiangolo 的 Gunicorn+Uvicorn dockerized 的FastAPI 应用程序有什么区别?为什么我的结果表明,仅使用 Uvicorn 进行部署时我会得到比 Gunicorn+Uvicorn 更好的结果?

当我在 Tiangolo 的文档中搜索时,它说:

您可以使用 Gunicorn 来管理 Uvicorn 并运行多个这些并发进程。这样,您可以获得最佳的并发性和并行性。

由此,我可以假设使用这个 Gunicorn 会得到更好的结果吗?

这是我使用 JMeter 进行的测试。我将脚本部署到 Google Cloud Run,结果如下:

使用 Python 和 Uvicorn:

在此处输入图片说明

使用 Tiangolo 的 Gunicorn+Uvicorn:

在此处输入图片说明

这是我的 Python Dockerfile (Uvicorn):

FROM python:3.8-slim-buster
RUN apt-get update --fix-missing
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y libgl1-mesa-dev python3-pip git
RUN mkdir /usr/src/app
WORKDIR /usr/src/app
COPY ./requirements.txt /usr/src/app/requirements.txt
RUN pip3 install -U setuptools
RUN pip3 install --upgrade pip
RUN pip3 install -r ./requirements.txt --use-feature=2020-resolver
COPY . /usr/src/app
CMD ["python3", "/usr/src/app/main.py"]
Run Code Online (Sandbox Code Playgroud)

这是我用于 Tiangolo 的 Gunicorn+Uvicorn 的 Dockerfile:

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.8-slim
RUN apt-get update && apt-get install wget gcc -y
RUN mkdir -p /app
WORKDIR /app
COPY ./requirements.txt /app/requirements.txt
RUN python -m pip install --upgrade pip
RUN pip install --no-cache-dir -r /app/requirements.txt
COPY . /app
Run Code Online (Sandbox Code Playgroud)

您可以从 Tiangolo 的 Gunicorn+Uvicorn 中看到错误。它是由Gunicorn引起的吗?

已编辑。

因此,就我而言,我使用延迟加载方法来加载我的机器学习模型。这是我加载模型的类。

FROM python:3.8-slim-buster
RUN apt-get update --fix-missing
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y libgl1-mesa-dev python3-pip git
RUN mkdir /usr/src/app
WORKDIR /usr/src/app
COPY ./requirements.txt /usr/src/app/requirements.txt
RUN pip3 install -U setuptools
RUN pip3 install --upgrade pip
RUN pip3 install -r ./requirements.txt --use-feature=2020-resolver
COPY . /usr/src/app
CMD ["python3", "/usr/src/app/main.py"]
Run Code Online (Sandbox Code Playgroud)

而且,这是我的 API 的端点。

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.8-slim
RUN apt-get update && apt-get install wget gcc -y
RUN mkdir -p /app
WORKDIR /app
COPY ./requirements.txt /app/requirements.txt
RUN python -m pip install --upgrade pip
RUN pip install --no-cache-dir -r /app/requirements.txt
COPY . /app
Run Code Online (Sandbox Code Playgroud)

小智 77

Gunicorn是一个应用程序服务器,它使用WSGI协议与您的 Web 应用程序进行交互。这意味着 Gunicorn 可以为使用FlaskDjango等同步 Web 框架编写的应用程序提供服务(对于 2021 年之前发布的版本更是如此)。Gunicorn 负责运行 Web 应用程序的多个实例,确保它们运行正常并根据需要重新启动它们,在这些实例之间分发传入请求并与 Web 服务器通信。除此之外,Gunicorn 的速度相当快。为了优化它,我们付出了很多努力。Gunicorn 本身与 FastAPI 不兼容,因为 FastAPI 使用新鲜的ASGI标准。

Uvicorn是一个支持ASGI协议的应用服务器。它还可以选择启动和运行多个工作进程。然而,Uvicorn 处理工作进程的能力比 Gunicorn 更有限。

Uvicorn 有一个与 Gunicorn 兼容的工人阶级。这将允许您在 Gunicorn 中运行 asgi-app!因此,如果您想在该级别(Python 级别)拥有一个好的进程管理器,您可以使用 Gunicorn 作为 asgi-app 的进程管理器!

如果您有一个包含KubernetesDocker Swarm或其他类似复杂系统的机器集群来管理多台机器上的分布式容器,那么您可能希望在集群级别处理复制,而不是使用进程管理器(例如带有工作线程的 Gunicorn)每个容器。像 Kubernetes 这样的分布式容器管理系统之一通常具有某种集成的方式来处理容器的复制,同时仍然支持传入请求的负载平衡。全部在集群级别。在这些情况下,您可能希望从头开始构建 Docker 映像,安装依赖项并运行单个 Uvicorn 进程,而不是使用 Uvicorn 工作线程运行 Gunicorn 之类的东西。

  • Gunicorn 中的 ASGI 支持问题至今已持续 6 年([此处](https://github.com/benoitc/gunicorn/issues/1380),任何人都可以贡献自己的力量:) (8认同)
  • 但请注意,k8s pod 并不是 Gunicorn Worker 的真正实用替代品 - 举一个问题:节点可以处理的 pod 数量限制远低于每个用户的进程数量(250-1000)(最多420 万)。 (3认同)