Signalr SQL scaleout: disadvantages of using multiple threads?

Question

On the SignalR Performance page, you can read:

A stream in this context is the scale used by the scaling provider; this is a table if SQL Server is used, the topic if the service Bus is used and subscription if Redis is used. Each stream provides ordered read and write operations; a single thread is the potential of a large-scale bottleneck , so the number of threads can be increased to help reduce this bottleneck. If multiple streams are used, SignalR will automatically distribute (fragmented) the messages through these streams in a way that ensures that messages sent from any given connection are in order.

The number of threads (i.e. a table in SQL) can be set as follows:

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

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

The documentation does not give any clues to decide what value to give. Should I set it to 1, 3, 10, 1000? What are the pros and cons of great value? Does it 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 for storing messages. Using more tables reduces the chance of blocking and can increase throughput. This must be consistent across all sites in the web farm. Default: 1.