管理效能 (Service Broker)
Service Broker 應用程式的效能一般由兩個因數決定：
- 在指定期間內抵達的訊息數量。
- 應用程式處理每個訊息的速度。
監視這兩個因數是瞭解應用程式效能的關鍵。
Service Broker 提供一組會提供其活動資訊的效能計數器。Service Broker 還會將嚴重錯誤記錄到 SQL Server 錯誤記錄檔和 Windows 應用程式事件記錄檔中。如需有關 Service Broker 之效能計數器、動態管理檢視和追蹤事件的詳細資訊，請參閱＜監視 Service Broker＞。
微調 Service Broker 預存程序
大部份情況下，微調使用 Service Broker 的預存程序與微調其他任何預存程序沒有什麼不同。但是，還有一些其他考量。
首先，使用 WAITFOR 子句。訊息很少會以可預測的間隔抵達。甚至是在訊息以大致相同的預存程序處理訊息速度抵達的服務中，也可能會有沒有訊息可用的時候。因此，此程序應使用含 RECEIVE 陳述式或 GET CONVERSATION GROUP 陳述式的 WAITFOR 子句。如果沒有 WAITFOR，則當佇列中沒有可用的訊息時，這些陳述式會立即返回。視預存程序的實作而定，此程序然後可能會透過陳述式回送，沒有必要地消耗資源；或者程序可能會結束，僅為了不久之後能重新啟動，比光是繼續執行還消耗更多的資源。
使用含 RECEIVE 或 GET CONVERSATION GROUP 陳述式的 WAITFOR 子句，可容許時間上的無法預期性。如果應用程式作為背景服務繼續執行，則不要在 WAITFOR 陳述式中指定逾時。如果應用程式由 Service Broker 啟動，或作為排程作業執行，則要指定較短的逾時 (例如 500 毫秒)。使用 WAITFOR 陳述式的應用程式會正常地處理訊息間無法預期的間隔。同樣地，當沒有訊息可處理時，在短暫的逾時之後結束的啟動應用程式也不會消耗資源。
Service Broker 可保證一次僅有一個應用程式的執行個體可以接收共用交談群組識別碼之交談的訊息。設計應用程式以利用交談群組鎖定來進行同步處理。如果應用程式維護狀態，則考慮使用交談群組識別碼來識別交談的狀態。在同一個交易中處理交談群組的多個訊息。但是，一般來說，在給定的交易中僅會處理一個交談群組的訊息。這有利於確保應用程式之一個以上的執行個體可以處理訊息，即使是在交談群組數量相當小的時候。
此外，避免使用訊息保留。維護儲存訊息之最重要資訊的個別記錄資料表能改善效能。僅在應用程式需要傳送和接收之正確訊息的事件中，才使用訊息保留。
其次，在工作完成時結束交談。Service Broker 會維護每個使用中交談的狀態。雖然特殊交談的狀態數目比較少，但是未結束交談的應用程式可能會逐漸降低效能。
最後，將交易保持簡短。例如，如果服務的交談模式涉及同一交談群組上的大量訊息，則限制在每個交易中處理的訊息數目可能會提高整體輸送量。
請參閱
其他資源
Conversation Group Locks
Message Retention
效能監視和微調的如何主題