リクエスト
サンプラーとも呼ばれます
HTTP リクエストは、テストで実行する作業の「最小」単位です。一般的に、ArcGIS Enterpriseをテストする際には、マップサービス、フィーチャサービス、ルートソルブなどのリソースのURLであることが多いですが、*.cssや*.jsファイルのような静的オブジェクトへの呼び出しであることもあります。
プロトコルはHTTP（プレーンテキスト）またはHTTPS（セキュア）であり、メソッドは多くの種類がありますが、通常はGET、POST、およびHEADが最も一般的です。
動的なマップサービスリクエストは次の形式に似ています：
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
同じURLをApache JMeter HTTPリクエストとして表したもの：
静的リクエストの例：
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeterでは、リクエストとサンプラーの区別もありますが、どちらも実行するアクションを定義しています。サンプラーとは、OSレベルでプロセスを実行し、ファイルジオデータベースを作成するジオプロセシングツールの実行や、エンタープライズジオデータベース内に新しいSDEバージョンを作成するなどのアクションを行うものです。すべてのテストには少なくとも1つのリクエストまたはサンプラーが必要です。
もう一つのタイプのサンプラーはWebSocketです。HTTPリクエストと似ており、「ウェブ」経由で呼び出しを行いセキュアにできる点は同じですが、リモートサーバーとの通信に異なるプロトコルとパラメータ指定方法を使用します。
トランザクション
トランザクションは1つ以上のhttpリクエストの論理的なグループ化です。リクエストは動的および／または静的であり、一緒にこれらのリクエストは通常1つのユーザー操作を構成します。例えば：
- ウェブアプリの読み込み
- パンやズームなどのナビゲーション操作
- 検索機能
- エンタープライズジオデータベース内で新しいSDEバージョンを作成すること
テストでトランザクションを使用することは技術的な必須要件ではありませんが、そうすることで個々の操作（例：トランザクション）を分離して、それぞれのパフォーマンス挙動を実行中に示すことができるため分析が大幅に向上します。これは非常に有益です。
例えばマップスケール1:72,224のみがパフォーマンス問題を抱えていることがわかれば、チューニング観点からどのマップドキュメントやプロジェクト領域を調整すべきか正確に把握できます。
トランザクションはこれを達成する助けとなります。
Apache JMeterトランザクションには1つの操作から3つのリクエストが含まれています：
テスト
テストプランまたはテストプロジェクトとも呼ばれます
「テスト」という用語はかなり一般的であり、名詞（例：リソース呼び出し用にテストを作成した）としても動詞（例：サービスをテストする）としても使われます。トランザクションやリクエストは通常テスト内で定義されます。テストにはさらに設定可能なオプションがあり、例えば：テスト実行時間、結果の保存先、リモートサーバー上でメトリックを収集するかどうかなどがあります。
異なるフレームワークではテスト記述用語が若干異なりますが、Apache JMeterの場合、テストまたはテストプロジェクトはTest Planと呼ばれ、*.jmxファイル拡張子で指定されます。
ステップロード
ロードとも呼ばれます
ステップロードとは、テスト中に適用する同時実行スレッド数と期間を均等かつ段階的（例：階段状）に増加させる特性です。ステップロード設定はマップサービスのパフォーマンスやスケーラビリティ、また展開資源がより多くのリクエストに対してどのように振る舞うか理解するために役立ちます。
負荷圧力はテスト終盤で減少させることも可能ですが必須ではありません。
Apache JMeter Thread Group (bzm - Concurrency)による特定ステップロードの指定と可視化：
一定負荷
一定負荷も適用するスレッド数と期間を定義しますが、多くの場合長時間安定したレートで設定されます。この設定はパフォーマンスやスケーラビリティよりも耐久性や安定性理解に主眼があります。
Apache JMeter Thread Group (bzm - Concurrency)による特定一定負荷の指定と可視化：
テストスレッド
スレッドとも呼ばれます
これは負荷を適用する仕組みであり、トランザクションやリクエストなどテスト内で定義された作業を繰り返し実行します。
テストスレッドは通常直列動作し、それぞれ最初にテスト内で定義された最初のリクエストを読み込み、それをサーバーへ送信し応答を待ちます。次のリクエストはサーバーから応答が返るかタイムアウトになるまで発行されません。この条件が満たされると次のリクエストへ進みます。ほとんどのテストでは各スレッドがこの処理を実行時間中ずっと繰り返すよう設定されています。
様々な技術ではテストスレッドを仮想ユーザーと呼ぶことがありますが誤解を招く場合があります。テストスレッドは単なる手段（負荷）であり目的（達成されたスループット）ではありません。
つまりステップロード設定で100スレッドになったからといって環境が100人同時仮想ユーザーを支えているわけではありません。この場合ユーザー数判定はトランザクション／秒などスループットから計算されます。
Apache JMeter Thread Group (bzm - Concurrency)によるステップロード指定（テストスレッド経由）：
ユーザー
仮想ユーザーとも呼ばれます
サポート可能なユーザー数は負荷試験で最もよく求められる項目の一つであり、多くの場合以下の形になります：
- この特定サービスまたはアプリケーションはいくつユーザーをサポートできますか？
- 特定サービスまたはアプリケーションは少なくともXユーザーをサポートできますか？
ユーザー数計算はシンクタイムおよび測定された試験成果物（例：スループット）と密接に関連しています および応答時間。
これらの入力を使用したLittle Lawは、環境がサポートできるユーザー数の理論的な推定を提供できます。<\/P>
Think Time<\/STRONG>
ワークフローペーシングとも呼ばれます<\/STRONG><\/EM><\/H5>Think timeは、マップサービスやウェブアプリケーションと自然に対話する人間の行動による遅延をシミュレートするためにテストに追加される期間（秒またはミリ秒で定義）です。
Think timeの遅延は、トランザクション（例：操作）やリクエスト、さらにはテスト自体（これがワークフローペーシングと呼ばれます）に追加できます。追加方法は使用されるテストフレームワークによって異なる場合があります。
Apache JMeterの場合、さまざまな種類の遅延をシミュレートするためにテストに追加できる複数のタイマーがあります。<\/P>Key Performance indicators (KPIs)<\/STRONG><\/H5>KPIはロードテストの分析を支援するテストメトリクスです。最も一般的なもののいくつかは、テストの応答時間とスループットの測定に関連しています。ただし、失敗したリクエストの数をカウントしたり、平均コンテンツ長（リクエストごと）をカウントしたり、ハードウェア利用率（CPU、メモリ、ネットワーク、ディスクなど）の情報を収集したりする項目にも及びます。
ハードウェア利用率をキャプチャする能力は通常、追加のテスト構成と環境内の権限を必要としますが、この情報はロードテストから取得される最も重要な成果物の一つです。<\/P>注意: キャプチャされたハードウェア利用率はロードテストから取得される最も重要な成果物の一つです。<\/FONT><\/STRONG><\/P>Response Time<\/STRONG><\/H5>応答時間は、リクエスト、トランザクション、またはテストのパフォーマンスを測定するために使用される一般的なメトリクスです。簡単に言えば、操作がどれだけ速く動作しているかを理解するためのものです。
値は通常秒またはミリ秒で表示されます。パフォーマンスが速いほど応答時間が短くなり、それがより良好なユーザー体験につながります。応答時間はテスト期間中にプロットしてパフォーマンスのスケール変化を理解したり、特定のポイント（例：スループットがピークに達した場所）でスループットと一緒に一覧表示したりできます。<\/P>注意: 応答時間はロードテストから取得される最も重要な成果物の一つです。<\/STRONG><\/FONT><\/P>理想的には、テスト対象アイテムのパフォーマンスは以下の曲線を描きます。この曲線では応答時間がピークスループット付近で急速に上昇します。以下の例では、ピークスループット時の平均リクエスト応答時間は約0.4秒でした。<\/P>
<\/span><\/P>Throughput<\/STRONG>:<\/H5>スループットはマップサービス、ウェブアプリケーション、またはハードウェアインフラストラクチャのスケーラビリティを測定するために使用される一般的なメトリクスです。本質的には、一定期間内に操作が実行できる速度を理解するためのものです。
値は通常requests\/sec、transactions\/sec（例：operations\/sec）、またはtests\/secとしてキャプチャされますが、多くの場合1時間あたりで表現されます（秒あたりレート×3600）。
スケーラビリティが高いほどスループットが増え、それがより多くのユーザーサポートにつながります。
一部のテスト分析ではテスト全体のすべてのトランザクションの平均スループットに焦点を当て、一方で他は各個別操作ごとの平均スループットを調べることがあります。<\/P>注意: スループットはロードテストから取得される最も重要な成果物の一つです。<\/STRONG><\/FONT><\/P>理想的には、テスト対象アイテムのスループットは以下の曲線に似ており、一旦ピークに達すると横ばいになります。 <\/SPAN>スループットがピークまたは横ばいになると、そのテストが何らかのボトルネックに遭遇したことを示唆します。 以下の例ではピーク時の平均リクエストスループットは約24 requests\/second（または86,400 requests\/hour）でした。<\/P>
<\/span><\/P>Bottleneck<\/STRONG><\/H5>ボトルネックとは、展開環境内でそのコンポーネントまたは階層のいずれかが受信リクエストへの応答速度を制限している状態です。ボトルネックには以下のような形態があります:<\/P>ハードウェア例ArcGIS Server のすべてのCPUコアが完全に使用されている<\/LI>利用可能なメモリが枯渇している<\/LI>データベースサーバーのストレージディスクI\/Oが完全に使用されている<\/LI>ネットワークカードが飽和している送信または受信トラフィックによるもの <\/LI><\/UL><\/LI><\/UL><\/LI>ソフトウェア例十分なハードウェア資源があるにもかかわらずデータベースが同時接続25件のみ許可するよう設定されていた<\/LI>マップサービス消費時のスループットが横ばいになるがArcGIS Server CPU利用率は25%を超えない<\/LI><\/UL><\/LI><\/UL>ボトルネックは展開環境には常に存在し、そのうちどれが最初に制限要因となるかを特定することが分析の一部です。大きな負荷下でのみ観察される場合もあるため、最初のボトルネック箇所を明らかにするにはロードテストが必要になることがあります。サーバー資源や設定がボトルネック分析で通常注目されますが、テストクライアント資源（CPU、メモリ、ネットワーク、ディスク、および場合によってはtesting license）も要因となり得ます。ボトルネック到達自体は必ずしも問題ではなく、それによってシステム内で最初に弱点や制限箇所がどこか分かります。場合によってはボトルネックは「良いこと」と見なされることもあります。例えば大規模なArcGISキャッシング処理ではCPUが最初のボトルネックになることが望ましいです。それによってマップタイル作成作業をCPUが行っていることになるからです。他方で別のボトルネック（例：ディスクI\O）が原因でCPU使用率が50%までしか上昇しない場合、そのジョブ完了まで100% CPU使用時より2倍時間がかかります。<\/P>注意: ボトルネックは展開環境には常に存在します<\/STRONG><\/FONT><\/P>Test Type<\/STRONG>
パフォーマンステスト、load test、stress test、endurance test、benchmark testとも呼ばれます<\/STRONG><\/EM><\/H5>多くの組織では実施しているテストを分類するために異なるカテゴリを使用します。<\/P>パフォーマンステストは通常、サービスやアプリケーションが遅く動作している場合や予想より長い応答時間を生じている問題解決に利用されます。この種のテストではステップロードを伴う必要なく、一人ユーザーによるウェブブラウザから直接対象エンドポイントへの操作として簡単に実行できます。<\/P>load test は特定スループットおよび応答時間目標達成を目的としたステップロードテストとして説明されることがあります。例えば X transactions/sec<\/> を Y秒未満 の応答時間で失敗なしで達成するなどです。この場合サーバーハードウェア資源枯渇につながることもありますが、それ自体が目的ではありません。また load test は scalability test と呼ばれることもあります。<\/P>stress test は類似したテストですが、多くの場合 load test の目標負荷よりさらに高い負荷到達を目指します。つまり load test が X transactions/sec を目指すなら stress test は X * 5 transactions/sec を大きな失敗なく達成しようとします。<\/P>endurance test はシステムコンポーネント破壊を 試みる 特徴があります。その適用負荷は stress test の複数倍となり、大きなエラー発生とそれら発生時点でのスループットおよび応答時間観察を目的とします。また endurance test は durability test とも呼ばれ、その場合適用負荷は非常に長期間一定でありハードウェア利用率および回復パターン観察も含みます。<\/P>Test Plan<\/STRONG><\/H5>一般的にはテストプランとはドキュメントや表形式 または、実行される特定のテストとそれぞれの目標を定義するリスト。これらの目標は各テストの理由と目的です。結果の分析（手動または生成されたテストレポートから）は、各テストの目標が達成されたかどうかを判断するのに役立ちます。<\/P>Testing Framework <\/STRONG><\/H5>Testing Framework は、ライブラリ、API、およびリクエストの組み立てやテスト、適用する負荷の定義のためのグラフィカルユーザーインターフェース（GUI）の形で使用されるツールまたは技術です。
優れた Testing Framework は多数存在し、その中で Apache JMeter はそのうちの一つ<\/EM>に過ぎません。目的はすべて似ていますが、多くは特定のコンポーネントの語彙やテスト作成および負荷適用方法に異なるアプローチを取っています。いくつかはリクエストとトランザクションの定義を独自のファイルに分け、ステップロード構成を別にしています。
Apache JMeter では、すべてのテストオブジェクトが Test Plan に定義され、ツリー内で論理的に分離されています。<\/P>いくつかの負荷テストフレームワークの例:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>いくつかのパフォーマンステストフレームワークの例:<\/P>
wget<\/A>- 1つ以上のURLを取得するためのコマンドラインツール<\/LI>
- 各リクエストとレスポンスに関して高い詳細レベルを提供可能<\/LI><\/UL><\/LI>
curl<\/A>
- 1つ以上のURLを取得するためのコマンドラインツール<\/LI>
- 各リクエストとレスポンスに関して高い詳細レベルを提供可能<\/LI><\/UL><\/LI>
Fiddler<\/A>- 単独でもウェブブラウザと併用でも使えるGUIベースのHTTPデバッガー<\/LI>
- 各リクエストとレスポンスに関して高い詳細レベルを提供可能<\/LI><\/UL><\/LI><\/UL>
Testing Framework Architecture<\/STRONG><\/H5>ArcGIS Enterprise のテストでは、アーキテクチャ上の注目点は主に展開層（Load Balancer、Web Adaptor、Portal for ArcGIS、ArcGIS DataStore、ArcGIS Server、Enterprise Geodatabase、および Network Storage）のスケーラビリティに集中します。通常、8コアのテストマシン1台で典型的なテストに十分な数のリクエストを送信できますが、適用する負荷が大きい場合は複数台が必要になることもあります。<\/P>使用する Testing Framework によっては、複数のテストコンポーネントを別々のマシンに分離して test client<\/EM> のスケーラビリティを向上させることができます。<\/P>一般的にスケールアウトされるコンポーネントは以下です:<\/P>Test Controller名前が示す通り、コントローラーの主な役割はテストを開始・停止し、1台以上の Test Agent からテストメトリクス収集を調整することです。<\/LI>Apache JMeter の場合、コントローラーは GUI に統合されていますが、コマンドラインから実行される際にも動作しています。他の Testing Framework ではウェブベースの Test Controller フロントエンドがある場合もあります。<\/LI><\/UL><\/LI>通常、任意のテスト環境には1つだけ Test Controller が必要ですが、それは Test Agent とは別の専用ハードウェア上で動作させることも可能です。<\/LI><\/UL><\/LI>Test AgentTest Agent の主な仕事はサーバーへのリクエスト送信とレスポンス受信です。このコンポーネントが最も多く作業を行い、最も多くCPUリソースを必要とします。<\/LI><\/UL><\/LI>大規模なジョブの場合は複数台の Test Agent マシンが必要になることがあります。<\/LI>Apache JMeter の場合、デフォルトで Test Agent は Test Controller と同じマシン上で動作します。<\/LI><\/UL><\/LI>Test Repository負荷テスト結果を保存する専用マシンです。応答時間、スループット、ハードウェア利用率などのテストメトリクスを含むことがあります。<\/LI><\/UL>Apache JMeter の場合、結果はコントローラー上にテキスト（*.JTL）ファイルとして保存されます。結果をデータベースに送信することも可能ですが、それはデフォルトではありません。<\/LI>Test Visualizationリアルタイムでテストメトリクスやハードウェア利用率を可視化するために使用されるマシンです。<／Li>Apache JMeter の場合、本番テスト実行時には GUI はデータ可視化には推奨されずコマンドラインが推奨されます。結果がデータベースに送信された場合は追加ソフトウェアが Test Repository に接続して情報を可視化できます。<／Li>Interactive Response Time Law<／STRONG>
Interactive Response Time Law はユーザー数、スループット、応答時間、およびユーザー思考時間という主要なパフォーマンス要因間の関係を定義する式です。この計算式は他の3つがわかれば関心あるパラメータを求めるように変形できます。例えばシステム利用ユーザー数、平均応答時間、および平均ユーザー思考時間がわかれば、そのシステムへの推定スループット要求量を導き出せます。この法則はユーザー数からスループットへおよびスループットからユーザー数への変換やその他多くの場合に非常に有用であり、キャパシティプランニングなどテスト関連分野で基礎となります。<／P>
以下の式によります:
N = X * (R + Z)<／P>
N = ジョブ数または同時ユーザー数
X = システム内秒あたりスループット
R = 応答時間またはジョブがシステム内で過ごす平均時間
Z = 思考時間
Interactive Response Time Law の詳細については以下をご覧ください:<／P>
<／P>
<／P>
Apache JMeter は <／SPAN>Apache License 2.0.< / A > Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation.< / SPAN >< / P >
