uWSGI — серверная платформа для размещения веб-приложений на Python (WSGI, ASGI), Ruby (Rack), PHP, Perl и других языках. В большинстве случаев uWSGI стоит за Nginx в роли application server: Nginx принимает HTTP-запросы клиентов и передаёт их uWSGI через Unix-сокет по протоколу uwsgi (бинарный) или HTTP.
Как работает
uWSGI запускает пул рабочих процессов (workers), каждый из которых загружает Python-приложение в память. При поступлении запроса от Nginx свободный worker обрабатывает его и возвращает ответ. Для Python это означает: Django или Flask не запускается заново для каждого запроса — приложение постоянно живёт в памяти worker-процессов.
Типовая конфигурация Nginx → uWSGI для Django:
location / {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/myapp.sock;
}
uWSGI поддерживает Emperor-режим — мастер-процесс управляет несколькими приложениями по конфиг-файлам в директории vassals. При изменении конфига приложение автоматически перезагружается (graceful reload) без остановки сервера.
История
uWSGI разработан итальянским разработчиком Робертом Де Маркизом с 2009 года. Проект вырос из решения для хостинга Python-приложений на общем сервере. С 2012 года uWSGI поддерживает SPDY и WebSocket. Параллельно развиваются альтернативы: Gunicorn (более простой, только Python), Daphne (ASGI для Django Channels), Uvicorn (ASGI, быстрее для async-кода).
Связь с хостингом
На VPS с Python-приложениями стек Nginx + uWSGI — стандарт для Django-проектов. Systemd-юнит uWSGI обеспечивает автоперезапуск при сбоях. При высокой нагрузке количество workers настраивается динамически (harakiri timeout, cheaper-initial). Для async-фреймворков (FastAPI, Starlette) предпочтительнее Uvicorn или Daphne, поскольку uWSGI не поддерживает native async в Python 3.11+.
Принцип работы uWSGI
uWSGI реализует протокол WSGI (PEP 3333) для запуска Python-приложений. Nginx → uWSGI Socket (Unix socket или TCP) → Python-процесс. Режимы: pre-fork (несколько worker-процессов), threaded, async. Для Django и Flask — стандартный production-стек.
Типичная конфигурация
INI-файл: module = myapp.wsgi:application, workers = 4, threads = 2, socket = /run/app.sock. Systemd unit для автозапуска. Nginx: uwsgi_pass unix:/run/app.sock + include uwsgi_params.
uWSGI vs Gunicorn
Gunicorn: проще в настройке, достаточен для большинства проектов. uWSGI: больше возможностей (async с gevent, Emperor-режим для нескольких приложений, harakiri-тайм-аут). Для высоконагруженных Django — uWSGI с --harakiri 30 (убивает зависшие воркеры). ASGI-приложения (FastAPI, Django 4+) используют Uvicorn вместо Gunicorn/uWSGI.
uWSGI Emperor mode
Emperor: один uWSGI процесс управляет несколькими приложениями. Конфиг: uwsgi --emperor /etc/uwsgi/apps-enabled/*.ini. Каждое приложение — отдельный .ini файл в папке. Автоматический перезапуск при изменении конфига. Удобно для хостинга нескольких Python-приложений на одном сервере.
Мониторинг uWSGI
uWSGI Stats Server: stats = /tmp/uwsgi.stats.sock → uwsgitop /tmp/uwsgi.stats.sock. Метрики: workers активны/idle, запросы/сек, медиана времени ответа. Prometheus exporters: uwsgi_exporter. statsd-push plugin: экспорт метрик в StatsD каждые N секунд.