Может ли кто-нибудь объяснить плюсы / минусы при использовании WSGI VS uWSGI с Nginx.
В настоящее время я создаю рабочий сервер для веб-сайта Django, который я подготовил, но не могу решить, следует ли мне использовать WSGI или uWSGI. Не могли бы вы подробно объяснить, что отличает каждую конфигурацию? Какая конфигурация лучше всего масштабируется?
Это сообщение в блоге представляет собой очень подробное сравнение множества серверов Python WSGI с резюме и некоторыми рекомендациями в конце.
Lowe Thiderman
А также использует конфигурации для некоторых серверов, которые действительно хитры и заставляют их выглядеть хуже, чем они могут быть. Надо быть осторожным при чтении этого сравнения.
Грэм Дамплтон,
25
WSGI - это спецификация. uWSGI предоставляет реализацию спецификации WSGI. Их нельзя сравнивать. Вы можете только сравнивать разные реализации.
Грэм Дамплтон,
Ответы:
101
Хорошо, ребята, эта путаница связана с отсутствием подробностей из нескольких источников, а также из-за наименования этих протоколов и того, что на самом деле представляет собой WSGI.
Резюме:
WSGI и uwsgi - это протоколы, а не серверы. Он используется для связи с веб-серверами для балансировки нагрузки и особенно для использования дополнительных функций, которые чистый HTTP не может предоставить. Пока что Nginx и Cherokee реализовали этот протокол.
uWSGI - это сервер, и один из реализуемых им протоколов - WSGI (не путайте протокол uwsgi с сервером uWSGI). WSGI - это спецификация Python . Существует несколько реализаций спецификации WSGI, и она предназначена для использования не только для серверов приложений / веб-серверов, но существует довольно много серверов приложений WSGI (например, CherryPy, который также имеет готовый к производству веб-сервер, совместимый с WSGI. , если вы еще не достаточно запутались!).
Сравнение uwsgi с WSGI - это сравнение апельсинов с яблоками.
Опечатка: «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 на другой сервер, когда нагрузка станет серьезной.
Меня немного смутил ваш ответ. Я не вижу, чтобы он упоминал о запуске какой-либо реализации 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, который мы будем использовать в этом руководстве. Убедитесь, что он установлен, чтобы продолжить.
Ответы:
Хорошо, ребята, эта путаница связана с отсутствием подробностей из нескольких источников, а также из-за наименования этих протоколов и того, что на самом деле представляет собой WSGI.
Резюме:
источник
python manage.py runserver
?python manage.py runserver
это внутренний сервер, встроенный в Django. Это не apache, nginx, gunicorn или что-то еще.django-extensions
предоставляетrunserver_plus
платформу Werkzeug, но максимально приближенную к серверуrunserver
.Как правило, лучше всего запускать Python в отдельном процессе от вашего основного веб-сервера. Таким образом, веб-сервер может иметь множество крошечных потоков, которые очень быстро обслуживают статический контент, в то время как ваши отдельные процессы Python будут большими и тяжелыми, и каждый будет запускать свой собственный интерпретатор Python. Такой простой
WSGI
- это плохо, потому что он раздувает каждый из ваших потоков nginx большим интерпретатором Python. Использованиеflup
илиgunicorn
илиuWSGI
позадиnginx
намного лучше, потому что это освобождает nginx для простого обслуживания контента и позволяет вам выбирать, сколько крошечных легких потоков nginx запускать, независимо от вашего выбора, сколько тяжелых потоков Python вы вызываете для обслуживания динамического контента.gunicorn
На данный момент люди кажутся очень довольными , но любой из этих трех вариантов должен работать нормально.В будущем это также позволит вам переместить Python на другой сервер, когда нагрузка станет серьезной.
источник
Я считаю, что это http://flask.pocoo.org/docs/deploying/uwsgi/ - хороший ответ, чтобы прояснить путаницу. Вопрос не глупый, случается с любым, кто видит эти два термина и не имеет предварительной информации о том, как все работает за пределами мира mod_PHP (например, ничего против php или людей)
На сайте хорошо объясняется на практике, что необходимо и в чем разница, а также хороший пример развертывания для nginx.
Для удобства здесь цитируется объяснение из Flask wiki:
источник