FastAPI Gunicorn Uvicorn用于通过Google云运行进行生产部署（压力测试）

Question

在这里我想问你，用python运行gunicorn-uvicorn和tiangolo的默认值有什么区别？

我曾尝试使用JMeter和线程属性对它们进行压力测试：

通过这些，我得到了结果：

从上面我试过：

1. 带天戈罗基地的Dockerfile

这是我案例1（天戈罗基地）的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

这是我的案例2 Dockerfile（使用gunicorn命令的Python基础）：

FROM python:3.8-slim-buster as builder
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
COPY . /usr/src/app
ENTRYPOINT gunicorn --bind :8080 --workers 1 --threads 8 main:app --worker-class uvicorn.workers.UvicornH11Worker --preload --timeout 60 --worker-tmp-dir /dev/shm

这是我的案例3 Dockerfile（带Python命令的Python base）：

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"]

在这里我感到困惑，从上面的结果来看，它们的结果似乎相当相同，上面三种方法之间的区别是什么？哪一个最适合生产？很抱歉，我是生产部署API的新手。我需要一些关于这个案子的建议。非常感谢。

这是我的云运行命令

gcloud builds submit --tag gcr.io/gaguna3/priceengine

gcloud run deploy backend-pure-python \
    --image="gcr.io/gaguna3/priceengine" \
    --region asia-southeast2 \
    --allow-unauthenticated \
    --platform managed \
    --memory 4Gi \
    --cpu 2 \
    --timeout 900 \
    --project=gaguna3

Answer 1

有人建议，可以通过添加Gunicorn来获得比uvicorn更快的3x。

gunicorn-w4-kuvicorn。工人。UvicornWorker主：应用程序

有关更多详细信息和基准，请参阅：https://stackoverflow.com/a/63427961/2705777

Answer 2

根据您的示例，我注意到第一个容器使用的是经过微调的gunicorn版本，也在tiangolo的github页面中提到

此映像包含一个“自动调整”机制，因此您只需添加代码即可自动获得相同的高性能。

在我看来，这可以通过对gunicorn workers执行动态缩放和/或使用Cpython模块来实现。

第二个容器和第三个容器之间的区别是您为服务定义的工作线程的数量，在第二个容器中，您只有一个工作线程和8个线程，如果您使用配置，您可以提高性能，如本文所述。

使用tiangolo/uvicorn gunicorn不是一个坏主意，但我建议您锁定容器的版本，这是为了防止将来的更改影响您的生产环境。

另一方面，使用普通python图像可以定制图像，而不用担心会破坏某些东西，但这需要一些时间才能获得与tiangolodocker相同的性能。