最大化SQL Server Service Broker吞吐量

Question

我们已经为我们的应用程序实现了SSB消息传递解决方案，但现在正在遇到扩展问题。任何具有SSB应用程序升级经验的人都能提出任何关于我们可能做错的建议吗？

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

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

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

相关诊断包括：

1. 我们的服务器有足够的CPU，I / O和网络带宽，即使在我们看到的最重的客户端负载下也是如此，即使消息在队列中备份也是如此。
2. 我们已将系统配置为激活5个拷贝的激活程序到512个拷贝，对吞吐量和最终用户性能几乎没有明显影响。
3. 激活的过程一次对多个消息进行操作，并使用一些温和的XML查询和针对某些小型数据库表的SELECTS处理它们。我们在空载条件下测试了这个程序，它的开销很轻。
4. 我们显示LCK_M_X，PAGELATCH_SH，PAGELATCH_EX和WRITELOG等等的高百分比（这些是前4名违规者）。
5. 我们的SENDs / sec数量大约是我们在最负载下看到RECEIVEs /秒的两倍。

如果有其他诊断对任何可能了解我们可以采取哪些措施加速配置的人有帮助，我可以找到它们。

Answer 1

  

我们显示的SEND /秒数大约是我们在最负载下看到的RECEIVE /秒的两倍。

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

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