Почему время доставки сообщений плохо масштабируется с помощью SignalR?

Question

Я все еще тестирую SignalR, но для меня действительно важно, чтобы сообщения доходили до клиента как можно быстрее (я имею дело с курсами акций в реальном времени).

Дело в том, что - почти в каждом сценарии, который я пробовал - от полностью локальных до запуска сотен экземпляров в Azure (с объединительной платой и всем...) время, необходимое для передачи сообщения с сервера на клиент, увеличивается экспоненциально по мере увеличения числа подключенных клиентов.

Я пробовал это с концентраторами, постоянным подключением, клиентами.net, клиентами JS, работающими в phantomJS, zombieJS & node.js ... Я в значительной степени перепробовал десятки конфигураций, но поведение всегда одинаково, что приводит меня к выводу, что это что-то присуще SignalR.

Я знаю, что SignalR может обрабатывать тысячи одновременно работающих клиентов на очень небольшом количестве серверов, но если сообщение проходит через несколько секунд (в том же регионе Azure), оно мне не нужно.

Есть идеи, что может замедлить сообщения?

Спасибо

Answer 1

Это объясняется в руководстве по их уменьшению: http://www.asp.net/signalr/overview/signalr-20/performance-and-scaling/scaleout-in-signalr

Ограничения

При использовании объединительной платы максимальная пропускная способность сообщений ниже, чем при прямой связи клиентов с одним узлом сервера. Это потому, что объединительная плата направляет каждое сообщение каждому узлу, поэтому объединительная плата может стать узким местом. Является ли это ограничение проблемой, зависит от приложения. Например, вот несколько типичных сценариев SignalR:

• Широковещательная рассылка на сервер (например, биржевой тикер): для этого сценария хорошо работают объединительные платы, поскольку сервер контролирует скорость отправки сообщений.
• Клиент-клиент (например, чат): в этом сценарии объединительная плата может быть узким местом, если количество сообщений зависит от количества клиентов; то есть, если скорость сообщений растет пропорционально увеличению числа клиентов.
• Высокочастотные в реальном времени (например, игры в реальном времени): объединительная плата не рекомендуется для этого сценария.

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

Я давно отказался от SignalR и сосредоточился на веб-сокетах с надлежащей системой очередей. Например, вы можете использовать библиотеку веб-сокетов вместе с MassTransit. SignalR предназначен для небольших проектов или не очень сегментированных сценариев или сценариев реального времени.