Публикации с меткой «fastcgi»

Из всех способов деплоинга django-проектов мой любимый — FastCGI. Он поддерживается большинством веб-серверов, позволяет внятно разграничить права доступа и имеет массу других преимуществ.

Однако в django его реализация не лишена недостатков. Чтобы запустить FastCGI-сервер нужно выполнить «./manage.py runfcgi» с немаленьким количеством параметров, которые если и можно запомнить, то точно не захочется писать каждый раз руками. А если это происходит в контексте обновления кода проекта на боевом сервере, то команд становится ещё больше. Приходится писать различные wrapper-ы для запуска и перезапуска, которые засоряют проект.

От переводчика

Данную статью я прочитал на Django Advent приуроченному к уже скорому выходу Django 1.2 и она показалось мне настолько интересной, что я решил ее перевести. Далее текст статьи.

Когда разрабатываешь сайт на Джанго, так легко просто открыть консоль и напечатать:

python manage.py runserver

С этой простой командой управления наши медиа файлы админки сайта поддерживаются правильным образом, PYTHONPATH правильно настроен и включает корневую папку нашего проекта, а так же запущен автоматически перегружающийся веб-сервер на указанном нами порту (от переводчика: по умолчанию порт 8000). Это так просто!

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

Однако иногда Apache не идеальное решение. Может быть ваш VPS имеет только 256 МБ памяти, а может быть мы хотим избежать сложности настройки Apache при установке. Или может быть нам просто не нравиться Apache. По любой из этих причин мы можем обратить свое внимание на FastCGI.

Последнее время в области веб-разработок стал набирать популярность язык программирования Python. Однако, массовому распространение Python мешает проблема эффективного запуска приложений на этом языке. Пока, в большинстве случаев, это удел выделенных или виртуальных серверов. Модульные языки в отличии от монолитного в базовой функциональности php на каждый запрос подгружают как минимум runtime-библиотеку, а как максимум — ещё несколько десятков запрашиваемых пользователем модулей. Поэтому классический подход наподобие mod_php для Python и Perl не очень уместен, а держать приложение постоянно в памяти было дороговато. Но время движется, техника стала мощнее и дешевле, и уже достаточно давно можно спокойно говорить о постоянно запущенных процессах с приложением в рамках массового хостинга.

О чём тут

Время от времени, в сети появляются различные предложения как запустить приложение на Python. Например, недавно хостинг Джино уникально поправил mod_python и предложил хостинг именно с его помощью. Следом за ним, некий хостинг Locum вообще отринул mod_python с его безопасностью (создаётся впечатление, что суть самобытная безопасность — это единственная проблема АйТи на пути к нирване) и провёл победоносное тестирование modwsgi против fastcgi. Комьюнити же, судя по проведённому мною поиску, разрывается между mod_python и FastCGI. Причём, FastCGI обычно имеется ввиду тот, что идёт в поставке Django — flup. Являясь популярным хостингом Python-приложений, мы не смогли пройти мимо и решили внести свою лепту в эту священную войну.

Преамбула

Из нескольких способов развертывания Django я сразу отмёл mod_python, потому что мне не хотелось поднимать тяжеловесный Apache. Решил развернуть на легком веб-сервере. На данный момент основных легковесных альтернатив Апачу две — lighttpd и nginx. Первоначально я выбрал первый, но столкнулся с проблемами, связанными с URL. Я подумал, что, может, nginx будет работать получше, и развернул приложение на нём. В этом деле мне очень сильно помог один скринкаст, уже не помню точно чьего авторства.
Всё было отлично, но когда я захотел использовать админку Django(удобная вещь, кстати), меня постигло разочарование — форма логина показывалась, но при попытке войти меня выбрасывало на admin/. После получаса гугления, я нашёл топик на небезызвестном форуме Ивана Салагаева, в котором описывалось решение проблемы. После того, как я последовал описанным советам, все заработало на-ура. Представляю вашему вниманию необходимую конфигурацию сервера и Django.

Интро Уже пару месяцев я разбираюсь с Python & Django. И вот настало время выкладывать свои художества в сеть ) Правда, мой первый сайт на Django посвящен ведению отчетов по работе. Он довольно прост и хвалиться нечем. Вместо этого я расскажу как просто развертывается проект на Django + Nginx + FastCGI. Устанавливаем У меня на офисном сервере стоит [...]

Неделю назад я сравнивал производительность и устойчивость работы nginx'а с Django с помощью mod_wsgi и fastcgi. Сравнение показало, что скорость работы при наличии быстрой локальной (читай - практически не оказывающей влияние) БД практически не отличается, отличается только количество используемых ресурсов.

А сегодня я наконец-то собрался посмотреть, что же будет, когда база данных находится на другом компе, а связь по wifi между веб-сервером и БД усугубляет проблему. :-) То есть весь смысл сегодняшних моих мучений - посмотреть на ситуацию с тормозящей базой данных (стало интересно после комментария Манлио). Заодно и хотелось посмотреть, как себя ведёт Apache.

Перед этим я таки запустил пару раз лёгкий тест (ab -n 100 -c 20) на Апач (с локальной базой данных), который показал, что апач не хочет использовать два моих ядра ни в какую. :-( Ни prefork, ни worker не использовали второе ядро и запрос в среднем занимал 28 мс, что в два раза дольше, чем nginx'овый показатель - 14 мс. Логически поразмышляв, можно понять, что тяжёлый Апач в любом случае работает медленнее nginx'а - второе ядро в два раза не ускорит (что и говорит показатель в 24 мс у nginx'а при работе с одним ядром :-).

Дальше PostgreSQL был запущен на другом ноуте. Апач я мерял как в prefork версии, так и в worker.

Первый вариант - ab -n 1000 -c 20:

• apache - ~37 мс. Стабильно, в пределах 5 запусков разницы не было даже в миллисекунду.
• nginx + mod_wsgi - ~50 мс. Ожидаемо.
• nginx + fastcgi prefork - ~28 мс. В мозгу не укладывается, что оно настолько быстрее Апача! :-)

Второй вариант - при ab -n 3000 -c 500 - не слишком отличается. Апач и фастцги - такие же, мод_всги вырос до 55 мс.

В этот момент мне показалось, что mod_wsgi годится только когда нету БД (или задержками на её работу можно пренебречь). Однако, поразмыслив, я сделал ход конём - увеличил количество воркеров в нгинксе. :-) При 16 воркерах (проверено позже - 8 достаточно) и 500 одновременных запросов один отклик приходит в среднем раз в 28 мс. Теперь и результат фастцги укладывается, и апач выглядит толстым и тяжёлым, как обычно. ;-) Правда, каждый процесс nginx'а, работающий с джангой, кушает порядка 15 мегабайт. Хотя это в любом случае меньше, чем апач и fastcgi.

Выводы каждый может сделать сам для себя, но nginx + mod_wsgi однозначно - очень интересная комбинация.

Неделю назад я сравнивал производительность и устойчивость работы nginx'а с Django с помощью mod_wsgi и fastcgi. Сравнение показало, что скорость работы при наличии быстрой локальной (читай - практически не оказывающей влияние) БД практически не отличается, отличается только количество используемых ресурсов.

А сегодня я наконец-то собрался посмотреть, что же будет, когда база данных находится на другом компе, а связь по wifi между веб-сервером и БД усугубляет проблему. :-) То есть весь смысл сегодняшних моих мучений - посмотреть на ситуацию с тормозящей базой данных (стало интересно после комментария Манлио). Заодно и хотелось посмотреть, как себя ведёт Apache.

Перед этим я таки запустил пару раз лёгкий тест (ab -n 100 -c 20) на Апач (с локальной базой данных), который показал, что апач не хочет использовать два моих ядра ни в какую. :-( Ни prefork, ни worker не использовали второе ядро и запрос в среднем занимал 28 мс, что в два раза дольше, чем nginx'овый показатель - 14 мс. Логически поразмышляв, можно понять, что тяжёлый Апач в любом случае работает медленнее nginx'а - второе ядро в два раза не ускорит (что и говорит показатель в 24 мс у nginx'а при работе с одним ядром :-).

Дальше PostgreSQL был запущен на другом ноуте. Апач я мерял как в prefork версии, так и в worker.

Первый вариант - ab -n 1000 -c 20:

• apache - ~37 мс. Стабильно, в пределах 5 запусков разницы не было даже в миллисекунду.
• nginx + mod_wsgi - ~50 мс. Ожидаемо.
• nginx + fastcgi prefork - ~28 мс. В мозгу не укладывается, что оно настолько быстрее Апача! :-)

Второй вариант - при ab -n 3000 -c 500 - не слишком отличается. Апач и фастцги - такие же, мод_всги вырос до 55 мс.

В этот момент мне показалось, что mod_wsgi годится только когда нету БД (или задержками на её работу можно пренебречь). Однако, поразмыслив, я сделал ход конём - увеличил количество воркеров в нгинксе. :-) При 16 воркерах (проверено позже - 8 достаточно) и 500 одновременных запросов один отклик приходит в среднем раз в 28 мс. Теперь и результат фастцги укладывается, и апач выглядит толстым и тяжёлым, как обычно. ;-) Правда, каждый процесс nginx'а, работающий с джангой, кушает порядка 15 мегабайт. Хотя это в любом случае меньше, чем апач и fastcgi.

Выводы каждый может сделать сам для себя, но nginx + mod_wsgi однозначно - очень интересная комбинация.

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

Запуск джанговского приложения под nginx'ом не вызвал абсолютно никаких проблем - использовался тот же файлик django.wsgi, который я приводил раньше для апача. Больше о настройке решил ничего не писать, потому как код ещё не стабильный и требует тестирования, потому использование где-то в реально жизни пока больному не показано.

Но тут начинается веселье - тестирование. ;-) Простая страничка, 15 запросов (PostgreSQL на этом же компе), инфы по этим запросам приходят мелочи (ещё хочу потестировать, чтоб было инфы побольше, а постгрес был на другом компе). 2 воркера (пробовал и 3, и 4 - выходит медленнее в любом варианте, на 2-4 мс). Два варианта запросов (ab -n 1000 -c 20 и ab -n 10000 -c 500) и три варианта серверов (mod_wsgi, prefork fastcgi, threaded fastcgi). Железо (всё равно интересно только в сравнении на одном железе и софте, потому конфигурация несущественна, но всё же) - Core 2 Duo T7300 и 2 Gb RAM.

При ab -n 1000 -c 20 (на каждый вариант сервера пришлось порядка 10-12 тестирований):

• mod_wsgi стабильно выдаёт 14.2-14.3 мс на запрос
• prefork fastcgi выдаёт 12.5-16.5 мс (в основном около 12, но иногда подскакивает), жрёт больше рамы - у меня xmobar¹ показывает количество съеденной памяти, при mod_wsgi там на пару процентов (процент - 20 мегов) меньше всегда
• threaded fastcgi выдаёт 24-25 мс на запрос - он использует только одно ядро, я пытался настроить в нгинксе upstream - он работает, но использует почему-то только 1 процесс

Т.е. в большинстве случаев при такой нагруженности фастцги выходит немного быстрее (хотя и кушает немножко больше ресурсов). Но... идём дальше? ;)

При ab -n 10000 -c 500 (тут вышло по 3-4 запуска):

• mod_wsgi выдаёт 13-14 мс. Каждый воркер хавает примерно 21/15 мегов памяти (VSZ/RSS)
• prefork fastcgi выдаёт 15.5-17 мс на запрос, но при этом запускается от 40 до 50 обслуживающих процессов, каждый из которых кушает 16-20 VSZ (10-13 RSS) мегов памяти! По xmobar'у расход выходит до 50% (скачками, обычно около 45-48) относительно 33% у wsgi. Это лишних 300 мегов оперативки!
• threaded fastcgi - самый интересный вариант. При таком количестве одновременных запросов он умирает. При -c 100 - тоже умирает. При -c 50 - живёт, но скорость выходит чуть ниже, чем при -c 20, а рабочий процесс хавает до 300 мегов VSZ.

Что тут можно сказать? Ждём, когда mod_wsgi станет стабильным! :-)

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

Запуск джанговского приложения под nginx'ом не вызвал абсолютно никаких проблем - использовался тот же файлик django.wsgi, который я приводил раньше для апача. Больше о настройке решил ничего не писать, потому как код ещё не стабильный и требует тестирования, потому использование где-то в реально жизни пока больному не показано.

Но тут начинается веселье - тестирование. ;-) Простая страничка, 15 запросов (PostgreSQL на этом же компе), инфы по этим запросам приходят мелочи (ещё хочу потестировать, чтоб было инфы побольше, а постгрес был на другом компе). 2 воркера (пробовал и 3, и 4 - выходит медленнее в любом варианте, на 2-4 мс). Два варианта запросов (ab -n 1000 -c 20 и ab -n 10000 -c 500) и три варианта серверов (mod_wsgi, prefork fastcgi, threaded fastcgi). Железо (всё равно интересно только в сравнении на одном железе и софте, потому конфигурация несущественна, но всё же) - Core 2 Duo T7300 и 2 Gb RAM.

При ab -n 1000 -c 20 (на каждый вариант сервера пришлось порядка 10-12 тестирований):

• mod_wsgi стабильно выдаёт 14.2-14.3 мс на запрос
• prefork fastcgi выдаёт 12.5-16.5 мс (в основном около 12, но иногда подскакивает), жрёт больше рамы - у меня xmobar¹ показывает количество съеденной памяти, при mod_wsgi там на пару процентов (процент - 20 мегов) меньше всегда
• threaded fastcgi выдаёт 24-25 мс на запрос - он использует только одно ядро, я пытался настроить в нгинксе upstream - он работает, но использует почему-то только 1 процесс

Т.е. в большинстве случаев при такой нагруженности фастцги выходит немного быстрее (хотя и кушает немножко больше ресурсов). Но... идём дальше? ;)

При ab -n 10000 -c 500 (тут вышло по 3-4 запуска):

• mod_wsgi выдаёт 13-14 мс. Каждый воркер хавает примерно 21/15 мегов памяти (VSZ/RSS)
• prefork fastcgi выдаёт 15.5-17 мс на запрос, но при этом запускается от 40 до 50 обслуживающих процессов, каждый из которых кушает 16-20 VSZ (10-13 RSS) мегов памяти! По xmobar'у расход выходит до 50% (скачками, обычно около 45-48) относительно 33% у wsgi. Это лишних 300 мегов оперативки!
• threaded fastcgi - самый интересный вариант. При таком количестве одновременных запросов он умирает. При -c 100 - тоже умирает. При -c 50 - живёт, но скорость выходит чуть ниже, чем при -c 20, а рабочий процесс хавает до 300 мегов VSZ.

Что тут можно сказать? Ждём, когда mod_wsgi станет стабильным! :-)