Signalr SQL scaleout: недостатки использования нескольких потоков?

Question

В SignalR Performance странице, мы можем прочитать:

потока в этом контексте является единицей, используемой шкалы с помощью scaleout поставщика; это таблица, если используется SQL Server, используется Тема, если используется служебная шина , и подписка, если используется Redis. Каждый поток обеспечивает заказанные операции чтения и записи; a один поток является потенциальным узким местом , поэтому количество потоков может быть увеличено, чтобы помочь уменьшить это узкое место. Если используется несколько потоков, SignalR будет автоматически распространять (осколочно) сообщения в этих потоках в способе , который гарантирует, что сообщения, отправленные из любого данного соединения, находятся в порядке.

Количество потоков (т. Е таблицы в SQL) может быть установлен следующим образом:

var connectionString = "(your connection string)"; 
var config = new SqlScaleoutConfiguration(connectionString) { 
    TableCount = 3, 
    MaxQueueLength = 50 }; 
GlobalHost.DependencyResolver.UseSqlServer(config); 

Но TableCount 1 по умолчанию в SQL scaleout. Если это узкое место в масштабе, почему это 1 по умолчанию? Что, если я установил его на 50?

Документация не дает никаких оснований для определения того, какую ценность следует предоставить. Должен ли я установить его на 1, 3, 10, 1000? Каковы плюсы и минусы большой ценности? Это просто увеличивает задержку?

Answer 1

Из документации:

https://msdn.microsoft.com/en-us/library/microsoft.aspnet.signalr.sqlscaleoutconfiguration(v=vs.118).aspx

TableCount
Получает или задает число таблиц для хранения сообщений в Использование нескольких таблиц уменьшает блокировок и может увеличить пропускную способность.. Это должно быть согласовано между всеми узлами веб-фермы. По умолчанию: 1.