Nginx + Django: mod_wsgi vs FastCGI

Вчера вечером таки связался с автором 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, но иногда подскакивает), жрёт больше рамы - у меня xmobar1 показывает количество съеденной памяти, при 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 станет стабильным! :-)

1 -

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

Pingbacks: 3

Открываю для себя WSGI | Александр Кошелев | webnewage.org
поиском альтернативы системы размещения, которую я использовал. Тут как нельзя лучше подвернулся пост Пираньи в котором он упоминается mod_wsgi для nginx, нагрянули воспоминания, была поднята “подшивка” рсс (желтые звездочки в ридере рулят:) ) и начался процесс глубокого изучения эт
webnewage.org, 21:17 (after 727 days)
Amazon byteflow: Django performance: Apache vs Nginx
Неделю назад я сравнивал производительность и устойчивость работы nginx’а с Django с помощью mod_wsgi и fastcgi. Сравнение показало, что fastcgi имеет тенденцию при (очень) больших нагрузках пад
piranha.org.ua, 15:47 (after 7 days)
Amazon byteflow: Nginx + Django: mod_wsgi vs FastCGI - en
(Translation of my previous post).
piranha.org.ua, 15:11

Comments: 9 (already: 2) Comment post

Не, ну 500 запросов одновременно — это непрактично. Это какие-то дикие нагрузки, которые редко бывают в природе, по-моему.

Но в общем и целом, я бы сказал, что эксперимент показывает, что не мост между Django и веб-сервером является узким местом.

Иван Сагалаев , 14:34

Не, ну 500 запросов одновременно — это непрактично.

100 запросов одновременно - практично? ;-) То же самое, просто при 500 это приобретает угрожающие очертания.

Но в общем и целом, я бы сказал, что эксперимент показывает, что не мост между Django и веб-сервером является узким местом.

В плане производительности - да. В плане пожирания ресурсов - mod_wsgi выходит заметно приятнее. А ещё можно вспомнить, что у него touch django.wsgi релоадит сервер, в то время как у fastcgi - надо сервер перезапускать, что при отсутствии раскидывания на несколько процессов приводит к потерям соединения у клиентов. Не страшно, конечно (один апстрим обычно у маленьких проектов только), но ведь неприятно. Да и мороки больше, надо его запускать ещё, следить чтоб не сдох, и так далее.

В общем, сплошные минусы. Или плюсы, смотря о чём говорить. ;-)

Alexander Solovyov , 15:08

Ок, только лень поборю. ;-) Или ближе к ночи сегодня сделаю, или в понедельник уже.

Alexander Solovyov , 16:44

А как nginx удается параллельно обрабатывать wsgi запросы, если он не создает дополнительных процессов и тредов? Вы пробовали вариант, когда SQL-запрос занимает много времени?

Ilya Novoselov , 17:23 (after 259 days)

А никак, в этом случае он блокирует весь процесс. Процессов можно заранее запустить несколько, конечно, но это не то…

Alexander Solovyov , 08:24 (after 260 days)

Дак получается тогда, что Django mod_wsgi это не практическое решение, и дело на самом деле не в стабильности mod_wsgi?

Ilya Novoselov , 11:31 (after 260 days)

В этом посте речь идёт о mod_wsgi для nginx’а, а не для Apache. Ничего общего между ними нету.

Alexander Solovyov , 12:01 (after 260 days)

Дак я и не говорю про апач.

Ilya Novoselov , 12:30 (after 260 days)

Ну просто сочетание слов “Django mod_wsgi” наталкивает на разные мысли. А так да, нгинксовый mod_wsgi не годится для использования с приложениями, которые локаются…

Alexander Solovyov , 05:20 (after 261 day)

Comment form for «Nginx + Django: mod_wsgi vs FastCGI»

Required. 30 chars of fewer.

Required.

Comment post