Pull to refresh

Comments 22

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

Стресс-тест еще не делал.
Добавьте модулям префиксы пока не поздно…
можно подробнее? я новичок в эрланге и не знаю как там и что?
Ну, такие имена как channel helper middleware uuid общеупотребительные. В Erlang пространство имён двухуровневое. Так что, если вы вдруг захотите подключить к своему приложению стороннюю библиотеку вроде github.com/avtobiff/erlang-uuid то поймаете конфликт имён.
Ну и ваше приложение никто не захочет встраивать в свою систему из за этого.
Идея в том, чтобы вы своим модулям добавляли префикс типа
epusher_channel
epusher_helper
epusher_middleware
и т.п. — чтобы уменьшить вероятность коллизии имён.
Можете посмотреть как сделано в том же Cowboy: у всех модулей префикс cowboy_.
Код можно упростить, SockJS умеет подключать напрямую через websocket, в обход механизма детектирования транспорта. Для этого надо url задавать в виде ws://host:port/centrifuge/websoket.
спасибо за замечание, но не могли бы вы более подробно пояснить, что имеете в виду? В каком месте упростить и зачем обходить детектирование транспорта — поддержки вебсокетов в браузере ведь может и не быть?
Я имею в виду, убрать
tornado.web.url(
                r'/connection/websocket',
                WebsocketConnection,
                name="connection_websocket"
            ),

и класс WebsocketConnection
К SockJS серверу можно подключаться, как через клиентскую библиотеку так и напрямую через raw WebSocket.
о! спасибо большое, не знал, обязательно поправлю
Существует более быстрая чем Server-Sent Events реализация передачи сообщений — Websockets

Что, простите?)
Я не понял в чем WebSockets «более быстрая», чем SSE.
Два текстовых протокола, с минимальными различиями на уровне кодирования
Server-Sent Events — это http протокол со всеми его оверхедами, WebSockets — это надстройка поверх TCP, изначально разработанная для обмена сообщениями между браузером и веб-сервером в режиме реального времени (wikipedia). Посмотрите вот на этот замечательный пост на SO — там многое объясняется.
Oh, so wrong…
Этот пост — о сравнении HTTP-запросов и Web Socket.
И его главный постулат — websocket быстрее, потому что не надо каждый раз слать хедеры.
Но, внезапно, SSE это тоже долгоживущий TCP-сокет. Который передает заголовки лишь при подключении(как и WebSocket). То есть, это сравнение совершенно не о том
Задержки на установку соединения сказываются на производительности, разве нет? Ну и также все общение при использовании SSE инкапсулируется в HTTP — а это промежуточные прокси, файрволлы, которые могут буфферизовать траффик, что приводит к увеличению времени ответа.
>Задержки на установку соединения сказываются на производительности, разве нет?
Соединение устанавливается один раз при подключении. Как и у WebSockets, они ведь наверное тоже требуют первоночальное подключение?)

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

Вобщем давайте я сформулирую свою мысль. Единственное значимое отличие WebSocket от SSE — наличие двухсторонней связи(SSE — односторонняя).
Пожалуй, вы правы. Поисследовал этот вопрос повнимательней — и да, скорее всего увеличения производительности нет, во многих тестах, которые я смог найти в интернете SSE не уступает вебсокетам по производительности. Думаю, это утверждение у меня на подсознательном уровне сформировалось и не хотелось так просто с ним расставаться. Спасибо.
Отношусь спокойно, так как выбрал для разработки язык, которым лучше владею. Конечно, Erlang в подобных серверах просто всеми красками расцветает, но сколько я за него не брался — никак не мог преодолеть рубеж между книгой и написанием чего-либо.

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

Articles