结论和关键点

纵观五次测试运行，首轮测试中因数据库实例资源配置不足，明显导致系统性能和用户体验下降。 一旦数据库实例针对工作负载进行合理调整，ArcSOC : vCPU 比例对工作流执行时间的影响便变得微乎其微。 我们从下表可以看出，采用 1:1 的 ArcSOC : vCPU 比例时，查看工作流增加了 0.246 秒的等待时间，但对编辑工作流影响不大（参见 P99 等待时间 HS）。 这很可能是因为托管服务器上的 ArcSOC 处于繁忙状态。

虽然 2:1 的比例几乎能实现相同的工作流执行时间，且未出现明显的等待现象，但 UN GIS 服务器的内存利用率较高 (82%)。 针对这些涉及版本化编辑的工作流而言，2:1 的比例过高，因为 UN GIS 服务器上的最大 ArcSOC 数仅为 7 个。 因此，单纯增加 UN GIS 服务器上的 ArcSOC 数量只会造成服务器资源的浪费。 不过，对于承载仅限查看工作流的托管服务器而言，2:1 的比例则能够轻松支持。 UN GIS 服务器需要更多内存来支持 2:1 及以上的比例。 对于 4:1 的比例，托管服务器同样需要更多内存。

资源利用率

我们得出结论，增加更多服务实例并未改善编辑用户体验，尽管通过减少等待时间可能提升查看工作流的响应速度。 我们发现，即使是空闲的 ArcSOC 也在持续消耗服务器资源。 上表显示，随着 ArcSOC : vCPU 比例的增加，工作流执行时间略有延长。

这表明额外的 ArcSOC 并非支持用户请求的必要条件，反而造成了系统资源（主要是内存）的无效占用。 上表数据证实，编辑工作流未能利用额外的 ArcSOC，但对于每小时操作量更高的查看工作流而言则可以。 因此，对于我们的系统而言，托管服务器中采用 2:1 的 ArcSOC 与 vCPU 比例对仅查看服务最为理想，而 UN GIS 服务器上则采用 1:1 的比例。

关键点

• 数据库实例资源不足会对整个系统产生负面影响：

  • 对于我们的系统来说，更大的地理数据库实例规模 (16 vCPU) 至关重要

  • ArcSOC、GIS 服务器 CPU 和 Web Adaptor 均处于繁忙状态，导致性能问题看似波及整个系统

  • 在数据库配置过低的情况下，工作流执行时间约为正常情况的两倍

  • 数据库资源不足对性能的影响远大于地图实例配置不当带来的影响

  • 仅仅增加数据库资源就能大幅提升系统行为和性能

• 在数据库资源配置合理的前提下，提高 ArcSOC（地图服务实例）与 vCPU 的比例并未改善最终用户体验或缩短工作流执行时间

• 添加不必要的服务实例会因消耗额外的资源而对系统产生负面影响

• 即使处于空闲状态，增加运行中的地图实例数量依然会影响 GIS 服务器的内存利用率

• 工作负载分离依然重要 - 暴露版本化数据的要素服务比仅限查看的服务会消耗更多的 GIS 服务器内存

  • 数据库实例的可用资源（CPU、RAM 和磁盘 I/O）显著提升后，整个系统处理负载的能力也相应显著提升

• 至少应监控数据库 CPU、ArcSOC 使用情况、GIS 服务器资源以及用户体验，以便为您的系统确定最佳配置，尤其是在进行任何更改之后