Существует множество руководств о том, как настроить nginx для взаимодействия с uWGSI, когда я хочу развернуть приложение Django.
Но зачем мне в этом комплекте nginx? Сам uWSGI может обслуживать приложения WSGI Python, он может обслуживать статические файлы, он также может выполнять SSL. Что может nginx, чего не может uWSGI?
Вы этого не сделаете.
В любом случае это простой ответ - вы не необходимость Это. uWSGI сам по себе способный сервер.
Однако другие серверы, такие как nginx, существуют дольше и (возможно, в любом случае) более безопасны, а также имеют дополнительные функции, не поддерживаемые uWSGI - например, улучшенную обработку статических ресурсов (с помощью любой комбинации Expires или E-Tag заголовки, сжатие gzip, предварительно сжатое сжатие gzip и т. д.), которые могут значительно снизить нагрузку на сервер и сеть; Кроме того, сервер, такой как nginx, перед вашим приложением Django может также реализовать кеширование вашего динамического контента, что еще больше помогает снизить нагрузку на сервер и даже помогает облегчить использование CDN (что обычно не очень хорошо работает с динамическим контентом. ). Вы могли бы даже пойти дальше и иметь nginx на полностью отдельном сервере, обратном проксировании запросов динамического контента в кластер серверов приложений с балансировкой нагрузки при одновременной обработке статического контента.
Например, мой блог (хотя это WordPress, но перед ним есть nginx) настроен на кеширование сообщений на 24 часа и на кеширование страниц индекса на 5 минут; хотя я не вижу достаточно трафика, чтобы это действительно имело значение большую часть времени, это помогает моему маленькому VPS выдерживать периодические всплески, которые в противном случае могли бы его сбить - например, большой всплеск трафика, когда одна из моих статей была выбрана Твиттер с тысячами подписчиков, многие из которых ретвитнули его тысячам подписчиков.
Если бы у меня был «голый» сервер uWSGI (и если бы это был сайт Django, а не WordPress), он мог бы противостоять ему просто отлично - или он мог бы дать сбой и сгореть, стоив мне пропущенных посетителей . Наличие nginx перед ним для обработки этой нагрузки действительно может помочь.
При этом, если вы просто запускаете небольшой сайт, который не будет видеть много трафика, нет никакой реальной необходимости в nginx или чем-то еще - просто используйте uWSGI самостоятельно, если вы этого хотите. С другой стороны, если вы увидите много трафика ... ну, вы по-прежнему Возможно, вам понадобится uWSGI, но вы должны хотя бы подумать перед ним, чтобы помочь с нагрузкой. На самом деле вам действительно следует провести нагрузочное тестирование различных конфигураций готового сайта, чтобы определить, что лучше всего подходит для вас при ожидаемой нагрузке, и использовать то, что в итоге получится.
IMO, если вы разместите свой сайт в Интернете вместо Lab, вы можете увидеть разницу.
Представьте себе пользователя из другой страны с низкой скоростью сети и открытым веб-браузером для доступа к вашему сайту. uWSGI будет обрабатывать это HTTP-соединение в потоке. Этот поток может потратить довольно много времени на ожидание полного запроса Http из-за низкой скорости сети. Если размер вашего пула потоков равен 100, представьте, что 100 пользователей так медленно работают, что произойдет? Нет незанятого потока для обработки другого запроса Http.
Но для Nginx все иначе. Nginx разработан по схеме «реактор». Вы можете погуглить "Reactor Pattern", чтобы увидеть, как это работает. Короче говоря, медленное соединение не влияет на обработку других запросов Http.