slav0nic's blog

Заметки о python, linux и других занимательных вещах

Бесполезность async серверов в Веб

В предыдущем посте поигрался с асинхронным способом запуска Django через cogen. Как оказал - совершил ошибку :) /me не спец в async-программировании Ниже выскажу своё мнение.

Итак, "асинхронизм" довольно сложная и тонкая штука, которую легко можно нарушить лишь одной синхронной I/O операцией. В тестах на "hellow world" асинхронный метод показал хороший результат, НО в реальных веб-приложениях есть узкое место, а конкретней СУБД. В реальной ситуацие мы получаем, что к базе существует лишь 1 коннект, т.е. django создаёт коннект -> выполняет операцию -> закрывает коннект, и потом опять повторяет данную последовательность. Поэтому на реальном приложении я получил такую ситуацию, что приложения начинало "накапливать" запросы к бд, и как-бы выставляло их в очередь и выполняло последовательно через 1 коннект. Хотя у psycopg2 и есть async API, но в django ORM данная поддержка отсутвует.

При запуске через cherrypy мы имеем тредовый WSGI сервер, при этом к базе у нас не 1 коннект, а несколько параллельных (max число упирается в число тредов).

В общем остановился на cherrypy + pgbouncer + postgres. PgBouncer использую по той причине, что у Постгреса тяжко с обработкой новых коннектов, да и на VPS лучше держать форки в памяти, чем каждый раз стартовать новый из-за тормознутости HDD. По поводу тестов piranha и результатов для CherryPy - там не был указан параметр request_queu_size, который используется сервером как параметр для socket.listen() (по дефолту он равен 15, так что результат очевиден), да и у Spawning dev-watch режим не выключен В)

Так что, имхо, использовать async можно лишь на серверах где нет БД, там будет реальный прирост производительности. Хотя на малонагруженых серврерах тоже сойдёт. Испытания проводил на серваке с нагрузкой более 18 req/s, в MYSQL (уже сменил на postgres) avg был равен около 550 q/s иногда и 1.2к %)

bsdemon post on 2008-12-12 14:36:02
Кстати у twisted есть асинхронное db api, который где может повторяет питоновский db api, но различия конечно же есть. Интересно может можно будет переучить Django на него?
slav0nic post on 2008-12-12 14:39:23
исходя из судьбы django-sqlalchemy - это сложно сделать. Джанговский орм мне очень не нравится из-за таких вот вещей=(
bsdemon post on 2008-12-12 14:48:43
А что с django-sqlalchemy? Джанговский ОРМ просто ужасен - и дело тут не только в сабже. Мне больше нравиться dejavu или sqlalchemy - там можно маппить классы даже на селекты. Вообщем active record не моё :) Ну а вообще если не нравиться django orm, то и сам django не стоит использовать, лучше уже тогда werkzeug + jinja2 + sqlalchemy. Потому как единственный плюс в джанге это скаффолдинг.
slav0nic post on 2008-12-12 15:06:55
с алхимией на сколько я знаю довольно рпоблемная была интеграция, хотя сейчас проект вроде опять оживился, но последний коммит 2008 число %) уж сильно ОРМ завязан на внутренности. С ормом приходится мириться) всё равно это лучше чем pylons или TG
Grigoriy Petukhov post on 2008-12-12 15:14:26
А как же newforms и template engine? Чем не плюсы?
slav0nic post on 2008-12-12 15:18:11
ну вот из-за этого и юзаю джангу) хотя возможно в некоторых приложениях аля xml-rpc сервисы и тп (где есть лишь выдача инфы) буду юзать webpy + db api для вьюшек, а джангу лишь для админки )
bsdemon post on 2008-12-13 12:28:33
Да newforms согласен это плюс, а вот насчёт шаблонов, я предпочитаю jinja2, одна из причин http://tinyurl.com/6z9ejf. Что-то подобное newforms я собираюсь написать сам.
Андрей Светло post on 2008-12-16 23:42:08
sqlalchemy+pylons+mako Правда, сам уже год не использую - текущий проект не для веба. А ребята гоняют. В целом очень довольны. Славоник, мое мнение о асинхре и twisted ты и так знаешь - в умелых руках бомба, плюс сотрудников очень быстро обучал до нужного уровня. В последний раз - 2 недели назад. Потребовался асинхронный ftp, и twisted хорошо подошел. Он вообще отлично вписывается в любое GUI.

web.py