测试方法和结果

测试的目的是验证设计是否按预期执行并能够支持工作流、用户和预期负载。 系统测试提供了在较低环境中的系统部署期间发现和纠正问题的机会，理想情况是在问题出现在生产环境之前进行修正。 本次测试研究的重点是验证系统是否支持各项工作流，了解负载如何影响系统及其组件，以及评估最终用户体验。

在针对不同的负载场景执行工作流时，每个组件都受到监控。 测试完成后，对结果进行了汇总和分析，以确定系统的瓶颈和资源过多的组件。 此信息用于识别在重复进一步测试之前需要扩展、缩减或缩小的系统组件。

通过捕获工作流测试人员的屏幕记录来执行手动用户体验测试，以确保系统用户能够高效地完成其工作流。

有关详细信息，请参阅如何设计有效的测试策略。

工作流节奏

该测试研究将节奏模型应用于测试的工作流。 节奏模型显示了测试打算如何模拟宗地管理组织的工作节奏，其中的工作流为员工资源团队每小时执行一定数量的操作。 此方法基于 Esri 客户输入，旨在匹配数据所基于的中型宗地管理客户场景。

在一小时的测试期间，工作流已配置为分时错峰触发，以避免同时启动，同时仍允许部分重叠，以此模拟真实环境中任务的展开方式。 在以下节奏模型中，您可以查看如何指定每个工作流的节奏和每小时的操作次数，这些参数共同定义了系统的“设计负载”。

随后，通过成倍增加工作流数量来提高负载，直到系统无法再提供可接受的响应或支持成功的工作流为止；在本例中，则是增加到足以验证系统适用于目标类型组织的程度。 请注意，本次测试研究中采用的工作流节奏模型可能与贵组织的日常使用情况有所不同。

性能测试工具

由于 ArcGIS 是一个多层系统，因此跨客户端、服务和数据存储层以及底层基础架构本身进行了性能测试。 在本测试研究中，使用了 JMeter 模拟用户工作流并测量不同负载下的系统性能。 除了为评估最终用户体验而执行的手动工作流外，还记录并重现了 ArcGIS Pro 请求以模拟负载。 还使用了 Windows 性能监视器和 ArcGIS Monitor 来监控不同组件之间的资源利用率。

有关详细信息，请参阅性能测试工具。

测试结果

此体系结构已在三种方案下通过自动负载测试和手动用户操作进行了验证，您可以在下面看到每种方案的结果。 高层面来看，测试结果表明，按当前实施情况，系统配备了充足的资源，能够支持从设计负载到 8 倍设计负载的使用量。 测试还进一步验证了正确进行应用和系统配置对性能的重要性。

测试方案：设计负载

Observations:

• 系统支持负载
• 托管服务器（查看工作流）平均 CPU 利用率低于 30%（橙线）
• 宗地服务器（编辑工作流）平均 CPU 利用率低于 40%
• SQL Server 显示 CPU 利用率非常低，通常保持在 15% 以下
• SQL Server 实例上的磁盘利用率尖峰可以归因于后台 Windows 进程（金线）
• 并发请求显示在整个测试期间，系统在任何给定时间大约支持 3 个并发查看请求（红色）和 1 个并发编辑请求（蓝色）

测试方案：4 倍设计负载

Observations:

• 系统能够承受该负载，各组件的资源利用率仅有微小的增加
• 托管服务器平均 CPU 利用率通常低于 40%
• 宗地服务器平均 CPU 利用率通常低于 50%
• SQL Server 的 CPU 利用率通常保持在 40% 以下
• 磁盘利用率的周期性尖峰可归因于工作流的启动或特定的工作流步骤。 具体来说，15:10 - 15:20 之间的尖峰与“汇总宗地”工作流有关，即多个仪表盘同时打开
• 并发请求显示系统在整个测试期间平均支持 10 到 15 个并发查看请求和编辑请求，同时存在较大的并发查看请求尖峰且很快关闭。

测试方案：8 倍设计负载

Observations:

• 系统能够承受负载，各组件间的资源利用率呈预期增长
• 托管服务器 CPU 利用率通常保持在 50% 以下
• 宗地服务器 CPU 利用率通常保持在 50% 以下
• SQL Server 的资源利用率显著提升，CPU 利用率持续达到约 60%。
• 并发请求显示系统在整个测试期间持续支持 35 个并发查看请求尖峰和平均两个并发编辑请求。
• 20:20 出现的读取请求尖峰，是“汇总宗地”工作流启动所致。

服务实例配置

除了虚拟机资源利用率外，我们还监控每次测试运行中的 ArcSOC 利用率，以帮助了解服务是否得到正确调整。 对于所有设计负载最高达到 8 倍的运行，繁忙的 ArcSOC 远低于最大值 (16)，这表明针对这些负载，我们配置的地图实例数量超出了实际需求。 如果这是一个负载低于 8 倍设计负载的生产环境，我们可以选择缩减托管服务器和 GIS 服务器机器的尺寸以节省成本。 这假设我们会同时监控 ArcSOC 的利用率以及服务器 CPU 和内存，以判断何时需要扩展以满足需求。 此外，我们还需要确保不会让这些机器过载，因为每个 ArcSOC 都会占用一定的内存，而每个繁忙的 ArcSOC 都会占用一个虚拟 CPU。

下图显示，在 8 倍设计负载下，托管服务器站点的所有 16 个 ArcSOC 在特定时间点均处于繁忙状态。 当所有 ArcSOC 都处于繁忙状态时，我们预计服务等待时间会增加（我们确实观察到了这一点）。 然而，宗地服务器（右侧）显示 ArcSOC 利用率较低，16 个配置中最多只有 9 个处于繁忙状态。

托管服务器（左侧）的初始尖峰是测试开始时仪表盘启动所致。 我们已针对未来的测试运行调整了工作流节奏，将仪表盘启动时间分散在几分钟内进行，以更好地反映真实场景。

• 想了解更多信息，请参阅这篇详细介绍 ArcSOC 优化艺术与科学的博客。

用户体验 - 手动工作流时间

除了自动化工作流外，我们还通过录制工作流测试人员的屏幕来观察用户体验，并从这些录像中提取工作流持续时间（用户完成工作流中所有步骤所需的时间）。 这一做法旨在确保系统用户能够高效地完成其工作流。

如下图所示，所执行的工作流时间基本一致，所有测试场景中仅有细微差异。 这表明系统能够承受增加的负载，而不会对最终用户所感知到的系统响应速度产生负面影响。

用户体验 - 手动工作流步骤时间

除了工作流本身，我们还记录了所有工作流中关键步骤的执行时间。 这表示系统承受负载时，完成每个工作流特定步骤所需的平均时间。 您可以在下面的图表中看到合并宗地工作流的示例，其中完成每个步骤所需的时间在所有负载场景下都非常一致。 这种模式虽然有轻微波动，但在所有工作流程中都保持一致。

结论和关键点

这些测试是在测试环境中进行的，而非生产系统。 您的系统在工作流、配置或设计上可能会有所不同。 例如，在 Azure 中，通常不使用 Web Adaptor（假设采用 SAML），而是由 AppGateway 直接将负载分发到各个服务器。 但是，您可以借鉴这些测试方法和结果以实现自己的目标：

• 系统层面的可观测性设计除了能够支持故障排查等其他关键活动之外，还能提供宝贵的信息，以便在基础设施成本与性能调整之间取得合理平衡。
• 监控系统服务器资源、ArcSOC 利用率和工作流完成时间 - 无论是在测试期间（阶段/测试环境）还是生产环境中。
• 寻找资源配置与资源利用率不匹配的区域。 例如：
  • 以 8 倍设计负载来看，托管服务器站点似乎适合此等规模的请求。 然而，GIS 服务器（宗地服务器）仍有大量未使用的资源。
  • 我们有多个机会可以缩减基础设施规模以节省成本，同时保持相同的性能和用户体验。
  • 另外，我们或许还能优化重新配置 ArcSOC 的分布方式，来支持工作流的执行。