Асинхронные веб-фреймворки

[vitus_wagner]

Народ, а кто может подсказать фреймворки для построения веб-страниц, в которых порядок генерации отдельных фрагментов не принципиален?

Вернее, требуется фреймворк, который выдает запрос в БД, а потом не дожидаясь его результата выдает следующий и т.д., а по мере получения результатов эти результаты обрабатывает. Причем с более-менее приличным синтаксическим сахаром.

Ну то есть что-то подобное есть в питоновских вариантах на базе Twisted и Tornado, но у twisted просто ужасный синтаксис в этом месте. Опять же Twisted и Tornado не самые популярные инструменты у веб-разработчков.

Дело в том, что выяснилось, что если не соблюдать четкую последовательность запрос-ответ-запрос-ответ, а вывалить в бэкенд сразу сотню запросов, а потом читать ответы, у постгреса даже на той же машине, получается ускорение примерно вдвое (на простых запросах, сводящихся к одному index range scan или index lookup).

Соответственно, хочется попытаться оторвать от libpq существующую там проверку на "если результат предыдущего запроса не прочитан, со следующим посылаем", и попытаться это применить на каких-то реальных задачах.

Подобные паттерны с сотнями легких запросов в рамках одного коннекта характерны как раз для динамических веб-фреймворков.

У меня возникло подозрение, что подобный стиль работы естественным образом вписывается во всякие решения на базе haskell или ocaml. Но я web-фреймворков на базе этих языков (да и самих-то языков) толком не знаю.

Comments

Go подойдёт

[8df887a0-b2d1-4ca4-8758-9799a5a7bad1 [openid.stackexchange.com]]

Go со своим CSP на эту роль подходит прекрасно.

Вот простецкий код с демонстрацией: numWorkers "запросов" осуществляются параллельно, их "результаты" по мере поступления рендерятся в HTML.
После того, как все отработали, рендерер, который тоже работал параллельно, отдаёт результат в основной код.

Вот код на плэйграунде (http://play.golang.org/p/GxwDWPnFFb)

Как можно заметить, в коде нет ни одного события и ни одного колбэка.

В реальном коде были бы изменения:
* Горутины, которые делают запросы, получали бы инстанс sql.DB (который на самом деле инкапсулирует пул запросов) и выполняли запросы.
* Рендерер мог бы рендерить не в буфер, а напрямую в тело HTTP-ответа клиенту.

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

Нативный драйвер (чистый Go) хорошего качества под Постгрес есть (https://github.com/lib/pq).

К сожалению, локального инстанса Постгреса у меня нет, и в плейграунде с ним, понятно, тоже не поиграться.

Если что, готов ответить на вопросы (XMPP, e-mail kostix at 007spb.ru).

[tiendil.livejournal.com]

На всякий случай уточню, что на Twisted можно писать в стиле Tornado. Даже есть портированная торнадовская веб часть, Cyclone называется.

Популярные асинхронные фремворки врядли существуют, асинхронность не самая простая для восприятия штука.

[vitus_wagner]

Я в курсе про Cyclone.


По-моему, вообще генерация веб-страниц это самая ниша для функционального программирования - получаешь на вход некоторый набор параметров - URL заголовки запроса, состояние БД, возвращаешь строку.

[grey-kristy.livejournal.com]

Дело в том, что никто уже давно не собирает веб страницы на строне сервера. Страница рисуется JS на стророне клиента, а информацию JS получает от сервера по кусочкам, асинхронно, обычно через web socket'ы

А так, для Эрланга есть асихнронный клиент к Постгресу, можно пользоваться

[freedom_of_sea.livejournal.com]

так ведь рисует его джаваскрипт, который как раз простой и асинхронный

[tiendil.livejournal.com]

Вот я бы не назвал асинхронный код на JS простым. Конечно, если код заключается в том чтобы колбэк на ajax повесить, то это просто. А что-то сложнее там тоже не легко делается.

Хотя я уже не в курсе какие сейчас там новые фреймворки понаписали, может что прорывное и появилось.

[anonim-legion.livejournal.com]

ЖЖ-юзер jakobz что-то подобное делал. Также, C#-tasks как раз примерно таким и могут заниматься, то есть запустить кучу запросов, а потом собирать из них большое дерево-результат.

[aduchi.livejournal.com]

на томже питоне есть aiohttp и falcon

[vitus_wagner]

Это совсем не про то. Мне нужен шаблонизатор, позволяющий создавать сложные страницы, для которых требуются сотни запросов к базе. А не тривиальные подложки под REST.

aiohttp, возможно, имеет перспективы, но судя по всему - еще не выросло.

[andrzejn]

ASP.Net MVC примерно с версии .Net Framework 4.0 весь асинхронный. А активно пишущаяся версия .Net 5.0, которую обещают зарелизить в 2016 году, будет изначально совместима с линуксами и MacOS.

[angry-elf.livejournal.com]

В Django весь ORM сделан ленивым, т.е. лезет в базу при попытке вывода данных, а не при формировании запроса. Соответственно, теоретически, можно с ним наколдовать асинхронность.

[vitus_wagner]

Вот Django это уже интереснее. Потому что это весьма распространенный фрейморк. И вообще, возможно тут мне надо смотреть не в сторону шаблонизаторов, а в сторону ORM (хотя я их терпеть ненавижу).

Потому что вообще идея пайплайнинга запросов возникла из соображений "ну многие noSQL-базы так делают, и это там дает выигрыш".

[tanner-of-kha.livejournal.com]

Весь гешефт ленивости в том, что все функции в цепочке, возващающие QuerySet, объединяются в один SQL-запрос. Если попытаться извлекать QuerySet’ы из БД асинхронно, всё это развалится.

Да и как это реализовать? Я могу представить асинхронный database backend для Django только так, что функции ORM работают c нативными SQL views вместо отложенных результатов. Но боюсь, тогда испортятся и переносимость, и производительность в тех случаях, когда это вообще будет возможно. Создание SQL view − довольно ресурсоёмкая штука afaik.

[allter]

Мне кажется, асинхронка запросов к БД именно на одном коннекте в фреймворке общего назначения - очень редкий сценарий использования.

Сохранять в шаблоне для вывода жёсткую привязку к БД для того, что бы шаблонизатор мог асинхронно разбить множество N полей шаблона на количество M (M<=N) запросов к БД и потом собрать полученные данные в страницу; либо в контролере по хитрой логике делать тоже самое - очень неслабое нарушение идеалогии MVC, с соотвествующими накладными расходами на написание/поддержание этого не-MVC`шного кода.

А так - в большинстве крупных проектов, по-моему, так или иначе используются мультиплексоры обращений к RDBMS (где K коннектов к RDBMS используются всеми частями системы через синхронные tcp запросы к серверу-мультиплексору либо через какой-то сервер очередей/протокол сообщений). Учитывая большое количество одновременно выполняющихся программ, получается почти такая же "упаковка" запросов, только без применения, собственно, асинхронных техник.

Возможно, где-то в области высокочастотного трейдинга именно асинхронное выполнение запросов востребовано (но, боюсь, им нужно больше детерминированности в скорости и порядке выполнения отдельных запросов - что немного противоречит асинхронности).

[vitus_wagner]

Как раз использование подобной асинхронности не требует жесткой привязки к БД. Поскольку режим, когда перед передачей следующего запроса надо дождаться результата предыдущего, является частным случаем дисциплины "шлем запросы пока их соглашаются принимать, и обрабатываем результаты по мере их получения".

И тут как раз ситуация, когда не нужно разбивать множество полезй шаблона на M<=N запросов в БД, а можно, не мудрствуя лукаво посылать для каждого поля отдельный запрос.

[tanner-of-kha.livejournal.com]

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

[http://users.livejournal.com/_arty/]

насколько я представляю, самый популярный фреймворк express для node.js изначально асинхронный, и все его «дети» тоже

[cross-join.livejournal.com]

Тут порочен изначальный принцип "много мелких запросов на чтение".
Попытайтесь собрать их в несколько более крупных запросов, производительносить вырастет не в 2 раза, а на порядки.

[vitus_wagner]

Я тут как раз занимаюсь оптимизацией производительности постгреса в ситуации много мелких запросов на чтение. И пытаюсь найти (казалось бы естественный) реальный пример, на котором полученные результаты можно демонстрировать.

ZeroMQ from Python?

[anonym-mouse.livejournal.com]

ZeroMQ from Python.

Вам придется разобраться, какую из patterns
использовать (например, Publish-Subscribe etc)

Тогда программки на обоих концах соединения
смогут издавать асинхронные запросы или публиковать
результаты - и их собирать в осмысленное.

В целом вы как бы хотите что-то вроде парадигмы
Эрланга, воплощенной в каком-то из Web Frameworks?

Присобачьте ZeroMQ (или её потомков по нисходящей),
и пользуйтесь существующим framework'ом.

.. если я понял вашу задачу правильно..

Re: ZeroMQ from Python?

[vitus_wagner]

По-моему, вы не поняли мою задачу совсем.

У меня есть клиент-серверная база данных, и есть возможность выполнять в секунду вдвое больше запросов к этой базе ценой некоторого переупорядочения отправки запросов и разбора ответов к ней на клиенте. Соответственно вопрос заключается в том, какое приложение можно найти, которое сумеет это ускорение использовать.

Так что всякое middleware вроде MQ тут вообще ни при чем. Сокет соединяющий клиента и сервер - он сам по себе очередь, вернее даже две, поскольку данные по нему передаются в обе стороны.

[metaclass.livejournal.com]

nginx и постгрес-модуль для него?
node.js, которая вдоль и поперек должна быть асинхронной, по идее (надеюсь клиенты к СУБД для нее тоже асинхронные и используют тот же libuv для сокетов).

[vitus_wagner]

А что nginx тащит из postgres? nginx он же веб-сервер, он сам веб-страницы не генерирует.

Там что ли ORM отображающий реляционную базу в набор REST-объектов?
Ну так к это совершенно незрелищно в плане демонстрации.

[kremator666.livejournal.com]

Очевидный нодюжс или ангулар.жс очевиден

[allter]

И что, там есть шаблонизатор с асинхронным сборщиком страниц? Если да, то можно какой-то пример асинхронной сборки?

Асинхронные-то циклы обработки событий есть сейчас на всех платформах, как и сопрограммы (yield), синтаксические сахары вроде Promise и т.п. Т.е. при желании везде можно в две строчки навертеть, была бы только необходимость...