测试引擎性能时的建议
在测试 BizTalk 引擎性能时应当遵循以下准则：
了解加载行为配置文件 正如这三个负载测试所说明的，了解负载的配置文件与一段时间内处理的消息有关，这一点至关重要。 对这一点理解越深，就越能准确地测试和调整系统容量。 若只知道峰值吞吐量要求，则最保守的办法是调整系统大小，以便使最大可承受吞吐量等于或大于峰值负载。 但是，如果可预测负载峰值和低谷，则可更好地优化系统以在峰值之间恢复正常，从而使总体部署规模更小、开销更低。
提前测试性能 避免陷入在设计和测试解决方案功能方面投入大量精力的陷阱，但要等到最后一分钟才能在生产硬件上测试性能。 在开发周期中，应尽可能早地在系统上运行模拟预期负载状况的性能测试。 如果必须对设计或体系结构做出更改才能达到您的要求，则尽早了解这一点将有助于您争取时间再次进行调整和测试。
在测试性能时模拟预期的负载配置文件 此组件有两个主要组件：
模拟负载随时间变化的状况。
尽可能长时间运行测试以评估性能的可持续性。
通常情况下，如果您的周期实际为一天，则应计划至少运行性能测试一天，以验证可承受性。 运行测试的时间越长越好。
模拟生产配置 例如，端口的数量和类型、主机和主机实例配置、数据库配置以及适配器设置。 不要认为配置更改不会对性能造成很大影响。
使用真实消息 消息大小和消息复杂性会影响性能，因此请确保使用计划在生产中看到的相同消息架构和实例进行测试。
在性能测试期间模拟正常操作 尽管负载测试不包括它们，但标准操作活动（如定期数据库查询、备份和清除）会影响你的可持续吞吐量，因此请确保在性能和容量测试运行期间执行这些任务。 若要在生产中使用这些操作，那么这将同时包括 DTA 和 BAM 跟踪。
MessageBox 的 I/O 子系统的速度是一个关键的成功因素 执行的负载测试使用专用于此生成的 MessageBox 数据库文件的快速存储区域网络。即使在这种情况下，清理作业也能将 SQL 数据文件的空闲时间逼近零。 大多数情况下，I/O 子系统是生产系统中的瓶颈。 优化 SQL I/O 的常规策略是：如果可能，则将数据库数据文件和日志文件分别放于单独的物理驱动器上。
确保所有 MessageBox 服务器上都运行 SQL 代理 显然，如果 SQL 代理未运行，则永远不会运行清理作业，因此请确保这些作业正在运行。
后台打印深度是一个关键指示器 无论其他指标如何，此度量值都将为你提供一种快速而简单的方法来评估系统是否被过度驱动。