データベース リソースへの影響に関するテスト結果

1 つ目のテストでは、GIS サーバー リソースが十分であっても、データベース リソースがシステムの負荷処理能力に与える影響を調べました。 これは、データベースがシステム全体にどれほど大きな影響を及ぼすかを示すためです。 つまり、ユーザーが長時間にわたって待たされている場合、その問題は必ずしも ArcGIS Server 層だけに起因するとは限らないということです。

テストの方法と結果

サーバー リソースが十分であっても、データベース リソースがシステム パフォーマンスに与える影響を比較するために、以下の 2 つのテストを実施しました:

• 1 つ目のテストでは、8 つの vCPU を搭載した小規模なデータベース仮想マシン インスタンスを使用
• 2 つ目のテストでは、16 個の vCPU を搭載したより大きなデータベース仮想マシン インスタンスを使用

システムの他のすべての要素は 1:1 の ArcSOC 構成に保ちました。 つまり、ArcGIS Server インスタンスで vCPU あたり 1 つの ArcSOC を構成し、ArcSOC と vCPU の数が等しくなるようにしました。 ArcSOC の使用や可用性、サービス待ち時間、システム リソースの使用率、 error 率などのパフォーマンス指標をキャプチャーして監視し、各構成を評価しました。 テストは元のシステム テスト調査の設計負荷の 8 倍の負荷で実施され、システムに影響を与えるのに十分な負荷を確保するために、ArcGIS Enterprise サーバーのリソースは半分 (前のテスト調査の半分) に削減しました。

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

負荷テスト 1: 小規模なデータベース インスタンス - 8 つの vCPU

この実行は、縮小されたデータベース サーバーへのシステム影響を観察するため、PostgreSQL インスタンスで 8 つの vCPU を利用可能な状態で実施しました。 ArcGIS GIS Server (UN Server) にも 8 つの vCPU が搭載されていました。 以下に、システム全体のリソース使用率を示す 6 つのインスタンス リソース グラフと、同時リクエスト数を示す 1 つのグラフを示します。 各リソース グラフでは、オレンジのラインは CPU 使用率 (%)、ゴールドのラインはディスク使用率 (%)、紫のラインはメモリー使用率 (%) を表しています。

以下の図では、PostgreSQL データベースの CPU 使用率は 100% に達しており、ホスティング サーバーの CPU も頻繁に 100% まで急上昇していることがわかります。 これは、設計負荷の 8 倍のワークフローに関連する表示リクエスト数が多いためです。

下のグラフは、JMeter ログから測定された同時リクエスト数を示しています。 同時表示リクエストを表す赤いラインでは、テストの実行に伴って 538 まで上昇する傾向があることに注目してください。 これは、リクエストが閉じられていないことを示しています。 後のグラフでは、このラインが上下に一定に動いているのが見られます。これは、システムが応答しており、負荷を処理できる速さでリクエストが閉じられていることを示しています。

この構成では、PostgreSQL データベースのグラフにおけるオレンジ部分 (CPU 使用率)、ホスティング サーバー CPU 使用率の急上昇、同時リクエスト数の多さからもわかるように、データベース サーバーがリソース不足であったため、負荷をサポートできませんでした。

この点をさらに裏付けるために、以下のグラフはリモート コンピューター上で動作している Soccer (ArcSOC Monitoring) ユーティリティーによって取得されたホスティング サーバー上の ArcSOC 使用状況を示しています。 赤いラインは 100% (8 個) でビジー状態の ArcSOC を表しています。これはデータベースの過負荷に起因すると考えられます。 ArcSOC はデータベースの応答を待つ間、ビジー状態で保留されます。 実際、ArcSOC は非常にビジー状態であったため、Soccer はその状態を追跡できませんでした。この点は、赤いラインが不完全であることと、最大値 (緑のライン) が急激に下がることからわかります。

負荷テスト 2: 大きいデータベース インスタンス - 16 個の vCPU

2 つ目のテストでは、PostgreSQL データベース インスタンスの vCPU を 16 個に倍増させ、最初のテストとの違いを観察しました。 ArcGIS GIS Server はそれぞれ 8 個の vCPU をプロビジョニングした状態のままです。 前の図と同様に、CPU 使用率はオレンジ、ディスク使用率はゴールド、メモリー使用率は紫色で示しています。 いくつかの急上昇を除き、すべてのサーバーの CPU、ディスク、メモリーの使用率はおおむね 60% 未満で稼働しています。

同時リクエスト数のグラフでは、同時表示リクエストは平均 36 回で、いくつかの急上昇が見られます。 オープン リクエスト数は、前のグラフのように増加傾向になく、このシステムが負荷を適切に処理していることを示しています。

以下の ArcSOC グラフは、ホスティング サーバー上の ArcSOC がビジー状態であるが、システム全体の応答は良好であることを示しています。 使用率の 99% (p99) は 8 soc 以下ですが、平均は 4.81 となっています。 後ほど、システムによってユーザーが効率的に作業できるかどうか検討するために、ユーザー エクスペリエンスを確認します。

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

システム全体の使用率やパフォーマンスに加え、データベース インスタンスで利用可能なリソースが増加したことにより、エンド ユーザーの作業効率が大幅に向上しました。 このテスト調査では、ワークフロー実行時間 (ユーザーがワークフローのステップを完了するのにかかる時間) と、ワークフロー ステップ実行時間 (ワークフロー内の主要なステップを完了するのにかかる時間) を観察することでエンド ユーザーの効率性を評価しました。

上のグラフから、小規模なデータベースのテスト実行においてシステム リソースの飽和度が高くなると、ワークフロー実行時間が長くなり、その結果、エンドユーザー エクスペリエンスが悪化することがわかります。 ArcGIS Server のリソースが十分に確保されていても、リソースが適切に割り当てられていないデータベースでは、リソースが適切に割り当てられていたデータベースと比べて、すべてのワークフローの全体的な実行時間が大幅に増加しました。 特に、資産の表示ワークフローでは、適切にサイズ調整されたエンタープライズ ジオデータベースを用いることで、ワークフロー実行時間が劇的に短縮されました。

ワークフロー実行時間に加え、データベース リソースが特定の編集ワークフロー ステップの所要時間にどのように影響するかをより深く調べることができます。 しかし、資産の更新ワークフローでは、プロジェクトを開いて資産を見つけるまでの時間に大きな差があることが示されています。 同様に電力トレースでは、すべてのワークフロー ステップで大幅な時間の増加が見られました。 このパターンは、キャプチャーされたすべてのワークフローで継続しました。