nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Apache JMeterロードテスト中のハードウェア使用率のキャプチャ（中級）

AaronLopez

Apache JMeterロードテスト中のハードウェア利用率のキャプチャー

測定されたトランザクションスループットと応答時間は、ArcGIS Enterpriseのロードテストにおける重要なデータですが、展開マシンのキャプチャされたハードウェア利用率も重要な情報を提供します。これらのテスト成果物を組み合わせることで、サイトの能力と効率性の適切な分析が可能になります。

アプリケーションやフィーチャサービスが特定のスループットレベルに達したことを確認することは良いことですが、テストされたワークロードのキャプチャされたプロセッサ利用率を調べながらスケーラビリティ特性を確認することはさらに良いことです。

この記事では、マシンのハードウェア利用率をキャプチャするいくつかの方法について説明します。このリソース使用状況は、ArcGIS EnterpriseのApache JMeterロードテストの結果を補完し、さらなる分析に役立ちます。この記事は、WindowsおよびLinux用の無料ツールとユーティリティを使用した最も一般的なシナリオに焦点を当てます。

キャプチャ戦略

残念ながら、ロードテストでハードウェア利用率をキャプチャするための万能な方法はありません。さまざまな環境（Windows、Linux、Cloud、Kubernetes、Dockerなど）や必要なアクセス権限や許可がない場合があるため、Apache JMeterテスト実行中にハードウェアから使用情報をキャプチャおよび監視するために戦略や方法論を変更する必要がある場合があります。

例えば、perfmon（例：Performance Monitor）は無料でMicrosoft Windowsのすべてのインスタンスに含まれており、環境内のすべてのマシンがWindowsの場合に非常に有効です。これは複数のWindows技術（例：WMI、DCOM）のフロントエンドであり、それらすべてが組み合わさって「リアルタイム」でグラフ表示やスクリプトによるリソースキャプチャをデータファイルに保存する多用途なフレームワークを提供します。

しかし、perfmonはLinuxでは利用できないため、同等の情報をキャプチャするには別のツール（例：dstat）が必要です。もちろん、すべてWindows環境でも制限されたクラウド環境などでperfmonアプローチに課題が生じることがあります。しかし、この貴重なマシンデータを記録する他の方法はあるのでしょうか？この記事で後ほどその答えを探ります。

ロードテストでどんな情報をキャプチャすべきか？

地図画像生成やジオプロセシングサービス要求計算などGIS作業がArcGIS Enterprise展開に送信されると、その応答処理を行うサーバーマシンはジョブ完了のためにさまざまなハードウェアリソースを使用します。理想的にはほとんどの作業は中央処理装置（CPU）で行われますが、必ずしもそうとは限りません。

使用している監視技術に関係なく、ロードテスト用に使用状況を監視・キャプチャする際には4つの主要なハードウェアカウンターカテゴリがあります：

プロセッサ
メモリ
ネットワーク
ディスク

各カテゴリには、そのリソース利用率を示すために使用できるさまざまなメトリックがあります。テスト中にすべての利用可能なプロセッサメトリックをキャプチャする必要はなく（推奨もしません）、重要なものだけで十分です。つまり、典型的なロードテスト質問や特定の目的に答えるために必要なものだけです。

通常、重要なメトリックには以下が含まれます：

プロセッサ
- 利用率パーセンテージ
メモリ
- 空き容量（MBまたはバイト）
- 使用量（MBまたはバイト）
- 使用率パーセンテージ
ネットワーク
- 送信量（MBまたはバイト）
- 受信量（MBまたはバイト）
ディスク
- アイドル率パーセンテージ
- キュー長
- 読み取り量（MBまたはバイト）
- 書き込み量（MBまたはバイト）

注意：サーバーに複数ディスクがある場合、それぞれ別々に収集することを強く推奨します。つまり、Cドライブ、Dドライブ、およびEドライブは異なるリソースとして扱ってください。複数のアクティブなネットワークデバイスが存在することも技術的には可能ですがあまり一般的ではありません。

手動で追加されたさまざまなハードウェアメトリックから収集しているPerformance Monitorインターフェース：

注意：利用率キャプチャ方法によって値がバイト単位で保存される場合やメガバイト単位の場合があります。どちらでも問題ありませんが、分析およびレポート提示時にどちらがキャプチャされているか理解しておくことが重要です。

注意：トランザクションスループット（例：transactions/sec）およびトランザクション応答時間（例：秒）とともに上記メトリックはロードテストの主要業績評価指標(KPI)の大部分を構成します。 KPIは特定テストや取り組みの成功度合いを定義済みテスト目標（例：Test Plan）と比較評価・ベンチマークする助けとなります。

サンプル間隔

通常、スケーラビリティに主眼を置いたロードテストは1～2時間以上実行されません。そのため比較的短時間と見なされるので、5～10秒という高速間隔（短い頻度）でハードウェア利用率をキャプチャすることが理にかなっています。これにより十分なデータ取得が保証され詳細分析が可能になります。もしキャプチャ間隔が1分以上だと、テストによるハードウェア資源への重大な影響が見逃される可能性があります。

注意：ネットワーク上で既に監視ソフトウェアが稼働していてArcGIS Enterpriseサーバーから定期的にハードウェア利用率を収集している場合があります。生成されたレポートがあれば、それらもロードテスト分析に使用可能ですが、その際キャプチャ間隔が短い頻度（例：5～10秒）である必要があります。ロードテスト分析では、一日全体よりも数時間分の詳細メトリック情報が重要です。

キャプチャとモニタリングの違い

「キャプチャ」と「モニタリング」という用語はしばしば同義で使われます。しかしApache JMeterテスト目的では、本記事はモニタリングよりも使用状況をキャプチャ(記録)することに焦点を当てています。ここでの主な違いはキャプチャとは情報を記録・保存し後から分析しやすくすることです。

テストクライアント(ロードジェネレーター機)

ArcGIS Enterpriseへのロードテストからハードウェア利用率をキャプチャするときは、ベストプラクティスとしてテストクライアントマシンからも使用状況測定を行うことです。
多くの場合サーバー資源観察に注力しますが、テストクライアント側ハードウェアもボトルネックになる可能性があります。これらマシンが十分な容量（例：プロセッサ、メモリ、ネットワークまたはディスク）を持たない場合、展開への負荷生成能力が悪影響を受けます！

サーバーベースラインの理解

Your ArcGIS Enterprise展開ハードウェアについてあまり詳しくない場合は、システムアイドル時のリソース利用状況を見ることを推奨します。この「使用状況」はベストケースシナリオのイメージ形成に役立ちます。つまりソフトウェアとサービスが稼働しているものの誰も使っていない状態でマシンがどう見えるかということです。そのような状況では4つすべてのハードウェアカテゴリからの資源活動は最小限であるべきですロードテストではこの「アイドル状態」の情報記録は必須ではありませんが、その様子を知っておくことは良いことです。

注意：Task Manager(Windows用)やtop(Linux用)などツールは手動でシステム資源利用状況を見るには優れています。しかしこれらはすべてカテゴリからファイルへ使用状況保存には理想的ではありません。

Task Managerによるシステム資源利用状況ビュー(Windows)：

topによるシステム資源利用状況ビュー(Linux)：

一般的な利用率キャプチャ例

Perfmon を使う (ロードテスト外で利用率キャプチャ)

Your user account に必要な権限がWindows上で利用可能であると仮定すると、perfmon はその一つですロードテスト分析のためのハードウェア使用率を記録する最も簡単な方法。Performance Monitor（および関連技術）は、ローカルマシンまたは複数のリモートサーバーから同時に使用状況をキャプチャできます。<\/P>

注意：繰り返しになりますが、各ハードウェアグループ内でperfmonが利用可能なメトリクスは非常に豊富です。<\/STRONG><\/FONT>
また、多くのソフトウェアメトリクスもキャプチャ可能ですが、この場合は少ない方が良いです。ほとんどの状況で必要なのはごく少数のカウンターだけです。<\/STRONG><\/FONT><\/P>前述のように、考慮すべき点は以下の通りです：<\/P>ArcGIS EnterpriseのデプロイメントがLinux上で動作しているperfmonはLinuxでは利用できません最も簡単な回避策は、別の方法論を使って情報を収集することです（後述）<\/LI><\/UL><\/LI><\/UL><\/LI>デプロイメントがクラウド上にある場合クラウド内の他のデプロイメントマシンから収集するためにクラウドでperfmonを実行することは技術的には可能ですが、裏側では通常環境でブロックされるネットワークプロトコルを使用していますここでの最も簡単な回避策は、各クラウドマシンで手動でperfmonを実行し、テスト完了時に生成された出力を収集することです<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Windowsでperfmonを起動するのは次のコマンドを実行するだけで簡単です：<\/P>実行 --> perfmon<\/LI><\/UL>そこから各マシンおよびそれぞれのハードウェアメトリクスとカウンターを追加できます。これは非常に強力ですが、時間がかかりタイプミスが起こりやすい可能性があります！<\/P>代わりに、この方法論で推奨される戦略は、これらすべての項目が事前定義されたPowerShellスクリプトを使用することです。<\/P>以下は4つの主要なハードウェアカテゴリから重要なperfmonメトリクス（既に定義済み）を収集し、指定可能な4台の異なるマシンからこれを行います：<\/LI><\/UL> <\/P># =============================================================================== # 更新日: 2022-08-02 # ファイル名: ps_get_all_continuous.ps1 # バージョン: 0.1.0 # 説明: 各種メトリクスを継続的に収集し、(バイナリ)値をファイルに保存 # 注意: カウンター初期化に時間がかかるため、テスト開始20秒前に収集開始推奨 # =============================================================================== Write-Output -InputObject 'すべてのメトリクスを収集中（継続）...' # 変数 # Windows Perfmon カウンター $counters = "Processor(_Total)\% Processor Time","Memory\Available MBytes","Memory\Committed Bytes","Memory\% Committed Bytes In Use","Network Interface(*)\Bytes Received/sec","Network Interface(*)\Bytes Sent/sec","LogicalDisk(_Total)\% Idle Time","LogicalDisk(_Total)\Disk Read Bytes/sec","LogicalDisk(_Total)\Disk Write Bytes/sec" # 収集対象マシン $computers = @('server1.domain.com','server2.domain.com','server3.domain.com','server4.domain.com') # サンプル収集間隔（秒） $sampleinterval = 10 $date = (Get-Date) $dyndate = '{0:yyyyMMddTHHmmss}' -f $date # 例: 20220303T140044 # ファイル名 $filename = "perfmon_all_continuous" # 出力ファイル形式（blg, csv, tsvから選択） $outputfiletype = "blg" # 出力ファイル名 $outputfile = '{0}_{1}.{2}' -f $filename, $dyndate, $outputfiletype # Get-counter 実行 Write-Output -InputObject ('開始日時: {0}' -f $date) Get-counter -Computername $computers -Counter $counters -Continuous -Sampleinterval $sampleinterval | Export-counter -Force -FileFormat $outputfiletype -Path $outputfile <\/code><\/pre> <\/P><UL><LI>メトリクスは10秒ごとに収集されます PowerShellウィンドウでCtrl-Cを押すまで継続。情報はWindowsで開けるバイナリ形式ファイルに保存されます（さらなる分析や変換用）：<\/LI><\/UL><img src="https://us.v-cdn.net/6038851/uploads/images/49356iC6B4C3B9199D2CF8/capturehardware_powershell_start_output.png" role="button" title="capturehardware_powershell_start_output.png" alt="capturehardware_powershell_start_output.png" \/><\/P>注意：このPowerShellスクリプトはロードテスト開始の約20～30秒前に開始することを推奨します。カウンター初期化には即時性がなく数秒かかるためです。<\/FONT><UL><LI>*.blgファイルはキャプチャ中いつでも開けますが、最新情報はスクリプト実行中のPowerShellウィンドウでCtrl-Cを押すまでファイルにフラッシュ・保存されません。<\/LI><LI>*.blgファイルをダブルクリックして開くと以下のような画面になります：<\/LI></UL><img src="https://us.v-cdn.net/6038851/uploads/images/49377i9D7D47D522AD17A4/capturehardware_powershell_results.png" role="button" title="capturehardware_powershell_results.png" alt="capturehardware_powershell_results.png" \/>最終結果は私たちがキャプチャしたものと非常によく似ています。ただし、この場合プロセスが自動化されています（これは良いことです）。Performance Monitorのこのインターフェースから特定メトリクスの選択／解除、グラフ画像としてエクスポート、生データをCSVなど別形式で保存、全収集マシンから使用状況分析などが可能です。非常に強力です！注意：Performance MonitorスクリプトはJMeterと直接統合されていません。 <\/STRONG>注意：クラウドデプロイメントの場合、それぞれのサーバー上で手動でperfmonスクリプトを実行する必要があります。<\/STRONG><H3 id="toc-hId--464400263">dstat の使用（ロードテスト外で利用率キャプチャ）</H3>dstat は多くのLinuxディストリビューション向け（または付属）の無料コマンドラインツール（dag@wieers.com作成）で、ハードウェア使用率をキャプチャ・監視します。 数年更新されていませんが堅牢でスクリプト化も容易です。<UL><LI>dstat をオプションなしで実行した端末出力例：</LI></UL><img src="https://us.v-cdn.net/6038851/uploads/images/49381i3426B23A73682927/capturehardware_dstat_monitor.png" role="button" title="capturehardware_dstat_monitor.png" alt="capturehardware_dstat_monitor.png" \/>以下コマンドはLinuxサーバー上で5秒ごとにハードウェア使用率をcsvファイルへキャプチャしCtrl-Cで手動停止します：<UL><LI>[gisadmin@pesrv04 ~]$ dstat -tTcmn --disk-util -d --nocolor --noheaders --output dstat_20220823.csv 5</LI></UL><img src="https://us.v-cdn.net/6038851/uploads/images/49383i12F99873FC093EA3/capturehardware_dstat_capture.png" role="button" title="capturehardware_dstat_capture.png" alt="capturehardware_dstat_capture.png" \/>dstatではキャプチャされるプロセッサ使用率は「アイドル時間パーセンテージ」であり、使用率パーセンテージではありません。使用率パーセンテージを得るには値から100を引いてください。ただしディスク使用率は使用率パーセンテージです。また上記出力には表示用フォーマットが含まれており、生値（非表示）はメモリ・ネットワーク・ディスクともバイト単位で保存されています。<\/STRONG>dstatスクリプトはデプロイメント内すべてのLinuxマシン上で手動かつ個別に実行する必要があります。JMeterとは直接統合されません。ロードテスト終了後スクリプト停止しCSVファイルを収集して分析（例：表計算ソフトによるグラフ化等）が可能です。<\/STRONG><H3 id="toc-hId-2023112570">Apache JMeter の使用 (ロードテストから直接利用率キャプチャ)</H3>perfmonやdstatスクリプトより手順や課題が多いものの、Apache JMeter を使ってハードウェア利用率をキャプチャする主な利点があります：<UL><LI>一貫性. 同じJMeter Test Plan を使ってWindows・Linux・Macから同じハードウェアメトリクスをキャプチャ可能<UL><LI>これは複数の無料ソフトウェアによって実現されています：<UL><LI>JMeter に追加される<A href="https://jmeter-plugins.org/wiki/PerfMon/" target="_blank" rel="noopener nofollow noreferrer">jp@gc - PerfMon Metrics Collector</A> 拡張機能 <UL><LI>このコンポーネントはどのメトリクスをどのマシンから収集するか定義します</LI></UL></LI><LI>A deployment内各サーバー上Java Runtime Environment (JRE) で動作する<A href="https://github.com/undera/perfmon-agent/blob/master/README.md" target="_blank" rel="noopener nofollow noreferrer">PerfMon Server Agent</A> ツール <UL ><LI>このコンポーネントが各サーバー上で実際に収集しJMeterへデータ送信します</LI></UL ></LI ></UL ></LI ></UL ></LI ></UL >jp@gc - PerfMon Metrics Collector コンポーネントはJMeter Plugins Manager経由（「PerfMon (Servers Performance Monitoring)」下）でTest Planへ簡単に追加できます：<img src="https://us.v-cdn.net/6038851/uploads/images/49709i9536381D99067E93/capturehardware_jmeter_pluginmanager.png" role="button" title="capturehardware_jmeter_pluginmanager.png" alt="capturehardware_jmeter_pluginmanager.png" \/><\/P > PerfMon Server Agent コンポーネントは比較的簡単に追加できますが、正しく動作させるためにはいくつかの追加手順が必要です。<\/SPAN><\/P>注意: sigar-amd64-winnt ライブラリのバグにより、JDK または JRE のバージョンが 8 より大きい場合、ServerAgent は標準のライブラリを使用するとクラッシュします。回避策としては、ライブラリをパッチするか、最新のバージョン 8 の JRE を使用することです。<\/STRONG><\/FONT><\/P><A href="https:\/\/www.openlogic.com\/openjdk-downloads" target="_self" rel="nofollow noopener noreferrer">OpenLogic<\/A> は Windows、Linux、Mac 向けに無料で定期的に更新される v8 OpenJDK (および JRE) リリースを提供しています。JDK も動作しますが、この場合はエージェントの実行に必要な環境を提供しつつダウンロードサイズが小さいため、JRE の使用が推奨されます。<\/FONT><\/P>注意: ServerAgent には 32bit または 64bit のどちらの JRE でも動作します。<\/STRONG><\/FONT><\/P>注意: OpenLogic の JDK または JRE は Apache JMeter 自体の実行にも使用できます。<\/STRONG><\/FONT><\/P><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49406iEBD98A1C9C85F57D\/capturehardware_openlogic_download.png" role="button" title="capturehardware_openlogic_download.png" alt="capturehardware_openlogic_download.png" \/><\/span><\/FONT><\/P><UL><LI>ServerAgent と OpenLogic JRE を同じフォルダーに解凍した状態:<\/SPAN><\/FONT><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49499i1001834053E61544\/capturehardware_openlogic_serveragent_explorer.png" role="button" title="capturehardware_openlogic_serveragent_explorer.png" alt="capturehardware_openlogic_serveragent_explorer.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI> OpenLogic JRE を ServerAgent フォルダー内に移動した状態:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49500i9E7477A4EACB100A\/capturehardware_openlogic_serveragent_jre.png" role="button" title="capturehardware_openlogic_serveragent_jre.png" alt="capturehardware_openlogic_serveragent_jre.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI>startAgent.bat ファイルをエディタで開き、ServerAgent フォルダーにコピーした JRE ディレクトリ名で更新します:<\/LI><\/UL> <\/P><pre class="lia-code-sample language-csharp"><code> off\n\nset JAVAPATH=.\\openlogic-openjdk-jre-8u342-b07-windows-64\\bin\n%JAVAPATH%\\java -jar %0\\..\\CMDRunner.jar --tool PerfMonAgent %*<\/code><\/pre> <\/P><UL><LI>変更を保存します<\/LI><LI>C:\\JMeterAgent\\ServerAgent-2.2.3 フォルダーには、ハードウェア利用率収集用に適切なマシンへコピー可能な自己完結型 ServerAgent が存在します<\/LI><LI>Windows でエージェントを起動するには、startAgent.bat をダブルクリックします<UL><LI>エージェントはコマンドウィンドウで起動します:<\/LI><\/UL><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49501iB7B6D67885E49A9C\\capturehardware_serveragent_listening.png" role="button" title="capturehardware_serveragent_listening.png" alt="capturehardware_serveragent_listening.png" \/><UL><LI>エージェントは Apache JMeter Test Plan によって指示されるまでメトリクスの「収集」を開始しません <UL><LI>デフォルトでは、エージェントと JMeter は TCP および UDP ポート 4444 で通信します<\/LI></UL></LI></UL>注意: jp@gc - PerfMon Metrics Collector は名前に "perfmon" を使っていますが、実際には Windows Performance Monitor 技術を利用していません。利用していません。<\/STRONG><H1 id="toc-hId--737670810">メトリクス収集対応の SampleWorldCities <\/> テストプラン</H1><UL><LI>この記事で使用されている Apache JMeter Test Plan のダウンロードはこちら: <A href="https:\/\/community.esri.com\/ccqpr47374\/attachments\/ccqpr47374\/implementing-arcgis-blog\/355.14\/1\/sampleworldcities5.zip" target="_self">sampleworldcities5.zip</A>  <\/> </LI> <LI>Apache JMeter でテストプランを開くと以下のようになります:<UL class="lia-list-style-type-circle"><LI>User Defined Variables を環境に合わせて調整してください<UL ><LI>このテストではハードウェア利用率を収集するために4台の異なるマシンを定義しています:<UL ><LI>Web アダプター<UL ><LI>リクエストもこのエンドポイントに送信されます</LI></UL ></LI ><LI>ArcGIS Server</LI ><LI>Portal for ArcGIS</LI ><LI>テストクライアント (JMeter を実行しているマシン)<UL ><LI>このマシンのホスト名はテスト実行時に JMeter によって自動検出されます</LI ></UL ></LI ></UL ></LI ></UL ></LI ></UL ></LI ></UL ><img src="https:\/\us.v-cdn.net\6038851\uploads\images\49509iFF0B49BC3452FB54\capturehardware_jmetertestplan_userdefinedvariables.png" role="button" title="capturehardware_jmetertestplan_userdefinedvariables.png" alt="capturehardware_jmetertestplan_userdefinedvariables.png" \/><H2 id="toc-hId-1878924742">テストプランのコンポーネント</H2 >jp@gc - PerfMon Metrics Collector 拡張機能はここで唯一注目すべき要素であり、このテストは以前の記事の SampleWorldCities 用テストプランとほぼ同一です。<\/> <H3 id = "toc-hId-200552998">jp@gc - PerfMon Metrics Collector 拡張機能</H3 >前述の通り、この拡張機能は各稼働中エージェントに何を収集させるか指示します。この記事で提供されているテストプランには4つの主要なハードウェアカテゴリごとのカウンターが既に追加されています。 <\/> 注意: メトリクスパラメータは Linux と Mac にも対応しています。ただし、拡張機能内の Disks IO メトリクスは C ドライブ (例: C\:\) 上で収集するよう設定されており、Linux には存在しません。これを \/ に変更する必要があります。<\/> <img src = "https:\/\us.v-cdn.net\6038851\uploads\images\49510iD61C8B558F5AFD10\capturehardware_jmetertestplan_perfmonmetricscollector.png " role = "button " title = "capturehardware_jmetertestplan_perfmonmetricscollector.png " alt = "capturehardware_jmetertestplan_perfmonmetricscollector.png " \/><H2 id = "toc-hId--1735984184">JMeter と ServerAgent 間の接続性検証</H2 >GUI の再生ボタン (緑色三角形) をクリックしてテストを開始します<\/> <UL ><LI >すべての ServerAgents が稼働中で ArcGIS Enterprise 展開内の対象マシンからアクセス可能な場合、それらは利用率を収集し情報をテストプランへ送信できます<\/> </LI ><LI >JMeter はこの情報を受信するとチャートタブに表示します<UL ><LI >接続性検証のため数秒間収集させ、その後テストを停止してください<\/> </LI ></UL ></LI ></UL ><img src = "https:\/\us.v-cdn.net\6038851\uploads\images\49512iACE9249861C62895\capturehardware_jmetertestplan_validateconnectivity.png " role = "button " title = "capturehardware_jmetertestplan_validateconnectivity.png " alt = "capturehardware_jmetertestplan_validateconnectivity.png " \/>注意: コマンドラインからテストを実行すると、収集されたメトリクスデータを含むファイル名は bat スクリプト内の変数によって定義された "results_" ファイルに基づきます。テスト完了後、この "jp@gc - PerfMon Metrics Collector" 要素を使って生データを読み込み特定カウンターを抽出したりチャート画像を生成できます。このファイル名は文字列 "perfmon_" で始まります。 <\/> results ファイルと perfmon ファイルはいずれも *.jtl 拡張子ですが CSV ファイルです。<\/> <H1 id = "toc-hId-622445930">テスト実行</H1 >負荷テストは通常の JMeter テストプランと同様に実行してください。<\/> sampleworldcities5.zip プロジェクトに含まれる runMe_withP.bat スクリプトは Apache JMeter チーム推奨のテスト実行例です。 <\/> <UL ><LI >runMe_withP.bat スクリプトには環境に合わせて設定が必要な jmeterbin  <\/> 変数が含まれています<\/> </LI ><LI >このスクリプトには他の記事の runMe.bat より少し多いロジックがあります<UL ><LI >この追加ロジックは結果ファイルと収集されたハードウェアファイルが同じ runname で終わるようにするためです<\/> </LI ></UL ></LI ><LI >runMe_withP.bat スクリプト内容:<\/> </LI ></UL > <\/> <pre class = "lia-code-sample language-csharp"><code >echo off rem Scripted JMeter Test Plan execution rem Utilizing ApacheJMeter.jar for invocation rem rem 2022/08/25.1 rem rem With environment variable to JMeter support (for PerfMon extension) rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ rem *** Variables *** rem Set JMeter memory to min/max of 4GB (adjust based on your test client resources) set heap=-Xms4g -Xmx4g -xyz:MaxMetaspaceSize=256m rem Location of %JAVA_HOME%\\bin set javadir=%JAVA_HOME%\\bin rem Location of Apache JMeter bin set jmeterbin=C:\apache-jmeter-5.5\bin rem JMeterテストプランのルートフォルダの場所（例：テストプランが存在するフォルダ） set projectdir=%~dp0 rem JMeterテストプランの名前（JMXファイル拡張子なし） set testname=sampleworldcities5 rem 各テスト実行の結果ファイルに付加される文字列 set runname=testrun1 rem プロキシ設定 rem set proxyhost=http://localhost rem set proxyport=8888 rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ rem *** エンジンを始動 *** color 20 rem テストで参照するための環境変数を設定（例：${__P(env.run)}） set jvm_args="-Denv.runname=%testname%_%runname%" echo on rem *** テスト開始 *** %javadir%\java.exe --illegal-access=warn %jvm_args% %heap% -jar %jmeterbin%\ApacheJMeter.jar -Jjmeter.save.saveservice.autoflush=false -n -f -t "%projectdir%\%testname%.jmx" ^ -l "%projectdir%\results\results_%testname%_%runname%.jtl" ^ -j "%projectdir%\logs\debug_%testname%_%runname%.log" ^ -e -o "%projectdir%\reports\%testname%_%runname%" ^ rem 必要に応じてコメント解除 rem -H %proxyhost% -P %proxyport% ^ rem *** テスト完了 *** echo off color 40 ping localhost -n 5 color 07

注意: 常に推奨される のは、負荷テストの開始時間と期間を組織内の適切な担当者と調整することです。これにより、ユーザーやオンプレミスのArcGIS Enterprise Siteを使用する他の同僚への影響を最小限に抑えられます。さらに、他の活動や使用によるシステムノイズがテスト結果を「汚染」するのを防ぐことができます。

注意: いくつかの理由から、 ArcGIS Onlineが提供するサービスに対しては決して負荷テストを行わないことが強く推奨されます。

一般的な方法論ガイド

このガイドはすべてのハードウェア利用状況キャプチャシナリオを網羅することを目的としていません。

シナリオ #1
- サーバー
  - Windows
- 環境
  - オンプレミス
- 収集マシン（テストクライアント）
  - Windows
- 説明
  - WindowsからWindowsの使用状況をキャプチャ
- 難易度
  - 簡単／中程度
- 推奨方法論
  - Windows Perfmon（PowerShellスクリプト経由）

シナリオ #2
- サーバー
  - Windows／Linux
- 環境
  - オンプレミス
- 収集マシン（テストクライアント）
  - Windows
- 説明
  - WindowsからWindows／Linuxの使用状況をキャプチャ
- 難易度
  - 中程度
- 推奨方法論
  - JMeter Perfmon Extension と ServerAgent

シナリオ #3
- サーバー
  - Linux
- 環境
  - オンプレミス
- 収集マシン（テストクライアント）
  - Windows／Linux
- 説明
  - Windows／LinuxからLinuxの使用状況をキャプチャ
- 難易度
  - 簡単／中程度
- 推奨方法論
  - dstatコマンドまたはスクリプト

シナリオ #4
- サーバー
  - Windows／Linux
- 環境
  - クラウド
- 収集マシン（テストクライアント）
  - Windows
- 説明
  - WindowsからWindows／Linuxの使用状況をキャプチャ
- 難易度
  - 中程度
- 推奨方法論
  - Cloud Watch／Azure Monitor（本記事では扱っていません）

シナリオ #5
- サーバー
 - Windows
- 環境
 - クラウド
 収集マシン（テストクライアント）説明 < ul > < li > WindowsからWindowsの使用状況をキャプチャ < / li > < / ul > < / li > < li > 難易度 < ul > < li > 中程度 < / li > < / ul > < / li > < li > 推奨方法論 < ul > < li >展開内の各マシンでWindows Perfmon（PowerShellスクリプト経由）を実行すること< / li > < / ul > < / li > < / ul > < / li > < / ul > < ul >< li > シナリオ #6 < ul >< li > サーバー< ul >< li > Linux < / li >< / ul >< / li >< li > 環境 < ul >< li > Kubernetes < / li >< / ul >< / li >< li > 収集マシン（テストクライアント）< ul >< li > Windows < / li >< / ul >< / li >< li > 説明 < ul >< li > WindowsからLinuxコンテナ／ポッドの使用状況をキャプチャ < / li >< / ul >< / li >< li > 難易度 < ul >< li > 中程度／難しい < / li >< / ul >< / li >< li > 推奨方法論 < ul >< li >環境ダッシュボードまたはカスタムリソースエンドポイント（本記事では扱っていません）< / li >< / ul >< / li >< / ul >< / li >< / ul >< h1 id="toc-hId-1302504300">一般的な利用状況収集の課題< / h1 > 負荷テスト用に展開マシンのハードウェア利用状況をキャプチャすることはベストなテスト手法ですが、常に可能とは限りません。 最も典型的な課題は次の通りです：< ul >< li > 権限 < ul >< li > 最も一般的なものです。< / li >< li > リモートサーバーから使用状況を取得するアクセス権や能力が与えられていないことが最も一般的な課題です。< / li >

環境／場所
- ローカルネットワーク上のマシンから利用状況を収集することと、クラウド上のマシンから利用状況を収集することは異なります。< / li >

オペレーティングシステム
- 時にはOS自体が利用状況取得に対して*障害*となる場合があります。< / li >

技術的な問題
- 特定の環境（例：Kubernetes／Docker）は従来型（物理または仮想）マシンと同じAPIで利用状況を収集できない場合があります。< / li >

最後に考えること

簡単に言うと、ArcGIS Enterprise展開内のマシンからハードウェア利用情報を取得し、負荷テスト結果と共に分析する方法は多様です。最適な取得方法とは…迅速に情報を記録し効果的な分析に使える方法ならどれでも良いということです。

一つの記事で全ての状況、環境、シナリオをカバーできるわけではありませんが、本記事では一般的なものについて複数のデータ取得方法を挙げています。

タグ付けされた投稿をもっと見る

Operational Support

Strategy & Planning

Architecture & Security

AaronLopez

Hi @ErickTGG,
Any observability tool could be used to capture operation data like CPU and memory usage from a performance/load test. And, if these reports and filters already exist and can be consumed that is definitely a good strategy.

One thing to keep in mind is that by default, many monitoring tools capture metrics for long term analysis. A common polling rate is every 1 minute or 5 minutes since they are expecting to store a lot of data (and this frequency can help with the manageability and scalability of that system).

As such, that "lower" resolution is generally not ideal for examining the impact of a load test. A typical load test runs for 1-- 2 hours. For such a short duration, higher capture intervals like 5, 10, or 20 seconds, are usually favored so a more detailed impact on the deployment's resources can be seen. This might be adjustable with most monitoring tools...not sure.
In cases where this higher resolution is not an option or maybe there is no monitoring tool even available, having the testing framework capture this type of data can be extremely valuable for the analysis.

Hope that helps.
Aaron

ErickTGG

Hey - Any reason why you haven't covered anything here with ArcGIS Monitor?

Is it that we can just create some filters in ArcGIS Monitor to view the same metrics?

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.