Давайте обо всем по порядку.
Когда устанавливается соединение, оно занимает ресурсы системы. Это память и открытые порты. В случае если соединение часто рвется, то эти ресурсы будут удерживаться определенное время. На это время влияют как настройки системы, так и настройки сервера SignalR. И если память не критичный ресурс, то ресурс портов весьма ограничен — их всего 2^16 на каждый ip адрес. Поскольку клиенты подключаются к одному адресу, в случае использования reverse proxy, этот лимит не выглядит таким уж и большим. Проблема тем более усугубится в случае постоянных обрывов соединения со стороны клиента.
Что бы избежать этой ситуации, необходимо корректно завершать соединения со стороны клиента или по-возможности снизить значения KeepAliveInterval и ClientTimeoutInterval.
По поводу протухания — возможно при закрытии ноута обрывается связь с сервером, в таком случае в соответствии со значением параметра ClientTimeoutInterval связь будет принудительно разорвана. Клиент при этом получит уведомление на onclose.
Redis хорошо справляется с синхронизацией вызовов исходящих от хаба, и это рекомендуемый способ синхронизации.
Однако для хранения списка подключений по каждому клиенту Redis неудобен:
В процессе работы приходится делать выборки как по клиенту, так и по группе. Отсюда двоякость ключей. Это неудобно.
Нет простой и надежной стратегии управления жизненным циклом записи: с одной стороны записи должны протухать, с другой стороны мы не должны удалять записи, по которым есть живое соединение, но нет активности.
Достаточно много операций записи одновременно с операциями чтения, придётся бороться с коллизиями.
Источник указан в комментарии выше, читайте внимательней.
Про выразительность: выразительность это несомненно важно, но в угоду выразительности жертвовать производительность там, где важна производительность все же не стоит. Речь шла именно о производительности
Забавно смотреть на ваши оптимизации, расположенные по соседству со считыванием через cin
Про циклы:
зачем в цикле считать биты
Любое число — совокупность бит. В угоду производительности, там где это оправданно, а в этом случае это оправданно — можно и биты посчитать. К тому же решение весьма простое и абстракция в виде функции несомненно проста в использовании и потому эффективна.
и не стоит игнорировать их
Тезис верный, но не стоит принимать его за аксиому. Всему свое место и там где уместно использование готовых функций конечно же не стоит городить велосипеды.
5 — 6 битовых операций это не так сложно
не понимаю тогда чем решение, предложенное мной, сложно.
Дело в том, что высокоуровневые cin и scanf очень медленные по сравнению с getchar_unlocked. Для преобразования входного потока в число можно использовать функцию:
inline int read_int()
{
register int c = getchar_unlocked();
int x = 0;
int neg = 0;
if(c=='-')
{
neg = 1;
c = getchar_unlocked();
}
for(; '0'<=c && c<='9' ; c = getchar_unlocked()) {
x = (x<<1) + (x<<3) + c - '0';
}
return neg ? -x : x;
}
Можно заменить на getchar_unlocked() для *nix или getchar() для всех остальных.
getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее. digital-madness.in/blog/2013/fast-io-in-c/
Давайте обо всем по порядку.
Когда устанавливается соединение, оно занимает ресурсы системы. Это память и открытые порты. В случае если соединение часто рвется, то эти ресурсы будут удерживаться определенное время. На это время влияют как настройки системы, так и настройки сервера SignalR. И если память не критичный ресурс, то ресурс портов весьма ограничен — их всего 2^16 на каждый ip адрес. Поскольку клиенты подключаются к одному адресу, в случае использования reverse proxy, этот лимит не выглядит таким уж и большим. Проблема тем более усугубится в случае постоянных обрывов соединения со стороны клиента.
Что бы избежать этой ситуации, необходимо корректно завершать соединения со стороны клиента или по-возможности снизить значения KeepAliveInterval и ClientTimeoutInterval.
По поводу протухания — возможно при закрытии ноута обрывается связь с сервером, в таком случае в соответствии со значением параметра ClientTimeoutInterval связь будет принудительно разорвана. Клиент при этом получит уведомление на onclose.
Redis хорошо справляется с синхронизацией вызовов исходящих от хаба, и это рекомендуемый способ синхронизации.
Однако для хранения списка подключений по каждому клиенту Redis неудобен:
getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее.
digital-madness.in/blog/2013/fast-io-in-c/
Вложенные формы стандартом HTML не допускаются.
вот как это должно выглядеть: