Вчера вечером таки связался с автором 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 станет стабильным! :-)