等待服務代理消息的性能影響

我有一個情況，多個客戶端應用程序通過 Service Broker 發送消息（利用儲存的過程）。這些消息由另一個客戶端應用程序獲取，然後進行處理。獲取消息的方式是應用發出以下 SQL 語句（虛擬碼）：

LOOP {
   WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM SB_ReceiveQ)
   ProcessMessage
}

所以基本上程式碼只是阻塞，直到收到消息。這一切都很好。

我的問題是關於發出WAITFOR (RECEIVE...命令的含義，該命令基本上永遠掛在某些基於服務代理的資源上。我應該知道與此模式相關的任何性能問題嗎？

作為參考，這是 SQL Server 2005。

您正在阻止 SQL Server 中的工作人員，並且工作人員受到限制，受最大工作執行緒數的限制。這意味著不應有數千個請求被阻止，WAITFOR(RECEIVE...)否則您將餓死伺服器的工作人員。

但首先想到的問題是*為什麼沒有槓桿服務代理啟動*？這樣您就不會一直等待，而只會在啟動時等待，因為有消息要接收。

在 SQL Server 2005 中，我們每天有 50 多台機器每天都在做這件事。已經做了 3 年多沒有問題。

引用自：https://dba.stackexchange.com/questions/24356