第 1 阶段：设置评估范围
本主题介绍BizTalk Server性能评估的范围阶段的各个方面。
进行性能评估时，常见的错误是低估性能评估的范围。 如果未事先分配足够的资源和时间，则负责性能评估的团队将无法完成构建和测试类似于生产的复杂环境所需的所有任务。 进行绩效评估的团队应仔细选择其战斗。 大多数性能评估是在非常有限的时间范围内执行的，因此团队应确定并专注于一两个（可能最多三个）关键性能目标。 要测试的应用程序应专门开发，以专注于确定的性能目标，并应尽可能多地考虑所有其他技术变量。 本主题介绍BizTalk Server性能评估的范围阶段的各个方面。
开始性能评估之前的注意事项
在完成性能评估的任何其他工作之前，应考虑以下因素。 这些因素将有助于确定范围阶段的一般方向，并且是性能评估的良好起点。
消息加载
请务必从一开始就考虑如何复制实际通过生产系统的消息负载。 例如，如果在生产环境中，20% 的消息大小为 <20KB，50% 的消息大小为 <100KB，其余 30% 的大小可能高达 1 MB，请务必在实验室中复制。
制定要测试的方案的简要详细信息
确定要测试的测试用例后，必须确定其中涉及的主要组件。 这包括BizTalk Server组件 (（如消息传送和业务流程) ）和其他组件，包括 MQSeries 或 SAP 等第三方技术。 从一开始就了解所有这些内容非常重要，因为这将帮助你衡量实验室的复杂性，并使你能够规划参与期间所需的技术技能。
确定将使用的适配器
性能评估实验室使用将在生产环境中使用的实际适配器至关重要。 无法使用生产中使用的实际适配器会导致问题，因为不同适配器的性能差异很大。 例如，文件适配器是最快的BizTalk Server适配器之一，但它缺少某些系统所需的一些功能;特别是文件适配器不提供对事务的支持。 事务支持提供在 MSDTC 事务的上下文中读取消息并将其写入 MessageBox 数据库的功能。 事务支持会产生开销。 因此，使用文件适配器模拟需要事务支持的生产方案不是可行的比较。 在这种情况下，性能结果实质上无效，因为它们不太可能反映生产系统的实际性能。
估计性能评估所需的时间
使用以下准则估算性能评估所需的时间：
为设置测试环境分配两周的准备时间。 一周将用于构建所需的基础结构、软件组件和应用软件更新。 第二周将专门设置与BizTalk Server生产环境重复的特定环境。
为将在性能评估期间分析的每个测试用例额外分配一周。
在实际绩效评估结束时分配一周，以记录性能评估的结果。
因此，对于包含两个测试用例的典型性能评估，完成评估的估计时间为：
(两周的准备时间) + (两周的实际绩效评估) + (一周，以记录结果) = 总共五周。
记录性能评估
作为确定绩效评估范围的一部分，评估的详细信息应记录在参与摘要中。 本文档应明确定义绩效评估的目标和目的、利益干系人和里程碑。 本文档将作为绩效评估的路线图，帮助确保所有利益干系人就参与细节达成一致，并确保绩效评估保持正轨。本文档应在整个性能评估中更新，并在性能评估结束时包含结果摘要。
目的和目标
仔细定义吞吐量和延迟目标 - 你尝试最大化什么性能标准？ 通常，以下一个或多个性能度量值是BizTalk Server性能评估的重点。
吞吐量 - 通常以可在指定时间间隔内处理的每个时间单位的消息数来度量。 例如，吞吐量目标可能定义为每秒处理 3 小时 100 条消息的能力。
延迟 - 通常定义为可在给定时间间隔内端到端处理的所有消息的百分比，例如：
所有消息的 95% 应在两秒内进行端到端处理。
所有消息的 100% 应在四秒内进行端到端处理。
峰值负载
完成一批X 的时间
Floodgate 恢复方案
高级体系结构，包括硬件和软件
应根据“在硬件和软件约束下实现最高可能 X ”来衡量性能目标。 确定如何提前度量目标。 例如，“XLang/s\orchestrations completed /second'计数器测量的 X 端到端的最大可持续吞吐量”。
注意
在上面的示例中， X 是性能评估的重点单元的占位符。 X 可以表示与 BizTalk 解决方案相关的业务流程、消息或其他性能指标。
是否可实现所需的性能？
评估性能注意事项时，应首先确定可用的硬件资源是否足以满足性能目标。 在某些情况下，如果不对硬件进行额外投资，就无法实现所需的性能。 在给定特定硬件配置的情况下，没有可用于确定性能的神奇公式，因为许多因素会影响解决方案的性能，包括业务流程的复杂性、使用的自定义代码、消息保存到 MessageBox 数据库的次数以及外部系统的限制。 下表汇总了用于实现特定方案的特定性能目标的硬件。
注意
以下信息仅供参考。 不同BizTalk Server解决方案的要求差异很大，因此在估计所需的硬件资源时，应将此表中的值用作粗略的“经验法则”。
示例硬件方案
| 处理类型 | BizTalk Server计算机 | SQL Server计算机 | 获得的吞吐量 | 备注 |
|---|---|---|---|---|
| 作为 Web 服务公开的业务流程，MQSeries 适配器 | - 6 台BizTalk Server 2010 台计算机 - 每个运行两个 3-GHZ 双核处理器的服务器 - Windows Server 2008 R2,8GB 内存 |
- 3 台SQL Server 2008 R2 计算机 - 每个运行四个 3-GHZ 双核处理器的服务器 - 64 位 16 GB 内存 - 单一 MessageBox 数据库 |
每秒 95 个业务流程 | - 平均延迟 1.11s - 99% 的消息已处理， <延迟为 2 秒 |
| Messaging | 6 BizTalk Server 2010 台计算机 | 3 SQL Server 2008 R2 计算机 | 在 2 小时内达到的峰值吞吐量为每秒 277 条消息 | 优化解决方案之前，峰值吞吐量为每秒 125 条消息 |
| 使用业务流程和 Web 服务的低延迟方案 | 一台双处理器BizTalk Server 2010 计算机 | 一个四核处理器SQL Server 2008 R2 计算机 | 每秒 60 个业务流程 | < 实现了 350 毫秒延迟 |
| 使用业务流程的低延迟方案 | 23 四核处理器BizTalk Server 2010 计算机 | - 3 台SQL Server 2008 R2 计算机 - 一个 16 CPU 主 MessageBox 数据库 - 两台 8 CPU 辅助 MessageBox 数据库计算机 |
每秒 1156 个业务流程 | 截至 2010 年 1 月，是记录BizTalk Server运行业务流程的最高可持续性能 |
在可用的硬件基础结构被认为足以实现所需的性能后，在确定BizTalk Server性能评估的范围时，请考虑以下事项：
需要哪些适配器和/或加速器？
在解决方案中实现业务流程的要求是什么？
记录吞吐量要求：解决方案的最大可持续吞吐量要求是什么？
延迟要求：对于请求-响应和请求-响应方案，解决方案需要如何响应？
解决方案从文档加载高峰期恢复情况如何？
解决方案的高可用性要求是什么？
解决方案的文档跟踪要求是什么？
任何依赖应用程序（例如远程 Web 服务或其他系统）的性能特征是什么？ 如果依赖应用程序无法跟上所需的负载，整体系统性能将相应地降低。
在作用域阶段要考虑的硬件信息
确定解决方案范围时，请创建包含以下内容的高级硬件关系图：
计算机体系结构 (，例如 x86、x64 和 IA64)
CPU 要求 (，例如类型、速度、数量、内核以及超线程)
每台计算机的 RAM 要求
本地磁盘存储 (类型、大小、速度)
SAN (存储要求：LUN 数;SAN 卡 类型)
每台计算机中的网卡 (个数，每秒 100 兆位 (Mbps) ，而每秒 1 千兆位 (1 Gbps) .)
如何在解决方案中部署防火墙？
是否会使用网络负载均衡硬件？
是否要群集化特定计算机？
在作用域阶段要考虑的软件信息
硬件信息同样重要，因为将在性能评估期间使用的软件堆栈。 应确保记录以下信息：
每台计算机的操作系统 ( 32 位或 64 位，群集化或不) 。
每台计算机上安装的服务器软件。
使用的虚拟化软件。
通常不安装的特定软件功能，例如 COM+ 汇总修补程序或所需的SQL Server主机修补程序。
确定代码更改是否在性能评估的范围内
这是在范围确定过程中要确定的最重要的事项之一。 BizTalk Server及其使用的基础组件 (SQL Server、Windows、IIS 和更多) ，可以使用本指南中讨论的优化技术和配置更改进行优化。 但是，如果尚未开发应用程序以获得最佳性能，可能会妨碍这些性能提升。 因此，只有在确信在应用程序进入实验室之前已完成彻底的代码评审时，才应从范围中删除代码更改。 如有必要，你可能同意只允许某些更改，例如，删除业务流程中的持久性点。
角色和职责
运行绩效评估的最重要方面之一是确保明确分配角色和职责。 应在性能评估开始时分配以下关键角色：
参与潜在顾客 - 参与主管负责拥有端到端的总体参与。 此角色通常由高级顾问或架构师执行。 理想情况下，此人应该具有优化基于BizTalk Server系统的经验。 需要了解SQL Server和任何其他技术，包括第三方技术。 请注意，主管不必是所有领域的专家，但他们至少需要对技术有一定了解，这样他们才能与这些领域的专家合作，并了解他们正在应用的优化。
测试设计器 - 有必要让一个致力于设计和实现将在实验室期间执行的测试的人员。 这将涉及决定将用于创建测试的测试框架，测试每个测试以确保它满足实验室的要求，并确保负责运行测试的人员知道如何使用客户端。
环境所有者 - 在实验室中拥有准确反映生产BizTalk Server环境的代表性环境至关重要。 执行此角色的人员将负责检查所使用的软件和硬件堆栈的每个项，并验证没有显著差异。 例如，在 32 位平台上运行时，SQL Server 2008 R2 只能寻址 4GB 的物理内存，而不使用物理地址扩展 (PAE) 或地址窗口扩展 (AWE) 。 在 SQL Server 2008 R2 中， (这是 Windows Server 2008 R2) 当前支持的最大物理内存，可以寻址最多 1 TB 的 64 位内存。 因此，客户和实验室环境之间的显著差异是BizTalk Server和SQL Server使用的 CPU 体系结构。 除了这些明显因素之外，其他不太明显的因素（例如已安装的 Service Pack 级别和修补程序）可能会影响环境的性能。
生成环境潜在顾客 - 在为性能评估制定详细规范后，应分配某人负责构建环境。 这将包括硬件和软件堆栈。 在许多情况下，一个人将对此负责 (这通常是环境所有者) 。 但是，在大型企业中，环境所有者可能需要是不同团队之间的联络人，他们可能各自负责解决方案的各个组件。 例如，一个团队可能负责 Windows 版本，另一个团队负责SQL Server，另一个团队负责BizTalk Server。
部署主管 - 必须让某人负责确保将应用程序正确部署到BizTalk Server、配置正确的绑定以及应用任何自定义配置。 此角色需要对解决方案有深入的了解，并且需要具备打包应用程序并部署应用程序的知识，然后验证它是否在实验室环境中处于正常运行状态。
产品专家 – 确定性能评估所需的产品专家非常重要。 所需的确切技能取决于BizTalk Server应用程序的设计和用途。
最常见的产品专业知识之一是广泛了解性能优化SQL Server。 这些技能有两个目的：第一，通常需要执行SQL Server优化来优化 BizTalk 数据库的性能;第二，许多 BizTalk 解决方案使用自定义数据库。 如果未将正确的优化应用于SQL Server环境，则自定义数据库的使用可能会成为解决方案中的瓶颈。 为了识别并应用适当的数据库优化，通常需要以下SQL Server技能：
全面了解SQL Server存储过程代码，包括优化现有存储过程的能力。
能够识别和生成缺失的数据库索引。
能够编写脚本以将数据库拆分为多个文件。
注意
有关应用此优化的详细信息，请参阅 优化 Databases2 的文件组。
能够使用 SQL Server 2008 R2 性能仪表板报告识别性能问题。
对于性能评估涉及的每个专业技术，应按照上述SQL Server的要求列表进行定义。 这可确保获取的资源对所需的资源具有明确的预期。 在性能评估期间经常需要专业知识的另一项技术是 IBM Websphere MQ。 以下列表说明了 IBM WebSphere MQ 产品专家的要求规范：
在 MQSeries 的监视、维护和自定义方面的经验。
具有安装和迁移新版本 MQSeries 的经验。
能够分析和优化 MQSeries 性能。
执行 MQSeries 问题分析。
了解与 MQSeries 安全性、管理、恢复和自动化相关的流程和过程。
文档主管 - 在整个性能评估过程中端到端更新实验室文档至关重要。 在生产环境中成功应用优化并且系统获得所需的性能级别之前，不应判断实验室参与的总体成功性。 为此，必须保留以下信息的详细记录：
实验室的高级结果摘要
未解决的问题
已解决的问题
实验室时间线
实验室进度
按类别实现的优化
(按时间顺序实现了优化，以确保可以在生产系统中按相同的顺序应用它们)
高级体系结构关系图
要测试的方案的详细信息
涉及的第三方技术
实验室硬件示意图
联系人列表
详细的硬件清单
包含完整详细结果的附录
开发人员 - 是否需要开发人员在很大程度上取决于参与的范围。 如果代码库已被锁定，并且实验室只是在那里测试基础结构和平台优化，则不应需要开发人员的服务。 在生产服务器的“上线”日期之前执行性能测试时，可能会发生这种类型的方案。 此时，代码应已锁定，完整回归测试应已完成或正在进行。 对实验室中引入的代码所做的任何更改都可能导致回归，从而给生产系统带来风险。 如果允许更改代码，则通常需要开发人员。 以下列表显示了参与BizTalk Server性能评估的开发人员通常需要的技能：
能够识别和修复业务流程的性能问题
能够识别和修复管道的性能问题
熟悉 .NET，包括：
企业库
Visual Studio F1 探查器专业知识
Microsoft Visual Studio 2010 Ultimate 或 Visual Studio Test Professional 2010
测试线索 - 确保获得准确、完整和彻底的结果集至关重要。 测试主管负责确保在每次测试运行后捕获、适当分析和分发所需的信息。 请务必考虑如何捕获数据，通常测试数据适合使用 Excel 电子表格进行演示。 以下列表说明了应在实验室期间运行的每个测试捕获的数据：
测试运行编号
日期
处理的消息总数
每秒处理的消息数
开始时间
停止时间
测试持续时间（分钟）
挂起的消息数/处理的消息总数 - 可以从 BizTalk 管理控制台捕获，也可以使用 性能监视器 测量BizTalk Server性能计数器。
处理失败的消息数
已成功处理的 # 或消息
测试客户端响应
客户端进程平均持续时间，以秒为单位 - 通常，此值是在实现具有BizTalk Server的同步消息传送解决方案时测量的，在这种情况下，必须知道平均客户端持续时间的值，因为这通常代表最终用户等待解决方案响应的时间。
客户端进程持续时间最大值，以秒为单位
客户端进程持续时间最小值，以秒为单位
BizTalk Server请求/响应延迟（以秒为单位）
每秒完成的业务流程数
按时处理的消息百分比
Visual Studio Team System 测试工具使用的 TestResultsLocation 变量的值。
BizUnit 使用的 TestResultsLocation 变量的值。
任何评论或建议
除了收集结果，测试主管还应确保他们监视每个测试运行，以查看是否存在任何趋势。 应将性能改进传达给团队的其他成员，并应指示性能提高了多少，以及应用了哪些优化来实现改进。 在一天结束时，测试主管必须提供在实验室中执行的测试的摘要。 这样，利益干系人就可以随时了解实验室的持续进度。 下表说明了如何在示例更新电子邮件中汇总此信息：
测试结果摘要
状态 吞吐量 平均延迟 %< 2 秒 测试运行数 BizTalk Server 台计算机数 消息数 平均消息大小 持续时间 向外扩展 140 条消息/秒 0.777 秒 99.3% 2 6 270,000 609 字节 30 分钟 最佳 50 条消息/秒 1.12 秒 99.12% 17 2 360,000 609 字节 2 小时 基线 30 条消息/秒 1.52 秒 92.9 % 4 2 36,000 609 字节 20 分钟 目标 5 条消息/秒 < 2 秒 90% - 2 - - -
定义性能评估开始时所需的所有可交付结果
在开始进行BizTalk Server绩效评估之前，必须就必须到位的可交付结果达成一致。 以下部分介绍性能评估开始时应实施的可交付结果。
要测试的应用程序 – 必须在性能评估期间使用的完整应用程序可用。 在开始性能评估之前，应用程序必须处于完全正常运行状态，否则可能会失去宝贵的实验室测试时间。
规划自动生成和部署 - 在进行性能评估之前，应为要测试BizTalk Server解决方案开发自动生成和部署过程。 通过自动执行应用程序的生成过程，可以执行连续的每日生成过程，然后可以附带一组生成验证测试， (BVT) 测试通过系统的功能流。 这使你能够在整个开发生命周期中更快、更轻松地检测编译和功能问题。 在实验室中，这意味着如果需要进行任何代码更改，可以快速验证更新的解决方案是否正常工作。 为性能实验室手动生成、部署和配置应用程序可能是一项繁琐且容易出错的任务。 因此，建议使用自动化技术来完成以下生成和部署活动：
从源代码管理获取最新代码。
生成完整的解决方案。
将解决方案部署到环境。
创建 BizTalk 应用程序。
将BizTalk Server资源（如 .dll 文件和绑定）添加到 BizTalk 应用程序。
导入绑定文件以创建端口并绑定到业务流程。
将 BizTalk 应用程序导出为 Microsoft® Windows® Installer 包，以便可以在测试或生产环境中部署它。
注意
有关实现自动生成过程的详细信息，请参阅自动化生成过程
MSBuild 随 .NET Framework 2.0 一起引入，使开发人员能够自动执行如前所述任务。 SDC 任务库包含多个特定于BizTalk Server MSBuild 任务，可从 下载https://go.microsoft.com/fwlink/?LinkId=119288。
在性能评估期间要使用的测试数据 – 所使用的测试数据对性能评估的整体有效性和成功率有相当大的影响。 假设BizTalk Server应用程序利用消息传送、业务流程和规则引擎。 规则引擎从接收端的管道组件内调用，以确定将用于处理消息的业务流程;它还从业务流程内的各个点调用它以确定流。 规则引擎实现缓存，以便优化规则策略执行。 因此，如果在性能评估期间将单个消息用作测试数据，则测试结果可能因缓存) 而 (倾斜，并且可能会获得无法在生产环境中复制的结果。
理想情况下，在性能评估期间使用的测试数据应该是实际生产数据或生产数据的子集。 测试数据还应模拟将流经生产系统的流量的负载和模式。 定义测试数据的要求时，请考虑以下因素：
将在给定时间段内流经系统的消息数 - 这通常表示为每秒消息数或每小时消息数。
消息类型 – 消息是平面文件、XML 还是二进制文件？
消息分布 – 平面文件所占的百分比是多少，每种 XML 消息类型的使用百分比是多少？
峰值负载处理要求 - 在许多情况下，可能会在非高峰时段处理大型交换。 例如，大量付款可能在午夜发布到银行的系统。 如果是这种情况，请确保在测试期间能够复制此副本。
用于接收/发送消息的终结点 - 在许多环境中，单独的接收位置配置为接收不同类型的消息。 例如，可以使用文件适配器接收平面文件消息，也可以使用 MQSeries 适配器来接收 XML 消息。 虽然消息可能全部由同一业务流程处理 () 但它们在系统中具有不同的入口点。 其中每个不同的接收位置都可以托管在单独的主机中;事实上，这样做通常会提高系统的整体性能。
下表提供了在确定测试数据规范时应捕获的信息示例：
示例测试数据规范
| 类别 | 说明 |
|---|---|
| 每秒消息数 | - 在此方案中，最大吞吐量是关键 - 目标为每秒 50 条消息 - 低延迟不是目标 |
| 消息类型 | - 小 XML 消息，大约 25 KB，符合 XML 架构 X - 中等 XML 消息，大约 512 KB，符合 XML 架构 Y |
| 消息分布 | - 58% 25 KB (小型 XML 消息) - 25% 512 KB (中等 XML 消息) - 11% 3 MB (中等二进制数据 - PDF) - 不可压缩 - 4% 7.5 MB (大型二进制数据 - PDF) - 不可压缩) - 2% 20 MB (大型二进制数据 - PDF) - 不可压缩 |
| 峰值负载处理要求 | (20MB) 的大型二进制数据将代表上面指定的数据 (的大约 2%，) 处理此数据的时间不可预测。 系统必须能够在任何给定时间容纳这些大型消息。 |
| 用于接收/发送消息的终结点 | 小型 XML 消息 (25 KB) - 接收位置：PaymentXMLDocIn - 主机：ReceiveHost - 使用的管道：XMLReceive 中等 xml 消息 (512 KB) - 接收位置：PaymentXMLDocIn - 主机：ReceiveHost - 使用的管道：XMLReceive 中等二进制数据 (3 MB) – PDF - 不可压缩 - 接收位置：BinaryDataIn - 主机：ReceiveHost - 使用的管道：PassThruReceive 大型二进制数据 (7.5 MB – 20 MB) – PDF - 不可压缩 - 接收位置：BinaryDataIn - 主机：ReceiveHost - 使用的管道：PassThruReceive |
| 测试数据的位置 | 本地可访问的测试文件共享，例如：\\PerformanceLabs\July\Test Data\ |
将信息放入表中可完成多项操作。 首先，它使利益干系人更容易就有关测试数据的假设达成一致。 其次，它提供可用于确定性能评估的潜在优化的信息。 例如，在上表中可以看到，用于处理所有不同数据类型的所有接收位置都托管在 ReceiveHost BizTalk 主机中。 这意味着此主机的每个实例将负责处理不同类型和大小的数据 (例如 XML 和二进制不可压缩 PDF 数据) 。 假设每个主机实例都是BizTalk Server进程 (BTSNTSVC.EXE) 的单个实例，这可能会成为处理瓶颈。 因此，在这种情况下，针对环境的一个明显优化是测试将每个接收位置分离到其自己的单独主机的性能改进。 通过以摘要表格格式访问测试数据信息，可以更轻松地测量这样的简单优化。
- 规划自动负载测试和负载生成 - 建立性能评估的测试数据配置文件后，请务必考虑如何在环境中执行负载测试。 对于 BizTalk Server 2010 负载测试，我们使用了 Visual Studio 2010 负载测试。 有关如何使用 Visual Studio 2010 促进负载测试的详细信息，请参阅 使用 Visual Studio 促进自动测试。