Centrifuge — брокер реал-тайм сообщений

[merc]

Я пишу похожую штуку — эмуляцию бекенда pusher.com на эрланге github.com/arrowcircle/erlypusher
У Вас есть функционал presense-каналов?
Стресстест делали?

[FZambia]

в статье описал почти весь функционал, который на данный момент имеется, за исключением, пожалуй, мелких фич вроде использования exponential back-off при авторизации клиентов во время реконнекта. Поэтому, нет, таких каналов пока что нет. Доступ к определенному каналу сейчас ограничивает пользовательское приложение во время авторизации. Никакой дополнительной информации о канале пока что получить нельзя.

Стресс-тест еще не делал.

[seriyPS]

Добавьте модулям префиксы пока не поздно…

[merc]

можно подробнее? я новичок в эрланге и не знаю как там и что?

[seriyPS]

Ну, такие имена как channel helper middleware uuid общеупотребительные. В Erlang пространство имён двухуровневое. Так что, если вы вдруг захотите подключить к своему приложению стороннюю библиотеку вроде github.com/avtobiff/erlang-uuid то поймаете конфликт имён.
Ну и ваше приложение никто не захочет встраивать в свою систему из за этого.
Идея в том, чтобы вы своим модулям добавляли префикс типа

epusher_channel
epusher_helper
epusher_middleware

и т.п. — чтобы уменьшить вероятность коллизии имён.
Можете посмотреть как сделано в том же Cowboy: у всех модулей префикс cowboy_.

[Dumbris]

Код можно упростить, SockJS умеет подключать напрямую через websocket, в обход механизма детектирования транспорта. Для этого надо url задавать в виде ws://host:port/centrifuge/websoket.

[FZambia]

спасибо за замечание, но не могли бы вы более подробно пояснить, что имеете в виду? В каком месте упростить и зачем обходить детектирование транспорта — поддержки вебсокетов в браузере ведь может и не быть?

[Dumbris]

Я имею в виду, убрать

tornado.web.url(
                r'/connection/websocket',
                WebsocketConnection,
                name="connection_websocket"
            ),

и класс WebsocketConnection
К SockJS серверу можно подключаться, как через клиентскую библиотеку так и напрямую через raw WebSocket.

[FZambia]

о! спасибо большое, не знал, обязательно поправлю

[andll]

Существует более быстрая чем Server-Sent Events реализация передачи сообщений — Websockets

Что, простите?)

[FZambia]

спасибо, поправил

[andll]

Я не понял в чем WebSockets «более быстрая», чем SSE.
Два текстовых протокола, с минимальными различиями на уровне кодирования

[FZambia]

Server-Sent Events — это http протокол со всеми его оверхедами, WebSockets — это надстройка поверх TCP, изначально разработанная для обмена сообщениями между браузером и веб-сервером в режиме реального времени (wikipedia). Посмотрите вот на этот замечательный пост на SO — там многое объясняется.

[andll]

Oh, so wrong…
Этот пост — о сравнении HTTP-запросов и Web Socket.
И его главный постулат — websocket быстрее, потому что не надо каждый раз слать хедеры.
Но, внезапно, SSE это тоже долгоживущий TCP-сокет. Который передает заголовки лишь при подключении(как и WebSocket). То есть, это сравнение совершенно не о том

[FZambia]

Задержки на установку соединения сказываются на производительности, разве нет? Ну и также все общение при использовании SSE инкапсулируется в HTTP — а это промежуточные прокси, файрволлы, которые могут буфферизовать траффик, что приводит к увеличению времени ответа.

[andll]

>Задержки на установку соединения сказываются на производительности, разве нет?
Соединение устанавливается один раз при подключении. Как и у WebSockets, они ведь наверное тоже требуют первоночальное подключение?)

>Ну и также все общение при использовании SSE инкапсулируется в HTTP — а это промежуточные прокси, файрволлы, которые могут буфферизовать траффик, что приводит к увеличению времени ответа.
Так позвольте, а что, WebSocket это не касается?

Вобщем давайте я сформулирую свою мысль. Единственное значимое отличие WebSocket от SSE — наличие двухсторонней связи(SSE — односторонняя).

[FZambia]

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

[FZambia]

Упс, не туда написал, но успел отредактировать:)

[md55]

А как вы относитесь к неутешительным результатам тестов вебсокетов на питоне?
github.com/ericmoritz/wsdemo/blob/results-v1/results.md

[FZambia]

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

По вашей ссылке приведены плачевные результаты для Gevent, а я вижу, что у них в репозитории есть еще и Python c Tornado, не знаете, есть ли результаты для этой связки?

[seriyPS]

eric.themoritzfamily.com/websocket-demo-results-v2.html

[FZambia]

По этой ссылке совершенно другая картина. Добавились бенчмарки с количеством запущенных процессов по количеству ядер, и конечные результаты поменялись. По-моему, все не так уж неутешительно. А если взять Pypy в расчет — то и вовсе замечательно. Опять же, логично, что Erlang и Go показали лучшие результаты — оба языка спроектированы с уклоном на concurrency. В любом случае, какие бы ни были результаты, питон для Centrifuge был выбран не из соображений производительности.