каналы Phoenix и их отношение к розеткам

Мне нужен совет по поводу каналов эликсира / феникса. У меня есть приложение, связанное с изменением места проведения, и, чтобы уменьшить объем данных, отправляемых каждому клиенту, я хочу, чтобы каждый клиент подписывался только на те места, которые ему интересны.

Имея это в виду, я думал о том, чтобы пойти по пути создания канала для «VenueChanges / *» и чтобы каждый клиент подписывался на канал несколько раз с каждым идентификатором места, который ему нужен, например «VenueChanges / 1», «VenueChanges / 2». " так далее.

Места, о которых заботится клиент, будут часто меняться, что будет означать, что он будет часто присоединяться к каналам и покидать их.

Мой вопрос в том, каковы накладные расходы при многократном подключении клиента к каналу. Правильно ли я предполагаю, что по-прежнему будет открыт только один сокет, а не новый сокет для каждого из соединенных каналов?

Также какие-нибудь советы по управлению постоянным присоединением и уходом каналов от клиента? Есть еще какой-нибудь совет в целом? Если это плохая идея, какие альтернативы лучше?


person Owen    schedule 25.01.2016    source источник
comment
Отличный вопрос, но, к сожалению, это не лучший вопрос для StackOverflow. Общие советы считаются не по теме. Вы сами пробовали посмотреть, что будет?   -  person CoderDennis    schedule 25.01.2016
comment
Я не согласен, только последняя часть была общим советом, есть также конкретный вопрос о производительности   -  person Owen    schedule 26.01.2016
comment
Вы имели в виду, что часто присоединяются к темам / комнатам каналов и покидают их? Такое впечатление у меня получилось от VenueChanges: 1, VenueChanges: 2 и т. Д.   -  person David Kuhta    schedule 03.11.2016


Ответы (1)


Что касается вопроса о сокете, вы правы в том, что у вас по-прежнему будет только один сокет на клиента (несколько каналов мультиплексируются по этому одному сокету).

Не отвечая напрямую на ваш постоянный вопрос о присоединении / выходе, сообщение Криса МакКорда на Phoenix Channels vs Rails Action Cable содержит действительно хорошие данные о производительности, которые лучше всего резюмировать:

С помощью Phoenix мы показали, что производительность каналов остается стабильной по мере увеличения спроса на уведомления, что важно для обработки всплесков трафика и предотвращения перегрузки.

Тем не менее, ваше серверное оборудование и стратегия распределения также будут играть важную роль в решении этой проблемы.

Наконец, исходя из того, что вы имели в виду присоединение к каналу / выход из тем (или "комнат", как это называется в некоторых местах), как видно из теста Криса с 55 000 подключений:

Важно отметить, что Phoenix сохраняет одинаковую скорость отклика при трансляции для тестов с 50 и 200 пользователями на комнату.

person David Kuhta    schedule 03.11.2016
comment
Спасибо, это действительно интересно. Кроме того, я заметил кое-что в источнике каналов github.com/phoenixframework/phoenix/blob/master/lib/phoenix/, который предлагает альтернативу объединению нескольких тем - person Owen; 15.11.2016