несколько django сайтов

через wsgi попробуй

и да, а чем эта жока не канает ? https://docs.djangoproject.com/en/1.2/howto/deployment/modpython/

пробовал. Дело в том, что первый сайт к которому обращаешься перекрывает остальные.

mod_python устарел же.

Дело в том, что первый сайт к которому обращаешься перекрывает остальны

Что значит «перекрывает»?

Мы такое через lighttpd и fastcgi делаем, это довольно просто, и тяжелого апача нет. Он-то джанге вообще не нужен, если подумать. Nginx тоже подойдёт, он хороший.

Гугление особых результатов не дало, т.к. все рецепты ориентированны на версию джанги 1.3.

А у тебя какая?

Вот тебе рецепты для 1.2, раз уж так: https://docs.djangoproject.com/en/1.2/howto/deployment/modwsgi/

Всё это дело засовываешь в апачевский virtualhost и вперёд.

Через wsgi по одному сайту на один виртхост.

Мы такое через lighttpd и fastcgi делаем, это довольно просто, и тяжелого апача нет. Он-то джанге вообще не нужен, если подумать. Nginx тоже подойдёт, он хороший.

А висящие толпы manage.py - это не тяжёлый апач, это легко и удобно. Не говоря уже о том, что fastcgi в принципе тормознее будет, чем wsgi.

у меня 1.4. В нем немного по другому проект выглядит.

Каким образом?

А висящие толпы manage.py - это не тяжёлый апач, это легко и удобно. Не говоря уже о том, что fastcgi в принципе тормознее будет, чем wsgi.

А разве апач с wsgi не будет запускать эти же толпы под нагрузкой?

Там выше была ссылка на настройку одного сайта с wsgi. Всё точно так же, только под каждый сайт пишется свой wsgi-скрипт по шаблону и свой виртхост. Как настроить множество виртуальных хостов в апаче, вроде бы уже все знают. Или нет? :)

нет, не будет

Он их будет запускать по мере надобности. Те, что наиболее часто используются, будут запущены практически всегда. Остальные - реже. Ведь нас никто не заставляет держать множество prefork-процессов, слушающих всегда. А так же не обязательно заставлять дёргать django для статических файлов, настроив алиасы.

Если нагрузка сильно большая, перед апачем ставится проксирующий nginx с кешированием и натравливается на отдачу статики. В такой конфигурации у меня «тяжёлый» апач вместе с nginx'ом справлялись в несколько раз лучше, чем fcgi+nginx. А всё дело в том, что апач - это не монстр, которого воткнул и смотришь, как он тормозит, а мощный и гибкий веб-сервер и при допиливании под ситуацию(как и с любой программой в принципе) работает отлично.

Он их будет запускать по мере надобности. Те, что наиболее часто используются, будут запущены практически всегда. Остальные - реже. Ведь нас никто не заставляет держать множество prefork-процессов, слушающих всегда.

Но если проект и так нагружен, то разве будет значительная разница? Понятно, что если на хостинге куча сайтов, и некоторые редко сильно нагружают, то решение с fcgi будет всегда есть больше памяти, и разница будет.

И раз уж такой разговор, то что можно сказать об nginx+uwsgi?

апач - это не монстр, которого воткнул и смотришь, как он тормозит, а мощный и гибкий веб-сервер

вах, приятно видеть, что я не одинок в своем мнении (:

Но если проект и так нагружен, то разве будет значительная разница?

Моя практика показывает, что wsgi отзывчивее, чем fscgi под большой нагрузкой. Собственно, на схему apache(wsgi)+nginx я перешёл с django fastcgi+nginx, потому что ошибки о недоступности посыпались и ресурсы на сервере кончаться начали. :)

И раз уж такой разговор, то что можно сказать об nginx+uwsgi?

Ещё не добрались руки протестить.

что можно сказать об nginx+uwsgi?

оптимальный вариант, давно только такое использую.

оптимальный вариант, давно только такое использую.

Я уже тоже:)

Блин, не заметил что старый тред. Мне уведомление прилетело по тэгу.