Я ищу слишком упрощенный ответ на следующий вопрос. Я пытаюсь создать фундаментальное понимание того, как Nginx работает вместе с чем-то вроде Gunicorn.
Нужен ли мне и Nginx, и что-то вроде Gunicorn для развертывания приложений Django на Nginx?
Если да, что на самом деле обрабатывает HTTP-запросы?
Ps. Я не хочу использовать Apache и mod_wsgi!
Ответы:
Слишком упрощенно: вам нужно что-то, что выполняет Python, но Python не лучший в обработке всех типов запросов.
[Отказ от ответственности: я разработчик Gunicorn]
Менее упрощенно: независимо от того, какой сервер приложений вы используете (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy), любое нетривиальное развертывание будет иметь что-то восходящее, что будет обрабатывать запросы, которые ваше приложение Django не должно обрабатывать. Тривиальными примерами таких запросов являются статические ресурсы (images / css / js).
Это приводит к двум первым уровням классической «трехуровневой архитектуры». Т.е. веб-сервер (в вашем случае Nginx) будет обрабатывать множество запросов на изображения и статические ресурсы. Запросы, которые необходимо генерировать динамически, будут затем передаваться на сервер приложений (в вашем примере Gunicorn). (Кроме того, третий из трех уровней - это база данных)
Исторически говоря, каждый из этих уровней будет размещаться на отдельных компьютерах (и, скорее всего, на первых двух уровнях будет несколько компьютеров, т.е. 5 веб-серверов отправляют запросы на два сервера приложений, которые, в свою очередь, запрашивают одну базу данных).
В современную эпоху у нас есть приложения всех форм и размеров. Не каждый проект выходного дня или сайт малого бизнеса на самом деле нуждаются в мощности нескольких машин и будут работать довольно успешно на одной коробке. Это породило новые записи в массив хостинговых решений. Некоторые решения соединяют сервер приложений с веб-сервером (Apache httpd + mod_wsgi, Nginx + mod_uwsgi и т. Д.). И вполне обычно размещать базу данных на той же машине, что и одна из этих комбинаций веб-серверов и приложений.
Теперь в отношении Gunicorn мы приняли конкретное решение (копирование из Unicorn Руби), чтобы отделить вещи от Nginx, полагаясь на поведение прокси Nginx. В частности, если мы можем предположить, что Gunicorn никогда не будет читать соединения напрямую из Интернета, то нам не нужно беспокоиться о клиентах, которые работают медленно. Это означает, что модель обработки для Gunicorn очень проста.
Разделение также позволяет писать Gunicorn на чистом Python, что сводит к минимуму затраты на разработку и не оказывает существенного влияния на производительность. Это также дает пользователям возможность использовать другие прокси (при условии, что они буферизуются правильно).
Что касается вашего второго вопроса о том, что на самом деле обрабатывает HTTP-запрос, простой ответ - Gunicorn. Полный ответ - Nginx и Gunicorn обрабатывают запрос. По сути, Nginx получит запрос, и если это динамический запрос (обычно основанный на шаблонах URL), то он передаст этот запрос в Gunicorn, который обработает его, а затем вернет ответ Nginx, который затем перенаправит ответ обратно в исходный клиент.
Итак, в заключение, да. Вам нужно и Nginx и Gunicorn (или что-то подобное) для правильного развертывания Django. Если вы специально хотите разместить Django с Nginx, я бы рассмотрел Gunicorn, mod_uwsgi и, возможно, CherryPy в качестве кандидатов на сторону Django.
источник
Мне понравилось это объяснение в его простоте:
https://gist.github.com/Atem18/4696071
источник
Слишком упрощенный ответ:
ДА.
И Nginx и Gunicorn.
Поскольку вы развертываете на Nginx, конечно, вам нужен Nginx.
Поскольку вы развертываете Django, который является веб-фреймворком, вам нужно что-то связующее между веб-сервером (Nginx) и веб-фреймворком (Django). В мире Python такая вещь называется сервером WSGI (но думаю, что это промежуточное ПО), примерами которого являются Gunicorn и uWSGI. При обработке запроса Nginx передает запрос в Gunicorn или uWSGI, который, в свою очередь, вызывает код Django и возвращает ответ.
Этот документ и ответ Пола помогут вам узнать его лучше.
источник
Gunicorn - это пустая трата ресурсов. Вы можете просто прокси передать django, слушая порт, вместо запуска gunicorn поверх django и снова nginx поверх всего этого. В тестах я видел очень заметное увеличение скорости. Nginx может легко обрабатывать прямые запросы к django. Gunicorn - это не что иное, как эстакада (фактически более медленный эстакада) над обычной дорогой. Он просто сидит и пожирает ваши ресурсы и пытается заявить, что работает на вашем сайте.
nginx в основном буферизует все запросы и обрабатывает запросы статических файлов самостоятельно (если вы настроили его таким образом). И передает весь динамический контент на другой сервер. (Gunicorn / django).
Gunicorn не имеет другого применения, кроме как просто передать запрос в приложение. Это как соломинка, которую можно пить из стекла напрямую или пить из соломы в ограниченном темпе (здесь пьющий - джанго). А nginx - официант, который принес тебе стакан сока.
Я проверил и нашел это - с оружейным: 22 тыс. Запросов / с без оружейного: 34 тыс. Запросов / с
Вашему сайту понадобятся дополнительные требования при большой нагрузке.
источник