テストの方法と結果

手動テストと自動負荷テストを組み合わせて実施し、マップ範囲とレイヤー縮尺の表示設定の構成ミスが、編集と表示のワークフローのパフォーマンスとユーザー エクスペリエンスに与える影響を調べました。 ワークフローを負荷下で実行しながら、デスクトップ コンピューター インスタンス、ArcGIS Pro、Web アプリを監視しました。

編集者が定義されたワークフローを実行する際の手順をシミュレートするため、スクリプト テストが実施されました。 テスト完了時に、結果が集約および解析され、さまざまなハードウェア構成でデスクトップの使用率とエンドユーザーの効率が比較されました。

テストの方法

マップ範囲とレイヤーの表示縮尺範囲がパフォーマンスとユーザー エクスペリエンスに与える影響をテストするために、以前にテストされ、優れたパフォーマンスとユーザー エクスペリエンスを発揮することが確認された、適切に構成されたマップにいくつかの変更を加えました:

• ダッシュボード Web マップ (資産の表示ワークフローに使用):「電気レイヤー」の表示範囲を近郊レベルから郡レベルに変更し、マップのデフォルト範囲を近郊から郡に変更。
• Experience Builder Web アプリ (資産の集計ワークフローに使用): 電線レイヤーの表示設定とデフォルトのマップ範囲を、上記と同じ設定に更新。
• ArcGIS Pro プロジェクト マップ (編集ワークフローに使用):「電線」グループ レイヤー内の「中電圧導体」レイヤーの表示範囲を削除し、デフォルトのマップ範囲を 1:500,000 に設定。

これらの変更は、マップ範囲とレイヤーの表示設定の構成が、さまざまな種類の基本的な電力事業ネットワーク情報管理ワークフローに与える影響を確認するために選択されました。 Viewer のワークフローに使用される読み取り専用の Utility Network サービスはホスティング サーバーで動作し、編集ワークフローは GIS サーバーでホストされている UN サービスを利用します。 したがって、レイヤーの表示設定とマップ範囲が適切に構成されていない場合、編集ワークフローと表示ワークフローに及ぼす影響は、それぞれのシステム コンポーネントのインスタンスで確認できます。

パフォーマンス テスト ツール

ArcGIS は多層システムなので、パフォーマンス テストは、クライアント層、サービス層、データ ストレージ層、および基盤となるインフラストラクチャー自体にわたって行われました。 このテスト調査では、JMeter を使用してユーザーのワークフローをシミュレートし、さまざまな負荷のもとでシステム パフォーマンスを測定しました。 ArcGIS Pro の記録されたリクエストを再生することで負荷をシミュレートしました。また、手動のワークフローを実行することで、エンドユーザー エクスペリエンスも評価されました。

各コンポーネントのリソース使用率を監視するため、Windows パフォーマンス モニターと ArcGIS Monitor も使用されました。 詳細については、パフォーマンス テスト ツールをご参照ください。

テストの結果

マップ構成が不適切である場合に、さまざまな負荷のもとでパフォーマンスとユーザー エクスペリエンスにどのような影響を与えるかを理解するために、システムを 3 つのシナリオでテストしました。 負荷シナリオごとに、表示設定が最適化された同一のシステム (左) と比較して影響を評価できます。 大まかに言うと、レイヤーの表示設定とマップ範囲にたった 1 つや 2 つでも不適切な構成があるマップでは、特に高い負荷がかかったときに、システムの使用率とユーザー エクスペリエンスが大きな影響を受ける可能性があることがテスト結果に示されています。

テスト シナリオ: 設計負荷の 2 倍

所見:

• 全体として、システム コンポーネントの使用率は許容範囲内ですが、最適化されたシステムと比較して、データベース、Utility Network (UN)、およびホスティング サーバー インスタンスの使用率が 2 倍になっています
• ホスティング サーバーと UN サーバーは、実行中に CPU 使用率の急上昇を示しています
• サービスの待機時間と ArcSOC 使用率は許容可能な閾値内に収まっています

テスト シナリオ: 設計負荷の 4 倍

所見:

• ホスティング サーバーとデータベースは、テスト全体を通じてかなりのリソース使用率を示し、最適化されたシステムと比較して約 4 倍の使用率になっています
• PostgreSQL インスタンスは、設計負荷の 2 倍のときと比較して、リソース使用率が 200% 以上増加しています
• サービスの待機時間は増加し続けています
• ホスティング サーバー上のほとんどの ArcSOC は、実行中ビジー状態を保ち、一部のインスタンスはピークに達します
• UN サーバー上の ArcSOC は、ホスティング サーバーと比較して影響が少なく、直線的かつ段階的に増加します

テスト シナリオ: 設計負荷の 8 倍 (最適) と 設計負荷 の 6 倍 (準最適) の比較

所見:

• 準最適な構成では、特にホスティング サーバーで実行されているビューアー ワークロードでサービスの待機時間が許容範囲を下回り、全体的なパフォーマンスが低下しています
• 準最適な構成では、ホスティング サーバーの使用率は、最適化されたシステムでの設計負荷の 8 倍と比較しても、6 倍の場合は約 4 倍も高くなります
• PostgreSQL インスタンスは、6 倍の準最適な構成では閾値に達しています。これは設計負荷の 8 倍での最適なシステムの使用率の 2 倍以上です
• ホスティング サーバー上のほとんどの ArcSOC は、準最適な構成で最大閾値に達します。サーバーがビジー状態になり、SOC 使用率値を取得できないために、異常な動作が観察されるようになります
• UN サーバー (エディター) 上の ArcSOC は、ホスティング サーバーと比較して影響が少なく、直線的かつ段階的に増加します

ArcSOC 使用率の比較

ArcSOC の使用率が増加すると、サービスの待機時間が長くなることが多く、最終的にはユーザーの業務効率に影響を与えます。 ArcSOC の使用率は、すべての負荷シナリオで監視されました。 すべてのテストで、ArcSOC の使用率は、マップが最適化されたシステムと比較して著しく高くなりました。 以下のグラフは、設計負荷の 4 倍で大きな違いがあることを示しています。 最適化されたシステムと比較して、ホスティング サーバーでの ArcSOC の使用率は約 3 〜 4 倍、UN サーバーでは約 2 倍増加します。

ユーザー エクスペリエンス

ユーザー エクスペリエンスを評価するために、ワークフローのステップ時間がキャプチャーされました。 ワークフローが完了するまでに時間がかかる場合は、システムのリクエストへの応答が遅れていることを意味します。 以下のグラフは、最適化されたシステムと最適に設定されていないシステムの両方で、ワークフロー内の特定のステップを完了するまでにかかった平均時間を示しています。

負荷管理以外のすべてのワークフローでは、負荷の増加に伴い、合計ワークフロー時間の増加が見られました。 設計負荷の 6 倍では、アセットの表示ワークフローは、設計負荷の 2 倍に比べて約 15 倍も長くかかります。 資産と電気の更新ワークフローのログインとプロジェクトを開くステップは最も時間がかかり、システムの負荷が増加するにつれて所要時間が著しく増加します。 さらに、設計負荷の 6 倍では、場所検索、デバイスへのズーム、および下流トレースのステップは、設計負荷の 4 倍と比べていずれも所要時間が指数関数的に跳ね上がります。