最大限度地提高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可以在出現問題的隊列上產生重要的結果集。如何實現這一點取決於您的業務工作流的具體情況。