Как стать автором
Обновить

Комментарии 79

А FastCGI не пробовали? Вроде шустро работает
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я вам кокретно продемонстрировал разницу в расходе памяти. (конец статьи). Это по сравнению с mod_wsgi + apache. Демонов получается одинаковое количество. fastcgi как мне известно, плохой, иначе небыло бы смысла в wsgi.
Сам по себе FastCGI не плох. WSGI как стандарт взаимодействия веб-сервер/приложение был создан по другими причинам, нежели «наш ответ FastCGI».
Я о реализации. Сами стандарты в плане производительности и т.п. сравнивать смысла нет. А wsgi как мне известно был ответом на Джавовский стандарт.
fapws джангу в том же mm держит, полагаю. Ну а строки в питоне immutable, т.е. в рамках одного процесса не копируются зазря.
> В частности, джанга построена на flup,

Это как?

> Лишний веб сервер посредине — это лишняя работа по прекачиванию данных из одних буферов в другие. Этот вариант не самый производительный.

А вы знаете как flup обрабатывает бинарные потоки, которые к нему от сервера приходят? Поизучайте. Это слезы

> По тестам проведенным мною лично и теми же разработчиками django оптимальный вариант именно работа джанги через fastcgi.

Вполне может быть, но не с flup.

У flup пока есть другие преимущества из-за которых иногда его оправдано использовать.
НЛО прилетело и опубликовало эту надпись здесь
> // я понял что дискуссия с вами господа будет продолжаться вечно.

Ещё бы, если вы на наши скромные вопросы не отвечаете.

> оно там есть и через него работает джанга когда дружиш ее с fastcgi.

Так значит не джанга построена, а в ней есть механизм взаимодействия с flup. Это уж, извините, разные вещи.

> что именно и как вы ему скармливаете и покажите тот кусок кода который вас смущает во флапе.

Обидно trac флаповский сломался, а то бы ещё как показал.

> а теперь о трэдах:

Вот тут вы как раз на вопрос (заданный чуть ниже) не ответили. Как по вашему работает fapsws и flup? Причем тут nginx вообще не понятно. Видимо чтобы «объему» добавить и не сказать ничего по существу.

Не конструктивная позиция. А обидно, было бы очень интересно обсудить конкретный вопрос.
НЛО прилетело и опубликовало эту надпись здесь
>синхронный фронт

from www.grid.net.ru/nginx/nginx-modules.html:
>Главной особенностью реализации nginx, является то, что все сетевые операции ввода-вывода выполняются асинхронно относительно выполнения рабочих процессов.

Кто кого наёбывает? :)
НЛО прилетело и опубликовало эту надпись здесь
Задержки сети куда больше, обычно, чем задержки в других местах. Веб-сервер главным образом должен работать с сетью, а не файловой системой. К тому же, если мы говорим о nginx, в связке nginx + fapws только и играет роль сетевой свящки клиента и самого приложения (больше он ничего не делает… опустим отдачу статики, да и тут он один из лидеров).

Вы сами уже запутались и стоите в позиции «лишь бы против». Сначала вы говорите что FastCGI рулит, а теперь говорите что nginx сосёт. У вас FastCGI в воздухе висит? Или мб апач?

Короче определитесь что вас не устраивает — бэкенд или фронтенд. По последнему сообщению кажется что вас уже всё не устраивает.
НЛО прилетело и опубликовало эту надпись здесь
>flup в свою очередь умеет работать через fastcgi. Нахрена изобретать велосипеды?
Ваше слова?

>помойму если кого что и не устраивает то это только вас.
Эти слова должны быть моими :)
Пожалуйста не надо заниматься мифотворчеством. Описанная вами ситуация это когда имеется один воркер и он же отдает огрооомный файл. Но это надо чтобы звезды на небе сошлись. Обычно воркеров несколько и проблема тотальной их блокировки не стоит.

При всем при этом, это не мешает быть nginx'у (его воркерам) асинхронным веб-сервером с блокирующим файловым I/O (почему так сделано, вопрос к Сысоеву и разработчикам ядер *nix подобных систем). И уж тем более это не мешает fapws быть честным асинхронным сервером. Как эта асинхронность влияет на производительность, в каких случаях она дает выигрыш, а в каких нет — это уже тема совершенно другого разговора.

В данном конкретном случае мы оставляем на совести автора поста то, как он настаивал до сего момента свой flup и почему он у него кушал много памяти. В ситуации медленной обработки запроса правильно настроенный флап может дать прирост производительности. В случае быстрых ответов наоборот fapws может дать значительно увеличение rps при константном расходе памяти. Вот тут имеет смысл его использовать.

Потом, уж коли вы не знаете, как работает fapws, то пожалуйста не надо материться и другим затыкать рты, говоря, что они ничего не понимают. Как выясняется вы сами плаваете в данной теме и явно имеет некий процент каши в голове по поводу как работы nginx'а так и обсуждаемых бекэндов. Про fapws и, например, cogen советую вам поизучать материалы отдельно. Чтобы впредь вы своим воинственным невежеством не оскорбляли участников сообщества.
НЛО прилетело и опубликовало эту надпись здесь
> fapws ниразу не юзал, не отрицаю. Но в сказки что с четнием/записью файлов там полный aio я не верю.

Файлов? Так посмотрите и поверьте. Это не больно.

> в 3ем параграфе ваше ответа какаято ересь. А вы знаете как fapws будет обрабатывать медленные соединения? и за счет чего там не будет расхода памяти? я вот могу доказать что он будет. На каждое соеднение. и вполне приличен так. Особенно если ваши соединения «медленные».

В общем посмотрите fapws. Догадки строить все умеют.

> А то у меня о хабре итак складывается наредкость поганое впечатление.

А вы у Сысоева в рассылке материтесь? А посылаете всех направо и налево? Так вы сами создаете атмосферу сообщества. Изначально вы пришли и сюда и полили всех грязью. А на прямые вопросы стали раздражаться и давать пространные ответы. Да ещё, как выяснилось, в теме в которой вы не разбираетесь.

Когда будете в адекватном состоянии, то буду рад пообщаться с вами например по почте или джаберу.
Небольшое примечание: у автора топа раньше был apache2 + mod_wsgi
НЛО прилетело и опубликовало эту надпись здесь
а меня то не спросили. вы так весело сретесь, давай еще — у меня попкорн еще не закончился.
> оно там есть и через него работает джанга когда дружиш ее с fastcgi.
С таким же успехом в неё может быть встроен fapws, не кажется? flup для дев-сервера на сколь я понимаю.
Вообще конечно fapws не замена апачу (тем более хорошо настроенному). Он не production ready или по крайней мере об этом никто не знает. Потом все эти решения плохо масштабируются под нагрузкой. Нет умного шедулера процессов, а следовательно адаптивно форкаться или порождать новые инстансы сервера для балансировки на них не получится.

Кстати supervisord умеет нативно работать над FastCGI и может динамически порождать процессы в зависимости от нагрузки. Вот это уже интересно.
Неужели вы думаете что на 256 Мб будет крутится что-то сильно нагруженное? :) Впринципе целевая аудитория именно такая. Тем кому нужно распределение не будут даже бесплатно юзать 256 Мб сервера.

Если интересно, там 4 сайта всего с 200 униками в день каждый. С апачом это жрало всю память и 150-200 Мб swap… Не спорю, апач стоковый. После небольшой настройки ситуация немного изменилась, но не так кардинально.

И в моём случае стабильность системы с апачём многим меньше чем fapws3 (ну мне так кажется, пока не долго на нём сижу), т.к. каждые 5 дней использование всех ресурсов зашкаливало и слайс просто отказывал в обслуживании до хард ресета. Поэтому тут не всё так просто :)
у меня на слайсе в 256 крутится 5 сайтов суммарно с 6к уников в сутки (nginx->apache + mod_php/mod_wsgi). Все летает. Что я делаю не правильно?
nginx -> apache :)
Незнаю уж почему, но длинные цепочки _лично мне_ не нравятся. Выход одной цепочки из строя и всё. Пиши пропало.
*цепи
как короче?
Просто тогда в посте не хватает упоминания «целевой аудитории» такого решения чтобы не возникало лишних вопросов.

А вообще апач с embeded mod_wsgi (и даже в принципе mod_python) может очень хорошо и не прожорливо работать с минимальным расходом ресурсов. Но согласен, его в разы труднее настраивать и надо понимать чего хочешь и как этого добиться.

Ах да, ещё, fapws не чисто питонячий — там сердце это сишный libev для асинхронной обработки I/O.
Интересно было бы почитать про сборку апача под Django и вообще питон. С тестами.
Напишем:-)
Ждём :) Для меня это вообще нереальные дебри, я еле с модулями разобрался (пока выкидывал ненужные, сервер падал многа-многа раз), а уж сборка статичная… :)
у меня django и lighttpd общаются через flup (WSGI-совместимый FastCGI-сервер)

в django flup поддерживается (python manage.py runfcgi)

пара скриптов в init.d для запуска/остановки сервера и готово
как это настроить — описано прямо в документации django

так что мне непонятно, почему автор выбрал такой мудрёный вариант
flup форкается и тредится (можно конечно ему сказать maxсhildren=1, но смысл). fapws асинхронный однотредовый. Разные подходы у них.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Так вы разочаровывайте аргументировано. Я только рад буду новому научиться от умных людей. Расскажите как fapws работает и как flup на самом деле, если я не прав. Пожалуйста.
Автор, видимо, в душе исследователь. И это позитивно!

Я долго колебался между lighttpd и nginx, но потом выбрал последний просто из-за какой-то мелочи. Джанга подключена через flup/fastcgi аналогично, как абсолютно штатный вариант.

Исторически сложилось, что я пускаю сервер скриптом при помощи init, так как останов не предусматривается, а рестарт получается в этом случае просто при помощи kill.
НЛО прилетело и опубликовало эту надпись здесь
топик про экономию расхода памяти на VDS

очевидно, что делать highload-проект на VDS вряд ли кто-то станет

так что не понимаю, к чему ваш коммент

алсо, пруфлинк в студию
НЛО прилетело и опубликовало эту надпись здесь
Какой нагрузке и как валится? Очень интересно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Что такое хорошая нагрузка и что там валится?

Глядя на фастцги и пул воркеров просто не понятно чему там валиться.
> Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...».

Не думаю что проблема тут в nginx или mod_wsgi под него ;) что-то не так делаете
Экзамплы не запускаются с той же ошибкой… Я даже не знаю что уж так :)
fapws как и nginx mod_wsgi годны для потестить и для вашего случая. Почитайте комменты в багтрекере lighttpd. flup действительно иногда нужно перезапускать(впрочем, не буду утверждать т.к. не уверен что он был причиной нескольких аномалий). Грамотно собраный апач с mod_wsgi наше все.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
он сравнивает mod_wsgi, что совсем другое и к fapws отношения, кроме как использования одного стандарта взаимодействия с приложением, не имеет.
daevaorn + 1
да и статейка старовата уже, имхо
Вы не забывайте что fapws и прочие асинхронные сервера не зря называются асинхронными. При любом синхронном вызове блокируетя весь сервер. А посколько Django и другие используют вполне себе синхронный режим работы то для реального приложения один fapws будет практически всегда заметно медленнее чем пулл процессов или потоков.

Мы пробовали обходить это ограничение запуская 4 фапса на разных портах, и потом распределяя коннекшены между ними на lighttpd. В такой конфигурации скорость поднялась до уровня flups (разница в пределах статистической погрешности). Выигрыш есть только по памяти, а флап проверен в бою. Да и на память мы не жадные. Так что пока все проекты остались на флапсе.

PS: автор блога byteflow в нашей команде работает
Кстати вот это очень интересный момент. Долгие обработчики запроса блокируют весь асинхронный сервер. Причем, что обидно, зачастую долгие эти обработчики из-за сложных запросов в базу данным, которые конечно же синхронные. Вот тут недостающее звено явно проступает — асинхронный драйвер для базы данных и его интеграция в веб сервер для прозрачного переключения контекста обработки http запросов. Пока хорошего решения нет, кроме как проксирования запросов в базу через промежуточный http сервер, но это увеличивает сильно latency и в большинстве случаев не эффективно.
Асинхронный драйвер для базы данных требует асинхронного фреймворка. Асинхронность вообще любит под себя захавывать всю архитектуру приложения.

Twisted вполне удовлетворяет всем требованиям, но что-то не получил в вебе особого распостранения. То-ли Nevow дело, то-ли в том что синхронный код людям всё же привычней.

А относительно Django, imho, форки — это единственный кошерный способ запуска.
fapws3 — еще молодое…
странно, что для продакшена вы не попробовали несколько решений
есть еще lighttpd в качестве фронтенда и бэкенд cherrypy, интересно было бы перед выбором чего-либо пробовать разные их и не только их комбинации, ибо тема действительно насущная…

в любом случае спасибо за материал для размышлений!

ну а с апачем действительно пора кончать;)
НЛО прилетело и опубликовало эту надпись здесь
с каких это пор лайти только для статики? он так же умеет и реверс прокси и фронтендом для fapws3 или cherypy или flup-а быть

> fapws3 пошустрее cherrypy
не готов утверждать.
покажите пруфтесты.

fapws3 насколько помню только в декабре делаться начался, сыроват еще, не зачем скрывать…

а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…
> а fapws2 не умел треды совсем: пока одна страничка не отдастся, вторую он даже не начинал отдавать…

Так это специфика асинхронного сервера и синхронного приложения. fapws3 так же себя ведет.

Надо просто несколько инстансев иметь.
несколько сколько? 200 или 300?

у меня на продакшене 150-200 одновременно живущих конектов — обычное дело.
Ну 3-5 где-то. В зависимости от специфики проекта.

Так тут дело не в числе конектов к фронту, а в скорости ответа на запрос от бекэнда.

Тредовые сервер точно также не будет обрабытывать новый запрос, если все воркеры заняты.
это проблемы джанги и медленной СУБД,

я по сабжу небольшую заметку писал 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 постить не буду, т.к. сам не пользуюсь.
Да, но не все тут на архе сидят :) Но идея очень правильная, так сказать, arch way :)
у меня лично, как раз наобарот, fapws3 жрал очень много процессорного времени(про память не помню), да он быстрый, но ресурсов жрет нереально много, предпочитаю пускать джангу через nginx+fastcgi для продакшен проектов
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории