テストは、設計が期待した性能を発揮し、ワークフロー、ユーザー、および意図した負荷をサポートすることを検証するために実施されました。 システム テストによって、下位環境でのシステム デプロイ中、理想的には本番環境で問題が発生する前に、問題を発見して修正する機会が得られます。 このテスト調査のテスト方法では、システム パフォーマンスとエンドユーザー エクスペリエンスを主眼としました。 各コンポーネントについて、それぞれ異なる負荷シナリオに対してワークフローを実行し、監視が行われました。
テストが完了すると、結果が集約され、分析され、システム内のボトルネックとリソース過剰のコンポーネントの両方を特定しました。 この情報を使用して、スケール アップ、スケール ダウン、またはスケール アウトが必要なシステム コンポーネントを特定してから、さらにテストを繰り返しました。
ワークフロー テスターの画面記録を取得して手動のユーザー エクスペリエンス テストを行い、システムのユーザーがワークフローを生産的に完了できることを確認するために実施されました。
詳細については、効果的なテスト戦略の設計の方法をご参照ください。
このテスト調査では、テストされたワークフローにペーシング モデルを適用しました。 ペーシング モデルは、ユーティリティーでの作業ペースをテストでシミュレートする方法を示しており、ワークフローはスタッフ リソースのチーム全体で 1 時間あたりの一定数の操作として実行されます。 この手法は Esri のお客様からの情報に基づいており、使用データは中小規模のガス事業者のシナリオに準拠しています。
さまざまなワークフローは、1 時間のテスト期間全体に分散され、同時に開始されないようにずらされながら、実際のワークフローと同様に重複もするように設定されました。 このワークフロー ペーシングの全体的な内訳は、システムが受ける「設計負荷」と見なされます。 その後で、システムが許容範囲で応答できなくなる、またはワークフローを正しくサポートできなくなるまで、ワークフローの数を徐々に増やすことで、負荷を高めていきました。 このテスト調査で適用されたワークフロー ペーシング モデルは、組織での一般的な日常使用と一致しない場合があることに注意してください。
ArcGIS は多層システムなので、パフォーマンス テストは、クライアント層、サービス層、データ ストレージ層、および基盤となるインフラストラクチャー自体にわたって行われました。 このテスト調査では、JMeter を使用してユーザーのワークフローをシミュレートし、さまざまな負荷のもとでシステム パフォーマンスを測定しました。 ArcGIS Pro の記録されたリクエストを再生することで負荷をシミュレートしました。また、手動のワークフローを実行することで、エンドユーザー エクスペリエンスも評価されました。 各コンポーネントのリソース使用率を監視するため、Windows パフォーマンス モニターと ArcGIS Monitor も使用されました。
詳細については、パフォーマンス テスト ツールをご参照ください。
このアーキテクチャーは、自動負荷テストと手動操作によるテストを通じて、3 つのシナリオで検証されました。各シナリオの結果を以下に示します。 概略として、テスト結果は、実装時点でシステムには設計負荷から設計負荷の 4 倍までの負荷をサポートするのに十分なリソースがあったことを示しています。 また、テスト結果からは、アプリケーションとシステムの構成が適切であることがパフォーマンスのため重要だということも明らかになりました。 どのシナリオでも、システム使用率は負荷に比例して増加します。
システムに負荷がかかっている間、実行されたワークフローの時間は、ユーザーが経験したのと同様に記録されました。 これは、ワークフローにリストされているすべてのステップを完了するまでの時間を示しています。 実行されたワークフローの時間は、システムが設計負荷の 8 倍で過負荷になるまで一貫していました。
システムに負荷がかかっている間、8 つのワークロードすべてにわたり、主要な個別のステップについて、実行されたワークフローの時間がキャプチャーされました。 これは、各ステップを完了するのに要した平均時間を示します。 実行時間は、システムが設計負荷の 8 倍で過負荷になるまで一貫していました。