ArcGIS Server展開の負荷テストに推奨される戦略
ほとんどのテストソフトウェアは、テスト完了後に何らかのレポートを生成できます。このレポートは、テスト計画で尋ねられた質問に答えるべきです。
例えば：
a) ArcGISサービスはすべてのCPUを利用できたか（例：CPUバウンド）？
b) ArcGISサービスは特定のスループット（例：一定量のトランザクション/秒）を提供できたか？
c) スループットはパフォーマンス要件を満たす平均応答時間を提供したか？
テストの目的を定義することで、テスト作業が目標に集中し続けるのに役立ちます。
- 既知の重大なバグや欠陥がないアプリケーションに対してテストを実施する
負荷テストは、展開やアプリケーションの機能テストとして使用すべきではありません。
アプリケーションは負荷テストを実施する前に品質保証（QA）テストに合格している必要があります。
さらに、アプリケーションに重大なバグが含まれている場合、その欠陥は提供されるサービスのパフォーマンスとスケーラビリティに測定可能な影響を与える可能性があります。これは結果的にテスト結果を無効にし、時間、費用、およびリソースの浪費につながる可能性があります。
- 負荷テスト前にアプリケーション（およびArcGISサービス）と対話する
システム上で唯一のユーザーであり、ArcGISサービスの応答が非常に遅い場合、負荷下でのテストを実施する必要はありません。次のステップはArcGISサービスのパフォーマンス調整と最適化です。
多くの場合、負荷テストはQA／ステージングまたはテスト環境で実施されますが、時には本番環境でも行われることがあります。
どの環境であっても、多くの場合、サービスやリソースは他のユーザー（負荷テストチームだけでなく）によっても消費されていることを忘れてはいけません。
混乱や予期せぬ事態を避けるために、適切な担当者と負荷テストの実行を調整することが強く推奨されます。
これにより実際のユーザーにとってより良い体験が提供され、実際のユーザーによる操作から生じる不要なノイズを負荷テスト中に回避できます。
時には様々な理由でテスト環境が縮小され、その結果、時間とともにテスト環境と本番環境が大きく異なる場合があります。この場合、テスト環境から得られた結果は、本番環境のパフォーマンスやスケール性能とはほとんど関係がなくなります。
例えば：
a) 本番環境が高可用性アーキテクチャで展開される予定ならば、テスト環境も同様であるべきです。
b) 本番環境が500GBのベクターデータを含むエンタープライズジオデータベースを利用する予定ならば、テスト環境も同様であるべきです。
c) 本番環境が32コアのArcGIS Serversを使用し、サービスインスタンス最大数が32に設定されているならば、テスト環境も同様であるべきです。
テスト環境と本番環境を同期させておくことで、結果への期待値や価値を最大化できます。意図的に一致させない場合は、テスト開始前および結論作成時にその旨を記録してください。
初期負荷ステップとして1を使用すると、ポストテスト分析に役立ちます。
ステップ1（または1つの同時実行テストスレッド）は、最良ケースシナリオを表します。これはベースラインとなり、圧力が増加した際（例：追加のテストスレッドが加えられた時）にArcGISサービスがどれだけうまくスケールしたか理解するための良い指標となります。
- テストに関わるすべてのマシンからハードウェア使用率を収集する
ほとんどのテスティングフレームワークはサーバーおよびテストクライアント自身からハードウェア使用率を収集する機能を提供します。これはリソース消費状況やボトルネック（例：テストクライアント上のリソースも制限要因になり得る）特定に有用です。
しかし、この機能があっても権限やネットワークアクセス（例：ファイアウォール／ルーター経由接続）の問題でハードウェア使用率収集が常に可能とは限りません。
直接的な収集手段として便利ですが、それ以外にもWindowsのPerfMonやLinuxのdtstatなど無料ツールを使ってデータ取得する方法もあります。追加作業ですが価値があります。テスト完了後には手動作成したハードウェア使用率チャートデータから分析可能です。
特定のWebアプリケーションが複数のArcGISサービスを使用している場合、それぞれ個別にテストおよび調整してください。
この方法はどのサービスがボトルネックや制限要因となっているか特定しやすくします。
もしArcGISサービスがArcGIS Server上で利用可能なCPUハードウェア全体を活用できない場合、適切な担当者へ展開内で調整機会が存在すると通知すべきです。
また、多数のArcGISサービスを一度にテストすると潜在的なボトルネック発見が困難になるため、完全なアプリケーションワークフローから始めることは避けてください。
インターネット「シミュレーション」を行わないよう努めてください。展開先に物理的に近い場所でテストすることでサーバーハードウェアが提供できる性能について最良の理解が得られます。
意図的なネットワーク遅延や帯域幅不足はノイズとなり、ArcGISサービスおよびそれらが稼働しているサーバー能力全体把握を困難にします。
8時間連続で実行しなくても対象ArcGISサービスについて有用な情報は得られます。ただし短すぎる負荷試験も避けるべきです。適切な情報量となる試験時間（および各ステップ期間）選択が重要です。つまり、「良い」平均値取得に十分なリクエストサンプル数記録について考慮してください。
試験時間長さは通常応答時間と関連します。高速応答なら5分間ステップ負荷でも多くリクエスト処理可能です。遅い応答なら15分間ステップ負荷必要になるかもしれません。
初回推定ではステップ・試験期間設定が必ずしも正確にならず調整・再試験が必要になることがあります。
ArcGIS Serverログは多く情報分析可能ですが、高ログレベルVERBOSEおよびDEBUGは非常に多忙なサイトではパフォーマンス低下原因となり、本番環境設定として推奨されません。一方WARNING（デフォルト）は警告・エラーのみ記録し最高パフォーマンス提供します。
ただしFINE設定は動的リクエスト経過時間など有用分析情報と速度との良好な妥協点です。
- 従来型ArcGISサービスは(ArcGIS) Server内で調整可能
従来型（例：専用）ArcGISサービス負荷試験前または性能理解・調整前に、そのArcSOCインスタンス最大数設定値をArcGIS server上利用可能CPUコア数へ設定してみてください。
サービス再起動後、この設定によって複数同時リクエストが利用可能ハードウェア活用でき最良状態表示されます（この場合サービスはCPUバウンドと仮定）。
style="padding-left : 30px;">ArcSOCインスタンスの最大値を増やすと、サービスがより多くのCPUを利用できるようになりますが、その分、メモリも多く消費します。ArcGIS Serverマシンに調整を受け入れるのに十分なメモリがあることを確認してください。サービスの需要が高くない場合、追加のインスタンスはアイドル状態（デフォルトは1800秒）になり、サーバーメモリを解放するためにシャットダウンされます。<\/P>
同様に、サービスインスタンスの最小値を最大値に合わせて増やすことは、予測可能なパフォーマンスを得るための良い戦略です。これは最も人気のあるサービスに推奨されますが、そのような構成ではアイドル時間経過後もインスタンスがシャットダウンしないため、常にメモリ（そのサービス用）を消費することに注意してください。<\/P>
共有サービスにも調整可能なインスタンス設定があります。ただし、共有サービスが負荷テストに耐えうるほど人気がある場合は、従来の専用サービスとして実行するよう調整すべきです。<\/P>
- すべてのArcGISサービスがCPUバウンドではありません<\/STRONG><\/LI><\/UL>ArcGISサービスがCPUバウンドであるとは、そのスループット（またはサポート可能な容量）がArcGIS ServerマシンのCPU数によってのみ制限されていることを意味します。多くの場合、これは良いことです。<\/P>しかし、常にそうとは限りません。時にはネットワークなど他のハードウェアでボトルネックが発生することがあります。また、設計上または意図せずソフトウェアコンポーネントでボトルネックに遭遇することもあります。<\/P>したがって、テスト中のハードウェアメトリクスの収集は非常に重要です。CPU、メモリ、ネットワーク、およびディスクの使用状況を観察することで、ArcGIS Serverサービスのスケーラビリティを制限している要因がサーバーのハードウェアかテストクライアントかを理解するための重要な情報を提供できます。<\/P>重要なのはスループット（ユーザー数ではない）<\/STRONG><\/LI><\/UL>スループットは測定され、ユーザー数は計算されます…これらはテストから得られる異なる成果物です。<\/P>テストでは通常、スループットはトランザクション／秒（または操作／秒）として定義され、この値はテストクライアントソフトウェアによって測定されるべきものです。一方、「ユーザー」の定義はさまざまですが、多くの場合スループットから計算されます。<\/P>スループットはロードテストの結果から直接観察されるため、展開のスケーラビリティを判断するための最良の指標の一つです。<\/P>関連して言えば、テストスレッド（例：ロードテストへの負荷増加に対応して増加する項目）はユーザーとは異なります。使用されるテストスレッド数とその継続時間は通常、テストのステップロード定義で設定されます。<\/P>テストが成功したことを確認する<\/STRONG><\/LI><\/UL>テスト完了は必ずしも「良い」結果やテスト計画内の質問に成功裏に答えられたことを意味しません。正しいリクエストが送信され期待通りのレスポンスが得られているか検証・確認することが重要です。<\/P>テスト内で送信されたリクエスト構成を手動で簡単に品質管理（QC）チェックすることで前者を助けます。<\/P>平均コンテンツ長（レスポンスごと）を監視することで後者を助けます。<\/P>ほとんどのテストソフトウェアには平均コンテンツ長（または類似したもの）を取得する機能があります。この指標の平均値はテスト全体で比較的一定であるべきという一般的な経験則があります。大幅に増加または減少した場合はさらなる調査が推奨されます。期待されたレスポンスが返ってきていない可能性（例：画像やjsonコンテンツではなくエラー）があるか、有効だが大きく変動している場合は別のテスト設計が必要かもしれません。<\/P>さらに、リクエスト自体が成功しているか（例：HTTP 200）を判断することも重要です。一部のテストソフトウェアではレスポンス内で検証チェックを設定できる場合があります。それでも平均コンテンツ長メトリックのプロファイリングはサーバーから期待されるレスポンスについてより正確な見解を提供します。<\/P>テスト結果はX人のユーザーサポート保証ではない<\/STRONG><\/LI><\/UL>テスト結果はあくまでテストされたワークフローのみを検証します。このワークフローは特定タイプのリクエストに対するスループットと対応する応答時間を示しますが、その展開がX人のユーザーをサポートできることを約束または保証するものではありません。<\/P>ユーザーの定義は異なる場合があり、展開によって意味合いも異なることを覚えておいてください。<\/P>ArcGIS OnlineやGoogle Mapsなど共有リソースでのテストは避ける<\/STRONG><\/LI><\/UL>ArcGIS OnlineやGoogle Mapsから提供される無料かつ公共のサービスは「コミュニティ」のために存在します。そのようなリソースは非常に堅牢でスケーラブルですが、すべてのユーザー向けにパフォーマンスチューニングできるわけではありません。<\/P>これらはオンプレミス展開の直接的な一部ではないため、「外部」リソースと見なすべきです。その結果、それらへのリクエストはロードテストから除外し、テスト対象ハードウェア自身の能力だけに焦点を当てるべきです。<\/P>再現可能なテスト結果<\/STRONG><\/LI><\/UL>ArcGIS Serverサービスへのロードテスト結果で複数回実行時に類似した傾向線（例：同じポイント付近で同じスループット達成）が示された場合、そのリソースは一般的に「安定」と見なされます。同じ結果を繰り返せることは良い特徴です。<\/P>結果がすぐには再現できない場合、テスター／アナリストはより深く調査し、不安定な挙動の原因を理解しようと努める必要があります。それはハードウェアが他の要求（例：システム上の別ユーザー）への対応に使われていた可能性があります。また展開が共有インフラ（例：仮想化）上の場合、基盤となるハードウェアが別目的（他仮想マシンによる資源集約的タスク実行）で使用されていた可能性もあります。このような場合、ピーク時間外でロードテストを実施するとより再現性ある結果となり、そのサービスには安定性潜在力があることが示されるかもしれません。<\/P>テスト／ワークフロー設計は現実的でユーザーから期待される内容に基づくべき<\/STRONG><\/LI><\/UL>理論や予測ではなく、ユーザーがどのようにアプリケーションを使うべきか…予想されるワークフローに集中してください。ロードテスト自体は簡単ですが、不必要または起こりそうもないシナリオまで含めて範囲拡大しやすいです。
価値を理解する<\/STRONG><\/LI><\/UL>多くの場合、有用で良質なテストへの道筋自体もテストと同じくらい重要です。アナリストとしてこれらが役立ちます：<\/P>a) テスト手順を検証すること<\/P>b) 結果説明能力を最大化し、それによってあなたのテスト価値も高まります<\/P> 1) 一部個人は単なる結果だけでなく分析や結論も求めます<\/P> 2) データによってこれら結論を裏付ける準備をしてください<\/P>シンプルに保つ<\/STRONG><\/LI><\/UL>時には最も有益なテスト努力とはシンプルで過度に複雑でないものです。<\/P>
