🚀 WSGI, ASGI и серверы приложений

Короткий ответ WSGI — стандартный синхронный интерфейс между Python-приложением и веб-сервером; встроенный dev-сервер однопоточен и не выдерживает нагрузку, поэтому перед приложением ставят WSGI-сервер (Gunicorn, uWSGI), умеющий управлять несколькими рабочими процессами и таймаутами. Как это работает подробнее WSGI описывает простой контракт — приложение это вызываемый объект application(environ, start_response); любой WSGI-совместимый сервер может обслуживать любое WSGI-совместимое приложение. Пример кода Что использовать на практике Рекомендация. flask run удобен только для локальной разработки; в production запускают gunicorn app:app --workers 4 — несколько процессов-воркеров обрабатывают запросы через WSGI-интерфейс приложения. Подводные камни Риск. запускать встроенный dev-сервер в production, игнорируя предупреждение «development server»; думать, что WSGI сам ускоряет приложение — он просто определяет интерфейс.

Читать полностьюapplication-server

Короткий ответ Для CPU-bound нагрузки число воркеров выбирают близким к числу ядер (формула 2*CPU+1 как отправная точка), а для I/O-bound асинхронного приложения важнее, что один event loop может обслуживать много соединений без блокировки, поэтому большое число воркеров не ускоряет ожидание внешних сервисов. Как это работает подробнее каждый UvicornWorker — отдельный процесс с собственным event loop; GIL не даёт параллельно исполнять байткод Python в потоках одного процесса, поэтому параллелизм для CPU-bound ограничен числом процессов. Пример кода Что использовать на практике Рекомендация. начинают с workers = CPU_cores и нагрузочно тестируют с реалистичным профилем; для смешанной нагрузки тяжёлые вычисления выносят в отдельные процессы (Celery), а не раздувают число ASGI-воркеров. Подводные камни Риск. ставить огромное число воркеров на машине с малым числом ядер — приводит к избыточному потреблению памяти и конкуренции за CPU; не учитывать, что блокирующий вызов внутри async-обработчика блокирует весь even

Читать полностьюapplication-server

Короткий ответ Главный риск — скрытые блокирующие вызовы (синхронный ORM, сторонние SDK без async-версии), которые при наивном переносе блокируют весь event loop и снижают, а не повышают производительность; реальный выигрыш появляется только если весь путь запроса действительно асинхронный, а нагрузка преимущественно I/O-bound. Как это работает подробнее Django с 3.1+ поддерживает async view и ASGI, но исторический ORM синхронный — вызов внутри async def view без sync_to_async выбросит ошибку либо, при обёртке, выполнится в отдельном потоке, что добавляет overhead переключения, а не даёт истинного ускорения. Пример кода Что использовать на практике Рекомендация. нужен аудит всех внешних вызовов на пути запроса — для каждого найти async-альтернативу или вынести в sync_to_async; миграцию делают постепенно, view за view, с нагрузочным тестированием каждого изменённого участка. Компромисс. полный переход с переписыванием критического пути даёт потенциальный выигрыш при высокой I/O-bound конкурентности, но требует

Читать полностьюapplication-server

Короткий ответ sync — один запрос на воркер, блокируется на любом I/O; gthread — несколько потоков на воркер; gevent — кооперативная многозадачность через monkey-patching блокирующих вызовов, позволяющая держать тысячи ожидающих соединений, но требующая совместимости всех используемых библиотек. Как это работает подробнее sync блокируется до завершения запроса; gthread позволяет другому потоку работать, пока один ждёт I/O (отпуская GIL); gevent патчит стандартную библиотеку так, что блокирующие вызовы становятся неблокирующими greenlet-переключениями. Пример кода Что использовать на практике Рекомендация. переход на gevent/gthread выгоден, когда узкое место — ожидание сети; выигрыша не будет, если узкое место — CPU-bound вычисления (GIL всё равно не даёт параллельно исполнять Python-код), и возможны баги, если используются C-расширения, не совместимые с monkey-patching. Подводные камни Риск. включить gevent без проверки совместимости зависимостей — получают труднодиагностируемые «подвисания»; считать, что gev

Читать полностьюapplication-server