Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Хорошая статья. Хоть и не использую Джанго увидел FastCGI и нет смотрю волшебного слова nginx в преамбуле и в ключевых словах — полез читать как реализовано. Ан нет — без nginx и тут не обошлось )
lighttpd/cherokee рекомендуется разработчиками, а про nginx на сайте Django ни слова, если не ошибаюсь
почему был выбран именно nginx не очень понятно, не думаю что тот же lighttpd чем-то хуже был бы…
почему был выбран именно nginx не очень понятно, не думаю что тот же lighttpd чем-то хуже был бы…
Дело вкуса, видимо. Я взял cherokee + uwsgi, в первую очередь и из-за хорошей документации и большого сообщества. Ну и потому, что на 160 мб vps (вместе с mysqld) крутится это оч шустро.
Я думаю Nginx или lighthttpd — дело вкуса. Nginx мне лично более знаком и нравиться, да и с Игорем Сысоевым можно даже лично поговорить, если уж очень надо :) Он кстати сам говорит, что легковестные веб-сервера нет смысла пытаться ускорить, так как они в основном большей частью вызывают функции нижележащей операционной системы. Так что более важно настраивать ее :) И еще один момент — доля серверов на nginx в мире постоянно растет и сейчас уже достигает 8%, если верить этой информации: www.linux.org.ru/news/russia/4373637, а lighthttpd заметно отстает.
Спасибо! Был без интернета сутки, не мог сразу ответить :)
Если мы хотим использовать команду sudo с нашим пользователем, то нам так же нужно отредактировать /etc/service
Подозреваю, речь шла об /etc/sudoers
Оставляя в стороне всякие незначительные стилистические моменты типа вопросительных знаков в описаниях опций и странности в обращении к читателю (то на «ты», то на «вы», причем именно с маленькой буквы), хочется заметить, что перевод пары терминов на русский (на мой вкус) выглядит спорным:
— «метод конкуренции» — неудачная калька с английского. Метод распараллеливания, способ одновременного исполнения,…
— «и это очень хорошее чтение» — под «чтением» обычно подразумевают процесс. «Чтиво» (если просторечно) или, например, источник.
Сам откладывал чтение Advent'а до выхода последней статьи, поэтому Ваш перевод прочитал раньше оригинала. Большое спасибо за труд; сборка советов очень грамотная, поэтому буду использовать сам и рекомендовать в качестве памятки.
— «метод конкуренции» — неудачная калька с английского. Метод распараллеливания, способ одновременного исполнения,…
— «и это очень хорошее чтение» — под «чтением» обычно подразумевают процесс. «Чтиво» (если просторечно) или, например, источник.
Сам откладывал чтение Advent'а до выхода последней статьи, поэтому Ваш перевод прочитал раньше оригинала. Большое спасибо за труд; сборка советов очень грамотная, поэтому буду использовать сам и рекомендовать в качестве памятки.
Автор, поправь на /etc/sudoers.
Сбивает с толку.
Сбивает с толку.
Спасибо! Очень актуально в ходе развертывания бета-версии проекта на django.
FastCGI в режиме threaded не очень стабилен. GIL опять зря приплели.
FastCGI очень медленный, как бы его не называли :)
А nginx поддерживает быстрый WSGI. Например, так: www.rkblog.rk.edu.pl/w/p/hosting-django-under-nginx-scgi-and-wsgi/
А nginx поддерживает быстрый WSGI. Например, так: www.rkblog.rk.edu.pl/w/p/hosting-django-under-nginx-scgi-and-wsgi/
Нельзя говорить, что FastCGI очень медленный. Он быстрый, просто WSGI еще быстрее.
blog.locum.ru/lab/fastcgi_protiv_wsgi
конечно на специфичном оборудовании, но все же в 20 раз быстрее
конечно на специфичном оборудовании, но все же в 20 раз быстрее
Тут вы совсем не правы. Нельзя сравнивать WSGI и FastCGI — они на разных уровнях ответственности оперируют. Первый это по сути дырка, а второй это провод с переходником который в неё втыкается.
Потом, mod_wsgi в nginx не работает. Вот просто не работает по одной просто причине — любая обработка запрос, которая уходит в mod_wsgi лочит весь воркер nginx. Если для раздачи файлов (а nginx до недавнего времени лочил воркеры и на этой операции из-за синхронного обращения к диску) это не критично, так как файлы обычно маленькие и отдаются зачастую напрямую из файлового кеша OS, то при мало-мальски серьезном приложении внутри mod_wsgi это становится большой проблемой.
По этой же причине проект по сути и умер.
Потом, mod_wsgi в nginx не работает. Вот просто не работает по одной просто причине — любая обработка запрос, которая уходит в mod_wsgi лочит весь воркер nginx. Если для раздачи файлов (а nginx до недавнего времени лочил воркеры и на этой операции из-за синхронного обращения к диску) это не критично, так как файлы обычно маленькие и отдаются зачастую напрямую из файлового кеша OS, то при мало-мальски серьезном приложении внутри mod_wsgi это становится большой проблемой.
По этой же причине проект по сути и умер.
а в других серверах, lighttpd или apache — работает?
Сам не пробовал, но точно знаю, что Джанго приложения вполне хорошо живут под lighttpd. Тот же блог Ивана Сагалаева (http://softwaremaniacs.org/about/) работает под lighttpd.
В lighttpd нет mod_wsgi (а если бы и был по той же архитектуре построен, то обладал бы теме же проблемами что и в nginx только ещё хуже — у лайти один воркер вообще), а в apache да есть, и да работает.
По технической части-то все здорово в этой статье.
Только непонятно все-таки, чем апач-то не угодил. Поднадоели уже все эти мифы: апач медленный, апач жрет кучу памяти, апач сложно настраивать и т.д. Оверхед апача на запуск джанги под mod_wsgi = метров 5 сразу + потом по паре сотен килобайт на процесс джанги (на процесс, не на тред). Это безо всяких перекомпиляций и тд, стандартный апач из дебиана, без каких-либо сакральных знаний о секретных натсройках. Средний процесс джанги метров 20 у меня занимает, тут +- пара сотен килобайт — совсем не существенно. Причем я совсем не уверен, что у fastcgi+flup оверхед меньше.
По скорости уже не знаю что нужно делать, чтобы упереться не в обработку запросов, а в скорость апача (и получить сколь-либо заметный выигрыш, перейдя на что-то еще),
По настройке тоже куча статей написано, ничего там сложного.
Страшные цифры для апача получают по нескольким причинам:
а) люди не отключат mod_php => в каждый процесс еще грузится здоровенный mod_php
б) неправильное использование mpm_worker без понимания того, как это работает. Можно использовать daemon mode и не париться ни о чем.
в) контейнер OpenVZ (см. habrahabr.ru/blogs/hosting/53236/)
Зато с апачем имеем самый стабильный и отточенный способ запуска джанги, и это, как мне кажется, важно. Хотя, возможно, это тоже миф, что flup глючит, дела с ним иметь не приходилось. Но даже если и не глючит, преимущества все равно неочевидны.
Только непонятно все-таки, чем апач-то не угодил. Поднадоели уже все эти мифы: апач медленный, апач жрет кучу памяти, апач сложно настраивать и т.д. Оверхед апача на запуск джанги под mod_wsgi = метров 5 сразу + потом по паре сотен килобайт на процесс джанги (на процесс, не на тред). Это безо всяких перекомпиляций и тд, стандартный апач из дебиана, без каких-либо сакральных знаний о секретных натсройках. Средний процесс джанги метров 20 у меня занимает, тут +- пара сотен килобайт — совсем не существенно. Причем я совсем не уверен, что у fastcgi+flup оверхед меньше.
По скорости уже не знаю что нужно делать, чтобы упереться не в обработку запросов, а в скорость апача (и получить сколь-либо заметный выигрыш, перейдя на что-то еще),
По настройке тоже куча статей написано, ничего там сложного.
Страшные цифры для апача получают по нескольким причинам:
а) люди не отключат mod_php => в каждый процесс еще грузится здоровенный mod_php
б) неправильное использование mpm_worker без понимания того, как это работает. Можно использовать daemon mode и не париться ни о чем.
в) контейнер OpenVZ (см. habrahabr.ru/blogs/hosting/53236/)
Зато с апачем имеем самый стабильный и отточенный способ запуска джанги, и это, как мне кажется, важно. Хотя, возможно, это тоже миф, что flup глючит, дела с ним иметь не приходилось. Но даже если и не глючит, преимущества все равно неочевидны.
Спасибо огромное! Статья очень помогла!
А чем не устраивает вариант запуска через /etc/inittab?
И геморроя меньше, и init следит за процессом, чтобы не упал, а в случае падения, сам его вежливо поднимет?
И геморроя меньше, и init следит за процессом, чтобы не упал, а в случае падения, сам его вежливо поднимет?
ap:2345:respawn:/bin/su apteka -c "/www/apt2/run/server.sh"
Ценю Ваш труд. Тем не менее, лучше грамотный английский текст, чем безграмотный перевод. В данном случае удручающее качество не оправдывается количеством. Пожалуйста, прогоните статью через ворд какой-нибудь или через знакомых. Лексика, стиль, орфография, пунктуация таковы, что… читать больно, чесслово.
(Надеюсь, Вы не обижаетесь на интепретаторы, компиляторы и читателей за внимание к синтаксису и пунктуации.)
(Надеюсь, Вы не обижаетесь на интепретаторы, компиляторы и читателей за внимание к синтаксису и пунктуации.)
Я использовал вместо /etc/event.d/svscanboot /etc/init/svscanboot.conf в Ubuntu 10.4. Это нормально? Иначе не работал initctl start svscanboot.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Развертывание сайта на Джанго, используя FastCGI