Service Broker 应用程序的性能通常由两个因素决定：
- 在指定时间段内到达的消息数
- 应用程序处理每个消息的速度
监视这两个因素是了解应用程序性能的关键。
Service Broker 包含一组能提供有关其活动信息的性能计数器。 Service Broker 还会将严重错误记录到 SQL Server 错误日志和 Windows 应用程序事件日志中。 有关详细信息，请参阅以下文章：
优化 Service Broker 存储过程
通常，优化使用 Service Broker 的存储过程与优化任何其他存储过程没有什么不同。 但是，还有一些进一步的注意事项。
首先，使用 WAITFOR 子句。 消息的到达时间间隔几乎不可预测。 即使在消息到达的服务中，消息的速率与存储过程处理消息的速率大致相同，有时可能没有消息可用。 因此，该过程应将 WAITFOR 子句与 RECEIVE 语句或 GET CONVERSATION GROUP 语句一起使用。 如果没有 WAITFOR，当队列中没有可用消息时，这些语句将立即返回。 根据存储过程的实现，该过程可能会通过相同的语句再次陷入循环，从而无谓地消耗资源；或者过程可能会暂时退出，然后在不久后重新激活，耗费的资源比一直不断运行要多。
可以通过将 WAITFOR 子句与 RECEIVE or GET CONVERSATION GROUP 语句结合使用来允许在计时中实现不可预测性。 如果应用程序作为后台服务持续运行，则不会在 WAITFOR 语句中指定超时。 如果应用程序是由 Service Broker 激活的或作为计划任务运行，请指定短超时时间，例如 500 毫秒。 使用 WAITFOR 语句的应用程序可正常处理消息之间的不可预知的间隔。 同样，当没有要处理的消息时，在短超时后退出的已激活应用程序不会消耗资源。
Service Broker 保证一次只有一个应用程序实例可以接收共享会话组标识符的会话的消息。 请将应用程序设计为利用用于同步的会话组锁定功能。 如果由应用程序维护状态，请考虑使用会话组标识符来标识会话的状态。 可以在同一事务中处理会话组的多个消息。 但是，通常仅在指定的事务中处理单个会话组的消息。 这样有助于确保应用程序的多个实例可以处理消息，即使在会话组的数目相对较小时，也是如此。
此外，应避免使用消息保持期。 维护一个单独的保存消息中最重要信息的日志表可以提高性能。 仅当应用程序需要发送和接收的确切消息时，才使用消息保留。
其次，应在任务完成时结束会话。 Service Broker 维护每个活动会话的状态。 尽管特定会话的状态量很小，但不会结束会话的应用程序可能会随时间而降低性能。
最后，应保持事务简短。 例如，如果服务的会话模式涉及同一会话组中的大量消息，则限制每个事务中处理的消息数可能会提高总体吞吐量。