Комментарии 5
Расскажите, пожалуйста, поподробнее, почему Redis — плохая идея? Вроде как это решение идёт в коробке, ну или почти в коробке с SignalR
Redis хорошо справляется с синхронизацией вызовов исходящих от хаба, и это рекомендуемый способ синхронизации.
Однако для хранения списка подключений по каждому клиенту Redis неудобен:
- В процессе работы приходится делать выборки как по клиенту, так и по группе. Отсюда двоякость ключей. Это неудобно.
- Нет простой и надежной стратегии управления жизненным циклом записи: с одной стороны записи должны протухать, с другой стороны мы не должны удалять записи, по которым есть живое соединение, но нет активности.
- Достаточно много операций записи одновременно с операциями чтения, придётся бороться с коллизиями.
Добрый день! У меня пара вопросов, возможно глупых.
1) У меня mvc проект, не spa. Хочу использовать в нем signalr. Подключение клиента к хабу идет от js.
$.connection.hub.start().done(function() {
Если один и тот же пользователь будет переключаться, бегать по меню сайта, то будет каждый раз вызываться $.connection.hub.start().done(function() {. Это нормально? Тут нет оверхада? А если пользователей много…
2) Были ли у вас проблемы с протуханием, когда signalr перестает работать, и как вы их решали? p.s Юзер закрыл ноут, через день открыл — а signalr отвалился.
1) У меня mvc проект, не spa. Хочу использовать в нем signalr. Подключение клиента к хабу идет от js.
$.connection.hub.start().done(function() {
Если один и тот же пользователь будет переключаться, бегать по меню сайта, то будет каждый раз вызываться $.connection.hub.start().done(function() {. Это нормально? Тут нет оверхада? А если пользователей много…
2) Были ли у вас проблемы с протуханием, когда signalr перестает работать, и как вы их решали? p.s Юзер закрыл ноут, через день открыл — а signalr отвалился.
Добрый вечер,
Давайте обо всем по порядку.
Когда устанавливается соединение, оно занимает ресурсы системы. Это память и открытые порты. В случае если соединение часто рвется, то эти ресурсы будут удерживаться определенное время. На это время влияют как настройки системы, так и настройки сервера SignalR. И если память не критичный ресурс, то ресурс портов весьма ограничен — их всего 2^16 на каждый ip адрес. Поскольку клиенты подключаются к одному адресу, в случае использования reverse proxy, этот лимит не выглядит таким уж и большим. Проблема тем более усугубится в случае постоянных обрывов соединения со стороны клиента.
Что бы избежать этой ситуации, необходимо корректно завершать соединения со стороны клиента или по-возможности снизить значения KeepAliveInterval и ClientTimeoutInterval.
По поводу протухания — возможно при закрытии ноута обрывается связь с сервером, в таком случае в соответствии со значением параметра ClientTimeoutInterval связь будет принудительно разорвана. Клиент при этом получит уведомление на onclose.
Давайте обо всем по порядку.
Когда устанавливается соединение, оно занимает ресурсы системы. Это память и открытые порты. В случае если соединение часто рвется, то эти ресурсы будут удерживаться определенное время. На это время влияют как настройки системы, так и настройки сервера SignalR. И если память не критичный ресурс, то ресурс портов весьма ограничен — их всего 2^16 на каждый ip адрес. Поскольку клиенты подключаются к одному адресу, в случае использования reverse proxy, этот лимит не выглядит таким уж и большим. Проблема тем более усугубится в случае постоянных обрывов соединения со стороны клиента.
Что бы избежать этой ситуации, необходимо корректно завершать соединения со стороны клиента или по-возможности снизить значения KeepAliveInterval и ClientTimeoutInterval.
По поводу протухания — возможно при закрытии ноута обрывается связь с сервером, в таком случае в соответствии со значением параметра ClientTimeoutInterval связь будет принудительно разорвана. Клиент при этом получит уведомление на onclose.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффективное управление подключениями SignalR