管理性能 (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
性能监视和优化操作指南主题