突发高负载测试

本主题中的信息引用了测试 方案中介绍的测试方案，用于测量引擎的 MST。

什么情况下将会发生水闸事件？

在很多情况下，每天只有几个大峰值 (也称为 泛洪门事件) 消息到达系统。 而在这些峰值之间，吞吐量非常低。 这种类型的情况的示例包括：

• 例如，在开市和闭市时的股票交易。

• 例如，在一天结束时，交易对帐期间的银行系统。

  其他类型的事件也可导致与水闸事件相似的积压行为。 例如，如果合作伙伴的发送地址脱机，以该地址为目标的消息将可能重试并/或挂起，而这将导致增加积压量。 如果合作伙伴重新联机，则可能有大量挂起的消息需要恢复，而这又将导致另一种类型的水闸事件。 下面的系统测试将阐释此行为。

模拟水闸事件

对于此测试，最初，系统将以最大可承受吞吐量的一半（这当然非常稳定）进行驱动。 然后，为模拟水闸事件，负载生成工具将配置为在短时间（与加速测试相同）内以大约每秒 410 条消息的速度进行发送。 下图显示了度量每秒所收到消息所生成的负载状况以及后台处理深度。

突发高负载测试的负载状况

请注意，从图中可看出，在水闸事件期间后台处理表中的积压快速增加。 但是，由于事件的生命期相对较短，而且事件之后的接收速率低于最大可承受速率，因此可以运行清除作业，从事件中恢复到正常状况，而无需停用系统接收。 对于此具体的测试，MessageBox 存储在 SQL Server 2005 中；此测试的持续时间从开始到结束大约耗时 45 分钟。

当然，每个系统都是不同的，所以“你的里程会有所不同。验证是否可以恢复的最佳方法是在进入生产环境之前使用代表性负载进行测试。

另请参阅

测量引擎的 MST 的测试方案
使用设置仪表板进行 BizTalk Server 性能调整
过载测试
可承受负载测试