调查瓶颈

本主题介绍调查瓶颈的建议过程。

问题的根源是什么？

瓶颈的来源可能是硬件或软件相关。 资源未充分利用时，这通常表明存在瓶颈。 瓶颈可能由硬件限制、软件配置效率低下或两者引起。

确定瓶颈是一个渐进式的过程，因此缓解一个问题可能导致发现下一个过程。 本主题的目标就是帮助您科学地确定和缓解这些瓶颈。 系统有可能在短期内以峰值执行。 但为了可承受吞吐量，系统只能按其执行速度最慢的组件的最快速度进行处理。

使用迭代方法进行测试

瓶颈可能发生在系统进入/退出) (终结点，也可能发生在中间 (业务流程/数据库) 。 隔离瓶颈后，使用结构化方法来标识源。 瓶颈缓解后，必须再次测量性能，以确保系统中的其他位置未引入新的瓶颈。

识别和修复瓶颈的过程应以迭代方式完成。 一次只改变一个参数，在每次测试运行期间重复完全相同的步骤，然后测量性能以验证单个修改的影响。 一次变化多个参数可能会掩盖更改结果。

例如，更改参数 1 可以提高性能。 但是，将参数 2 与更改参数 1 结合使用可能会产生不利影响，并否定更改参数 1 的好处。 这会导致净零效应，并导致对不同参数 1 的效果产生假负，对不同的参数 2 的效果产生误报。

测试一致性

应测量更改设置后的性能特征，以验证更改的效果。

• 硬件- 使用一致的硬件，因为改变硬件可能会导致不一致的行为并产生误导性的结果。 例如，不会使用笔记本电脑来测试 BizTalk 解决方案的性能。

• 测试运行持续时间 - 测量固定的最小时间段的性能，以确保结果是可持续的。 运行较长时间的测试还可以确保系统已经历初始暖/增加期，其中填充了所有缓存，数据库表已达到预期计数，并在达到预定义阈值后为限制提供足够的时间来调节吞吐量。 此方法将有助于发现最佳可承受吞吐量。

• 测试参数 - 不要因测试运行的不同而改变测试参数。 例如，改变映射复杂性和/或文档大小可能产生不同的吞吐量和延迟结果。

• 清理状态 - 测试完成后，在运行下一个测试之前，请确保测试环境的状态是干净的。 例如，历史数据可能会累积到数据库中，从而影响运行时吞吐量。 回收服务实例有助于释放缓存的资源，例如内存、数据库连接和线程。 在测试环境中，可能需要创建并执行bts_CleanupMsgbox存储过程，如 如何手动清除测试环境中的 MessageBox 数据库中的数据 (https://go.microsoft.com/fwlink/?LinkId=158064) 中所述。 此脚本旨在将BizTalk Server测试环境返回到运行之间的消息框的新状态。 该脚本删除所有正在运行的实例以及有关这些实例（包括状态、消息和订阅）的所有信息，但会保留所有激活订阅，因此无需重新登记业务流程或发送端口。 请注意，生产系统不支持此工具。

• 性能测试和优化 - 此测试类别的目标是最大限度地提高应用程序的性能和吞吐量，并找到系统的最大可持续吞吐量 (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组，并使用它们运行解决方案的一个或多个部分。 当需要隔离发送、接收、处理、跟踪主机的 1) 或 2) 当单个服务器的内存、I/O 或网络 I/O 资源达到最大值时，应查看横向扩展。 负载可以分散到多个服务器;但是，向BizTalk Server组添加新节点可能会增加 MessageBox 数据库的锁争用。

那么，应该纵向扩展还是横向扩展？ 纵向扩展平台可以减少 BizTalk 解决方案的延迟，因为它使单个任务 (例如消息映射) 运行速度更快。 横向扩展可以提高 BizTalk 解决方案的最大可持续吞吐量和可伸缩性，因为它允许跨多个计算机分散工作负荷。

另请参阅

查找并消除瓶颈