2

我们已经为我们的应用程序实现了一个 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/sec 数量的两倍。

如果有其他诊断对任何可能知道我们可以做些什么来加快配置速度的人有帮助，我可能会找到它们。

4

1 回答 1

6

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

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

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

于 2013-05-11T18:07:43.493 回答