Comments 13
Давай уже делать Ётту!
Знакомьтесь, друзья — это Алексей, мой коллега — мечтает перенести игру Ётта (https://www.igroved.ru/games/iota/) в браузер и приделать к ней мультиплеер. Показалось необходимым пояснить:)
А мы уже в 2016 году сделали*. Если интересно:
*Конечно завершённой реализацией это не назовёшь, но играть можно.
Мне кажется это знак, только ознакомился предыдущей статьёй и тут уже, статья о новых фишках, недавний релиз, причём в интересный день — 8 марта. Буду знакомиться дальше.
Меседжер в авито, помню что действительно был не очень, мягко говоря, сейчас им очень непринуждённо пользоваться, супер.
Спасибо за стоящий проект.
Меседжер в авито, помню что действительно был не очень, мягко говоря, сейчас им очень непринуждённо пользоваться, супер.
Спасибо за стоящий проект.
Александр, сколько инстансов центрифуги было запущено на тесте? А то не понятно по сколько коннектов и сообщений/сек на инстанс.
Есть ли график для gc_duration? gc в последние годы хорош, но все же.
Есть ли график для gc_duration? gc в последние годы хорош, но все же.
Добрый день, более подробное описание по ссылке в документации – centrifugal.github.io/centrifugo/misc/benchmark, там это написано — было 20 подов сервера в Kubernetes, каждый примерно 2 ядра CPU потреблял при максимальной нагрузке. К сожалению, графика gc_duration не осталось – возможность посмотреть была, эти метрики экспортируются, но теперь уже нет возможности поднять эти циферки. Можно только сказать, что STW паузы не превышали latency доставки сообщений в указанном 99 персентиле:) Но вопрос хороший — жалею, что этой информации не осталось.
Т.е. это где-то по 10к fan-out сообщений на ядро?
Если 500k разделить на 40 ядер, то да. Но CPU не только на fan-out тратился в этом случае, плюс большинство сообщений тут были индивидуальными, то есть проходили полный цикл всевозможных сериализаций и десериализаций на пути от продьюсера до консьюмера (чтение из ws, десериализация, понимание, что это публикация, сериализация для Редис, потом десериализация из PUB/SUB, далее сериализация консьюмера (1 раз для каждой годы, на которую долетело из PUB/SUB). Не знаю, ответил ли на вопрос?
Да, более чем :)
А то мне как-то привычнее измерять всё в попугаях на ядро, а не на систему в целом.
Тогда, наверное, можно позапускать бенчмарки, которые в коде разбросаны — они плюс-минус отдельные части покрывают. А тут, получается, я взял определенный сценарий, поднял в реальных условиях — и посмотрел на поведение всей системы в целом причем в распределенном сценарии с брокером. Очень искусственно это все, но как я написал в статье – хоть какие-то цифры и их порядки. 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. Но чет тоже пока не горю желанием менять.
Но в целом 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. Но чет тоже пока не горю желанием менять.
Давно присматривался к Вашей работе, как замене для github.com/tlaverdure/laravel-echo-server, тогда как раз не хватало нативных для Laravel функций авторизации каналов, поэтому написал свой вариан echo-server на Go.
В клиентских библиотеках нет ни одной для PHP. Но я знаю, что их существует несколько, в том числе заточенных под конкретные фрейворки. Они на столько плохие, что ни одну из них нельзя включить в этот список или просто ни у кого не дошли руки протестировать их?
Добрый день, только заметил новый комментарий. В списке в статье перечислены клиентские библиотеки — то есть те, что со стороны фронтенда приложения открывают WebSocket-подключение. А для серверного HTTP API есть набор библиотек, в том числе и для PHP. Вот тут перечислены.
Sign up to leave a comment.
Centrifugo — новости не в реальном времени