-
Подними его под cherrypy - и быстрее и надежнее будет.
-
Подними его под cherrypy - и быстрее и надежнее будет.
redbaron, я себе подбираю вебсервер (апач ставить не хочу) для django, это правда что cherrypy + django быстрее чем nginx + django? нигде не встречал их сравнение. Хотел бы узнать об этом подробнее.
-
это правда что cherrypy + django быстрее чем nginx + django?
Не бывает конкретных ответов на такие вопросы. Потому что это зависит от гораздо большего числа факторов, чем веб-сервер. Кроме того, CherryPy — это не веб-сервер, а веб-сервер + дисптечер URL'ов + тредный мультиплексор. Nginx — это чистый реакторный веб-сервер, который с Джанго должен связываться чем-то еще: или собственным модулем (что неверно) или через отдельный backend-сервер (в качестве которого может в том числе и CherryPy выступать).
Нет, правда. Неправильно думать, что достаточно просто выбрать набор каких-то компонентов, и все будет быстро. Надо все таки представлять, что там и зачем, и для чего это надо вашему приложению.
-
да ничего особенного я не планирую, маленький блог, и ставить такой динозавр как апач желания нету, я предполагал что лучше всего подойдёт для этой цели nginx, а о cherrypy я не слышал. поэтом хотел бы узнать подробности, особенно заинтриговало "под cherrypy - и быстрее и надежнее". Дело даже не в быстроте, просто я терпеть не могу громадные кобайны функционал которых я практически использую.
-
особенно заинтриговало "под cherrypy - и быстрее и надежнее"
Честно говоря, под этим я бы не подписался. Особенно с идеей ставить его как фронтенд-сервер.
По сути, если вам не нужно "ничего особенного", то стандартные на данный момент решения:
- Апач + mod_wsgi
- lighttpd/nginx + FastCGI (средствами библиотеки flup)
Все остальное существует пока в виде многочисленных экспериментов.
терпеть не могу громадные кобайны функционал которых я практически использую
Вот это как раз CherryPy. Он, правда, не огромный, но вполне себе комбайн. По сути-то это целый фреймворк доджанговской эры.
-
Спасибо, Иван, Вы отбросили практически все мои вопросы, хотя я собственно и думал о варианте lighttpd/nginx + FastCGI, только ещё сомневался - lighttpd или nginx, но так как оба варианта считаются стандартными то скорее всего выберу продукт Игоря Сысоева.
-
aleo0
0
А еще есть Fapws, который тоже довольно быстрый.
http://piranha.org.ua/blog/2008/08/28/running-django/
http://piranha.org.ua/blog/2008/07/31/wsgi-servers-short/ -
Bothari0
0
Иван, если CherryPy это комбайн, то мне страшно дать определение жанге :)
-
Cherrypy не кобаин в данном контексте. Из него берётся только wsgiserver - маленький, легий и быстрый wsgi сервер. Перед ним ставится nginx для раздачи статики, я запросы в django шлет как обычный http proxy. Работает шустро и красиво, не течет, не падает.
Вот тут подробнее и всё что надо для запуска: http://lincolnloop.com/blog/2008/mar/25/serving-django-cherrypy/ -
Меня в нем беспокоит, что он мультиплексируется исключительно тредами. Или я ошибаюсь?
-
Если уж затронули тему fapws, напишу. Сервер работал не долго на fapws3, при небольшой нагрузке со скоростью всё отлично (на глаз). Но два глюка заставили перейти на fastcgi.
- Иногда перед DOCTYPE возникают два символа - восьмёрка и что-то непонятно-юникодное. Как правило в админке, не всегда, процентов 80. Почти вылечилось подключением в шаблонах i18n и мидлвари определения языка. Но иногда всё-же проблема возникала вновь.
- Ограничение на размер ответа. Если хтмл код был больше 112-144 кб, он обрезался. В итоге не работали большие аттачменты на pybb (выдаются через джангу) и некоторые большие странички (админские в основном, формсет 20 строк, в каждой select с сотней элементов).
Nginx + FastCGI - дешево и сердито.
-
Меня в нем беспокоит, что он мультиплексируется исключительно тредами. Или я ошибаюсь?
Тредами и процессами. Тредами внутри настроек cherrypy (по умолчанию 10 тредов), а процессами - пускаем несколько cherrypy на разных портах и потом в nginx делаем load balancing:
http { upstream myproject { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; server 127.0.0.1:8003; } server { listen 80; server_name www.domain.com; location / { proxy_pass http://myproject; } } } -
Тредами и процессами. Тредами внутри настроек cherrypy (по умолчанию 10 тредов), а процессами - пускаем несколько cherrypy на разных портах и потом в nginx делаем load balancing:
Так получается что только тредами. Сам он не форкается.
-
А, вы имеете ввиду динамические изменения в зависимости от нагрузки? Тогда только треды, но не вижу сложностей запускать еще worker по расписанию и делать reload на nginx, при этом он подхватит новый конфиг не разрывая текущих соединений.
-
Поддерживаю redbaron по поводу NGINX/FastCGI. С fawps3 были точно такие же проблемы, поставил, посмотрел, моментально снес. Еще у меня пару сайтов на Spawning работают, и пока проблем не было. Но он памяти, все-таки побольше ест. Для очень мелких сайтов, ставлю просто FastCGI в threaded режиме с одним процессом. Так на сайт уходит около 20 мегабайт.
-
Попробуйте еще fapws2 - внутри он очень отличается от fapws3.
-
баг в fapws3 уже пофиксили
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.