Отдельные серверы для обслуживания приложения django и его содержимого?

Я немного не понимаю, как действовать дальше. Я настраиваю Django для работы на сервере Mediatemple DV. Я пытаюсь найти подходящую настройку для обслуживания изображений, видео и т. Д.

Я не совсем понимаю, что это означает в http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/

Мы рекомендуем использовать отдельный веб-сервер, т. Е. Тот, на котором еще не работает Django, для обслуживания мультимедиа. Вот несколько хороших вариантов:

lighttpd, Nginx, TUX, урезанная версия Apache, Cherokee

Означает ли это, что я должен обслуживать Django на одном экземпляре Apache (через mod_wsgi), а затем обслуживать его содержимое на другом экземпляре Apache или одной из альтернатив, указанных выше? Я могу сделать это на том же выделенном виртуальном сервере, верно? Если да, то какой совет, как мне это сделать?

Спасибо!


django apache mod-wsgi serving mediatemple
person pcpc33    schedule 05.04.2011    source источник

Ответы (3)


arrow_upward
7
arrow_downward

Большинству людей отдельный медиа-сервер не нужен. Растет критика по поводу того, что документация Django слишком либеральна, подталкивая людей в этом направлении, когда в этом нет необходимости.

Так что сначала не беспокойтесь, и если вы используете mod_wsgi, используйте также веб-сервер Apache для статических носителей. Тем не менее, рекомендуется убедиться, что вы запускаете приложение WSGI в режиме демона mod_wsgi, так как в этом случае процессы, обслуживающие статические файлы, будут небольшими и не будут нести накладные расходы по сравнению с фактическим динамическим веб-приложением.

Если вы слишком беспокоитесь об использовании памяти, также прочтите:

http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html.

Посмотрите, как это все происходит, и только тогда, когда самого Apache кажется недостаточно, тогда подумайте об использовании другого сервера для обработки мультимедиа, предпочтительным вариантом является использование nginx для обработки статических мультимедиа, при этом nginx также действует как прокси для Apache / mod_wsgi. Использование nginx впереди фактически позволяет Apache / mod_wsgi работать лучше, чего не будет при использовании nginx в отдельном домене.

person Graham Dumpleton    schedule 06.04.2011

arrow_upward
2
arrow_downward

По сути, он говорит о том, что вы должны использовать apache с помощью mod_wsgi для обслуживания вашего приложения django и использовать более легкий веб-сервер, такой как nginx, для обслуживания вашего статического контента.

Например.

www.yourapp.com -> apache -> mod_wsgi -> ваше приложение django

static.yourapp.com -> nginx

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

Если вы настроите nginx так, чтобы он обрабатывал весь веб-трафик, вы можете отменить все запросы django через прокси к apache, находящемуся за ним, и перехватить все статические файлы и обслуживать их прямо из nginx.

см. эти ссылки для получения дополнительной информации.

http://codespatter.com/2009/04/23/how-to-speed-up-your-django-sites/

django: обслуживание статических файлов через nginx

https://serverfault.com/questions/122809/django-serving-static-files-through-nginx

https://serverfault.com/questions/199038/serving-static-files-fails-nginx < / а>

person Ken Cochrane    schedule 05.04.2011

arrow_upward
-1
arrow_downward

Кен прав в своей оценке и рекомендует обслуживать все, что стоит за прокси-сервером NGINX. Это путь.

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

Если вы смотрите на большое количество пользователей и большой трафик, разбивка медиа-сервера на его собственную машину предотвратит сбой друг друга и даст вам немного больше гибкости.

Ознакомьтесь с Gunicorn, если вы еще этого не сделали, поскольку это молниеносный, простой в развертывании сервер приложений и новая популярность .

person Dana Woodman    schedule 05.04.2011