Бесполезность 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к %)
