本主题介绍用于调查瓶颈的建议过程。
问题的来源是什么？
瓶颈的来源可能与硬件或软件相关。 当资源未充分利用时，通常表明存在瓶颈。 瓶颈可能是硬件限制、低效的软件配置或两者造成的。
识别瓶颈是一个增量过程，通过它缓解一个瓶颈可能会导致发现下一个瓶颈。 识别和缓解这些瓶颈的科学是本主题的目标。 系统可以在短时间内在高峰时段内执行。 但是，对于可持续的吞吐量，系统的处理速度只能与表现最慢的组件一样快。
使用迭代方法来测试
系统端点（进/出）或中间（协调/数据库）可能会出现瓶颈。 隔离瓶颈后，使用结构化方法来标识源。 缓解瓶颈后，请务必再次测量性能，以确保系统其他地方未引入新的瓶颈。
应以迭代方式确定和修复瓶颈的过程。 每次只改变一个参数，在每个测试运行期间重复完全相同的步骤，然后测量性能以验证单个修改的影响。 一次更改多个参数可能会隐藏更改的效果。
例如，更改参数 1 可以提高性能。 但是，将参数 2 与更改参数 1 结合使用可能会产生不利影响，并否定更改参数 1 的好处。 这会导致净零效应，对参数 1 的影响产生假阴性结果，对参数 2 的效果产生假阳性结果。
测试一致性
应在更改设置后测量性能特征，以验证更改的效果。
硬件- 使用一致的硬件，因为不同的硬件可能会导致不一致的行为并产生误导性的结果。 例如，不会使用笔记本电脑测试 BizTalk 解决方案的性能。
测试运行持续时间 - 测量固定的最小时间段的性能，以确保结果是可持续的。 长时间运行测试还可确保系统在填充所有缓存、数据库表达到预期计数的情况下，系统已经历初始热/上升期，并在达到预定义阈值后有足够的时间来调节吞吐量。 此方法有助于发现最佳的可持续吞吐量。
测试参数 - 测试运行时不要改变测试参数。 例如，不同的地图复杂性和/或文档大小可能会产生不同的吞吐量和延迟结果。
清理状态 - 测试完成后，请确保测试环境的状态在运行下一次测试之前是干净的。 例如，历史数据可以在影响运行时吞吐量的数据库中生成。 回收服务实例有助于释放缓存的资源，例如内存、数据库连接和线程。 在测试环境中，可能需要创建和执行bts_CleanupMsgbox存储过程，如 如何在测试环境中手动清除 MessageBox 数据库中的数据 （https://go.microsoft.com/fwlink/?LinkId=158064）。 此脚本旨在将 BizTalk Server 测试环境在每次运行之间的 Message Box 恢复到初始状态。 该脚本删除所有正在运行的实例以及有关这些实例的所有信息，包括状态、消息和订阅，但会保留所有激活订阅，因此无需重新登记业务流程或发送端口。 请注意，生产系统上不支持此工具。
性能测试和优化 - 此测试类别的目标是最大程度地提高应用程序的性能和吞吐量，并找到系统的最大可持续吞吐量（MST）。 有关规划和衡量最大可持续性能的详细信息，请参阅 规划持续性能 （https://go.microsoft.com/fwlink/?LinkId=158065）和 什么是可持续性能？ （https://go.microsoft.com/fwlink/?LinkId=132304）。
MST 是系统可以在生产环境中无限期处理的消息流量的最大负载。 所有 BizTalk 应用程序都应在进入生产环境之前测试性能和吞吐量。 至少应运行一组代表最常见使用方案的测试用例。 建议在与生产环境特征匹配的单独环境中进行针对预期负载和峰值负载的测试。 此环境应安装并运行所有公司标准服务，例如监视代理和防病毒软件。
我们还建议在生产中的同一硬件上测试新的 BizTalk 应用程序，以及正在运行的其他 BizTalk 应用程序。 这些其他 BizTalk 应用程序增加了 BizTalk Server、SQL Server、网络 I/O 和磁盘 I/O 的负担。 此外，一个 BizTalk 应用程序可能会导致另一个应用程序限制资源（例如，当缓冲深度过大时）。 在投入生产之前，所有 BizTalk 应用程序都应经过性能/压力测试。 此外，还应确定系统从峰值负载中恢复所需的时间。 如果在发生下一个峰值负载之前系统未完全从峰值负载恢复，则会出现问题。 系统会变得越来越落后，并且永远无法完全恢复。
预期：吞吐量与延迟
您可以预期从部署的系统中获得一定程度的吞吐量和/或延迟。 尝试实现高吞吐量和低延迟，同时对系统提出了相反的要求。 你可以期待以合理延迟获得最佳吞吐量。 随着吞吐量的提高，系统上的压力增加，例如更高的 CPU 消耗、更高的磁盘 I/O 争用、更大的内存压力以及更强的锁争用。 这种情况可能会对延迟产生负面影响。 若要发现系统的最佳容量，建议识别并最大程度地减少任何瓶颈。
存在于数据库中的已完成个案可能会导致瓶颈。 出现瓶颈时，性能可能会降低。 让系统有足够的时间排空可以帮助解决问题。 发现积压工作生成的原因并帮助解决问题非常重要。
若要发现积压工作的原因，可以分析历史数据并监视性能计数器（发现使用模式并诊断积压工作的来源）。 通常，当在夜间以批量方式处理大量数据时，可能会发生积压工作。 你可能会发现了解系统的容量及其从积压中恢复的能力很有用。 此信息可帮助你估算处理超驱动器方案的硬件要求，以及系统中要容纳的缓冲空间量，以处理吞吐量的意外峰值。
监视性能计数器有助于识别可能在运行时出现的潜在瓶颈。 但是，当我们怀疑 CPU 或内存瓶颈的罪魁祸首可能是构成解决方案的自定义组件之一时，我们强烈建议在性能测试期间使用分析工具（如 Visual Studio Profiler 或 ANTS 性能探查器）来缩小和分割产生问题的类。 显然，分析应用程序会影响性能表现。 因此，这些测试应侧重于分割导致内存消耗、CPU 使用率或延迟的组件，并应丢弃在这些测试期间收集的数字。
优化系统以实现最佳可持续吞吐量需要深入了解已部署的应用程序、系统的优缺点以及特定方案的使用模式。 唯一的方式是通过对与将会用于生产的拓扑进行彻底测试，从而发现瓶颈以及预测最优可持续吞吐量并具有一定确定性。 针对特定用例运行负载和压力测试时，将单个项目（接收位置、发送端口、业务流程）隔离到单独的主机实例中，并在性能监视器工具中设置正确的计数器对于缩小瓶颈原因至关重要。
本部分中的其他主题将指导你完成定义该拓扑的过程，并提供有关如何减少和避免瓶颈的指导。
规模化
部署拓扑的各个阶段都可能发生瓶颈。 可以通过纵向扩展或横向扩展环境来解决某些瓶颈。 纵向扩展是升级现有计算机的过程。 例如，可以将 BizTalk Server 计算机从四处理器计算机升级到八处理器计算机，以及替换现有 CPU 并添加更多 RAM。 这样，便可以加速资源密集型任务，例如文档分析和映射。 横向扩展过程就是将服务器添加到部署中。 纵向扩展或横向扩展的决定取决于瓶颈类型和要配置的应用程序。 应用程序需要从头开始构建，才能利用纵向扩展或横向扩展。以下指南说明如何根据遇到的瓶颈更改硬件部署拓扑。
纵向扩展 意味着在升级的硬件上运行 BizTalk 解决方案（例如，添加 CPU 和内存）。 当 1） 横向扩展过于昂贵或 2） 横向扩展不会帮助解决瓶颈时，应注意纵向扩展。 例如，如果在较快的计算机上运行任务，则可以显著减少转换和处理大型消息所花费的时间。
横向扩展 应用程序平台包括将 BizTalk 节点添加到 BizTalk Server 组，并使用它们来运行解决方案的一个或多个部分。 当您需要隔离发送、接收、处理、跟踪的主机时，或当单个服务器的内存、I/O 或网络 I/O 资源达到最大容量时，您应该考虑进行横向扩展。 负载可以分散到多个服务器;但是，将新节点添加到 BizTalk Server 组可能会增加 MessageBox 数据库上的锁争用。
那么，应该纵向扩展还是横向扩展？ 纵向扩展平台可以减少 BizTalk 解决方案的延迟，因为它使单个任务（例如消息映射）运行速度更快。 横向扩展可以提高 BizTalk 解决方案的最大可持续通量和可伸缩性，因为它允许将工作负荷分散到多台计算机上。