Самая чистая и быстрая настройка сервера для Django

Официально рекомендуемый способ развертывания проекта django - использовать mod_python с apache. Это описано в документация.. Главное преимущество в том, что это лучший документированный, наиболее поддерживаемый и наиболее распространенный способ развертывания. Минус в том, что он, вероятно, не самый быстрый.

Как сказал @Barry, в документации используется mod_python. Я не использовал Ubuntu в качестве сервера, но имел хороший опыт работы с mod_wsgi на Solaris. Вы можете найти документацию для mod_wsgi и Django на сайте mod_wsgi.

Быстрый обзор ваших требований:

• Легко настроить Я нашел apache 2.2 довольно простым в сборке и установке.
• Быстро и легко на ресурсах Я бы сказал, что это зависит от вашего использования и трафика. * Возможно, вы не захотите размещать все файлы на сервере с помощью Apache и использовать LightTPD (светлый) для серверных статических файлов.
• Может обслуживать медиафайлы Я так понимаю, вы имеете в виду изображения, файлы прошивки? Apache может это сделать.
• Несколько сайтов на одном сервере Хостинг виртуальных серверов на Apache.
• Лучше не устанавливать другие расширения Закомментируйте все, что вам не нужно, в конфигурации Apache.

Если вы используете lighthttpd, вы также можете использовать FastCGI для обслуживания Django. Я не уверен, как скорость сравнивается с mod_wsgi, но если память обслуживает правильно, вы получите несколько преимуществ, которые вы получите с mod_wsgi, которых вы не получите с mod_python. Основной из них заключается в том, что вы можете предоставить каждому приложению свой собственный процесс (что действительно полезно для разделения памяти разных приложений, а также для использования преимуществ многоядерных компьютеров.

Обновлено: просто чтобы добавить к вашему обновлению о nginix, если память снова работает правильно, nginix использует «гринлеты» для обработки параллелизма. Это означает, что вам, возможно, придется быть немного осторожнее, чтобы одно приложение не занимало все время сервера.

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

Некоторые общие рекомендации - использовать отдельный веб-сервер для обработки мультимедиа. Под отдельным я подразумеваю веб-сервер, на котором не работает Django. Этот сервер может быть, например:

• Lighttpd (Светлый)
• Nginx (EngineX)
• Или какой-нибудь другой легкий сервер

Затем для Django вы можете пойти разными путями. Вы также можете:

• Обслуживайте Django через Apache и:

  • mod_python

    Это стабильный и рекомендуемый / хорошо документированный способ. Минусы: использует много памяти.

  • mod_wsgi

    Насколько я понимаю, mod_wsgi - более новая альтернатива. Оказывается, это быстрее и проще по ресурсам.

  • mod_fastcgi

    При использовании FastCGI вы делегируете обслуживание Django другому процессу. Поскольку mod_python включает интерпретатор Python в каждый запрос, он использует много памяти. Это способ обойти эту проблему. Также есть некоторые проблемы с безопасностью.

    Что вы делаете, так это то, что вы запускаете свой сервер Django FastCGI в отдельном процессе, а затем настраиваете apache с помощью перезаписи для вызова этого процесса при необходимости.

Или вы можете:

• Обслуживайте Django без использования Apache, но с другим сервером, который изначально поддерживает FastCGI:

  (В документации упоминается, что вы можете сделать это, если у вас нет особых потребностей Apache. Я думаю, причина должна заключаться в экономии памяти.)

  • Lighttpd

  Это сервер, на котором работает Youtube. Он кажется быстрым и простым в использовании, однако я видел отчеты об утечках памяти.

  • nginx

  Я видел тесты, которые утверждали, что этот сервер даже быстрее, чем lighttpd. Хотя в основном это задокументировано на русском языке.

Другое дело, из-за ограничений Python ваш сервер должен работать в разветвленном режиме, а не в многопоточном.

Это мое текущее исследование, но мне нужно больше мнений и опыта.

Мы используем nginx и FastCGI для всех наших развертываний Django. Это в основном потому, что мы обычно развертываем на Slicehost и не хотим отдавать всю нашу память Apache. Думаю, это был бы наш «вариант использования».

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

Думаю, лучшая конфигурация не так известна. Но вот:

1. Используйте nginx для обслуживания запросов (динамический для приложения, статический контент напрямую).
2. Используйте веб-сервер python для обслуживания динамического контента.

Два самых быстрых решения для веб-сервера на основе Python:

• коген
• fapws2

Вам нужно заглянуть в Google, чтобы найти текущую лучшую конфигурацию для django (все еще в разработке).

Я использую nginx (0.6.32 взято у Сида) с mod_wsgi. Он работает очень хорошо, хотя я не могу сказать, лучше ли он, чем альтернативы, потому что я никогда не пробовал их. Nginx имеет встроенную поддержку memcached, которая, возможно, может взаимодействовать с промежуточным программным обеспечением кэширования Django (я фактически не использую его, вместо этого я заполняю кеш вручную с помощью python-memcache и аннулирую его при внесении изменений), поэтому попадания в кеш полностью обходят Django (моя машина для разработки может обслуживать около 3000 запросов в секунду).

Предостережение: nginx mod_wsgi очень не любит именованные местоположения (он пытается передать их в SCRIPT_NAME), поэтому очевидное "error_page 404 = @django" вызовет множество непонятных ошибок. Чтобы это исправить, мне пришлось пропатчить исходный код mod_wsgi.

Я тоже изо всех сил пытаюсь понять все варианты. В это сообщение в блоге я обнаружил некоторые преимущества mod_wsgi по сравнению с объяснением mod_python.

Несколько сайтов с низким трафиком на небольшом VPS делают потребление оперативной памяти основной проблемой, и mod_python кажется здесь плохим вариантом. Используя lighttpd и FastCGI, мне удалось получить минимальное использование памяти простого сайта Django до 58 МБ виртуальной и 6,5 МБ резидентной (после перезапуска и обслуживания одного запроса, не связанного с ОЗУ).

Я заметил, что обновление с Python 2.4 до 2.5 в Debian Etch увеличило минимальный объем памяти, занимаемой процессами Python, на несколько процентов. С другой стороны, лучшее управление памятью в 2.5 может иметь больший обратный эффект на длительные процессы.

Я использую Чероки.

Согласно их ориентиры (немного скептически), он справляется с нагрузкой лучше, чем Lighttpd и nginx ... Но я использую его не поэтому.

Я использую его, потому что, если вы наберете cherokee-admin, он запустит новый сервер, на который вы можете войти (с одноразовым паролем) и настроить весь сервер с помощью прекрасно выполненного webmin. Это потрясающая функция. Это уже сэкономило мне много времени. И это экономит моему серверу много ресурсов!

Что касается django, я запускаю его как многопоточный SCGI-процесс. Работает хорошо. Чероки тоже может держать его в рабочем состоянии. Опять же, очень приятная функция.

Текущая версия репозитория Ubuntu очень старая, поэтому я бы посоветовал вам использовать их PPA. Удачи.

Будьте проще: Django рекомендует Apache и mod_wsgi (или mod_python). Если обслуживание файлов мультимедиа является очень важной частью вашего сервиса, рассмотрите возможность использования Amazon S3 или Rackspace CloudFiles.

Есть много способов сделать это, поэтому я рекомендую внимательно прочитать статью о процессе развертывания на DjangoAdvent.com: Эрик Флоренцано - Развертывание Django с FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/ Читайте тоже: Майк Мэлоун - Масштабирование Django Блог Stochastictechnologies: идеальная установка Django Блог Миккеля Хоэга: 35% -ное время отклика-переключение-uwsgi-nginx

С Уважением

На мой взгляд, лучший / самый быстрый стек - varnish-nginx-uwsgi-django. И я успешно им пользуюсь.

У меня есть предупреждение за использование Cherokee. Когда вы вносите изменения в Django Cherokee, он поддерживает СТАРЫЙ процесс, вместо того, чтобы убивать его и запускать новый.

На Apache я настоятельно рекомендую эту статью.

http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl

Его легко настроить, легко убить или сбросить после внесения изменений.

Просто введите терминал

sudo /etc/init.d/apache2 restart

и изменения видны мгновенно.