Benchmark ArcGIS Enterprise...元のアプローチ
しばらく前に、事前構成されたApache JMeterテストを使用してNatural Earthデータセットを用いてArcGIS Enterpriseの展開をベンチマークすることについて話しました。そのテストの結果は、他の展開からの実行と比較して、基盤となるハードウェアのパフォーマンスとスケーラビリティ特性の比較的なアイデアを得ることができました。このアプローチにはいくつかの利点がありました:
- Natural Earthは無料のGISデータです
- 低〜中程度のデータ複雑性（扱いやすい）
- テストプランにはスケーラビリティ能力を観察するためのステップロードが含まれていました
有用で良い指標ではありましたが、スケーラビリティコンポーネントは通常テストが長時間実行されることを意味し（これもいくつかの複雑さを加えました）、私はArcGIS Enterpriseを通じて処理ハードウェア（例：CPU）だけをベンチマークする簡単な方法があるかどうか疑問に思っていました:
- JMeterをパフォーマンスのみの視点で使用することは可能か？
- 基盤となるFGDBやエンタープライズジオデータベースデータセットなしでArcGIS Enterpriseをベンチマークするテストを作成できるか？（これにより全体的な作業が簡素化されるはず）
結果は「はい」でした！
Benchmark ArcGIS Enterprise...別のアプローチ
さて...半分本当の話をしています。新しいベンチマークテストはFGDBやeGDBデータセットベースのサービスに依存しませんが、いくつかのデータは必要です。シンプルに保つために、データ（例：事前生成されたジオメトリ）は単純にJMeterサンプル要素を通じて、背後に参照されたデータセットがないArcGISリソースに渡されます。
では、これはどのように行われるのでしょうか？
信頼のおけるGeometry serviceを通じて。ArcGIS Serverのジオメトリサービスは、多くの幾何学的操作を実行するための機能へのアクセスを提供する組み込みリソースです。これらの操作（バッファや一般化など）の計算は、要求内容によって単純または複雑になることがあります。パフォーマンス分析者の視点から見ると、ArcGIS Serverを実行しているマシンのCPUハードウェアをベンチマークするための素晴らしい手段を提供します。
注意: ArcGIS Enterpriseという用語にはArcGIS Serverも含まれますが、このベンチマークは主に後者（例：ArcGIS Server）を対象としています。一部トラフィックはArcGIS Web Adaptor経由で流れ、Portal for ArcGIS認証も少量発生しますが、設計上、大部分の処理はArcGIS Serverによって行われます。
Geometry service使用の利点
Geometry serviceはArcGIS Server 9.3以降存在しており、そのため普及しています。これにより、それを利用したテストは簡単で信頼性があります。テストを駆動するデータがリクエスト内のキー／バリューペアに入っているため、持ち運びも容易です（例：持ち運ぶべきデータセットなし）。
注意: Geometry serviceは長い間ArcGIS Serverに含まれていますが、デフォルトではオフで実行されていません。テスト実行前にサービスを起動し、適切なPortal for ArcGISメンバーに共有する必要があります。
The Geometry_Functions_Benchmark テストプラン
- Apache JMeterでテストプランをダウンロードして開くと以下のようになります:
どんな種類の関数をテストすべきか？
ベンチマークとしては答えは少数です。この特定のテストプランではいくつか異なる操作のみ呼び出します...さらに同じ操作でも異なる方法で（例：意図的に異なる応答を得るためにリクエストパラメーターを変更）呼び出します。これにより可変性が提供され、同じことばかり繰り返すわけではありません。
以下はこのベンチマークで使用される操作です:
期待されるテストおよび操作パフォーマンス
このテストには高速で実行される操作もあれば、より時間がかかるものもあります。この速度はハードウェアによって異なります。最終的には、ArcGIS Enterprise（例：Server）が数分間だけ動作し処理性能の概念が掴めれば十分です。各操作が10分かかり（テスト全体はさらに長く）、ベンチマーク自体が時間的に負担になり実用的でなくなる可能性があります。
展開アーキテクチャ例
このベンチマークテストは2台の異なるサーバー（各サーバーごとに一度ずつ実行）でラボ内で実施されました:
- ArcGIS Enterprise -- マシン #1 (古いハードウェア)
- Intel Xeon E5-4650, 2.70 GHz
- ArcGIS Enterprise -- マシン #2 (新しいハードウェア)
- Intel Xeon Gold 6126, 2.60 GHz
P
注意: このテストはスループットより速度重視だったため、SPECint_rate_baseではなくSPECint_base数値が使用されました。 ベンチマークテスト実行
< P >< FONT color = "#000000"> 長時間実行するテストの場合、GUI内でテストプランを実行することは推奨されません。しかし、このテストは比較的短いため影響は軽微です。</ P >< P >< FONT color = "#FF0000">< STRONG > 注意: テスト実行時には常に開始時間と予想期間について適切な担当者と調整することが推奨されます。これによりユーザーや他の同僚への影響が最小限になり、また他活動による
システムノイズ によって結果が「汚染」されることも防げます。</ P >< H2 id = "toc-hId-1420371181"> 結果 < P > ユーザー定義変数を適切な環境（マシン #1…devlab05）へ調整後、JMeter GUI内でベンチマークが実行されました。結果は「View Results in Table」要素から確認できます:</ P >< UL >< LI > 便宜上、テストプランは最後の操作名内で全体のテスト実行時間を自動計算します< UL >< LI > これにより表からベンチマーク時間が簡単に観察可能になります </ LI ></ UL ></ LI ></ UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "jmeter_geometry_functions_benchmark_results_server1.png" style = "width: 999px;" >< img src = "
https://us.v-cdn.net/6038851/uploads/images/114073i4CE3499080850BE2/jmeter_geometry_functions_benchmark_results_server1.png" role = "button" title = "jmeter_geometry_functions_benchmark_results_server1.png" alt = "jmeter_geometry_functions_benchmark_results_server1.png" / ></ P >< UL >< LI >< SPAN > テストプランは新しいハードウェア上のサーバー（マシン #2…eistsrv05）へポイントするよう調整され再度ベンチマークが実行されました </ SPAN >< UL >< LI >< SPAN > 表から結果が最初の実行後に追加されています: </ SPAN ></ LI ></ UL ></ LI ></ UL >< P >< SPAN >
<\/span><\/SPAN><\/P>予想通り、最初のマシンは同じ操作を完了するのにより多くの時間を要しました。これにより、2台のマシン間で測定可能なパフォーマンスの差が生じました。<\/SPAN><\/P>マシン #1…devlab05ベンチマーク期間: 259946 ms<\/LI><\/UL><\/LI>マシン #2…eistsrv05ベンチマーク期間: 181441 ms<\/LI><\/UL><\/LI><\/UL>パーセンテージ変化の計算<\/H2>レスポンス時間が新しいハードウェアで低かった（例：より速かった）ため（古いハードウェアでの最初の実行と比較して）、減少率（percentage decrease）<\/EM>を計算します:<\/P>まず、元のサーバー時間 - 新しいサーバー時間 = 減少量<\/LI>次に、減少量 ÷ 元のサーバー時間 × 100 = % 減少率<\/LI><\/UL>(259946 ms - 181441 ms) / 259946 ms = 0.302<\/P>0.302 × 100 = 30.2% <\/P>古いハードウェア（開始点）のベンチマーク時間は新しいハードウェアより30%長かった。このパーセンテージ変化は、新しいハードウェアを使用した場合に測定可能な改善を示唆しています。<\/P>SPECに基づくパーセンテージ変化の推定<\/H2>元の実行からのベンチマーク時間とSPEC比率を使ってtarget_time（新しいマシンでのベンチマーク時間）を予測しましょう。これにより、おおよそ同じパーセンテージ変化が推定できるか理解する助けになります。<\/P>(Baseline_SPEC × Baseline_Time) = (Target_SPEC × Target_Time)<\/P>((Baseline_SPEC × Baseline_Time) / Target_SPEC) = Target_Time<\/P>(36.875 × 259946 ms) / 53.75 = 178335 ms（秒単位に切り捨て後）<\/P>(259946 ms - 178335 ms) / 259946 ms = 0.314<\/P>0.314 × 100 = 31.4%<\/P>この予測から、古いハードウェアは新しいハードウェアより31%遅いと推定されました。 これは観測されたベンチマーク時間に基づいて計算されたパーセンテージ変化に非常に近いです。 <\/P>将来のハードウェア<\/H1>
<\/span>プロセッサアーキテクチャとCPU速度は常に向上しています。やがて、このようなベンチマークテスト（現在構築されているもの）はわずか数分または数十秒で実行できるようになるでしょう（素晴らしい問題ですね）。その時点で、新技術により適合させるためにテストの複雑さを増して実行時間を延ばすことが可能です。<\/P>テスト内の最後のトランザクションが無効になっていることに気づいたかもしれません。この1000ポイントバッファリクエストは距離10000メートル、単位9035（国際メートル距離）で計算に時間がかかります（まともなハードウェアでも）。実行時間を合理的な長さに短縮するため無効化されました。ただし、必要に応じて関心のある展開環境のCPU速度によって追加計算として有効化できます。<\/P>最終的な考察 <\/H1>他のコミュニティ記事でも述べられているように、ArcGIS全体の幅広さと深さをカバーできる単一のサービスや機能はありません。しかし、GeometryサービスはGISという素晴らしい分野の一部を表すリソースであり、扱いやすいです。これがベンチマークテストに適した選択肢となっています。<\/P>高速なレスポンス時間はCPU速度だけによるもの？<\/H2>このGeometryベンチマークテストではそうです。しかし、実際のサービスでは処理速度だけが要因ではありません。<\/P>ディスク速度、利用可能メモリ、ネットワーク速度などサーバーハードウェアコンポーネントもレスポンス時間改善に寄与します（CPU速度に加えて）。これらすべてがユーザー体験に良い影響を与えます。<\/P>このベンチマークはクライアント要求／サーバ応答プロセスの大部分を占めるCPU性能に焦点を当てましたが、前述したように他のArcGISサービスも考慮すると唯一のサーバリソースではありません。<\/P>他のCPU比較ツールはどう？<\/H2>
<\/span>多くのユーティリティがあり、様々なサーバーハードウェア部品を多数のテストでプロファイル・評価できます。これらのテストは優れており、ハードウェア理解には確かに価値があります。ただし、一つのテストですべてのGIS要素を代表することはできません。しかし、このGeometry Benchmark Test Planが分析者ツールセットで役立つツールとなることを願っています。 <\/P>
<\/P>この記事で使用されたApache JMeter Test Planはこちらからダウンロードできます: geometry_functions_benchmark1.zip<\/A> <\/P> <\/P> <\/P> <\/P>帰属情報<\/STRONG><\/P>リソース: File:Wikimedia_Foundation_Servers-8055_43.jpg<\/A>説明: ラックマウント型11世代PowerEdgeサーバー群<\/SPAN>
作者:
Victorgrigas<\/A> - 自身による作品<\/SPAN>作成日: 2012年7月16日<\/SPAN>アップロード日: 2012年7月20日<\/SPAN>ライセンス: CC BY-SA 3.0<\/A>, リンク<\/A> <\/P> <\/P>
リソース:
File:Cpu-processor.jpg<\/A>説明:<\/P>
作者:
Fx Mehdi<\/A> - 自身による作品<\/SPAN>アップロード日: <\/SPAN>2019年5月30日<\/SPAN>ライセンス: クリエイティブ・コモンズ 表示 - 継承 4.0 国際ライセンス<\/A>
