Вопрос: Зачем мне nginx, когда у меня есть uWSGI


Существует много руководств по настройке nginx для взаимодействия с uWGSI, когда я хочу развернуть приложение Django.

Но зачем мне nginx в этом комплекте? Сам uWSGI может обслуживать приложения WSGI Python, он может обслуживать статические файлы, он также может выполнять SSL. Что может делать nginx, который не может использовать uWSGI?


50
2018-04-23 14:44


Источник


Я вижу, что этот вопрос закрыт по мотивам мнения. Я абсолютно не согласен. Вопрос: «Что может делать nginx, какой uWSGI не может?» основан на фактах. - user983447
Я вообще не говорю за повторное открытие, но в этом случае я согласен. Существующий вышеприведенный ответ является хорошим, что показывает, что вопрос, как написано, допускает разумные и релевантные ответы; Я думаю, что, вероятно, это хороший вопрос. - MadHatter


Ответы:


Вы этого не сделаете.

В любом случае, это простой ответ - вы не необходимость Это. uWSGI сам по себе является надежным сервером.

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

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

Если бы я запускал «голый» uWSGI-сервер (и предполагая, что это был сайт Django, а не WordPress), он, возможно, справился бы с этим просто отлично - или он мог быть разбит и сожжен, что стоило мне пропущенных посетителей , Имея nginx перед ним, чтобы справиться с этой нагрузкой, действительно может помочь.

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


42
2018-04-23 15:25



Единственное, что приходит мне на ум, я думаю, стоит отметить в дополнение к тому, что @Kromey в своем ответе говорит о том, что собственный протокол для uWSGI - это не http, а протокол uwsgi. Протокол uwsgi проще и эффективнее, чем http, и, таким образом, использование более полнофункционального веб-сервера (nginx или whatnot) перед вашим приложением uWSGI фактически не дублирует много обработки и может давать значительные преимущества в зависимости от вашего необходимо. - Håkan Lindqvist
@ HåkanLindqvist абсолютно прав; просто уточнить, что uWSGI полностью способна «говорить» HTTP, однако, поэтому может стоять сама по себе просто прекрасно, но да, стоит отметить, что перед этим веб-сервер будет использовать протокол uwsgi, а не HTTP, для говорить с uWSGI, и, следовательно, да, очень мало дублирования в обработке. - Kromey
Это прекрасный ответ, однако его можно улучшить с помощью ссылки на собственную документацию uWSGI по этой теме, которая объясняет с большей детализацией, что вы Можно делать с uWSGI: uwsgi-docs.readthedocs.io/en/latest/... - Tobias McNulty


ИМО, если вы разместите свой веб-сайт в Интернете вместо Lab, вы можете увидеть разницу.

Представьте, что пользователь из другой страны с низким доступом к сети открывал веб-браузер для доступа к вашему сайту. uWSGI будет обрабатывать это соединение Http в потоке. Этот поток может потратить довольно долгое время, чтобы дождаться полного запроса Http из-за низкой скорости сети. Если размер пула потоков равен 100, представьте себе, что 100 пользователей так медленно, что произойдет? Нет простоя для обработки другого запроса Http.

Но для Nginx все совсем другое. Nginx разработан в «Reactor Pattern». Вы можете использовать Google Reactor Pattern, чтобы узнать, как это работает. Короче говоря, медленное соединение не влияет на обработку других запросов Http.


1
2018-05-26 09:45



Я сомневаюсь, что Nginx собирается это изменить. Когда приложение Django размещается на Apache с использованием WSGI, функция просмотра будет вызываться до того, как данные POST будут считаны из сокета. Поэтому, если клиент работает медленно, он будет занимать поток из запроса, который был получен до тех пор, пока данные POST не будут получены. Почему замена Apache на Nginx изменилась? - kasperd
Насколько я знаю, по умолчанию Nginx не будет запрашивать HTTP-запрос для поддержки сервера приложений до получения полного HTTP-запроса. Таким образом, для сервера приложений, такого как Django, то, что они получили, всегда является быстрым подключением и запросом HTTP, не теряя времени на ожидание полного HTTP-запроса, после того, как он быстро выполнил квест, работающий поток может быть бездействующим для следующего запроса Http в ближайшее время. - jcyrss
Он называется буферизацией запросов, который по умолчанию включен в Nginx (в более старых версиях Nginx было невозможно отключить это): nginx.org/en/docs/http/... - Tobias McNulty