Здесь есть несколько переменных, поэтому никто не может сказать вам: «Выше X-клиентов вам нужно использовать сервис SignalR». В зависимости от того, как подготовлено ваше решение, тот или иной компонент может быть ограничивающим фактором.
Например, ограничения службы сервиса показывают максимальное количество веб-сокетов на экземпляр Web App. Для уровня Basi c это 350. Когда вам нужно 351, вы можете выбрать:
- Увеличить план обслуживания приложения до уровня Standard или выше.
- Добавьте дополнительный экземпляр и используйте объединительную плату Redis или Service Bus.
- Воспользуйтесь услугой SignalR.
- Отключите веб-сокеты от SignalR и положитесь на что-то вроде длинного опроса, который ограничен ресурсами сервера.
После того, как вы go перейдете на стандартный уровень обслуживания и масштабируете его до нескольких экземпляров веб-приложения, вы сможете довольно далеко разместить хостинг SignalR самостоятельно. Таким образом, мы использовали более 5K одновременно подключенных клиентов с четырьмя экземплярами Standard S3. Четвертое - вводящее в заблуждение число, потому что нам нужна была мощность для других частей нашего приложения, а не только для SignalR.
Когда вы сами принимаете SignalR, это накладывает некоторые ограничения, и вы можете повесить себя различными способами. Например, при использовании SignalR netcore вам необходимо иметь токен ARR для среды с несколькими экземплярами. Это отстой. И я однажды реализовал тесное переподключение опроса после того, как соединение было закрыто с внешнего интерфейса. Было забавно, когда наши серверы отключались более двух минут, возвращались обратно, и у нас было несколько тысяч веб-браузеров, которые пытались восстановить соединение. А в стандартном веб-приложении уровня действительно сложно определить, какой процент памяти и ЦП потребляют несколько соединений через веб-сокеты.
Итак, после всего сказанного, ответ звучит так: «Это зависит от многих вещей». Сделав это обоими способами, я бы на 1024 * вперед и использовал бы сервис SignalR.