FZambia 24 июн 2013 в 08:57

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

6 мин

18K

Веб-разработка*Python*

Recovery Mode

+38

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

merc 24 июн 2013 в 10:38

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

FZambia 24 июн 2013 в 11:03

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

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

seriyPS 24 июн 2013 в 20:14

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

merc 24 июн 2013 в 23:01

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

seriyPS 24 июн 2013 в 23:18

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

epusher_channel
epusher_helper
epusher_middleware

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

Dumbris 24 июн 2013 в 11:15

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

FZambia 24 июн 2013 в 11:22

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

Dumbris 24 июн 2013 в 12:54

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

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

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

FZambia 24 июн 2013 в 13:12

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

andll 24 июн 2013 в 11:34

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

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

FZambia 24 июн 2013 в 11:44

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

andll 24 июн 2013 в 11:54

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

FZambia 24 июн 2013 в 12:14

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

andll 24 июн 2013 в 12:18

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

FZambia 24 июн 2013 в 12:33

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

andll 24 июн 2013 в 12:46

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

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

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

FZambia 24 июн 2013 в 13:17

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

FZambia 24 июн 2013 в 12:13

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

md55 24 июн 2013 в 23:52

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

FZambia 25 июн 2013 в 00:22

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

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

seriyPS 5 июл 2013 в 22:21

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

FZambia 6 июл 2013 в 14:11

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

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

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

Публикации

Истории