Зачем мне нужен nginx, когда у меня есть uWSGI

62

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

Но зачем мне нужен nginx в этом комплекте? Сам uWSGI может обслуживать приложения WSGI Python, он может обслуживать статические файлы, он также может использовать SSL. Что может сделать nginx, чего не может 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, но вы должны по крайней мере рассмотреть что-то перед ним, чтобы помочь с нагрузкой. На самом деле, вы должны действительно тестировать различные конфигурации вашего готового сайта, чтобы определить, что лучше всего работает для вас при ожидаемой нагрузке, и использовать все, что в итоге окажется.

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

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

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

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

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