sql-server - 最大化SQL Server Service Broker吞吐量

我们已经为我们的应用程序实现了SSB消息传递解决方案，但是现在遇到了扩展问题。能够在SSB应用程序的扩展方面拥有丰富经验的人能否就我们可能做错的事情提供任何建议？

设置是我们使用单个启动器队列，该启动器队列通过激活的过程为单个目标队列提供数据。激活的过程将处理收到的消息，并有选择地将它们分发给已注册相关类型消息的客户端。

此第二阶段调度再次使用单个启动程序队列（与用于初始消息注入的启动程序队列不同），并将消息发送到确定为合适的任何数量的客户端队列。

每个客户端都对数据库执行操作，这些操作创建的消息将发送到所有其他客户端，因此这是一个N ^ 2伸缩问题。对于相对较少的客户（10个或更少），这对我们来说不是问题，但是当我们扩展到N = 35或N = 40范围时，我们开始入队消息的速度比某些情况下处理消息的速度更快点在工作流程中，我们开始遭受严重的延迟问题。但是，我们失败的负载仍然处于SSB实施报告的最佳情况下，因此，我确信我们的实施存在缺陷。

相关诊断包括：


即使在我们看到的最重的客户端负载下，即使消息正在队列中备份，我们的服务器也具有大量的CPU，I / O和网络带宽。
我们已将系统配置为从激活过程的5个副本到512个副本中的任何一个激活，而对吞吐量和最终用户性能几乎没有明显的影响。
激活的过程一次处理多个消息，并使用一些温和的XML查询和SELECTS对一些小型数据库表进行处理。我们已经在空载条件下对该程序进行了测试，其开销很小。
我们显示LCK_M_X，PAGELATCH_SH，PAGELATCH_EX和WRITELOG等待的百分比很高（这些是前4个违规者）。
在最重的负载下，我们显示的发送/秒数大约是接收/秒的两倍。


如果还有其他诊断方法对可能对加快配置速度有所了解的人有所帮助，我可能会找到它们。

最佳答案

在最重的负载下，我们显示的发送/秒数大约是接收/秒的两倍。


我认为这是问题的症结所在。计数器测量语句执行率，而不是消息。这意味着您的RECEIVE在每个结果集上可能只接收一两个消息。由于conversation group locking，RECEIVE被限制为仅对返回的每个结果检索一个对话组。即使队列中有成千上万的消息可用，即使它们都在单独的对话中，RECEIVE也只会返回一个。正如您所描述的，这通常会导致性能下降和症状。

为了获得高吞吐量，您必须以某种方式使消息属于少量对话，以便RECEIVE可以在出现问题的队列上产生重要的结果集。如何实现这一点取决于您的业务工作流程的细节。

关于sql-server - 最大化SQL Server Service Broker吞吐量，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16488162/