ホストされた Feature Layer サービスに対する Apache JMeter での負荷テストの作成（中級／上級）

AaronLopez

なぜHosted Feature Layer Serviceをテストするのか？

これまでのApache JMeterを用いたパフォーマンステストに関するコミュニティ記事は、エクスポート機能を通じてMap Servicesを操作することに焦点を当てていました。しかし、Hosted (feature) layersもArcGIS Enterpriseの人気機能であり、展開で広く使用されています。さらに、これらのレイヤーへのクエリは「繰り返し」グリッド設計に基づいており、他の可視化技術よりも高いスケーラビリティを提供するのに役立ちます。これに加え、返されたデータのクライアント側レンダリングが組み合わさることで、双方にとって有利な結果となります。

Hosted feature servicesは実績があり好まれているサービス技術であるため、負荷下でのfeature queriesをテストしてそのスケーラビリティを直接観察したいというのは理にかなっています。

Hosted Feature Layer Serviceテストの課題

エクスポートマップ機能のテストと比較すると、Hosted Feature Layer Serviceクエリのテストはプログラム的に実現するためにリクエストがより複雑です。ウェブブラウザでのナビゲーション「パン」や「ズーム」は、それぞれ独自のジオメトリを持つ複数の異なるクエリを生成します。この動作を繰り返すために構築される負荷テストでは、一つのリクエストだけでなく多くかつ変動する数のリクエストが発行されます。さらに、トランザクション内の各クエリリクエストはユニークなジオメトリとマップスケールに応じて変化するmaxAllowableOffsetを持つため、多くの動く要素を管理しなければなりません。

Hosted Feature Serviceをどのようにテストするか？

USGS Motor Vehicle Use Roads Dataset

この記事のプロセス理解は手順を再現できる場合に最も効果的です。しかし、この再現性には同じデータセットへのアクセスが必要です。データソースの空間サイズは適度なテストデータを生成できるほど大きく、ダウンロードが煩雑にならない程度である必要があります。

ここで紹介するのはMotor Vehicle Use Map: Roads feature layer dataset on hub.arcgis.comです。WGS 1984 Web Mercator (Auxiliary_Sphere)座標系で179K本のポリラインレコードからなるUSGS Roadsデータは、圧縮時約200MBになります。これはCreative Commons (CC0)ライセンスで提供されています。

• ArcGIS ProによるRoadsデータ表示例：

• ラベル表示有効時の大縮尺ビュー：

このデータはArcGIS ProからArcGIS Enterprise上のhosted feature serviceへ公開されるか、Portal for ArcGIS経由で直接ロードされます。

• このデータからサービスを作成するには、ArcGIS Enterprise内のPublish hosted feature layersをご参照ください。

テストデータ生成

このテストではJMeterテスト内で使用する良質なテストデータが必要です。

このようなタスクには非常に優れたLoad Testing Toolsの使用を強く推奨します。

バージョン1.2.2では「Generate Query Extents」ツールなど新機能が追加されており、feature serviceテストデータ生成に大いに役立ちます。

このデータはグリッドベース設計を利用しており、これが我々が求めるものです。グリッドベース方式では、対象領域用のエンベロープが裏側で作成され、それらが適切な512x512クエリエクステントへ変換されます。各初期エンベロープごとのクエリ数はグリッド上の位置によって異なり…これはウェブブラウザ内サービス動作を模倣しています。

ArcGIS Proからツールを利用可能にする方法

一度load-testing-tools プロジェクトをマシンにダウンロードしたら、解凍したフォルダーをArcGIS Proからアクセス可能またはアクセス可能になるディレクトリに配置してください。既存バージョンがインストール済みの場合、この更新版は別名フォルダーとして並行インストール可能です（または既存フォルダーと完全置換も可能）。

例：

• C:\Users\[username]\Documents\ArcGIS に load-testing-tools フォルダーを配置
• ArcGIS Pro のカタログから「Add Folder Connection」を使い、このディレクトリ内容を一覧表示

「Generate Query Extents」ツールはhosted feature service、ローカルコピー、またはenterprise geodatabase内データから動作可能です。

注意：ツールは任意データからクエリエクステント生成可能ですが、投影座標系はWGS 1984 Web Mercator Auxiliary_Sphere (WKID: 3857)である必要があります。

関心領域（Area of Interest）選択

テストデータ生成用に地図上から関心領域を選択します。この例では北西アメリカ合衆国（アイダホ州とモンタナ州境付近）からRoadsデータが表示されています。選択されたマップスケールは1:1,000,000です。

Generate Query Extentsツール実行

• Generate Query Extentsツール実行時には以下に類似した入力画面が表示されます：

Generate Query Extentsツール入力調整

デフォルト入力値は以下のように調整しました：

• いくつか小さいおよび大きいスケールレベルを除外
• 残ったスケールレベルは12, 13, 14で、それぞれマップスケール144448, 72224, 36112に対応
  • これらスケールレベルごとのレコード数を増加
  • Load Testing Toolsのバージョンによってはスケールレベル14が無い場合があります（無ければ手動追加してください）
• ファイル出力先は以下例のようになります：
  • C:\Users\username\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
• 「Run」をクリックしてツール実行

注意：テストデータ生成時間は複数要因（異なるスケールレベル数、各スケールレベルごとのレコード数、およびプロジェクト現在マップスケール）によって変わります。

注意：他データセット使用時には詳細度やフィーチャ密度によって異なるスケールレベル使用が必要になる場合があります。

生成されたテストデータ検証

生成されたテストデータを視覚的に検証することは良い習慣です。これによりテスターは負荷テスト中にfeature serviceへ空間的にどんな要求が行われるか把握できます。

ツールが正常完了すると生成されます 3つの主な関心のあるデータセット:<\/P>

• Bounding box feature classes
  • ランダムに生成された関心領域を含む<\/LI>
  • 要求された各Scale Levelごとに1つのfeature class<\/LI><\/UL><\/LI>
  • Query Extent feature classes
    • 各feature queryが基づく(512x512)タイルグリッドを含む<\/LI>
    • 要求された各Scale Levelごとに1つのfeature class<\/LI><\/UL><\/LI>
    • Query Extent CSV files
      • 生成されたテストデータを含む<\/LI>
      • 各行はfeature serviceリクエストの動的コンポーネントで構成される<\/LI>
      • 要求された各Scale Levelごとに1つのファイル<\/LI><\/UL><\/LI><\/UL>

        <\/span><\/P>Catalogパネルから、bbox_36112 feature classをArcGIS Proの現在のマップに読み込むこの出力はGenerate Bounding Boxesツールのデータと非常に似ている<\/LI><\/UL><\/LI>この例では、ランダムに生成されたボックスはピンク色で表示されるこれらの領域はfeature serviceからデータを要求するユーザーの画面解像度を表す<\/LI><\/UL><\/LI><\/UL><\/span><\/P>次に、Catalogパネルからquery_extents_36112 feature classを現在のマップに読み込むが、bbox_36112データの後ろ（下）に配置する<\/LI>この例では、query tile gridボックスは緑色で表示されるこれらのタイルはbboxesがデータを要求している地図上の領域に対応している<\/LI><\/UL><\/LI><\/UL><\/span><\/P>地図をズームインすると、これら2つのデータセット間の関係がよりよく理解できる<\/LI>下記の地図で見られるように、一部のbboxesはわずかにずれているが、それでも下のグリッドから共通のquery tileを共有している<\/LI>これらquery tiles（例：query_extent feature class）の座標がCSVファイルに入り、最終的にはJMeter load testに使用される<\/LI><\/UL><\/span><\/P>bboxesを詳しく見ると、それぞれのquery構成の詳細が明らかになる例えば、一部のbboxesは12個の「基礎となる」タイルを必要とし、他は15個または20個必要とする場合がある<\/LI>下記地図で見られるように、黒でハイライトされたbboxは赤色で示された12個の特定query tilesを必要としている<\/LI><\/UL><\/LI><\/UL><\/span><\/P> 注意: feature serviceのタイルグリッド設計は、その繰り返し可能性という重要な強みの一つです。この繰り返し可能性は、展開時のキャッシュによってスケーラビリティ向上に活用できます。これはexport mapでは不可能です。<\/STRONG><\/FONT><\/P>生成されたCSVファイルを調べることで、この変換結果が明らかになる<\/LI>テキストエディタでquery_extents_36112.csvファイルを見ると以下に似た内容が表示されるはずLoad Test Toolsのリリースによっては、CSVファイルがoperationid列でソートされている場合がある<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Load Testing Toolsのリリースによっては、行がoperationid列でグループ化されている場合とそうでない場合がある<\/LI>operationidの理解は重要なテスト概念であり、各operationはナビゲーションアクション（例：パンやズーム）を表す<\/LI>JMeterから見ると、operationはtransactionと同じ意味である同じoperationidを持つすべての行は同じtransaction controller下でfeature service query requestジオメトリになる<\/LI>

  ホステッドFeature Service Query Test Plan <\H1>
  
  
  この記事で使用したApache JMeter Test Planをダウンロードするには: <\span>
  
  roads_hfs1.zip
  
  

• 
  Apache JMeterでTest Planを開くと以下のようになる:
  • User Defined Variablesを環境に合わせて調整する
    • ツールから生成された3つのCSVファイルはJMeter変数DataFile_A, DataFile_B, DataFile_Cによってファイル名のみ参照される（ファイルシステムパスは含まれない）

Test Plan のコンポーネント

Data Reader Logic

roads_hfsテストは以前の記事で使われた他のApache JMeterテスト例とは少し異なるものです。主な違いは、依然としてデータ駆動型テスト（例：CSVファイルがリクエスト入力に使われる）ですが、通常使われる「CSV Data Set Config」Config Elementオブジェクトを使ってデータを読み込んでいないことです。代わりに、このロジックはGroovyコードを実行するJSR223 Samplersによって行われています。Groovyが使われている理由は前述したfeature serviceとのやり取りの性質によります。取引によって12件リクエストするものもあれば15件や20件の場合もあります（全体的な関心領域がタイルグリッド上どこに位置するかによります）。このリクエスト数の違いから、CSVファイルから読み込み利用するためにはより柔軟なメカニズムが必要となり、それゆえこの方法が採用されています。

• 各CSVファイル（例：各地図スケール）ごとに1つJSR223 Samplerがある
  • データ読み込み用JSR223 Samplers全てはOnce Only Controller内に置かれオーバーヘッドを最小化している
    • CSVファイル読み込みは各テストスレッド開始時に一度だけ実行される
• 以下に示す「JSR223 Sample A1」はquery_extents_72224.csvファイルを読み込む
  • Groovyコーディング経験はこのテスト実行には必須ではなく、これらJSR223 Samplersを書き換える必要もないが、CSVデータ読み込みロジック理解には役立つ

Operation ID Selection Logic

CSVデータ読み込み後、テストでは各スケールごとに毎回テスト反復時にoperation idを選択する必要があります。これを実現するため、第2セットのJSR223 Samplersがそれぞれ操作リストから選択します。

• 各地図スケールごとにランダムにoperation idを選ぶJSR223 Samplerがある
  • このoperation id生成用JSR223 Samplers全てはOperation GeneratorというTransaction Controller内に置かれている
    • これは各テストスレッド反復ごとに実行される
      
    • これらJSR223 Samplersを書き換える必要なくテスト実行可能
      

color="#FF0000">注意: Groovyを使用したJSR223 Samplersは一般的に高速に実行され、テストにほとんどオーバーヘッドを追加しません。<\/STRONG><\/FONT><\/P><\/span><\/P>操作ループとパラメータの設定<\/H3>操作IDが選択されると、焦点はループロジックになります。ここでテストはトランザクションを構成するフィーチャサービスクエリの数を検索します。そこから、3番目のJSR223 Samplersセットを使用して、ループ内の各イテレーションで前に選択された操作IDに関連付けられたリクエストパラメータを設定します。 <\/P>各地図スケールごとに1つのJSR223 Samplerがあり、操作IDとイテレーション値に基づいて関連するJMeter変数を設定しますこれらの項目はその後、HTTP Requestによって取得されるキー/バリューペアになります<\/LI>イテレーション値はCounter Config Elementによって追跡されます<\/LI>これらのJSR223 Samplersはテスト実行のために編集する必要はありません<\/LI><\/UL><\/LI>各Loop Controller、Counter、JSR223 Sampler、およびHTTP Requestオブジェクトはすべて対応するTransaction Controller内に配置され、各地図スケールの項目を論理的に分離します<\/LI><\/UL><\/span><\/P>HTTP Request<\/H3>本質的に、上記のすべてのテストロジックはこのテストコンポーネントのためだけに存在します。ここで、JMeter HTTP Requestオブジェクトは直前のJSR223 Samplerによって設定された特定のキー/バリューのJMeter変数を読み取ることができます。<\/P>このアプローチは非常にプログラム的であるため、地図スケールごとにHTTP Requestは1つだけです！この設計は保守性を重視しています。<\/P><\/span><\/P>注意: このテストアプローチは従来型の非ホスト型フィーチャレイヤサービスにも適用可能です。ただし、これらのフィーチャサービスにはmaxAllowableOffsetやquantizationParametersなどホスト型サービス特有のリクエストパラメータ最適化がありません。これらのオプションはHTTP Requestから削除する必要があります。<\/STRONG><\/FONT><\/SPAN><\/P>スレッドグループ構成<\/SPAN><\/H1>JMeter Test Planは現在10分間という比較的短いテスト用に構成されています。一般的にホスト型フィーチャサービスは良好なパフォーマンスを示すため、各ステップ（1分間）および全体のテストで多くのスループットが発生します。<\/P>異なる環境やデータでは望ましいテスト結果を得るために別の設定が必要になる場合がありますので、必要に応じて調整してください<\/LI><\/UL><\/span><\/P>テストプランの検証<\/H1>ベストプラクティスとして、本格的な負荷テストを実行する前に戻ってくる結果を検証することが常に推奨されます。<\/P>View Results Treeリスナーを使用して検証を支援するTest PlanにはView Results Tree Listenerが含まれていますがデフォルトで無効になっています有効化して結果を表示してください<\/LI><\/UL><\/LI><\/UL><\/LI>GUIからテストを開始してください<\/LI><\/UL>トランザクション <\/H2>「HFS」トランザクションのいずれかを選択結果は以下のようになるはずです:<\/LI><\/UL><\/LI><\/UL><\/span><\/P>この例では、上記リストされたトランザクション：HFS (mapscale: 72224)、HFS (mapscale: 36112)、および HFS (mapscale: 144448) はすべて成功裏に完了しました。
成功しましたSampler結果にはさらに詳細が記載されています。
各トランザクションはフィーチャクエリエクステントごとに1つのHTTPリクエストを送信しましたが、JMeterテストではSamplerも操作の一部としてカウントしています。
JSR223 Samplersはトランザクションへのオーバーヘッドが非常に少ないですがサンプル数は倍増します。これは単なる注意点です。
サイズ（バイト）をざっと確認してください
この例ではトランザクションサイズが約65KBであり、一部データが返されていてレスポンスが「空」ではないことを示唆しています。
リクエスト「HFS」トランザクションのいずれかを展開してください
httpsリクエストのいずれかを選択してください結果は以下のようになるはずです:



この例ではselectリクエストが成功裏に完了しました。




サイズ（バイト）をざっと確認してください




この例ではリクエストサイズがおよそ5KBであり、一部データが返されていてレスポンスが「空」ではないこと（例：1500バイト）を示唆しています。






ContentTypeも重要です




Test Plan内のパラメータによると、要求されたフォーマットはpbfであり、これはapplication/x-protobufを返します。




プロトコルバッファーで要求することはペイロード最適化というベストプラクティスです。




結果として得られるフォーマットはバイナリであり、このドキュメントで扱わない追加ツールなしには簡単には閲覧できません。









注意: フィーチャサービス（ホスト型フィーチャサービス含む）はクライアント側でレンダリングされます（export map のようなサーバー側ではありません）。Apache JMeter は（テスト）クライアントですが、ウェブブラウザのようにJavaScript経由でサーバーレスポンスをレンダリングしません。
テスト実行
負荷テストは通常のJMeter Test Planと同様に実行してください。
roads_hfs1.zip プロジェクトに含まれる runMe.bat スクリプトをご覧ください。これはApache JMeterチーム推奨のテスト実行例です。

runMe.bat スクリプトには jmeterbin 変数が含まれており、ご利用環境に合わせて適切な値に設定する必要があります。

注意: 負荷テスト開始時間と期間については関係者と必ず調整してください。これによりユーザーやArcGIS Enterprise Site を利用する他の同僚への影響を最小限に抑えられます。また他活動によるシステムノイズ(system noise) が発生しテスト結果が「汚染」されることも防げます。
JMeter レポート
スループット曲線

自動生成されたJMeterレポートは負荷下でのHFSトランザクションのスループット洞察を提供します。
非HFSトランザクションは手動で除外されています。
このケースではHFS操作のピークスループットがおよそ16.5 トランザクション/秒でした。

3つのHFSトランザクションがあるため合計すると約50 トランザクション/秒（または178,200 トランザクション/時）となります。



注意: 各HFSトランザクションはそれぞれ同じ重み付けで実行されたため自然と類似したスループットになります。 この場合、すべてのスケールにおけるHFSトランザクションはサブセカンド（1秒未満）でした。テストの終盤、最も負荷が高い時でも、平均応答時間は225ミリ秒（0.225秒）未満でした。<\/LI><\/UL><\/LI><\/UL><\/span><\/P>最終的な考察<\/H1>ホストされたフィーチャ レイヤー サービスのクエリをテストする他の方法として、エンドポイントやアプリケーションと対話しながらウェブブラウザからキャプチャしたトラフィックを通じて行う方法があります。これによりサービスURLのリストが生成され、それをテストに変換することが可能です。しかし、本記事で示したようなプログラム的アプローチは、キャプチャトラフィック方式では実際的に行えないほど多くの範囲をカバーする広範囲な空間領域のサービスをテストする戦略を提供します。<\/P>プログラム的アプローチはまた、テストプランのサイズがはるかに小さいため、メンテナンスも容易です。視点を変えると、本記事に含まれるJMeterテストは3つのHTTPリクエスト（各マップスケールごとに1つ）だけで構成されています。 <\/P>本記事で使用したApache JMeter Test Planのダウンロードはこちら: roads_hfs1.zip<\/A><\/STRONG><\/LI>本記事で使用したNatural Earthデータのサブセットのダウンロードはこちら: Motor Vehicle Use Map: Roads (Feature Layer)<\/A><\/STRONG> <\/LI><\/UL>

 <\/P>

 <\/P>

 <\/P>

Apache JMeter<\/A> は <\/SPAN>Apache<\/A> の下でリリースされています。<\/SPAN>License 2.0.<\/A> Apache、Apache JMeter、JMeter、Apacheフェザー、およびApache JMeterロゴはApache Software Foundationの商標です。<\/SPAN><\/P>

AaronLopez

Hi @StevenBeothy 

I think that test plan is valid and a good programmatic way to get a performance profile from each of the layers

However, there are a few items worth mentioning:

• My roads_hfs test requested * for the outFields
  • This is fine but can be considered aggressive, especially if the tables are "wide" (e.g., 50 or more attributes)
  • In that case, I would consider maybe asking for a few specific attributes (e.g., OBJECTID plus one or two others)
  • But, that assumes the requested attributes exist in all the layers
    • This is why using * is so easy
• My roads_hfs test was build around using hosted feature service queries (e.g., where resultType=tile)
  • I am a huge fan of the feature tiles and their data structure lends itself to efficient querying (repeatable extents for better caching, more predictable quantization tolerances for each of the layers)
  • A resultType of say standard would be similar but the test logic would be different (and in my opinion, more complex)
    
    • Additionally, requests with resultType=standard can ask for varying numbers of records being returned (through the use of the resultRecordCount and resultOffset parameters)
      • This adds variance and test complexity...which again is why I like testing with resultType=tile

To reiterate, I think your approach is good and resultType=tile style tests are a great way to consume a feature service.
I bring up these other items to give my opinion and perspective on what your test is doing and how its asking for the data...as well as the potential test logic impacts when asking for feature data when the resultType is not tile.

Hope that helps.