Pull to refresh

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. Не принципиально для оценки.
и заодно вопрос — производилась ли какая-либо оптимизация тестовой ОС
Нет, там в начале написано. Я, кстати, не знаю что надо оптимизировать для «Hello, world» :) FreeBSD. Пустая. Только апач торчит и всё. Параметры даны. Но я ещё в начале написал — не знаю как это может кому-то помочь.
Ну теоретически имеет смысл соптимизировать систему по заветам Сысоева: www.opennet.ru/base/net/tune_freebsd.txt.html

Хотя не думаю что на такой вот тестовой нагрузке это приведёт к смене расклада.
Вот и я так подумал. Смысл-то? Там же не сетевые сокеты.
Что такое «nginx+wsgi»? nginx — это веб-сервер. wsgi — спецификация интерфейса. Что значит Ваш "+"?
Ночь, голова совершенно не тем забита =) Я про mod_wsgi для nginx хотел сказать.
UFO landed and left these words here
Смотрел. У меня на dev сервере (Celeron 2,9GHz c 512 мозгами) c django+pgsql, 20 воркеров при запросе с далёкого сервера выдавали бешенные результаты: ~70 запросов/сек, против apache+mod_php который выдавал около 25 запросов/сек. Я бы мог понять разницу в 10%-30%, но не в 3 раза.
nginx является мультиплексором. Любая задержка внутри процесса превращает его в пень. А mod_wsgi под nginx предполагает только embedded режим. А держать кучу воркеров — а чем это тогда от апача отличается по сути?
UFO landed and left these words here
+ означает, mod_wsgi для nginx. По моим тестам эта связка работает намного быстрее апачевского mod_wsgi. Жаль, что проект заброшен.
Ну вот смотрите — если у вас есть возможность держать для пользователя отдельный nginx с набором воркеров — почему бы не вывесить вебсервер напрямую. Например Cherrypy или тот же fapws?
Я реально советую посмотреть осмысленность того модуля.
Объясните смысл. В чём смысл того модуля?
У него проблема есть. Если в приложении возникнет блокировка колом встанет весь сервер.
наблюдал подобные эффекты и в связке apache + mod_wsgi.
Там зависит от того какой у вас mpm используется.
Можно подробнее? Я пока решения своей проблемы не нашел и просто через каждые несколько миллионов запросов приходится перезапускать сервер.
Если у вас установлен apache2-mpm-worker поставьте apache2-mpm-prefork. Учтите что если у вас им же статика отдается, то может возрасти нагрузка.
Спасибо, буду изучать вопрос. Сервер рабочий, на нем не очень-то поэкспериментируешь, да и глюк случается довольно редко, поэтому попробую найти какое-то строгое обоснование происходящему.
У меня, кстати, вопрос. Немного холиварный.
При отсутствии лишней связи и монолитности самого 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. Тест немного о другом.
Питон потому что он сам по себе и проще, и вообще более классически, да и более производительный. Так скажем. на нагруженных проектах он выдержит больше, но это всё уходит за рамки нашего исследования.
Спасибо. Именно такого ответа я и хотел. Типа:
1. Питон более интересный язык;
2. Питон более производительный на нагруженных проектах.
Хотелось-бы увидеть еще производительность на этом железе Fapws (Fast asynchronous python wsgi server) william-os4y.livejournal.com. Как вы на это смотрите?
Fapws требует свежей libev. Которую надо еще собрать.
К тому же fapws (по крайней мере, когда я его пробовал) блокирует треды, что отменяет возможность перезагрузки приложения по таймауту.
Только что потестил, на hello world рещультат впечатляющий, на моем стареньком атлоне 4500 запросов.
Но стоило только поставить таймаут на пару секунд на ответ внутрь кода, как выяснилось, что он не обрабатывает соединения параллельно, а все по очереди!
То есть прийдет параллельно пара запросов и один их них будет ждать другого, а в реальной жизни не всегда hello world
Я сильно не копался — взял примеры, возможно что-то там и можно подкрутить
Все верно. fapws не является многопоточным, а реализует событийную машину. Любая задержка в приложении — остальные ждут. Как, собственно и в nginx.
Отлично :(
Только в нгинксе проще — он или сам отдал статику/кеш или передал дальше эстафету.
А что тогда модет подойти под такую задачу, когда надо пара сотен параллельных процессов/потоков с довольно длительными задачами, но без апача, а желательно и сервер на питоне?
Я пока немного разного пробовал, но пока что-то всё не то…
серверы, использующие событийную модель, как лицензия gpl: заражают ей все приложение. :)
В таком случае идеально подходит веб-сервер MochiWeb, но придется учить Erlang :)
Есть даже примеры миллиона одновременных запросов с постоянным соединением (т.н. Comet-приложения)
спасибо, если надо, то и эрланг можно — лишь бы заработало :)
Если не хочется учить erlang, то можно еще посмотреть на python/twisted.
Я тоже так решил, только почему то там тоже выполнение идет последовательно, правда не углублялся еще.
вот что интересно. если приложение чисто вычислительное (рассчитывает координаты сферического коня в вакууме, или отдает «Hello, World!» :) ), то использование ниток или процессов производительности не прибавляет, а даже наоборот. процессор все равно один и лишние переключения контекста ни к чему. другая картина получается, когда приложение часть времени проводит в ожидании (синхронного ввода-вывода, результата sql запроса, или стоит таймаут на пару секунд :) ). в это время процессор не задействован, сервер может обрабатывать другие соединения. картина производительности будет иная.
нитки/процессы vs событийные.
А зачем? И так всё ясно ИМХО :)
off: слог донельзя напоминает машинный перевод: «уникально поправил», «отринул с безопасностью». можете пояснить что значат эти обороты? или материал действительно переводной?
Нет, статья своя, конечно. Вдаваясь в текст — джино, судя по всему, действительно «уникально» по их словам поправил апач, заставив его запускать процессы из под пользователя. Правда, метод этот уже известен более 6 лет и разработан Дмитрием Котеровым.
А как выглядит конфиг апача для тестирования flup?
вот любопытно. если разделить transfer rate (клобайт/сек) на request per seconds, то получим килобайт / запрос.
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) то было бы гораздо, гораздо интереснее.

LA скорее всего зашкалит. Процессы таки. Посмотрю.
А в чём формальный смысл сравнение такой связки? Ну будут те же оценочные результаты. Разница-то.
ну, в сравнении nginx'а и апача, в основном, конечно, будет смысл.
OMG! Чего сравнения??? :))) nginx'а и apache'а? А в чём их сравнивать можно?
т.е. вы считаете что нет смысла сравнивать скорость и потребление ресурсов апача с mod_fastcgi и nginx'а?
В данной задаче нет. Более того, ни в какой другой тоже. Результат очевиден. Я там в начале написал про «комплексное решение».
А я не понял. Ну нет у вас задачи сравнивать apache и nginx (читать «вы все равно не поставите nginx), но другим то результаты интересны, почему бы и не сравнить.
Ммм… нет, просто нет смысла сравнивать автобус и фуру. Кстати, вот например в автобусах ликенского автозавода образца так года 2000-го стоит камазовский движок. Можно даже технически попробовать сравнить.
Формализуйте мне тесты сравнения. Какой функционал с каким и почему.
> Являясь популярным хостингом Python-приложений хостингом Python-приложений
я по два раза не повторяю, не повторяю :))
Опс… Спасибо, поправил :))
Воопрос интресный. Я тут выложу как я тесты делал. Предлагаю взглянуть.

P.S. Хотя, ответ ИМХО очевиден…
Жесть. как Вы думаетет будет ли зазница между запуском апача, и например другово сервера.
Будет. Апач сам по себе монстр. Но в этом тесте тестировалась скорость именно связки апач->приложение.
Не понял вопроса. Разница в чём? В запуске? Если он не похож на апач — будет. В оценке сравнительной производительности? Скорее всего нет, если я нигде не ошибся. В цифрах? Не смотрите на них. Будет.
UFO landed and left these words here
mod_worker с 1 тредом == mod_prefork.
идиотский вопроса на всякий случай

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) в блоге есть афигенный трактат по этому поводу. В общем-то я просто по-русски это всё описал, но у него — подробнее =).
ну и в довесок — остаточный страх mod_worker остался после сумасшедших глюков mod_php и worker mpm года 3-4 назад. В то время php хоть сам и был вроде как thread-safe, но вот какие-то из его расширений — не были, а т.к. в случае worker mpm есть 1 процесс внутри которого 25 (ну или скока там у вас) тредов и в это же процессе 1 пхп обрабатывает запросы этих тредов — крыша у не thread-safe расширений (и у всего приложения в целом) откровенно протекала.

Это же касается и других не thread-safe mod_* апача и сишных расширений питона (благо, таких по пальцам пересчитать).
Я предупредил, что может быть все плохо. А mod_wsgi получается работает довольно похоже с mod_fastcgi, только в сторону pyhton. Я думал он как нибудь все же по-другому, если там так, то замена mpm ничего не даст.
Почему замена mpm ничего не даст?
Читаем выше. Замена на mpm_preforker не даст профита в виде независания mod_wsgi.
Какое такое зависание mod_wsgi? Ты о чём, коллега? :)
Нет, ты по русски объясни. Там как раз написано что поможет. Не с зависанием правда, но поможет. А ты о чём? Давай, по пунктам.
Цитирую:
Апач запускает либо 2-3 форка и потом запускается управляющий форк mod_wsgi которому передаются все запросы нужные (чего там mod_wsgi уже запустит апача не касается, он все их сваливать в 1 форк будет все равно). Либо тоже самое, тока внутри форков апача ещё и
потоки порождаются (и все равно они все будут стучаться в 1 форк mod_wsgi).


Сугубо говоря в независимости от mpm есть управляющий форк. Если он вешается, то всему приходит копец. Кстати у fastcgi есть такой же управляющий форк.
И как часто у тебя он вешается? Через 5 дней будет год коммерческого использования. Ни разу не повис.
А кто сказал что у меня? :) Это вон у товарищей выше у них и узнавай.
Где? С nginx? Ну логично. Ты читать умеешь? :)) Там embeded mode
А, да, прости. Перепонтовался. Я даже пропустил тот тред ибо какой-то вздор. Да. Каюсь, посыпаю голову пеплом.
Не отключали. ППКС под всем. mpm-worker попробую действительно
я вот сейчас минималистичную статическую сборку апача только гентой делаю (совсем разленился… =)), благо это мегаудобно нынче. Прирост это может дать весьма внушительный (ну может процентов 5 — сильно зависит от захломлённости текущего варианта =)), особенно в prefork режиме, если форки новые запускаются. Ну и, конечно, афигенно ощутимо меньше кушает памяти.

сейчас ещё cherokee пополз вперёд. Я его даже и не щупал ещё толком, совсем не до этого. Но согласно www.cherokee-project.com/benchmarks.html — весьма многообещающая штука (не хило ли, 2х по сравнению с апачем — уже не шутки). Особенно учитывая что lighttpd заглох и остыл… а на холодную больше не заводится =)), nginx — промолчу… его ниша — бэкпрокси и точка. Разные fapws — для песочниц и игрушек да и только пока что.
Cherokee стоит попробовать. У нас сейчас все проекты на Django работают на связке Cherokee + scgi. Очень быстро, надежно и удобно.
Да, мы смотрим на него. Но… Но да, интересно.
ещё кстати можно mod_scgi попробовать… Тоже руки никак не доходили. По смыслу scgi мне очень нравится — спецификация малюююсенькая, как сильно упрощённый fastcgi. А скорость — точно такая же.
Only those users with full accounts are able to leave comments. Log in, please.