Signalr SQL scaleout : drawbacks of using multiple streams?

Question

In the SignalR Performance page, we can read :

A Stream in this context is a scale unit used by the scaleout provider; this is a table if SQL Server is used, a Topic if Service Bus is used, and a Subscription if Redis is used. Each stream ensures ordered read and write operations; a single stream is a potential scale bottleneck , so the number of streams can be increased to help reduce that bottleneck. If multiple streams are used, SignalR will automatically distribute (shard) messages across these streams in a way that ensures messages sent from any given connection are in order.

The stream count (ie. table in SQL) can be set like this :

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

But the TableCount is 1 by default in SQL scaleout. If this is a scale bottleneck, why is it 1 by default ? What if I set it to 50 ?

The documentation doesn't give any clue to decide which value to give. Should I set it to 1, 3, 10, 1000 ? What are pros and cons of a big value ? Does it just increase latency ?

Answer 1

From the documentation:

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

TableCount
Gets or sets the number of tables to store messages in. Using more tables reduces lock contention and may increase throughput. This must be consistent between all nodes in the web farm. Defaults to 1.