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

89

Хтось може пояснити плюси / мінуси при використанні WSGI VS uWSGI з Nginx.

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

Спасибі заздалегідь

python  django  nginx  wsgi  uwsgi 
— матриця_страху
джерело
Цей допис у блозі - це дуже детальне порівняння багатьох серверів Python WSGI із підсумком та деякими рекомендаціями в кінці.
— Lowe Thiderman
А також використовує конфігурації для деяких серверів, які насправді хитромудрі та роблять їх гіршими, ніж можуть бути. Потрібно бути обережним, що читаєш у порівнянні.
— Грехем Дамплтон,
25
WSGI - це специфікація. uWSGI забезпечує реалізацію специфікації WSGI. Ви не можете їх порівняти. Ви можете порівнювати лише різні реалізації.
— Graham Dumpleton

Відповіді:

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 - це протокол, а не сервер."
— Аман
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.
— Mike DeSimone
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 Manlio Perillo є програмним забезпеченням і не рекомендується, хорошими рішеннями є або WSGI або з gunicorn, або uWSGI, або FastCGI з Flup?
— Gulbahar
19

Я вважаю, що це тут http://flask.pocoo.org/docs/deploying/uwsgi/ є гарною відповіддю для усунення плутанини. Питання не безглузде, трапляється з кожним, хто бачить ці два терміни і не має попередньої інформації про те, як все працює за межами світу mod_PHP (наприклад, нічого проти php чи людей)

Цей сайт добре пояснює на практиці, що потрібно і в чому різниця, а також хороший приклад розгортання для nginx.

Для зручності тут наводиться пояснення з вікі Flask:

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.