Comments 91
сразу же хочется посмотреть на все конфиги всех частей тестовых систем.
У FastCGI значивая часть
FastCgiServer /home/user/project -processes 2 -user user -group user
У mod_wsgi
WSGIDaemonProcess wsgi-test user=uwsgi group=user home=/home/user processes=2 threads=5 maximum-requests=0 inactivity-timeout=60 display-name=wsgi-test
Какое место в конфигах ещё интересно? FastCGI — да, через suexec. Не принципиально для оценки.
FastCgiServer /home/user/project -processes 2 -user user -group user
У mod_wsgi
WSGIDaemonProcess wsgi-test user=uwsgi group=user home=/home/user processes=2 threads=5 maximum-requests=0 inactivity-timeout=60 display-name=wsgi-test
Какое место в конфигах ещё интересно? FastCGI — да, через suexec. Не принципиально для оценки.
и заодно вопрос — производилась ли какая-либо оптимизация тестовой ОС
Нет, там в начале написано. Я, кстати, не знаю что надо оптимизировать для «Hello, world» :) FreeBSD. Пустая. Только апач торчит и всё. Параметры даны. Но я ещё в начале написал — не знаю как это может кому-то помочь.
Ну теоретически имеет смысл соптимизировать систему по заветам Сысоева: www.opennet.ru/base/net/tune_freebsd.txt.html
Хотя не думаю что на такой вот тестовой нагрузке это приведёт к смене расклада.
Хотя не думаю что на такой вот тестовой нагрузке это приведёт к смене расклада.
nginx + wsgi не смотрели?
Что такое «nginx+wsgi»? nginx — это веб-сервер. wsgi — спецификация интерфейса. Что значит Ваш "+"?
Ночь, голова совершенно не тем забита =) Я про mod_wsgi для nginx хотел сказать.
UFO just landed and posted this here
+ означает, mod_wsgi для nginx. По моим тестам эта связка работает намного быстрее апачевского mod_wsgi. Жаль, что проект заброшен.
У него проблема есть. Если в приложении возникнет блокировка колом встанет весь сервер.
наблюдал подобные эффекты и в связке apache + mod_wsgi.
Там зависит от того какой у вас mpm используется.
Можно подробнее? Я пока решения своей проблемы не нашел и просто через каждые несколько миллионов запросов приходится перезапускать сервер.
У вас какой apache?
Apache/2.2.9 под Debian lenny
Если у вас установлен apache2-mpm-worker поставьте apache2-mpm-prefork. Учтите что если у вас им же статика отдается, то может возрасти нагрузка.
У меня, кстати, вопрос. Немного холиварный.
При отсутствии лишней связи и монолитности самого php я ожидал множителя от 2 и выше.
Почему python тогда? Ну понимаю, пхп говно и прочее, но что физически мешает всей связке достигнуть такой же производительности, как mod_php?
При отсутствии лишней связи и монолитности самого php я ожидал множителя от 2 и выше.
Почему python тогда? Ну понимаю, пхп говно и прочее, но что физически мешает всей связке достигнуть такой же производительности, как mod_php?
Эммм. Производительности вывода hello world?
Тут ваще весь тест — производительность hello world, если че :)
ну т.е. производительность оверхеда :)
Почему у питона оверхед этот так значительно больше?
Тут ведь особенности, скажем, синтаксиса языка тут явно не причем.
ну т.е. производительность оверхеда :)
Почему у питона оверхед этот так значительно больше?
Тут ведь особенности, скажем, синтаксиса языка тут явно не причем.
Почему у питона оверхед этот так значительно больше?
Моя думать, что WSGI дает больший оверхед, чем mod_php. Вообще стоит сравнить mod_php с fastcgi php или cgi php тогда можно что-то сказать.
Оверхед в наличии дополнительной связи между сервером и непосредственно воркером приложения по протоколу fastcgi/внутреннему протоколу.
Мы хотели еще провести тест php в режиме fastcgi, но сборка php-fpm не самая тривиальная задача. Да и не было цели сверять php и python. Тест немного о другом.
Мы хотели еще провести тест php в режиме fastcgi, но сборка php-fpm не самая тривиальная задача. Да и не было цели сверять php и python. Тест немного о другом.
Питон потому что он сам по себе и проще, и вообще более классически, да и более производительный. Так скажем. на нагруженных проектах он выдержит больше, но это всё уходит за рамки нашего исследования.
Хотелось-бы увидеть еще производительность на этом железе Fapws (Fast asynchronous python wsgi server) william-os4y.livejournal.com. Как вы на это смотрите?
и когена заодно если можно
Fapws требует свежей libev. Которую надо еще собрать.
К тому же fapws (по крайней мере, когда я его пробовал) блокирует треды, что отменяет возможность перезагрузки приложения по таймауту.
К тому же fapws (по крайней мере, когда я его пробовал) блокирует треды, что отменяет возможность перезагрузки приложения по таймауту.
Только что потестил, на hello world рещультат впечатляющий, на моем стареньком атлоне 4500 запросов.
Но стоило только поставить таймаут на пару секунд на ответ внутрь кода, как выяснилось, что он не обрабатывает соединения параллельно, а все по очереди!
То есть прийдет параллельно пара запросов и один их них будет ждать другого, а в реальной жизни не всегда hello world
Я сильно не копался — взял примеры, возможно что-то там и можно подкрутить
Но стоило только поставить таймаут на пару секунд на ответ внутрь кода, как выяснилось, что он не обрабатывает соединения параллельно, а все по очереди!
То есть прийдет параллельно пара запросов и один их них будет ждать другого, а в реальной жизни не всегда hello world
Я сильно не копался — взял примеры, возможно что-то там и можно подкрутить
Все верно. fapws не является многопоточным, а реализует событийную машину. Любая задержка в приложении — остальные ждут. Как, собственно и в nginx.
Отлично :(
Только в нгинксе проще — он или сам отдал статику/кеш или передал дальше эстафету.
А что тогда модет подойти под такую задачу, когда надо пара сотен параллельных процессов/потоков с довольно длительными задачами, но без апача, а желательно и сервер на питоне?
Я пока немного разного пробовал, но пока что-то всё не то…
Только в нгинксе проще — он или сам отдал статику/кеш или передал дальше эстафету.
А что тогда модет подойти под такую задачу, когда надо пара сотен параллельных процессов/потоков с довольно длительными задачами, но без апача, а желательно и сервер на питоне?
Я пока немного разного пробовал, но пока что-то всё не то…
серверы, использующие событийную модель, как лицензия gpl: заражают ей все приложение. :)
В таком случае идеально подходит веб-сервер MochiWeb, но придется учить Erlang :)
Есть даже примеры миллиона одновременных запросов с постоянным соединением (т.н. Comet-приложения)
Есть даже примеры миллиона одновременных запросов с постоянным соединением (т.н. Comet-приложения)
Если не хочется учить erlang, то можно еще посмотреть на python/twisted.
вот что интересно. если приложение чисто вычислительное (рассчитывает координаты сферического коня в вакууме, или отдает «Hello, World!» :) ), то использование ниток или процессов производительности не прибавляет, а даже наоборот. процессор все равно один и лишние переключения контекста ни к чему. другая картина получается, когда приложение часть времени проводит в ожидании (синхронного ввода-вывода, результата sql запроса, или стоит таймаут на пару секунд :) ). в это время процессор не задействован, сервер может обрабатывать другие соединения. картина производительности будет иная.
off: слог донельзя напоминает машинный перевод: «уникально поправил», «отринул с безопасностью». можете пояснить что значат эти обороты? или материал действительно переводной?
А как выглядит конфиг апача для тестирования flup?
вот любопытно. если разделить transfer rate (клобайт/сек) на request per seconds, то получим килобайт / запрос.
интересно, что у «flup 2 процесса / 5 тредов» эта величина больше чем у других конфигураций в два с небольшим раза. он что, строчку «Hello World!» отдает в юникоде? =)
1014,09 / 3484,67 0,291 754,55 / 3140,87 0,240 720,04 / 3262,5 0,221 654,98 / 1202,8 0,545 639,66 / 2651,86 0,241 171,23 / 712,78 0,240
интересно, что у «flup 2 процесса / 5 тредов» эта величина больше чем у других конфигураций в два с небольшим раза. он что, строчку «Hello World!» отдает в юникоде? =)
у джанге есть prefork способ запуска fcgi, не только threaded. интересно, какие бы в этом случае были результаты.
Ну и, я, конечно, понимаю что цели сравнивать nginx и апач не стояло, но если бы добавить в тестирование ещё и nginx + fcgi (prefork и threaded) то было бы гораздо, гораздо интереснее.
Ну и, я, конечно, понимаю что цели сравнивать nginx и апач не стояло, но если бы добавить в тестирование ещё и nginx + fcgi (prefork и threaded) то было бы гораздо, гораздо интереснее.
LA скорее всего зашкалит. Процессы таки. Посмотрю.
А в чём формальный смысл сравнение такой связки? Ну будут те же оценочные результаты. Разница-то.
А в чём формальный смысл сравнение такой связки? Ну будут те же оценочные результаты. Разница-то.
ну, в сравнении nginx'а и апача, в основном, конечно, будет смысл.
OMG! Чего сравнения??? :))) nginx'а и apache'а? А в чём их сравнивать можно?
т.е. вы считаете что нет смысла сравнивать скорость и потребление ресурсов апача с mod_fastcgi и nginx'а?
> Являясь популярным хостингом Python-приложений хостингом Python-приложений
я по два раза не повторяю, не повторяю :))
я по два раза не повторяю, не повторяю :))
Хотелось бы еще увидеть сравнение с Passenger в режиме wsgi.
Жесть. как Вы думаетет будет ли зазница между запуском апача, и например другово сервера.
Будет. Апач сам по себе монстр. Но в этом тесте тестировалась скорость именно связки апач->приложение.
Не понял вопроса. Разница в чём? В запуске? Если он не похож на апач — будет. В оценке сравнительной производительности? Скорее всего нет, если я нигде не ошибся. В цифрах? Не смотрите на них. Будет.
UFO just landed and posted this here
идиотский вопроса на всякий случай
1) отключали ли mod_php и прочие ненужные mod_* при тестировании с питоном?
а вообще что то у вас не то, ибо слишком медленно для hello world! Я когда-то тоже много экспериментировал (результаты — ниже) и у меня на AMD 3800+ (1 ядро) выдавало более 2000req/s, а на Intel 6700 quad core — почти 9000 при 4х «горячих» форках через mod_wsgi (естественно, daemon mode).
в целом если не трогать php (который тут в шутку похоже, или чтоб не спрашивали «а где же наш любимый пэхэпэ?!», то основные (юзабельные для продашна) на мой взгляд схемы это:
1) apache 2.2 / worker + mod_wsgi
2) apache 2.2 / worker + python-fastcgi
3) lighttpd/whatever + python-fastcgi
при этом я на апача очень долго сидел после того как запарившись как-то сильно ковырялся с компиляцией, все модули — в статику, большую часть дефолтных модулей вообще нахрен выкидывал за ненадобностью. Но 1 апачевский «упс» при этом все равно остаётся — в worker ему нужно выделить виртуальную память для всех возможных тредов. А в случае vps где иногда нет swap — это означает что сжирать он будет нереально много (правда, это значение при повышении нагрузки никогда не увеличится уже, что тоже удобно).
lighttpd/whatever в этом плане веселей, ибо у них футпринт в памяти просто мизерный в сравнении с апачем. У конкретно lighttpd ещё и довольно стабильный загрузчик/менеджер fastcgi приложений.
самое же главное — что выбирать между этими схемами надо именно из расчета «что удобнее», а никак не «что быстрее». Ибо в любом приложении отличном от Hello world разница становится абсолютно незаметной и несущественной. Главное лишь связку грамотно настроить. А вот тут начинаются грабли, связанные с тем, что грамотно настроить апач на его макс. производительность несоизмеримо сложнее чем вообще не настраивать тот же lighttpd =). Да и даже если запарится и долго тестить/экспериментировать с разными mod_prefork/mod_worker и их параметрами — результат не получится сделать быстрее lighttpd.
по поводу mod_wsgi vs python-fastcgi/mod_fastcgi хочется сказать отдельно. Mod_wsgi безумно логичен, но не лишён недостатков. Главный из них — это всё же наличие интерпретатора питона прямо в самом mod_wsgi (и, как следствие, потом в апаче, хотя это уже пофик). А это значит что засовывается он туда при компилляции. А это значит что воткнуть туда «левый» питон (не тот что основной на сервере) архи проблематично — потом ещё запускать весь апач с тюнеными LD_LIBRARY_PATH и LD_RUNTIME_PATH… брррр. Ну и последний гвоздик — 2 разных mod_wsgi под одним апачем, увы, совсем никак. Из плюсов апача пока ещё есть (и, вероятно, ещё побудет некоторое время =)) — настраиваемость и уйма возможно нужных других модулей… Есть ещё маленький бонус — писать свои mod_* в апаче используя восхитительную arp (apache runtime library) — одно удовольствие.
1) отключали ли mod_php и прочие ненужные mod_* при тестировании с питоном?
а вообще что то у вас не то, ибо слишком медленно для hello world! Я когда-то тоже много экспериментировал (результаты — ниже) и у меня на AMD 3800+ (1 ядро) выдавало более 2000req/s, а на Intel 6700 quad core — почти 9000 при 4х «горячих» форках через mod_wsgi (естественно, daemon mode).
в целом если не трогать php (который тут в шутку похоже, или чтоб не спрашивали «а где же наш любимый пэхэпэ?!», то основные (юзабельные для продашна) на мой взгляд схемы это:
1) apache 2.2 / worker + mod_wsgi
2) apache 2.2 / worker + python-fastcgi
3) lighttpd/whatever + python-fastcgi
при этом я на апача очень долго сидел после того как запарившись как-то сильно ковырялся с компиляцией, все модули — в статику, большую часть дефолтных модулей вообще нахрен выкидывал за ненадобностью. Но 1 апачевский «упс» при этом все равно остаётся — в worker ему нужно выделить виртуальную память для всех возможных тредов. А в случае vps где иногда нет swap — это означает что сжирать он будет нереально много (правда, это значение при повышении нагрузки никогда не увеличится уже, что тоже удобно).
lighttpd/whatever в этом плане веселей, ибо у них футпринт в памяти просто мизерный в сравнении с апачем. У конкретно lighttpd ещё и довольно стабильный загрузчик/менеджер fastcgi приложений.
самое же главное — что выбирать между этими схемами надо именно из расчета «что удобнее», а никак не «что быстрее». Ибо в любом приложении отличном от Hello world разница становится абсолютно незаметной и несущественной. Главное лишь связку грамотно настроить. А вот тут начинаются грабли, связанные с тем, что грамотно настроить апач на его макс. производительность несоизмеримо сложнее чем вообще не настраивать тот же lighttpd =). Да и даже если запарится и долго тестить/экспериментировать с разными mod_prefork/mod_worker и их параметрами — результат не получится сделать быстрее lighttpd.
по поводу mod_wsgi vs python-fastcgi/mod_fastcgi хочется сказать отдельно. Mod_wsgi безумно логичен, но не лишён недостатков. Главный из них — это всё же наличие интерпретатора питона прямо в самом mod_wsgi (и, как следствие, потом в апаче, хотя это уже пофик). А это значит что засовывается он туда при компилляции. А это значит что воткнуть туда «левый» питон (не тот что основной на сервере) архи проблематично — потом ещё запускать весь апач с тюнеными LD_LIBRARY_PATH и LD_RUNTIME_PATH… брррр. Ну и последний гвоздик — 2 разных mod_wsgi под одним апачем, увы, совсем никак. Из плюсов апача пока ещё есть (и, вероятно, ещё побудет некоторое время =)) — настраиваемость и уйма возможно нужных других модулей… Есть ещё маленький бонус — писать свои mod_* в апаче используя восхитительную arp (apache runtime library) — одно удовольствие.
да, и выше видел про «колом встающий апач с mod_worker и mod_wsgi при слипах».
обращу внимания что mpm тут ваще не при чем. Апач запускает либо 2-3 форка и потом запускается управляющий форк mod_wsgi которому передаются все запросы нужные (чего там mod_wsgi уже запустит апача не касается, он все их сваливать в 1 форк будет все равно). Либо тоже самое, тока внутри форков апача ещё и потоки порождаются (и все равно они все будут стучаться в 1 форк mod_wsgi).
Далее когда идут запросы, они идут на mod_wsgi в многопоточном режиме, а он уже перебрасывает их по схеме как настроен. Если например daemon mode с 1 приложением, 2 форками и 20 потоками в каждом, то одновременно может сожрать 40 обрабатывающихся внутри питона запросов (если канеш сам апач столько сможет одновременно сожрать — тут уж настройка mpm).
Так вот и коварность mod_prefork состоит в том, что пока запрос обрабатывается внутри mod_wsgi (в котором может быть например 1 процесс со 100 тредами прямо внутри питона), ему один хрен нужен 1 форк самого апача на КАЖДЫЙ запрос. Т.е. ему надо будет разогнать 100 форков (предполагаю, в разогретом состоянии 100 форков никто не держит? =)). И не дай бог в апаче стоит mod_php, ибо размер форков апача в таком случае будет апокалептичным (ну ладно-ладно, только если mod_php ещё и в статике запихнут =)).
При mod_worker 1 форк апача может обрабатывать энное кол-во одновременных запросов через потоки внутри самого форка. А так как апач в случае mod_wsgi фактически тупо перебрасывает последнему запросы — это как раз то что нужно, и worker гораздо практичнее prefork.
prefork, как правило, рушит сервер очень быстро, как только чуть чуть начинает хаваться своп — дальнейшее порождение форков убивает систему совсем начисто (если макс. лимит выше чем макс. памяти / размер форка, но тут уж надо сильно аккуратно настраивать prefork). Worker же начнёт убивать в таком случае сервер медленно, ибо каждый новый форк сможет обработать, например, ещё 100 соединений, а там уже лимит самого приложения вашего (т.е. настройка mod_wsgi) должен слать куда-подальше — в итоге вываливая всем подряд http 500.
Сразу скажу — не спорьте, если не верите — у Грэма Дамплтона (автор mod_python и mod_wsgi) в блоге есть афигенный трактат по этому поводу. В общем-то я просто по-русски это всё описал, но у него — подробнее =).
обращу внимания что mpm тут ваще не при чем. Апач запускает либо 2-3 форка и потом запускается управляющий форк mod_wsgi которому передаются все запросы нужные (чего там mod_wsgi уже запустит апача не касается, он все их сваливать в 1 форк будет все равно). Либо тоже самое, тока внутри форков апача ещё и потоки порождаются (и все равно они все будут стучаться в 1 форк mod_wsgi).
Далее когда идут запросы, они идут на mod_wsgi в многопоточном режиме, а он уже перебрасывает их по схеме как настроен. Если например daemon mode с 1 приложением, 2 форками и 20 потоками в каждом, то одновременно может сожрать 40 обрабатывающихся внутри питона запросов (если канеш сам апач столько сможет одновременно сожрать — тут уж настройка mpm).
Так вот и коварность mod_prefork состоит в том, что пока запрос обрабатывается внутри mod_wsgi (в котором может быть например 1 процесс со 100 тредами прямо внутри питона), ему один хрен нужен 1 форк самого апача на КАЖДЫЙ запрос. Т.е. ему надо будет разогнать 100 форков (предполагаю, в разогретом состоянии 100 форков никто не держит? =)). И не дай бог в апаче стоит mod_php, ибо размер форков апача в таком случае будет апокалептичным (ну ладно-ладно, только если mod_php ещё и в статике запихнут =)).
При mod_worker 1 форк апача может обрабатывать энное кол-во одновременных запросов через потоки внутри самого форка. А так как апач в случае mod_wsgi фактически тупо перебрасывает последнему запросы — это как раз то что нужно, и worker гораздо практичнее prefork.
prefork, как правило, рушит сервер очень быстро, как только чуть чуть начинает хаваться своп — дальнейшее порождение форков убивает систему совсем начисто (если макс. лимит выше чем макс. памяти / размер форка, но тут уж надо сильно аккуратно настраивать prefork). Worker же начнёт убивать в таком случае сервер медленно, ибо каждый новый форк сможет обработать, например, ещё 100 соединений, а там уже лимит самого приложения вашего (т.е. настройка mod_wsgi) должен слать куда-подальше — в итоге вываливая всем подряд http 500.
Сразу скажу — не спорьте, если не верите — у Грэма Дамплтона (автор mod_python и mod_wsgi) в блоге есть афигенный трактат по этому поводу. В общем-то я просто по-русски это всё описал, но у него — подробнее =).
ну и в довесок — остаточный страх mod_worker остался после сумасшедших глюков mod_php и worker mpm года 3-4 назад. В то время php хоть сам и был вроде как thread-safe, но вот какие-то из его расширений — не были, а т.к. в случае worker mpm есть 1 процесс внутри которого 25 (ну или скока там у вас) тредов и в это же процессе 1 пхп обрабатывает запросы этих тредов — крыша у не thread-safe расширений (и у всего приложения в целом) откровенно протекала.
Это же касается и других не thread-safe mod_* апача и сишных расширений питона (благо, таких по пальцам пересчитать).
Это же касается и других не thread-safe mod_* апача и сишных расширений питона (благо, таких по пальцам пересчитать).
Я предупредил, что может быть все плохо. А mod_wsgi получается работает довольно похоже с mod_fastcgi, только в сторону pyhton. Я думал он как нибудь все же по-другому, если там так, то замена mpm ничего не даст.
Почему замена mpm ничего не даст?
Читаем выше. Замена на mpm_preforker не даст профита в виде независания mod_wsgi.
Какое такое зависание mod_wsgi? Ты о чём, коллега? :)
Нет, ты по русски объясни. Там как раз написано что поможет. Не с зависанием правда, но поможет. А ты о чём? Давай, по пунктам.
Цитирую:
Сугубо говоря в независимости от mpm есть управляющий форк. Если он вешается, то всему приходит копец. Кстати у fastcgi есть такой же управляющий форк.
Апач запускает либо 2-3 форка и потом запускается управляющий форк mod_wsgi которому передаются все запросы нужные (чего там mod_wsgi уже запустит апача не касается, он все их сваливать в 1 форк будет все равно). Либо тоже самое, тока внутри форков апача ещё и
потоки порождаются (и все равно они все будут стучаться в 1 форк mod_wsgi).
Сугубо говоря в независимости от mpm есть управляющий форк. Если он вешается, то всему приходит копец. Кстати у fastcgi есть такой же управляющий форк.
И как часто у тебя он вешается? Через 5 дней будет год коммерческого использования. Ни разу не повис.
А кто сказал что у меня? :) Это вон у товарищей выше у них и узнавай.
Где? С nginx? Ну логично. Ты читать умеешь? :)) Там embeded mode
Я умею. Тут вроде нигде nginx слова нет:
habrahabr.ru/blogs/python/67475/#comment_1907318
habrahabr.ru/blogs/python/67475/#comment_1907318
Не отключали. ППКС под всем. mpm-worker попробую действительно
я вот сейчас минималистичную статическую сборку апача только гентой делаю (совсем разленился… =)), благо это мегаудобно нынче. Прирост это может дать весьма внушительный (ну может процентов 5 — сильно зависит от захломлённости текущего варианта =)), особенно в prefork режиме, если форки новые запускаются. Ну и, конечно, афигенно ощутимо меньше кушает памяти.
сейчас ещё cherokee пополз вперёд. Я его даже и не щупал ещё толком, совсем не до этого. Но согласно www.cherokee-project.com/benchmarks.html — весьма многообещающая штука (не хило ли, 2х по сравнению с апачем — уже не шутки). Особенно учитывая что lighttpd заглох и остыл… а на холодную больше не заводится =)), nginx — промолчу… его ниша — бэкпрокси и точка. Разные fapws — для песочниц и игрушек да и только пока что.
сейчас ещё cherokee пополз вперёд. Я его даже и не щупал ещё толком, совсем не до этого. Но согласно www.cherokee-project.com/benchmarks.html — весьма многообещающая штука (не хило ли, 2х по сравнению с апачем — уже не шутки). Особенно учитывая что lighttpd заглох и остыл… а на холодную больше не заводится =)), nginx — промолчу… его ниша — бэкпрокси и точка. Разные fapws — для песочниц и игрушек да и только пока что.
ещё кстати можно mod_scgi попробовать… Тоже руки никак не доходили. По смыслу scgi мне очень нравится — спецификация малюююсенькая, как сильно упрощённый fastcgi. А скорость — точно такая же.
Sign up to leave a comment.
Сравнение эффективности способов запуска веб-приложений на языке Python