Таких предложений не было. И я не представляю как сделать так, чтобы оно появилось. Должна быть ценность, которую пока большие компании не видят. Я сам работал и в mail.ru, и в Авито ранее. И в целом обеим компаниям наработки очень даже пригодились бы. В Mail.ru есть проекты (и далеко не один), использующие Centrifugo, в Авито есть мессенджер, построенный на бекенде на идентичной концепции.
Если нужно только одностороннее общение, от сервера клиенту, и стабильный набор подписок, – то описанные в статье unidirectional транспорты могут быть неплохим выбором, чтобы обойтись совсем без специализированного клиента на фронте. Уберете не только зависимость, но и слой дополнительной сложности. Хотя centrifuge-js в целом проверен временем - с ним не должно быть проблем (по крайней мере для основной функциональности).
Я бы вообще счастлив был обойтись без PRO, не только перформанса это касается. Я думаю, что идеального баланса не найти в такой модели. Я читал несколько статей про open core модель прежде чем пытаться сделать что-то подобное – и основная озвучиваемая проблема – это вечный конфликт между тем, что должно быть в OSS, и тем, что закрыто. И это так – я сам уже не один час над верным и оправданным разделением фичей думал... Но ничего другого на данном этапе не остается, кроме как попробовать что-то.
Добрый день, только заметил новый комментарий. В списке в статье перечислены клиентские библиотеки — то есть те, что со стороны фронтенда приложения открывают WebSocket-подключение. А для серверного HTTP API есть набор библиотек, в том числе и для PHP. Вот тут перечислены.
Тогда, наверное, можно позапускать бенчмарки, которые в коде разбросаны — они плюс-минус отдельные части покрывают. А тут, получается, я взял определенный сценарий, поднял в реальных условиях — и посмотрел на поведение всей системы в целом причем в распределенном сценарии с брокером. Очень искусственно это все, но как я написал в статье – хоть какие-то цифры и их порядки. Fan-out-а можно добиться больше на порядок точно, вот когда-то делал не распределенный бенчмарк – и там видно, что это уже до 100k на ядро — но опять же это не чистый fan-out, там тоже было много другой работы (но не было Redis-а). Но в целом под капотом у Centrifugo Gorilla Websocket – ничего сверх того, на что способна эта библиотека вкупе со стандартной библиотекой Go нет. На разных этапах есть определенные оптимизации (Gogoprotobuf, где-то меньше write сисколлов на запись при большом рейте сообщений в соединение, pipelining + smart batching при работе с Redis, вот есть статья про некоторые оптимизации внутри).
Но в целом Centrifugo это скорее про удобство и кроссплатформенность, чем про низкоуровневые оптимизации производительности. Хотя благодаря Go и плюс-минус адекватному его использованию performance на достаточно высоком уровне.
Например, Centrifugo сейчас использует под капотом библиотеку Centrifuge (хотя скорее это фреймворком правильней назвать, так как API у нее очень большой плюс диктуется протокол и многие другие вещи) для Go — для этой библиотеки я делал POC, где для WebSocket используется библиотека gobwas/ws и epoll — вот пример в репозитории — github.com/centrifugal/centrifuge/tree/master/_examples/custom_ws_gobwas — там немного других цифр можно ожидать (в основном по потреблению памяти), но как бы ни хорош был выигрыш я по-прежнему продолжаю использовать Gorilla WebSocket в сервере, так как лучше понимаю как в случае чего чинить (да оно и не ломается). Есть еще новомодная либа для WebSocket, которая по возможностям сейчас уже равна Gorilla WebSocket (кроме PreparedMessage вроде все остальное автор уже добавил) — github.com/nhooyr/websocket — для нее тоже есть пример в репозитории библиотеки github.com/centrifugal/centrifuge/tree/master/_examples/custom_ws_nhooyr. Но чет тоже пока не горю желанием менять.
Если 500k разделить на 40 ядер, то да. Но CPU не только на fan-out тратился в этом случае, плюс большинство сообщений тут были индивидуальными, то есть проходили полный цикл всевозможных сериализаций и десериализаций на пути от продьюсера до консьюмера (чтение из ws, десериализация, понимание, что это публикация, сериализация для Редис, потом десериализация из PUB/SUB, далее сериализация консьюмера (1 раз для каждой годы, на которую долетело из PUB/SUB). Не знаю, ответил ли на вопрос?
Добрый день, более подробное описание по ссылке в документации – centrifugal.github.io/centrifugo/misc/benchmark, там это написано — было 20 подов сервера в Kubernetes, каждый примерно 2 ядра CPU потреблял при максимальной нагрузке. К сожалению, графика gc_duration не осталось – возможность посмотреть была, эти метрики экспортируются, но теперь уже нет возможности поднять эти циферки. Можно только сказать, что STW паузы не превышали latency доставки сообщений в указанном 99 персентиле:) Но вопрос хороший — жалею, что этой информации не осталось.
Знакомьтесь, друзья — это Алексей, мой коллега — мечтает перенести игру Ётта (https://www.igroved.ru/games/iota/) в браузер и приделать к ней мультиплеер. Показалось необходимым пояснить:)
Не то что бы он чем-то не угодил, проект родился достаточно давно — MQTT не был достаточно распространен и я о нем не знал до определенного момента. За это время собственный протокол оброс некоторыми фичами, которых нет в спецификации MQTT. Протокол гораздо проще. Нет разных QOS (по сути Centrifugo — это только QOS 0) – это конечно не плюс, но на практике работает, и позволяет серверной реализации быть простой. Recovery в Центрифуге используется только при реконнектах, PUBREC аналога нет. Нет wildcard-подписок, что с одной стороны минус, а с другой очень сильно упрощает реализацию сервера и позволяет безболезненно шардировать каналы в Redis-ах. В общих чертах протоколы похожи — MQTT может предложить больше, но за счет радикального усложнения серверной части. Так как Центрифуга успешно используется в достаточном кол-ве проектов, могу сделать вывод, что протокол справляется с большим количеством практических задач.
Дополнил ридми информацией для контрибьютеров. Вы поймите меня правильно – я хорошо отношусь к фидбеку, но слова вроде «у вас странный подход к разработке» не очень похожи на конструктивизм – это задевает. Извиняйте если что…
Согласен, что если в стеке не используется Redis — тащить его далеко не идеальный вариант. Ну как я сказал — я не против попробовать это поддержать в будущем, но есть достаточно много моментов, которые на первый взгляд не видны и обеспечиваются текущей реализацией.
Если вы готовы помочь с этим — пишите мне в ЛС, или в Gitter-чат gitter.im/centrifugal/centrifugo — можно обсудить, я расскажу подробнее.
Проекту 5 лет, он давно развивается — в разработке принимали участие ребята, которые сейчас работают в Hashicorp, плюс один из очень уважаемых разработчиков в Go-сообществе Klaus Post внес свой вклад. Это на случай если вы считаете, что я один все это делал. Дизайнерские решения по возможностям были приняты давно. Вы пришли — вбросили не разобравшись issue, не смогли склонировать библиотеку правильно — и учите меня Go.
Мой подход к разработке — не делать что-то без реальной необходимости со стороны пользователей и стараться как можно меньше ломать API даже на такой ранней стадии. Не считаю это странным, вы можете думать как угодно.
Привет, пока Engine интерфейс скрыт внутри библиотеки, но мой план его в конечном итоге открыть. Не хочется делать это раньше времени (чтобы потом не менять внешнее API engine-а) пока кто-то не придет с реальным юзкейсом, какой-то реализацией и обоснованием преимуществ нового engine-a для юзкейса. Из коробки — те же два остаются, да.
Спасибо за фидбек, путаница есть из-за того, что я пишу про то, что еще не добралось до релиза – мне было важно собрать фидбек. Замечания постараюсь учесть.
Toml-файлы генерятся автоматически dep-ом, ничего туда руками прописывать не нужно — этот момент не понял.
Насколько понимаю теперь вместо HMAC авторизации используется JWT стандарт?
Да, все так. JWT так же под капотом использует HMAC (на самом деле JWT умеет на основе других алгоритмов генерировать подписи, напр. AES, но мы пока HMAC SHA-256 поддерживаем только). Благодаря тому, что библиотеки JWT есть для большинства языков — вся генерация токенов скрыта от пользователя, хотя под капотом там очень похожий механизм.
Позиция тут достаточно принципиальная в данный момент – если нужны методы восстановления истории для дисконнектов больше чем время жизни кеша, то это должно быть вне библиотеки.
История спроектирована именно под короткие дисконнекты на N секунд. Центрифуга держит кеш сообщений в памяти или в Redis – это информация, которая может быть потеряна (например если используется in-memory движок и нода перезагружается, в случае Redis история конечно сохранится, но семантика та же). В протоколе заложена возможность восстановить историю с бекенда в таком случае, так как Центрифуга дает клиенту понять были ли восстановлены сообщения.
Имхо под такой функционал история должна храниться персистентно и индексироваться — я не против это обсуждать, но перспектив особых не вижу в данный момент.
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?)
Добрый день, не смотрели ли на Centrifugo (https://github.com/centrifugal/centrifugo) как альтернативу Mercure? Предлагает больше транспортов на выбор и масштабируется (в то время как бесплатная версия mercure ограничена одной нодой ).
Какое-то время назад я пытался получить MOSS - получил отказ. Сейчас он уже не выдается. А какие фонды вы имеете в виду?
И что такое спонсорская поддержка для конференций? Я и без спонсорской поддержки могу выступать на конференциях, или вы о чем-то еще?
Таких предложений не было. И я не представляю как сделать так, чтобы оно появилось. Должна быть ценность, которую пока большие компании не видят. Я сам работал и в mail.ru, и в Авито ранее. И в целом обеим компаниям наработки очень даже пригодились бы. В Mail.ru есть проекты (и далеко не один), использующие Centrifugo, в Авито есть мессенджер, построенный на бекенде на идентичной концепции.
Если нужно только одностороннее общение, от сервера клиенту, и стабильный набор подписок, – то описанные в статье unidirectional транспорты могут быть неплохим выбором, чтобы обойтись совсем без специализированного клиента на фронте. Уберете не только зависимость, но и слой дополнительной сложности. Хотя centrifuge-js в целом проверен временем - с ним не должно быть проблем (по крайней мере для основной функциональности).
Я бы вообще счастлив был обойтись без PRO, не только перформанса это касается. Я думаю, что идеального баланса не найти в такой модели. Я читал несколько статей про open core модель прежде чем пытаться сделать что-то подобное – и основная озвучиваемая проблема – это вечный конфликт между тем, что должно быть в OSS, и тем, что закрыто. И это так – я сам уже не один час над верным и оправданным разделением фичей думал... Но ничего другого на данном этапе не остается, кроме как попробовать что-то.
Но в целом Centrifugo это скорее про удобство и кроссплатформенность, чем про низкоуровневые оптимизации производительности. Хотя благодаря Go и плюс-минус адекватному его использованию performance на достаточно высоком уровне.
Например, Centrifugo сейчас использует под капотом библиотеку Centrifuge (хотя скорее это фреймворком правильней назвать, так как API у нее очень большой плюс диктуется протокол и многие другие вещи) для Go — для этой библиотеки я делал POC, где для WebSocket используется библиотека gobwas/ws и epoll — вот пример в репозитории — github.com/centrifugal/centrifuge/tree/master/_examples/custom_ws_gobwas — там немного других цифр можно ожидать (в основном по потреблению памяти), но как бы ни хорош был выигрыш я по-прежнему продолжаю использовать Gorilla WebSocket в сервере, так как лучше понимаю как в случае чего чинить (да оно и не ломается). Есть еще новомодная либа для WebSocket, которая по возможностям сейчас уже равна Gorilla WebSocket (кроме PreparedMessage вроде все остальное автор уже добавил) — github.com/nhooyr/websocket — для нее тоже есть пример в репозитории библиотеки github.com/centrifugal/centrifuge/tree/master/_examples/custom_ws_nhooyr. Но чет тоже пока не горю желанием менять.
Если вы готовы помочь с этим — пишите мне в ЛС, или в Gitter-чат gitter.im/centrifugal/centrifugo — можно обсудить, я расскажу подробнее.
Мой подход к разработке — не делать что-то без реальной необходимости со стороны пользователей и стараться как можно меньше ломать API даже на такой ранней стадии. Не считаю это странным, вы можете думать как угодно.
Toml-файлы генерятся автоматически dep-ом, ничего туда руками прописывать не нужно — этот момент не понял.
Да, все так. JWT так же под капотом использует HMAC (на самом деле JWT умеет на основе других алгоритмов генерировать подписи, напр. AES, но мы пока HMAC SHA-256 поддерживаем только). Благодаря тому, что библиотеки JWT есть для большинства языков — вся генерация токенов скрыта от пользователя, хотя под капотом там очень похожий механизм.
Документация будет новая — уже есть прототип, который еще будет доработываться, но вот например описание JWT там — centrifugal.github.io/centrifugo/server/authentication
Не понял вопрос про проверку библиотекой токены выданные Centrifuge(o).
История спроектирована именно под короткие дисконнекты на N секунд. Центрифуга держит кеш сообщений в памяти или в Redis – это информация, которая может быть потеряна (например если используется in-memory движок и нода перезагружается, в случае Redis история конечно сохранится, но семантика та же). В протоколе заложена возможность восстановить историю с бекенда в таком случае, так как Центрифуга дает клиенту понять были ли восстановлены сообщения.
Имхо под такой функционал история должна храниться персистентно и индексироваться — я не против это обсуждать, но перспектив особых не вижу в данный момент.
Параметризуется на уровне канала — godoc.org/github.com/centrifugal/centrifuge#ChannelOptions