テストの方法と結果

テストは、設計が期待した性能を発揮し、ワークフロー、ユーザー、および意図した負荷をサポートすることを検証するために実施されました。システムテストによって、下位環境でのシステムデプロイ中、理想的には本番環境で問題が発生する前に、問題を発見して修正する機会が得られます。このテスト調査のテスト方法では、システムパフォーマンスとエンドユーザーエクスペリエンスを主眼としました。

各コンポーネントについて、それぞれ異なる負荷シナリオに対してワークフローを実行し、監視が行われました。テストが完了すると、結果が集約され、分析され、システム内のボトルネックとリソース過剰のコンポーネントの両方を特定しました。この情報を使用して、スケールアップ、スケールダウン、またはスケールアウトが必要なシステムコンポーネントを特定してから、さらにテストを繰り返しました。

ワークフローテスターの画面記録を取得して手動のユーザーエクスペリエンステストを行い、システムのユーザーがワークフローを生産的に完了できることを確認するために実施されました。

詳細については、効果的なテスト戦略の設計の方法をご参照ください。

ワークフローのペーシング

このテスト調査では、テストされたワークフローにペーシングモデルを適用しました。ペーシングモデルは、ユーティリティーでの作業ペースをテストでシミュレートする方法を示しており、ワークフローはスタッフリソースのチーム全体で 1 時間あたりの一定数の操作として実行されます。この方法は Esri のお客様からの情報に基づくもので、データの基になっている中小規模の電力事業のお客様のシナリオに一致させることを目的としています。

さまざまなワークフローは、1 時間のテスト期間全体に分散され、同時に開始されないようにずらされながら、実際のワークフローと同様に重複もするように設定されました。このワークフローペーシングの全体的な内訳は、システムが受ける「設計負荷」と見なされます。その後で、システムが許容範囲で応答できなくなる、またはワークフローを正しくサポートできなくなるまで、ワークフローの数を徐々に増やすことで、負荷を高めていきました。このテスト調査で適用されたワークフローペーシングモデルは、組織での一般的な日常使用と一致しない場合があることに注意してください。

ネットワーク情報管理システムのワークフローペーシングモデルの結果: 電力事業 (Oracle)

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

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

詳細については、パフォーマンステストツールをご参照ください。

テストの結果

このアーキテクチャーは、自動負荷テストと手動のユーザーにより、4 つのシナリオで検証されました。それぞれのシナリオの結果を以下に示します。大まかに言うと、テストの結果は、実装時点でシステムには設計負荷からその 8 倍までの負荷をサポートするのに十分なリソースがあったことを示しています。また、テスト結果からは、アプリケーションとシステムの構成が適切であることがパフォーマンスのため重要だということも明らかになりました。どのシナリオでも、システム使用率は負荷に比例して増加します。

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

ArcGIS Web Adaptor をホストしている 2 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果 Portal for ArcGIS をホストしている 2 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果 ArcGIS Server (ホスティングサーバー) をホストしている 2 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果 Utility Network サービスをホストしている ArcGIS Server をホストしている 2 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果 ArcGIS Data Store (リレーショナル) をホストしている 2 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果 Oracle および関連ワークフローのランタイムをホストしている 1 台のコンピューターについて行われた、設計負荷での自動負荷テストの結果同時実行ユーザー数の設計負荷での自動負荷テストの結果

システムはこの負荷をサポートでき、全体的なリソース使用量は低いものでした
ArcGIS Data Store (リレーショナル) は使用されませんでした - ベースマップはベクタータイルサービスとしてアクセスされました

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

ArcGIS Web Adaptor をホストしている 2 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果 Portal for ArcGIS をホストしている 2 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果 ArcGIS Server (ホスティングサーバー) をホストしている 2 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果 Utility Network サービスをホストしている ArcGIS Server をホストしている 2 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果 ArcGIS Data Store (リレーショナル) をホストしている 2 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果 Oracle および関連ワークフローのランタイムをホストしている 1 台のコンピューターについて行われた、設計負荷の 4 倍での自動負荷テストの結果同時実行ユーザー数の設計負荷の 4 倍での自動負荷テストの結果

システムはこの負荷に対応できました
ホスティングサーバーは全体として、10% 未満の CPU 使用率で動作しました
GIS サーバーは全体として、約 20% の CPU 使用率で動作しました
Oracle の CPU 使用率は 40% 未満に維持されました

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

ArcGIS Web Adaptor をホストしている 2 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果 Portal for ArcGIS をホストしている 2 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果 ArcGIS Server (ホスティングサーバー) をホストしている 2 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果 Utility Network サービスをホストしている ArcGIS Server をホストしている 2 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果 ArcGIS Data Store (リレーショナル) をホストしている 2 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果 Oracle および関連ワークフローのランタイムをホストしている 1 台のコンピューターについて行われた、設計負荷の 8 倍での自動負荷テストの結果同時実行ユーザー数の設計負荷の 8 倍での自動負荷テストの結果

システムはこの負荷に対応できました
ホスティングサーバーは全体として、20% 未満の CPU 使用率で動作しました
GIS サーバーは全体として、40% 以下の CPU 使用率で動作しました
Oracle の CPU 使用率のピークは 60% ～ 70% でした

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

ArcGIS Web Adaptor をホストしている 2 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果 Portal for ArcGIS をホストしている 2 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果 ArcGIS Server (ホスティングサーバー) をホストしている 2 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果 Utility Network サービスをホストしている ArcGIS Server をホストしている 2 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果 ArcGIS Data Store (リレーショナル) をホストしている 2 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果 Oracle および関連ワークフローのランタイムをホストしている 1 台のコンピューターについて行われた、設計負荷の 10 倍での自動負荷テストの結果同時実行ユーザー数の設計負荷の 10 倍での自動負荷テストの結果