Навіщо мені потрібен nginx, коли у мене є uWSGI

62

Існує багато підручників про те, як налаштувати nginx для співпраці з uWGSI, коли я хочу розгорнути додаток Django.

Але навіщо мені потрібен nginx у цьому комплекті? uWSGI сам може обслуговувати програми WSGI Python, він може обслуговувати статичні файли, він також може робити SSL. Що може робити nginx, що uWSGI не може?

nginx django uwsgi

— user983447
джерело

9

Я можу бачити, що це питання закрите на основі думки. Я абсолютно не згоден. Питання "Що може робити nginx, що uWSGI не може?" заснований на фактах.

— user983447

1

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

— MadHatter

55

Ви цього не робите.

Це все одно проста відповідь - вона вам не потрібна . uWSGI сам по собі здатний сервер.

Однак інші сервери, такі як nginx, вже довші і є (можливо, у будь-якому випадку) більш безпечними, а також мають додаткові функції, які не підтримуються uWSGI - наприклад, поліпшене управління статичними ресурсами (за допомогою будь-якої комбінації Expires або E-Tag заголовки, стиснення gzip, попередньо стиснений gzip тощо), які можуть значно зменшити навантаження сервера та мережі; крім того, такий сервер, як nginx перед вашим додатком Django, також може реалізувати кешування вашого динамічного контенту, додатково допомагаючи зменшити навантаження сервера і навіть допомогти полегшити використання CDN (що зазвичай не добре підходить для динамічного вмісту ). Ви можете навіть піти далі і мати nginx на абсолютно окремому сервері, зворотній запит на просування динамічного вмісту до кластеру, збалансованому завантаженням серверів додатків, одночасно обробляючи статичний контент.

Наприклад, мій блог (хоча це WordPress, у нього є nginx), налаштований на кешування публікацій протягом 24 годин та кешування сторінок індексів протягом 5 хвилин; в той час як я не бачу достатнього трафіку для цього, щоб дійсно мати значення протягом більшої частини часу, це допомагає моїй крихітній маленькій VPS погоді випадковим сплеском, який в іншому випадку може збити його - наприклад, великий приплив трафіку, коли одну з моїх статей вибрали створив Twitterer з багатьма тисячами підписників, багато з яких повторно написали твіт своїм тисячам підписників.

Якби я запускав «голий» сервер uWSGI (і припускаючи, що це був сайт Django, а не WordPress), це, можливо, підійшло б до нього просто - або воно могло б розбитися і спалити, що коштувало мені за пропущених відвідувачів . Маючи nginx перед собою, щоб обробити це навантаження, дійсно може допомогти.

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

— Кромей
джерело

3

Єдине, що мені спадає на думку, що, на мою думку, варто відзначити, окрім того, що @Kromey висвітлював у своїй відповіді, - це те, що власний протокол для uWSGI - це не http, а протокол uwsgi. Протокол uwsgi простіший та ефективніший для вирішення, ніж http, і, таким чином, вставляти більш повнофункціональний веб-сервер (nginx чи що-небудь) перед вашим додатком uWSGI насправді не дублює багато обробки та може забезпечити значні переваги залежно від вашого потреби.

— Håkan Lindqvist

@ HåkanLindqvist абсолютно коректний; просто для уточнення, uWSGI цілком здатний "говорити" HTTP, однак, тому він може стояти сам по собі чудово, але так, добре варто зазначити, що веб-сервер перед ним використовує протокол uwsgi, а не HTTP, щоб говорити з uWSGI, і, отже, так, дуже мало дублювання пов'язаної обробки.

— Кромей

Це прекрасна відповідь, однак її можна було б покращити за допомогою посилання на власну документацію uWSGI по цій темі, де детальніше пояснюється, що можна зробити з uWSGI: uwsgi-docs.readthedocs.io/en/latest/…

— Tobias McNulty

1

IMO, якщо ви розмістите свій веб-сайт в Інтернеті замість лабораторії, ви можете побачити різницю.

Уявіть, що користувач з іншої країни з низькою швидкістю мережі відкриває веб-браузер для доступу до вашого веб-сайту. uWSGI буде обробляти це Http-з'єднання в потоці. Цей потік може витратити досить довго, щоб чекати повного Http-запиту через низьку швидкість мережі. Якщо розмір пулу потоків становить 100, уявіть, що 100 користувачів сподобаються настільки повільно, що буде? Немає холостого потоку для обробки іншого Http-запиту.

Але для Nginx все зовсім інше. Nginx розроблений у "Реакторній схемі". Ви можете google "Реактор шаблон", щоб побачити, як він працює. Коротше кажучи, з'єднання з низькою швидкістю не впливає на обробку інших Http-запитів.

— Jcyrss
джерело

1

Я сумніваюся, що використання Nginx змінить це. Коли програма Django розміщується на Apache за допомогою WSGI, функція перегляду буде викликана, перш ніж будь-які дані POST будуть прочитані з сокета. Отже, якщо клієнт повільний, він займатиме потік від запиту, який отримано до отримання даних POST. Чому заміна Apache на Nginx змінить це?

— kasperd

1

Як я знаю, за замовчуванням Nginx не буде проксі HTTP-запит на сервер додатка, поки не отримає повний HTTP-запит. Отже, для сервера аплікатонів, як Django, те, що вони отримували, - це завжди швидке підключення та запит HTTP, не витрачаючи часу на очікування повного запиту http, після обробки квесту незабаром запущена нитка може не працювати для наступного Http-запиту незабаром.

— Jcyrss

1

Він називається буферизацією запитів, який увімкнено за замовчуванням у Nginx (у старих версіях Nginx це не вдалося вимкнути): nginx.org/en/docs/http/…

— Tobias McNulty