Signalr SQL scaleout：使用多个流的缺点？

Question

在SignalR Performance页面中，我们可以阅读：

  

此上下文中的流是横向扩展使用的缩放单位   供应商;如果使用SQL Server，这是一个表，如果服务是主题   使用总线，如果使用Redis，则使用Subscription。每个流确保   有序的读写操作; 单一流是一种潜力   规模瓶颈，因此可以增加流的数量来帮助   减少这个瓶颈。如果使用多个流，SignalR将   在这些流中自动分发（分片）消息   确保从任何给定连接发送的消息有序的方法。

流计数（即SQL中的表）可以这样设置：

App_Code

但是SQL scaleout中的var connectionString = "(your connection string)"; var config = new SqlScaleoutConfiguration(connectionString) { TableCount = 3, MaxQueueLength = 50 }; GlobalHost.DependencyResolver.UseSqlServer(config); 默认为1。如果这是一个规模瓶颈，为什么它默认为1？如果我将它设置为50怎么办？

文档没有提供任何线索来决定给出哪个值。我应该将它设置为1,3,10,1000吗？ 什么是重要的利弊？它只会增加延迟吗？

Answer 1

来自文档：

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

  

TableCount的
  获取或设置要在其中存储消息的表的数量。   使用更多表可减少锁争用并可能增加吞吐量。   这必须在Web场中的所有节点之间保持一致。默认为1。