Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
А FastCGI не пробовали? Вроде шустро работает
fapws джангу в том же mm держит, полагаю. Ну а строки в питоне immutable, т.е. в рамках одного процесса не копируются зазря.
> В частности, джанга построена на flup,
Это как?
> Лишний веб сервер посредине — это лишняя работа по прекачиванию данных из одних буферов в другие. Этот вариант не самый производительный.
А вы знаете как flup обрабатывает бинарные потоки, которые к нему от сервера приходят? Поизучайте. Это слезы
> По тестам проведенным мною лично и теми же разработчиками django оптимальный вариант именно работа джанги через fastcgi.
Вполне может быть, но не с flup.
У flup пока есть другие преимущества из-за которых иногда его оправдано использовать.
Это как?
> Лишний веб сервер посредине — это лишняя работа по прекачиванию данных из одних буферов в другие. Этот вариант не самый производительный.
А вы знаете как flup обрабатывает бинарные потоки, которые к нему от сервера приходят? Поизучайте. Это слезы
> По тестам проведенным мною лично и теми же разработчиками django оптимальный вариант именно работа джанги через fastcgi.
Вполне может быть, но не с flup.
У flup пока есть другие преимущества из-за которых иногда его оправдано использовать.
> // я понял что дискуссия с вами господа будет продолжаться вечно.
Ещё бы, если вы на наши скромные вопросы не отвечаете.
> оно там есть и через него работает джанга когда дружиш ее с fastcgi.
Так значит не джанга построена, а в ней есть механизм взаимодействия с flup. Это уж, извините, разные вещи.
> что именно и как вы ему скармливаете и покажите тот кусок кода который вас смущает во флапе.
Обидно trac флаповский сломался, а то бы ещё как показал.
> а теперь о трэдах:
Вот тут вы как раз на вопрос (заданный чуть ниже) не ответили. Как по вашему работает fapsws и flup? Причем тут nginx вообще не понятно. Видимо чтобы «объему» добавить и не сказать ничего по существу.
Не конструктивная позиция. А обидно, было бы очень интересно обсудить конкретный вопрос.
Ещё бы, если вы на наши скромные вопросы не отвечаете.
> оно там есть и через него работает джанга когда дружиш ее с fastcgi.
Так значит не джанга построена, а в ней есть механизм взаимодействия с flup. Это уж, извините, разные вещи.
> что именно и как вы ему скармливаете и покажите тот кусок кода который вас смущает во флапе.
Обидно trac флаповский сломался, а то бы ещё как показал.
> а теперь о трэдах:
Вот тут вы как раз на вопрос (заданный чуть ниже) не ответили. Как по вашему работает fapsws и flup? Причем тут nginx вообще не понятно. Видимо чтобы «объему» добавить и не сказать ничего по существу.
Не конструктивная позиция. А обидно, было бы очень интересно обсудить конкретный вопрос.
>синхронный фронт
from www.grid.net.ru/nginx/nginx-modules.html:
>Главной особенностью реализации nginx, является то, что все сетевые операции ввода-вывода выполняются асинхронно относительно выполнения рабочих процессов.
Кто кого наёбывает? :)
from www.grid.net.ru/nginx/nginx-modules.html:
>Главной особенностью реализации nginx, является то, что все сетевые операции ввода-вывода выполняются асинхронно относительно выполнения рабочих процессов.
Кто кого наёбывает? :)
Задержки сети куда больше, обычно, чем задержки в других местах. Веб-сервер главным образом должен работать с сетью, а не файловой системой. К тому же, если мы говорим о nginx, в связке nginx + fapws только и играет роль сетевой свящки клиента и самого приложения (больше он ничего не делает… опустим отдачу статики, да и тут он один из лидеров).
Вы сами уже запутались и стоите в позиции «лишь бы против». Сначала вы говорите что FastCGI рулит, а теперь говорите что nginx сосёт. У вас FastCGI в воздухе висит? Или мб апач?
Короче определитесь что вас не устраивает — бэкенд или фронтенд. По последнему сообщению кажется что вас уже всё не устраивает.
Вы сами уже запутались и стоите в позиции «лишь бы против». Сначала вы говорите что FastCGI рулит, а теперь говорите что nginx сосёт. У вас FastCGI в воздухе висит? Или мб апач?
Короче определитесь что вас не устраивает — бэкенд или фронтенд. По последнему сообщению кажется что вас уже всё не устраивает.
Пожалуйста не надо заниматься мифотворчеством. Описанная вами ситуация это когда имеется один воркер и он же отдает огрооомный файл. Но это надо чтобы звезды на небе сошлись. Обычно воркеров несколько и проблема тотальной их блокировки не стоит.
При всем при этом, это не мешает быть nginx'у (его воркерам) асинхронным веб-сервером с блокирующим файловым I/O (почему так сделано, вопрос к Сысоеву и разработчикам ядер *nix подобных систем). И уж тем более это не мешает fapws быть честным асинхронным сервером. Как эта асинхронность влияет на производительность, в каких случаях она дает выигрыш, а в каких нет — это уже тема совершенно другого разговора.
В данном конкретном случае мы оставляем на совести автора поста то, как он настаивал до сего момента свой flup и почему он у него кушал много памяти. В ситуации медленной обработки запроса правильно настроенный флап может дать прирост производительности. В случае быстрых ответов наоборот fapws может дать значительно увеличение rps при константном расходе памяти. Вот тут имеет смысл его использовать.
Потом, уж коли вы не знаете, как работает fapws, то пожалуйста не надо материться и другим затыкать рты, говоря, что они ничего не понимают. Как выясняется вы сами плаваете в данной теме и явно имеет некий процент каши в голове по поводу как работы nginx'а так и обсуждаемых бекэндов. Про fapws и, например, cogen советую вам поизучать материалы отдельно. Чтобы впредь вы своим воинственным невежеством не оскорбляли участников сообщества.
При всем при этом, это не мешает быть nginx'у (его воркерам) асинхронным веб-сервером с блокирующим файловым I/O (почему так сделано, вопрос к Сысоеву и разработчикам ядер *nix подобных систем). И уж тем более это не мешает fapws быть честным асинхронным сервером. Как эта асинхронность влияет на производительность, в каких случаях она дает выигрыш, а в каких нет — это уже тема совершенно другого разговора.
В данном конкретном случае мы оставляем на совести автора поста то, как он настаивал до сего момента свой flup и почему он у него кушал много памяти. В ситуации медленной обработки запроса правильно настроенный флап может дать прирост производительности. В случае быстрых ответов наоборот fapws может дать значительно увеличение rps при константном расходе памяти. Вот тут имеет смысл его использовать.
Потом, уж коли вы не знаете, как работает fapws, то пожалуйста не надо материться и другим затыкать рты, говоря, что они ничего не понимают. Как выясняется вы сами плаваете в данной теме и явно имеет некий процент каши в голове по поводу как работы nginx'а так и обсуждаемых бекэндов. Про fapws и, например, cogen советую вам поизучать материалы отдельно. Чтобы впредь вы своим воинственным невежеством не оскорбляли участников сообщества.
> fapws ниразу не юзал, не отрицаю. Но в сказки что с четнием/записью файлов там полный aio я не верю.
Файлов? Так посмотрите и поверьте. Это не больно.
> в 3ем параграфе ваше ответа какаято ересь. А вы знаете как fapws будет обрабатывать медленные соединения? и за счет чего там не будет расхода памяти? я вот могу доказать что он будет. На каждое соеднение. и вполне приличен так. Особенно если ваши соединения «медленные».
В общем посмотрите fapws. Догадки строить все умеют.
> А то у меня о хабре итак складывается наредкость поганое впечатление.
А вы у Сысоева в рассылке материтесь? А посылаете всех направо и налево? Так вы сами создаете атмосферу сообщества. Изначально вы пришли и сюда и полили всех грязью. А на прямые вопросы стали раздражаться и давать пространные ответы. Да ещё, как выяснилось, в теме в которой вы не разбираетесь.
Когда будете в адекватном состоянии, то буду рад пообщаться с вами например по почте или джаберу.
Файлов? Так посмотрите и поверьте. Это не больно.
> в 3ем параграфе ваше ответа какаято ересь. А вы знаете как fapws будет обрабатывать медленные соединения? и за счет чего там не будет расхода памяти? я вот могу доказать что он будет. На каждое соеднение. и вполне приличен так. Особенно если ваши соединения «медленные».
В общем посмотрите fapws. Догадки строить все умеют.
> А то у меня о хабре итак складывается наредкость поганое впечатление.
А вы у Сысоева в рассылке материтесь? А посылаете всех направо и налево? Так вы сами создаете атмосферу сообщества. Изначально вы пришли и сюда и полили всех грязью. А на прямые вопросы стали раздражаться и давать пространные ответы. Да ещё, как выяснилось, в теме в которой вы не разбираетесь.
Когда будете в адекватном состоянии, то буду рад пообщаться с вами например по почте или джаберу.
Небольшое примечание: у автора топа раньше был apache2 + mod_wsgi
> оно там есть и через него работает джанга когда дружиш ее с fastcgi.
С таким же успехом в неё может быть встроен fapws, не кажется? flup для дев-сервера на сколь я понимаю.
С таким же успехом в неё может быть встроен fapws, не кажется? flup для дев-сервера на сколь я понимаю.
Вообще конечно fapws не замена апачу (тем более хорошо настроенному). Он не production ready или по крайней мере об этом никто не знает. Потом все эти решения плохо масштабируются под нагрузкой. Нет умного шедулера процессов, а следовательно адаптивно форкаться или порождать новые инстансы сервера для балансировки на них не получится.
Кстати supervisord умеет нативно работать над FastCGI и может динамически порождать процессы в зависимости от нагрузки. Вот это уже интересно.
Кстати supervisord умеет нативно работать над FastCGI и может динамически порождать процессы в зависимости от нагрузки. Вот это уже интересно.
Неужели вы думаете что на 256 Мб будет крутится что-то сильно нагруженное? :) Впринципе целевая аудитория именно такая. Тем кому нужно распределение не будут даже бесплатно юзать 256 Мб сервера.
Если интересно, там 4 сайта всего с 200 униками в день каждый. С апачом это жрало всю память и 150-200 Мб swap… Не спорю, апач стоковый. После небольшой настройки ситуация немного изменилась, но не так кардинально.
И в моём случае стабильность системы с апачём многим меньше чем fapws3 (ну мне так кажется, пока не долго на нём сижу), т.к. каждые 5 дней использование всех ресурсов зашкаливало и слайс просто отказывал в обслуживании до хард ресета. Поэтому тут не всё так просто :)
Если интересно, там 4 сайта всего с 200 униками в день каждый. С апачом это жрало всю память и 150-200 Мб swap… Не спорю, апач стоковый. После небольшой настройки ситуация немного изменилась, но не так кардинально.
И в моём случае стабильность системы с апачём многим меньше чем fapws3 (ну мне так кажется, пока не долго на нём сижу), т.к. каждые 5 дней использование всех ресурсов зашкаливало и слайс просто отказывал в обслуживании до хард ресета. Поэтому тут не всё так просто :)
Просто тогда в посте не хватает упоминания «целевой аудитории» такого решения чтобы не возникало лишних вопросов.
А вообще апач с embeded mod_wsgi (и даже в принципе mod_python) может очень хорошо и не прожорливо работать с минимальным расходом ресурсов. Но согласен, его в разы труднее настраивать и надо понимать чего хочешь и как этого добиться.
Ах да, ещё, fapws не чисто питонячий — там сердце это сишный libev для асинхронной обработки I/O.
А вообще апач с embeded mod_wsgi (и даже в принципе mod_python) может очень хорошо и не прожорливо работать с минимальным расходом ресурсов. Но согласен, его в разы труднее настраивать и надо понимать чего хочешь и как этого добиться.
Ах да, ещё, fapws не чисто питонячий — там сердце это сишный libev для асинхронной обработки I/O.
у меня django и lighttpd общаются через flup (WSGI-совместимый FastCGI-сервер)
в django flup поддерживается (python manage.py runfcgi)
пара скриптов в init.d для запуска/остановки сервера и готово
в django flup поддерживается (python manage.py runfcgi)
пара скриптов в init.d для запуска/остановки сервера и готово
как это настроить — описано прямо в документации django
так что мне непонятно, почему автор выбрал такой мудрёный вариант
так что мне непонятно, почему автор выбрал такой мудрёный вариант
flup форкается и тредится (можно конечно ему сказать maxсhildren=1, но смысл). fapws асинхронный однотредовый. Разные подходы у них.
Автор, видимо, в душе исследователь. И это позитивно!
Я долго колебался между lighttpd и nginx, но потом выбрал последний просто из-за какой-то мелочи. Джанга подключена через flup/fastcgi аналогично, как абсолютно штатный вариант.
Исторически сложилось, что я пускаю сервер скриптом при помощи init, так как останов не предусматривается, а рестарт получается в этом случае просто при помощи kill.
Я долго колебался между lighttpd и nginx, но потом выбрал последний просто из-за какой-то мелочи. Джанга подключена через flup/fastcgi аналогично, как абсолютно штатный вариант.
Исторически сложилось, что я пускаю сервер скриптом при помощи init, так как останов не предусматривается, а рестарт получается в этом случае просто при помощи kill.
топик про экономию расхода памяти на VDS
очевидно, что делать highload-проект на VDS вряд ли кто-то станет
так что не понимаю, к чему ваш коммент
алсо, пруфлинк в студию
очевидно, что делать highload-проект на VDS вряд ли кто-то станет
так что не понимаю, к чему ваш коммент
алсо, пруфлинк в студию
Какой нагрузке и как валится? Очень интересно.
Что такое хорошая нагрузка и что там валится?
Глядя на фастцги и пул воркеров просто не понятно чему там валиться.
Глядя на фастцги и пул воркеров просто не понятно чему там валиться.
> Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...».
Не думаю что проблема тут в nginx или mod_wsgi под него ;) что-то не так делаете
Не думаю что проблема тут в nginx или mod_wsgi под него ;) что-то не так делаете
fapws как и nginx mod_wsgi годны для потестить и для вашего случая. Почитайте комменты в багтрекере lighttpd. flup действительно иногда нужно перезапускать(впрочем, не буду утверждать т.к. не уверен что он был причиной нескольких аномалий). Грамотно собраный апач с mod_wsgi наше все.
Здесь автор блога byteflow подсчитывал производительность wsgi vs fastcgi
piranha.org.ua/blog/2007/11/24/nginx-mod-wsgi-vs-fastcgi/
piranha.org.ua/blog/2007/11/24/nginx-mod-wsgi-vs-fastcgi/
он сравнивает mod_wsgi, что совсем другое и к fapws отношения, кроме как использования одного стандарта взаимодействия с приложением, не имеет.
daevaorn + 1
да и статейка старовата уже, имхо
да и статейка старовата уже, имхо
Вы не забывайте что fapws и прочие асинхронные сервера не зря называются асинхронными. При любом синхронном вызове блокируетя весь сервер. А посколько Django и другие используют вполне себе синхронный режим работы то для реального приложения один fapws будет практически всегда заметно медленнее чем пулл процессов или потоков.
Мы пробовали обходить это ограничение запуская 4 фапса на разных портах, и потом распределяя коннекшены между ними на lighttpd. В такой конфигурации скорость поднялась до уровня flups (разница в пределах статистической погрешности). Выигрыш есть только по памяти, а флап проверен в бою. Да и на память мы не жадные. Так что пока все проекты остались на флапсе.
PS: автор блога byteflow в нашей команде работает
Мы пробовали обходить это ограничение запуская 4 фапса на разных портах, и потом распределяя коннекшены между ними на lighttpd. В такой конфигурации скорость поднялась до уровня flups (разница в пределах статистической погрешности). Выигрыш есть только по памяти, а флап проверен в бою. Да и на память мы не жадные. Так что пока все проекты остались на флапсе.
PS: автор блога byteflow в нашей команде работает
Кстати вот это очень интересный момент. Долгие обработчики запроса блокируют весь асинхронный сервер. Причем, что обидно, зачастую долгие эти обработчики из-за сложных запросов в базу данным, которые конечно же синхронные. Вот тут недостающее звено явно проступает — асинхронный драйвер для базы данных и его интеграция в веб сервер для прозрачного переключения контекста обработки http запросов. Пока хорошего решения нет, кроме как проксирования запросов в базу через промежуточный http сервер, но это увеличивает сильно latency и в большинстве случаев не эффективно.
Асинхронный драйвер для базы данных требует асинхронного фреймворка. Асинхронность вообще любит под себя захавывать всю архитектуру приложения.
Twisted вполне удовлетворяет всем требованиям, но что-то не получил в вебе особого распостранения. То-ли Nevow дело, то-ли в том что синхронный код людям всё же привычней.
А относительно Django, imho, форки — это единственный кошерный способ запуска.
Twisted вполне удовлетворяет всем требованиям, но что-то не получил в вебе особого распостранения. То-ли Nevow дело, то-ли в том что синхронный код людям всё же привычней.
А относительно Django, imho, форки — это единственный кошерный способ запуска.
fapws3 — еще молодое…
странно, что для продакшена вы не попробовали несколько решений
есть еще lighttpd в качестве фронтенда и бэкенд cherrypy, интересно было бы перед выбором чего-либо пробовать разные их и не только их комбинации, ибо тема действительно насущная…
в любом случае спасибо за материал для размышлений!
ну а с апачем действительно пора кончать;)
странно, что для продакшена вы не попробовали несколько решений
есть еще lighttpd в качестве фронтенда и бэкенд cherrypy, интересно было бы перед выбором чего-либо пробовать разные их и не только их комбинации, ибо тема действительно насущная…
в любом случае спасибо за материал для размышлений!
ну а с апачем действительно пора кончать;)
с каких это пор лайти только для статики? он так же умеет и реверс прокси и фронтендом для fapws3 или cherypy или flup-а быть
> fapws3 пошустрее cherrypy
не готов утверждать.
покажите пруфтесты.
fapws3 насколько помню только в декабре делаться начался, сыроват еще, не зачем скрывать…
а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…
> fapws3 пошустрее cherrypy
не готов утверждать.
покажите пруфтесты.
fapws3 насколько помню только в декабре делаться начался, сыроват еще, не зачем скрывать…
а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…
> а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…
Так это специфика асинхронного сервера и синхронного приложения. fapws3 так же себя ведет.
Надо просто несколько инстансев иметь.
Так это специфика асинхронного сервера и синхронного приложения. fapws3 так же себя ведет.
Надо просто несколько инстансев иметь.
www.swivel.com/data_columns/show/9570256 бенчи, но непонятные вхлам.
это проблемы джанги и медленной СУБД,
я по сабжу небольшую заметку писал slav0nic.org.ua/entry/148
если вкратце, то в джанге отсутствует pool для базы, на каждый коннект подымается отдельный поток к базе, если вы развёртываете джангу на cherrypy (я сам юзаю этот метод) то теоретическое число одновременно обрабатываемых запросов упирается в параметр threads, а в асинхронном сервере один поток, вот отсюда и ростут все ноги)
кому понравился фапс, советую взгялнуть на cogen, он полностью на питоне
НО имхо самый оптимальный вариант развёртывание приложения -… SCGI
Во-первых протокол проще чем FCGI, следотально парсить его быстрее
Во-вторых fapws3, cherrypy это веб сервера, и имеет место бестолковый (в плане процессорного времени) парсинг заголовков протокла и другие мелочи, опятьже SCGI проще
сейчас написал простенький асинхронный SCGItoWSGI сервер на базе asyncore, работает быстрее фапса В)
я по сабжу небольшую заметку писал slav0nic.org.ua/entry/148
если вкратце, то в джанге отсутствует pool для базы, на каждый коннект подымается отдельный поток к базе, если вы развёртываете джангу на cherrypy (я сам юзаю этот метод) то теоретическое число одновременно обрабатываемых запросов упирается в параметр threads, а в асинхронном сервере один поток, вот отсюда и ростут все ноги)
кому понравился фапс, советую взгялнуть на cogen, он полностью на питоне
НО имхо самый оптимальный вариант развёртывание приложения -… SCGI
Во-первых протокол проще чем FCGI, следотально парсить его быстрее
Во-вторых fapws3, cherrypy это веб сервера, и имеет место бестолковый (в плане процессорного времени) парсинг заголовков протокла и другие мелочи, опятьже SCGI проще
сейчас написал простенький асинхронный SCGItoWSGI сервер на базе asyncore, работает быстрее фапса В)
Я посмотрел бенчмарки, cherrypy как-то тормоз выходит. Да и мало меня интересует скорость (4 сайта по 200 уников в день каждый), волнует скорее память (всего 256 мб)
Установка fapws3
Лучше было сделать пакет, тем более что PKGBUILD очень простой выйдет.
pkgname=fapws3
pkgver=0.2
pkgrel=1
pkgdesc="Fast Asynchronous Python Web Server"
arch=('i686' 'x86_64')
url="http://github.com/william-os4y/fapws3/tree/master"
license=('GPL')
depends=('python' 'libev')
makedepends=('setuptools')
install=
source=('http://github.com/william-os4y/fapws3/tarball/v0.2')
md5sums=('5a401ee8cf74ea7d77dd46ade42bddd3')
build() {
cd $startdir/src/william-os4y-fapws3-c7815ebc1a32d6d196d74dbcdc86bbfd39b81d61
python setup.py install --prefix=/usr --root=$startdir/pkg
}
# vim:set ts=2 sw=2 et:
В AUR постить не буду, т.к. сам не пользуюсь.
у меня лично, как раз наобарот, fapws3 жрал очень много процессорного времени(про память не помню), да он быстрый, но ресурсов жрет нереально много, предпочитаю пускать джангу через nginx+fastcgi для продакшен проектов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем память разумно. Часть 2. fapws3