В чем разница между Uvicorn и Gunicorn

Что проверяют

Понимаете ли вы, что это серверы для разных интерфейсов приложения, и знаете ли, как их запускают вместе в проде.

Как отвечать

Разница в интерфейсе, с которым они работают. Gunicorn это WSGI-сервер: синхронная модель, каждый запрос обрабатывается рабочим процессом от начала до конца, так работают Django и Flask. Uvicorn это ASGI-сервер: асинхронная модель поверх цикла событий, так работают FastAPI, Starlette и Django в асинхронном режиме.

Второе различие в устройстве: Gunicorn умеет управлять пулом рабочих процессов, следит за ними, перезапускает зависшие, поддерживает плавную перезагрузку. Uvicorn это в первую очередь сам сервер.

Отсюда классическая связка в проде: Gunicorn как управляющий процессами, а рабочие процессы уже с классом Uvicorn.

gunicorn app.main:app -k uvicorn.workers.UvicornWorker -w 4

Так получаются и асинхронная обработка, и присмотр за процессами. В свежих версиях Uvicorn умеет запускать несколько рабочих сам (--workers), поэтому связка перестала быть обязательной, но управление процессами у Gunicorn богаче.

Что ещё стоит сказать: число рабочих обычно берут по числу ядер (для синхронной модели ориентир «ядра умножить на два плюс один»); один блокирующий вызов внутри асинхронного приложения останавливает весь цикл событий, поэтому смешивать модели опасно; перед сервером в любом случае ставят обратный прокси вроде nginx для TLS, статики и таймаутов.

Где спотыкаются

Запускают асинхронное приложение под обычным рабочим Gunicorn и получают ошибку интерфейса или синхронное поведение.

Ставят десятки рабочих процессов «для скорости», не считая память: каждый процесс это своя копия приложения.

Держат --reload в проде, хотя он предназначен только для разработки.