最大限度地提高SQL Server Service Broker吞吐量

Question

我们已经为我们的应用程序实现了SSB消息传递解决方案，但现在正在进入扩展问题。任何具有SSB应用程序扩展经验的人都可以提供关于我们可能会做错什么的建议？

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

该第二阶段调度再次使用单个intitiator队列（不同于用于初始消息注入的队列）并将消息发送到任意数量的客户端队列被确定为合适的。

每个客户端都会针对创建发送给所有其他客户端的消息的数据库执行操作，所以这是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. 在我们最重的负载下，我们显示的发送次数/秒数大约是接收次数/秒。

如果还有其他的诊断方法对任何可能对我们可以做什么来加快配置速度的人有所帮助的诊断信息，我可以找到它们。

Answer 1

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

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

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