可持续负载测试
本主题中的信息是指用于 测量引擎 MST 的测试方案中所述的测试。
对于第一个测试，系统将驱动到 MST，以便可以观察运行状况良好的系统。
下图显示了使用此方法找到测试系统的最大可承受吞吐量后的关键指标。
可承受负载测试的负载状况
从此图中可以看出，在测试时间内，后台处理深度非常稳定并且没有增长：
图顶部的黑线表示系统每秒收到的全部消息（例如，两个接收服务器）。
图底部的线表示每个 SQL Server 的 MessageBox 后台处理深度。
一旦系统驱动到最大稳定后台处理深度点，就会根据每秒收到的消息数来度量 MST。 对于此方案，在描述的硬件上，MST 已达到每秒 290 条消息。
注意
如果系统驱动到某个点，在该点上后台处理深度经过一段时间后不再稳定，则说明已超出 MST。 对于评估最大负载，需要基于不同的负载进行若干测试，而在此最大负载上，后台处理深度可以保持稳定，并且系统可在不产生其他消息积压的情况下处理消息积压。
所有 BizTalk 部署性能分析部分均应包括检查某些关键指标以了解资源瓶颈。 用于运行于最大可承受吞吐量下的此部署的关键度量及其度量值如下所示：
CPU 使用率
| 服务器 | CPU 平均利用率 |
|---|---|
| BizTalk 服务器 | 55% |
| SQL Server（主 MessageBox 服务器） | 76% |
| SQL Server（其他 MessageBox 服务器） | 83% |
物理磁盘空闲时间
| 服务器 | 平均磁盘空闲时间 |
|---|---|
| 用于所有 SQL Server 的平均值 | 69% |
SQL Server 上的 SQL 锁
| 参数 | 值 |
|---|---|
| 每秒平均总锁定超时（每个 SQL Server） | 1980 |
| 平均总锁定等待时间（毫秒） | 495 |
在此测试期间，在 BizTalk 或 SQL Server 应用程序日志中未生成任何错误。
通过此数据，我们可以得出以下结论：
在我们的系统中没有明显的资源瓶颈。
所有这些指标均处于运行状况良好的范围内。
CPU 和磁盘空闲时间显示存在大量余量，甚至没有接近限定标准。
SQL 锁指示器看起来不错，锁超时数/秒不会开始成为问题，直到大约 5000 (，具体取决于你的SQL Server) 和锁等待时间低于 1 秒也正常。
我们已介绍了如何确定最大可承受吞吐量以及可承受、运行状况良好的系统的关键指标，现在，让我们来探讨与接收速度快于处理速度和垃圾回收速度的系统相关联的某些行为。 继续执行 Overdrive Load Test。