预测试后,进行了更正式的测试,以使用基础和移动工作流评估修改后的架构和配置。 修改后的架构通过在不同负载下添加移动工作流进行测试,桌面和编辑工作流始终在四倍设计负载下运行。 在针对不同的负载场景执行工作流时,每个组件都受到监控。 您可以将资源利用率对修改后的架构的影响与原始架构进行比较。
测试完成后,对结果进行汇总和分析,以验证系统的设计是否提供了积极的最终用户体验和效率。
该测试研究将节奏模型应用于测试的工作流。 节奏模型显示了测试打算如何模拟公共设施公司的工作流,其中的工作流为员工资源团队每小时执行一定数量的操作。 此方法基于 Esri 客户输入,旨在匹配数据所基于的中小型天然气公司客户场景。
这些工作流在一小时的测试时间段内交错进行,同时像实际工作流一样相互重叠。 工作流节奏的总体细分被视为系统承受的“设计负载”。
对于此测试,Web 和桌面编辑工作流已自动以四倍 (4x) 设计负载运行,如下图所示。 了解有关测试的工作流的详细信息。

基本工作流根据节奏模型进行,该模型旨在模仿人们的工作方式,提高测试的真实性。 在此模型中,工作流之间存在偏移,因此它们不会同时开始或结束。

如上所述,移动工作流在系统处于负载状态下执行。 移动工作流的设计负载如下所示,每小时共计 405 次操作。 然后,移动负载成倍增加,同时保持桌面负载一致。

此节凑模型显示使用按设计负载节奏运行的移动工作流在四倍设计负载下运行常规负载。 模型会随着对移动工作流施加的负载增加而逐渐调整。

离线视图工作流包括下载和同步,这会影响 ArcGIS Enterprise。 离线编辑工作流从类似的下载和同步开始,但也包括用于上传更改的第二次同步。 在移动设备上为查看或编辑数据而执行的工作不会影响 ArcGIS Enterprise。
在原始架构(左)中,在六倍设计负载下,ArcGIS Web Adaptors 非常饱和,并且 Portal for ArcGIS 计算机显示 CPU 使用率极高(见图 13)。 将此架构与修改后的架构(右)进行比较,后者的资源利用率(尤其是在 ArcGIS Web Adaptor 和 ArcGIS Portal 层)明显下降到更优化的阈值。 此外,您还可以观察修改后的架构中增加的 vCPU 如何帮助减少我们在原始架构中看到的导致下载超时的网络吞吐量(灰色)限制。

与预期一样,用户体验随着负载的增加而降级。 而此类影响在使用离线工作流时最为明显,如下所示。 例如,离线查看时间(包括下载步骤)在设计负载和四倍设计负载之间增加了 44%,在四倍和六倍设计负载之间增加了 78%。 大部分时间将归因于下载离线区域和同步数据。 因此,除了调整资源规模之外,优化离线区域、为移动工作人员提供良好的连接,甚至错开下载都有助于减少这些时间。
ArcGIS Pro 工作流执行时间在设计负载和六倍设计负载之间平均降低了 12%,这意味着编辑者每天都需要浪费 58 分钟时间等待系统。 在设计负载和四倍设计负载之间,这个数字是 9%,即 43 分钟。

由于编辑者维护许多员工在工作中使用的竣工网络,因此提供高性能的编辑环境非常重要。 尽管在四倍设计负载之前,增加移动工作流的负载不会对系统产生明显影响,但用户体验表明,随着负载开始超过原始设计负载,建议调整配置。
以下要求可能会改善用户体验并提高投资回报率: