結論と重要なポイント

5 回のテスト実行を行ったところ、最初のテスト実行におけるリソース不足のデータベース インスタンスが、システムのパフォーマンスとユーザー エクスペリエンスを著しく低下させていることが明らかでした。 ワークロードに合わせてデータベース インスタンスが適切にサイズに調整されると、ArcSOC と vCPU の比率がワークフロー実行時間に与える影響は小さくなりました。 以下の表を見ると、ArcSOC と vCPU の比率が 1:1 である場合、表示ワークフローに若干の追加の待ち時間 (0.246 秒) が発生しましたが、編集ワークフローへの影響は大きくありませんでした (「P99 Waits HS」参照)。 これはホスティング サーバーの ArcSOC がビジー状態であることが原因と考えられます。

一方で比率が 2:1 の場合、ワークフロー実行時間はほぼ同じで、待ち時間もほとんどありませんでしたが、UN GIS Server のメモリー使用率が高くなりました (82%)。 UN GIS Server の ArcSOC 数が最大でも 7 にしか達しないこれらのバージョン対応編集ワークフローには、2:1 の比率は高すぎます。 そのため、UN GIS Server 上の ArcSOC を増やしても、サーバー リソースの無駄遣いになるだけです。 一方、表示専用ワークフローをサポートするホスティング サーバーでは、2:1 の比率を問題なくサポートできました。 UN GIS Server で 2:1 以上の比率をサポートするには、より多くのメモリーが必要になります。 4:1 の比率になると、ホスティング サーバーでも多くのメモリーが求められます。

リソースの使用率

サービス インスタンスを追加しても、編集者のユーザー エクスペリエンスの向上にはつながらないという結論に至りました。ただし、待ち時間を短縮できれば、表示ワークフローの応答性が向上される可能性はあります。 未使用の ArcSOC でもサーバー リソースを消費していることがわかりました。 上の表は、ArcSOC と vCPU の比率が上がるにつれて、ワークフロー実行時間がわずかに増えることを示しています。

これは、ユーザー リクエストに対応するために、利用可能な ArcSOC が追加で必要だったわけではなく、システム リソース (主にメモリー) を不必要に消費していたことを示唆しています。 上記の表では、編集ワークフローでは追加の ArcSOC が活用されなかった一方で、1 時間あたりの操作数がはるかに多い表示ワークフローでは活用されていたことが確認できます。 したがって、当システムにおいて、ホスティング サーバーの表示専用サービスでは ArcSOC と vCPU の比率は 2:1 が最適であり、UN GIS Server では 1:1 が最適であることがわかりました。

重要なポイント

• リソース不足のデータベース インスタンスがシステム全体に悪影響を及ぼしました:

  • 当システムでは、より大きいジオデータベース インスタンス (16 vCPU) が不可欠であると判断しました

  • ArcSOC、GIS Server の CPU、Web Adaptor がビジー状態であったため、パフォーマンスの問題はシステム全体に及んでいるように見えました

  • データベースが小さすぎると、ワークフロー実行時間は約 2 倍になりました

  • リソース不足のデータベースは、構成が不適切なマップ インスタンスよりもパフォーマンスに大きな影響を与えました

  • データベース リソースを単に増やすだけで、システムの動作とパフォーマンスが大幅に向上しました

• 適切にリソースが割り当てられたデータベースでは、ArcSOC (マップ サービス インスタンス) と vCPU の比率を高めても、エンド ユーザー エクスペリエンスやワークフロー実行時間は改善されませんでした

• 不要なサービス インスタンスを追加すると、余分なリソースを消費し、システムに悪影響を及ぼす可能性があります

• 実行中のマップ インスタンス数を増やすと、たとえビジー状態でなくても、GIS Server のメモリー使用率に影響を与えます

• ワークロードの分離は依然として重要です。バージョン管理データを公開するフィーチャ サービスは、表示専用サービスよりも多くの GIS Server メモリーを消費します

  • データベース インスタンス上の利用可能なリソース (CPU、RAM、ディスク I/O) により、システム全体の負荷処理能力が大幅に向上しました

• 少なくとも、データベースの CPU、ArcSOC の使用状況、GIS Server のリソース、ユーザー エクスペリエンスを監視し、特に変更を加えた後は、システムに最適な構成を特定することが重要です