WSGI против uWSGi с Nginx [закрыто]

89

Может ли кто-нибудь объяснить плюсы / минусы при использовании WSGI VS uWSGI с Nginx.

В настоящее время я создаю рабочий сервер для веб-сайта Django, который я подготовил, но не могу решить, следует ли мне использовать WSGI или uWSGI. Не могли бы вы подробно объяснить, что отличает каждую конфигурацию? Какая конфигурация лучше всего масштабируется?

заранее спасибо

python  django  nginx  wsgi  uwsgi 
— матрица страха
источник
Это сообщение в блоге представляет собой очень подробное сравнение множества серверов Python WSGI с резюме и некоторыми рекомендациями в конце.
— Lowe Thiderman
А также использует конфигурации для некоторых серверов, которые действительно хитры и заставляют их выглядеть хуже, чем они могут быть. Надо быть осторожным при чтении этого сравнения.
— Грэм Дамплтон,
25
WSGI - это спецификация. uWSGI предоставляет реализацию спецификации WSGI. Их нельзя сравнивать. Вы можете только сравнивать разные реализации.
— Грэм Дамплтон,

Ответы:

101

Хорошо, ребята, эта путаница связана с отсутствием подробностей из нескольких источников, а также из-за наименования этих протоколов и того, что на самом деле представляет собой WSGI.

Резюме:

  1. WSGI и uwsgi - это протоколы, а не серверы. Он используется для связи с веб-серверами для балансировки нагрузки и особенно для использования дополнительных функций, которые чистый HTTP не может предоставить. Пока что Nginx и Cherokee реализовали этот протокол.
  2. uWSGI - это сервер, и один из реализуемых им протоколов - WSGI (не путайте протокол uwsgi с сервером uWSGI). WSGI - это спецификация Python . Существует несколько реализаций спецификации WSGI, и она предназначена для использования не только для серверов приложений / веб-серверов, но существует довольно много серверов приложений WSGI (например, CherryPy, который также имеет готовый к производству веб-сервер, совместимый с WSGI. , если вы еще не достаточно запутались!).
  3. Сравнение uwsgi с WSGI - это сравнение апельсинов с яблоками.
— Дерек Литц
источник
3
Опечатка: «1. uwsgi - это протокол, а не сервер». -> «1. WSGI - это протокол, а не сервер».
— Aman
9
На самом деле, то, что я написал для 1, верно, но это правда, что WSGI - это протокол, а также uwsgi, поэтому оба написанных вами утверждения верны :). Конечно, без остального контекста 1. Это протокол, используемый сервером uWSGI. wiki.nginx.org/HttpUwsgiModule , - «Не путайте протокол uwsgi с сервером uWSGI (который использует протокол uwsgi)»
— Дерек Литц
4
Ах хорошо. Я думал, вы пытаетесь провести различие между утверждением 1. «wsgi - это протокол ..» и 2. «uwsgi - это сервер, реализующий протокол».
— Аман
2
@DerekLitz, на каких серверах django запускается, когда мы это делаем python manage.py runserver?
— Пиюш С. Ванаре
python manage.py runserverэто внутренний сервер, встроенный в Django. Это не apache, nginx, gunicorn или что-то еще. django-extensionsпредоставляет runserver_plusплатформу Werkzeug, но максимально приближенную к серверу runserver.
— Майк
32

Как правило, лучше всего запускать Python в отдельном процессе от вашего основного веб-сервера. Таким образом, веб-сервер может иметь множество крошечных потоков, которые очень быстро обслуживают статический контент, в то время как ваши отдельные процессы Python будут большими и тяжелыми, и каждый будет запускать свой собственный интерпретатор Python. Такой простой WSGI- это плохо, потому что он раздувает каждый из ваших потоков nginx большим интерпретатором Python. Использование flupили gunicornили uWSGIпозади nginxнамного лучше, потому что это освобождает nginx для простого обслуживания контента и позволяет вам выбирать, сколько крошечных легких потоков nginx запускать, независимо от вашего выбора, сколько тяжелых потоков Python вы вызываете для обслуживания динамического контента. gunicornНа данный момент люди кажутся очень довольными , но любой из этих трех вариантов должен работать нормально.

В будущем это также позволит вам переместить Python на другой сервер, когда нагрузка станет серьезной.

— Брэндон Роудс
источник
1
Меня немного смутил ваш ответ. Я не вижу, чтобы он упоминал о запуске какой-либо реализации WSGI внутри nginx. Он сослался на главный сайт wsgi.org. Его первоначальное сравнение WSGI и uWSGI, таким образом, немного глупо, прежде всего, потому что uWSGI является реализацией спецификации WSGI. Вы сами использовали общий термин WSGI в сбивчивой форме, говоря, что «он раздувает каждый из ваших потоков nginx большим интерпретатором Python». Сама спецификация WSGI не может этого сделать, только реализации.
— Грэм Дамплтон,
1
Это могло бы иметь смысл, если бы мы сравнивали nginx + mod_wsgi (подключаемый модуль) и nginx + uWSGI (контейнер сервера приложений).
— clime
Итак, когда дело доходит до использования Nginx для запуска веб-приложений Python, поскольку mod_wsgi Манлио Перилло является мертвой программой и не рекомендуется, хорошими решениями являются либо WSGI с gunicorn, либо uWSGI, либо FastCGI с Flup?
— Гульбахар
19

Я считаю, что это http://flask.pocoo.org/docs/deploying/uwsgi/ - хороший ответ, чтобы прояснить путаницу. Вопрос не глупый, случается с любым, кто видит эти два термина и не имеет предварительной информации о том, как все работает за пределами мира mod_PHP (например, ничего против php или людей)

На сайте хорошо объясняется на практике, что необходимо и в чем разница, а также хороший пример развертывания для nginx.

Для удобства здесь цитируется объяснение из Flask wiki:

uWSGI - это вариант развертывания на таких серверах, как nginx, lighttpd и cherokee; см. другие варианты в FastCGI и автономных контейнерах WSGI. Чтобы использовать ваше приложение WSGI с протоколом uWSGI, вам сначала понадобится сервер uWSGI. uWSGI - это и протокол, и сервер приложений; сервер приложений может обслуживать протоколы uWSGI, FastCGI и HTTP.

Самый популярный сервер uWSGI - это uwsgi, который мы будем использовать в этом руководстве. Убедитесь, что он установлен, чтобы продолжить.

— Абхишек Дуджари
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.