• 戻る（Apache Jmeter）
  • Jmeter用語
  • Jmeterのインストール
  • JmeterによるWebアプリの負荷テスト
  • Jmeterによる3層C/Sの負荷テスト
  • Jmeterによる可変値の追跡
  • Jmeterの正規表現
  • Jmeterの結果のレポーティング

• Jmeter で使用される用語を拾ってまとめた。
• Jmeter はプログラマブルなツールなので、
  コンポーネントとコンポーネント階層を理解しておく必要がある。

補足（この階層図が本ページの要点）: JMeter の学習でつまずく最大の原因は、
個々のコンポーネント名を覚えることではなく、
**「どのコンポーネントを、どの階層に置くと、どの範囲に効くか」**が
分からないことである。

大原則は次の 2 つ。

1. 設定エレメント・タイマ・アサーション・前処理／後処理・リスナーは
   「置いた階層の配下すべて」に効く（スコープを持つ）。
2. サンプラーだけは「そこで 1 回実行される」（スコープを持たない）。

つまり、HTTP クッキー マネージャをテスト計画直下に置けば全スレッド グループに、
あるサンプラーの子として置けばそのサンプラーだけに効く。
「なぜかタイマが全リクエストに効いてしまう」の類の事故は
ほぼこの原則の理解不足に起因する。

なお、同一階層内の実行順序は種別で決まっており、
配置順ではない（設定エレメント → 前処理 → タイマ → サンプラー →
後処理 → アサーション → リスナー）。

• Visual Studio 的に言うとプロジェクト・テンプレート的なもの。
• これを開いて、負荷テストを新規作成する。

以下のようなテンプレートが存在する。

• build-web-test-plan.jmx
  比較的単純な負荷テスト
• build-adv-web-test-plan.jmx
  ログイン処理等を含む、やや複雑な負荷テスト
• build-webservice-test-plan.jmx
  SOAP を使った負荷テスト

• build-ftp-test-plan.jmx
  比較的単純な負荷テスト

• build-ldap-ext-test-plan.jmx
  比較的単純な負荷テスト
• build-ldap-test-plan.jmx
  ループコントローラを利用した負荷テスト

• jdbc.jmx
  PostgreSQL に対する JDBC 経由の負荷テスト
• mongodb.jmx
  JSR233 を使った mongodb に対する負荷テスト

• recording.jmx
  記録コントローラ（ユーザの操作を記録してテスト計画を自動作成する）利用時テンプレート
• BeanShellSampler.jmx
  Jmeter 用の軽量スクリプト言語（BeanShell）でテストを書いて直接実行。

補足（最新化）: テンプレートは JMeter 5.x でも
bin/templates/ 配下に同名で存在するが、
build-webservice-test-plan.jmx（SOAP/XML-RPC サンプラー用）は
JMeter 3.0 で SOAP/XML-RPC サンプラー自体が削除されたため
現在は存在しない。SOAP のテストは
HTTP リクエスト サンプラー + HTTP ヘッダ マネージャ
（Content-Type: text/xml、SOAPAction）で行う。

同様に MongoDB Script サンプラーも JMeter 4.0 で削除された。
現在の JMeter 5.x で追加されたテンプレートには
bolt.jmx（Neo4j）、functional_test.jmx などがある。

以下の設定が可能。

テスト計画のグローバル定義

テスト計画のスレッドグループ

• ワークベンチとは、作業領域のこと。
  • リクエスト記録領域
  • 測定結果データ領域
• 特定のテストエレメントは、ワークベンチでのみ使用できる。

補足（最新化：ワークベンチは廃止された）: WorkBench は JMeter 3.1 で非推奨、
4.0 で完全に削除された。現在は次のように扱う。

旧（〜3.x）	現在（4.0 以降）
WorkBench に HTTP(S) Test Script Recorder を追加	テスト計画直下に追加する
WorkBench は保存されない（一時領域）	テスト計画の一部として .jmx に保存される
「Save WorkBench」チェックで保存	不要

WorkBench が「保存されない一時領域」だったために
記録したスクリプトを失う事故が多く、
通常のテスト計画ツリーに一本化されたという経緯である。
本節の記述は JMeter 3.x 以前を前提としている点に注意。

• HTTP(S) Test Script Recorder（旧 HTTP Proxy Server）
• 電文をキャプチャしてワークロードをスクリプトとして記録する機能。
• 使用する場合、ワークベンチにこれを追加する。

補足: 現在はテスト計画直下に追加する（前述）。
また、HTTPS を記録するには JMeter が生成する
ルート証明書（ApacheJMeterTemporaryRootCA.crt）を
ブラウザ／OS の信頼されたルート証明機関にインポートする必要がある
（中間者としてキャプチャするため）。この証明書は有効期間 7 日である。

• 送信されたデータを単にミラーリングする非常に単純な HTTP サーバー。
• HTTP 要求の内容をチェックするのに便利。

System プロパティまたは JMeter プロパティの値が表示される。

• 負荷テストの実行計画を設定するもの。
• 以下のプロパティ設定や、コンポーネント追加ができる。

• スレッドグループ（仮想ユーザ群）
• 追加する場合、テスト計画で右クリック > 追加 > Threads(Users) > XXXX を選択。

以下の 3 種類の Threads(Users) がある。

• スレッドグループ
  通常のスレッドグループ
• setUp Thread Group
  テスト前のアクションを実行するスレッドグループ。
  • 通常のスレッドグループとほぼ同じ。
  • 通常のスレッドグループの実行前に実行される。
• tearDown Thread Group
  テスト後のアクションを実行するスレッドグループ。
  • 通常のスレッドグループとほぼ同じ。
  • 通常のスレッドグループの実行後に実行される。

以下のプロパティを設定。

• 名前
  スレッドグループの名前（ID ではない）。
• コメント
  スレッドグループの説明
• スレッド数
  起動するスレッド数 ≒ 仮想ユーザ数
• Delay Thread creation until needed
  スレッドが必要になったタイミングで生成するオプション。
• ループ回数
  • テスト・シナリオの実行回数
  • ［無限ループ］にチェックを入れると無限にテスト
• Ramp-up 期間（秒で指定）
  多重度（仮想ユーザ数）を徐々に増加させるためのパラメタ。
• スケジューラ
  • 開始時刻
    スケジューラが有効の場合、この時刻が来るまでテストの実施を待つ。
    ただし後述の起動遅延の指定があれば、そちらが優先される。
  • 終了時刻
    スケジューラが有効の場合、この時刻までテストが行われる。
  • 持続時間
    テストをこの時間だけ実行する
  • 起動遅延
    この秒数だけテストの実行を遅延する
  • 終了条件
    Jmeter のスレッドが終了する契機が、
    以下の終了条件のうち、いずれか達成の早いものになる。
    条件チェックは各サンプル間でのみ行われる。
    • 指定のループ回数に達した時
    • 終了時刻に達した時
    • 持続時間に達した時
• サンプラーエラー後のアクション
  サーバがエラーを返してきた場合など、
  リクエストが何らかの原因でエラーになった際どうするかを選択する。
  • 続行
    エラーを無視してテストを続行
  • Start Next Loop
    エラーを無視して次のループの最初から続行
  • スレッド停止
    現在のスレッドを終了
  • テスト停止
    いずれかのサンプルの終了をもってテスト全体が停止
  • Stop Test Now
    即座にテスト全体を停止。

補足（Ramp-up 期間の決め方）: Ramp-up は「見栄えのため」ではなく
測定を成立させるためのパラメタである。

• 短すぎると、全スレッドが同時にリクエストを投げるため
  サーバ側のスレッド プール／コネクション プールが枯渇し、
  「サーバの性能」ではなく立ち上がりの詰まりを測ってしまう。
• 長すぎると、最初のスレッドが終了した後に最後のスレッドが起動し、
  目標の多重度に一度も到達しない。

目安は、

Ramp-up（秒） ≒ スレッド数 ÷ （1 秒あたりに増やしたいユーザ数）

であり、かつ
**「1 スレッドが 1 ループを回る時間 × ループ回数 > Ramp-up」**を満たすこと。
定常状態（全スレッドが走っている区間）を確保してから、
その区間の統計だけを見るのが正しい
（Jmeterの結果のレポーティング）。

また、Delay Thread creation until needed を有効にすると
未起動スレッドのメモリを確保しないため、
大規模な Ramp-up でメモリを節約できる。

補足（サンプラーエラー後のアクションの選び方）: 負荷テストでは
原則**「続行」**にする。「テスト停止」にすると
1 件のエラーで測定全体が失われるためである。
一方、ログイン失敗のまま後続を流しても無意味なケースでは
「Start Next Loop」を選び、シナリオの整合性を保つ。

• サーバなどのテスト対象に対し、何らかの指示やリクエストを行うためのコンポーネント。
• サンプラーにより負荷テスト結果が収集され、この結果はリスナーにより参照できる。
• 追加する場合、スレッドグループかロジックコントローラで右クリック > 追加 > サンプラー > XXXX を選択。
• 様々なサンプラーがある。
  • Web サーバのテストであれば、「HTTPリクエスト」を選択する。
  • XXX サーバのテストであれば、「XXXX リクエスト」を選択する。

#	サンプラー名	説明
1	BeanShell Sampler	BeanShell スクリプト言語を使ってサンプラーを書く
2	BSF Sampler (DEPRECATED)	BSF スクリプト言語を使ってサンプラーを書く
3	JSR223 Sampler	JSR-223 スクリプト言語を使ってサンプラーを書く
4	Java Request	org.apache.jmeter.protocol.java.sampler.JavaSamplerClient を使用してリクエストを送りレスポンスを待つ。
5	JUnit Request	JUnit を使用してリクエストを送りレスポンスを待つ。

補足（現在は JSR223 + Groovy 一択）: BSF 系は JMeter 5.0 で削除され、
BeanShell は非推奨である。理由は性能で、
BeanShell はリクエストごとにインタプリタで解釈するため
負荷テストの足を引っ張る（それ自体がボトルネックになる）。

JSR223 サンプラー／要素で Groovy を選び、
「Cache compiled script if available」にチェックを入れると
スクリプトがコンパイルされてキャッシュされ、桁違いに速くなる。

• セッション層

#	サンプラー名	説明
1	TCP サンプラー	サーバに対して TCP リクエストを送りレスポンスを待つ。

• プレゼンテーション層

#	サンプラー名	説明
1	HTTPリクエスト	Web サーバに対して HTTP(s) リクエストを送りレスポンスを待つ。
2	FTP リクエスト	FTP サーバに対してファイルの取り出し／アップロードのリクエストを送る。
3	LDAP リクエスト	4 種類の LDAP リクエストを送る。
4	LDAP 拡張リクエスト	8 種類の LDAP リクエストを送る。 より実際の LDAP セッションに近いシミュレーションが行える。
5	JDBC Request	JDBC でデータベースに対して SQL を送りレスポンスを待つ。
6	MongoDB Script (DEPRECATED)	MongoDB に対して MongoDB Script を送りレスポンスを待つ。

• メール

#	サンプラー名	説明
1	SMTP サンプラー	SMTP / SMTPS プロトコルを使用してメールメッセージを送信。
2	Mail Reader サンプラー	POP3（S）/IMAP（S）プロトコルを使用してメールメッセージを受信（オプションで削除）。

• JMS（Java Message Service）

#	サンプラー名	説明
1	JMS Publisher	指定された宛先（トピック/キュー）にメッセージを送信
2	JMS Subscriber	指定された宛先（トピック/キュー）からメッセージを受信
3	JMS_Point-to-Point	ポイントツーポイント接続（キュー）でメッセージを送受信

• その他

#	サンプラー名	説明
1	OS Process Sampler	OS コマンドを実行する。

#	サンプラー名	説明
1	Access Log Sampler	Web サーバーのアクセスログを読んで HTTP リクエストを生成。
2	Test Action	・・・
3	Debug Sampler	・・・

補足: Test Action は「リクエストを送らないサンプラー」で、
一定時間の一時停止（Pause）や、スレッド／テストの停止を行う。
ロジックの区切りとして使う。
なお、JMeter 5.x では JSR223 Sampler に加え
GraphQL HTTP Request（5.4 以降）が標準で追加されている。

• ループや条件分岐など、複雑な制御を行うためのコンポーネント。
• 追加する場合、スレッドグループかロジックコントローラで右クリック > 追加 > ロジックコントローラ > XXXX を選択。
• また、下位にサンプラー（または子コントローラ）を追加できる。

• 選択

#	ロジックコントローラー名	説明
1	If Controller	指定した条件が "true" の場合、子コントローラーを実行する。条件は JavaScript または変数表現で指定。
2	Switch Controller	スイッチの値に従って子コントローラーを実行する。

• ループ

#	ロジックコントローラー名	説明
1	Loop Controller	特定回数分、子コントローラーを実行する。
2	While Controller	While で、指定した条件が "false" になるまでループしながら子コントローラーを実行する。
3	ForEach Controller	ForEach で、変数の値を変えながらループして、子コントローラーを実行する。

補足（If Controller は「JavaScript を使わない」）: If Controller の条件式は
既定で JavaScript として評価されるが、
リクエストごとに JavaScript エンジンを起動するため非常に遅い。
負荷テストでは必ず
「Interpret Condition as Variable Expression?」にチェックを入れ、
条件を ${__jexl3(...)} のような変数式で書く。
同じ理由で、While Controller の条件も変数式で書くのが定石である。

#	ロジックコントローラー名	説明
1	Simple Controller	サンプラー、子コントローラーの整理のため。
2	Module Controller	リンク先を参照。
3	Include Controller	リンク先を参照。

以下は、ググって。

• Once Only Controller
• Interleave Controller
• Random Controller
• Random Order Controller
• Throughput Controller
• Runtime Controller
• Transaction Controller
• Critical Section Controller
• Recording Controller

補足（実務で使用頻度が高いもの）: 上の「ググって」リストのうち、
負荷テストで実際によく使うのは次の 3 つである。

コントローラー	用途
Transaction Controller	配下の複数サンプラーを1 つの取引としてまとめて計測する。画面遷移 1 回＝1 トランザクションとして応答時間を見る場合に必須
Throughput Controller	配下を指定した割合（%）でのみ実行する。「照会 8 割・更新 2 割」といった業務比率の再現に使う
Once Only Controller	スレッドごとに初回のみ実行。ログイン処理に使う

Transaction Controller の「Generate parent sample」に
チェックを入れると子サンプルが集計から外れ、
レポートがトランザクション単位になる。

• リクエストにかかわる様々な項目を設定する。
• 追加する場合、テスト計画 － サンプラーを右クリック > 追加 > 設定エレメント > XXXX を選択。

#	設定エレメント名	説明
1	TCP サンプラー設定	TCP サンプラーのデフォルト設定
2	ログイン設定エレメント	ユーザ名とパスワードの設定
3	DNS Cache Manager	DNS キャッシュ機能を追加

• HTTP

#	設定エレメント名	説明
1	HTTP 認証マネージャ	認証機能を追加
2	HTTP クッキーマネージャ	クッキーを扱う機能を追加
3	HTTP Cache Manager	HTTP キャッシュ機能を追加
4	HTTP ヘッダマネージャ	ヘッダを追加または上書き
5	HTTP リクエスト初期値設定	HTTP 接続テスト時のデフォルト値を設定

• その他、既定値

#	設定エレメント名	説明
1	FTP リクエスト初期値設定	FTP リクエストのデフォルト値を設定
2	LDAP リクエスト初期値設定	LDAP リクエストのデフォルト値を設定
3	LDAP 拡張リクエスト初期値設定	LDAP 拡張リクエストのデフォルト値を設定
4	Java リクエスト初期値設定	Java リクエストのデフォルト値を設定

• 接続設定

#	設定エレメント名	説明
1	JDBC Connection Configuration	JDBC の接続設定
2	MongoDB Source Config (DEPRECATED)	MongoDB Script サンプラーのための接続設定を行う

補足（HTTP クッキーマネージャは必須）: セッションを持つ Web アプリを
測定する場合、HTTP クッキーマネージャを置かないと
全リクエストが新規セッションになる。
サーバ側にセッションが際限なく積み上がり、
「負荷をかけたらメモリを食い潰した」という
測定側の設定ミスによる偽の障害を起こす。

クッキーマネージャはスレッドごとに独立した Cookie ストアを持つため、
スレッド＝仮想ユーザとして正しく振る舞う。

スレッドグループ以下のコンポーネントの中から参照可能なデータ

#	設定エレメント名	説明
1	Counter	カウンタを生成
2	Random Variable	ランダム文字列を生成
3	User Defined Variables	任意の初期変数セットを定義
4	CSV Data Set Config	変数値を CSV ファイルで与える

補足（CSV Data Set Config の共有モード）: 分散実行やスレッド間で
同じ行を読ませたくない場合、「Sharing mode」の指定が要点になる。

Sharing mode	挙動
All threads（既定）	全スレッドで 1 つのファイル位置を共有。行が重複しない
Current thread group	スレッド グループ単位で共有
Current thread	スレッドごとに先頭から独立して読む（行が重複する）

「ユーザ ID が重複してログインに失敗する」の多くは
ここの設定漏れである。詳細は
Jmeterによる可変値の追跡を参照。

#	設定エレメント名	説明
1	Keystore Configuration	Java Key Store（証明書ストア）を設定
2	Simple Config Element	任意の値を追加・上書き（開発者向け）

• 待機のためのコンポーネント。
• 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > タイマ > XXXX を選択。

#	タイマ名	説明
1	BeanShell Timer	BeanShell(JSR-274) を使ったタイマ
2	BSF Timer (DEPRECATED)	BSF を使ったタイマ
3	JSR223 Timer	JSR-223 を使ったタイマ
4	Synchronizing Timer	逆セマフォ的な動きをするタイマ（瞬間的な高負荷を与える）。

#	タイマ名	説明
1	Constant Timer（定数タイマ）	各スレッドリクエストのたびに指定した秒数分遅延する。
2	Constant Throughput Timer（定数スループット・タイマ）	トータルのスループットが一定値に近づくように停止時間を調整する。

#	タイマ名	説明
1	Uniform Random Timer	各スレッドリクエストのたびにランダム時間停止し、遅延時間の総計は乱数値＋オフセット値の合計になるタイマ。
2	Poisson Random Timer	各スレッドリクエストのたびにランダム時間停止し、停止時間の総計はポアソン分布に従うタイマ。
3	Gaussian Random Timer	各スレッドリクエストのたびにランダム時間停止し、遅延時間の総計はガウス分布に従うタイマ。

補足（タイマは「思考時間」であって「待ち時間」ではない）: タイマを入れない
負荷テストは、人間が画面を見ずに 0 秒で次を押し続けるという
非現実的なシナリオになる。結果として、
少ないスレッド数でも過大なスループットが出てしまい、
実運用の同時接続数に換算できない。

実測から多重度を決める場合は
リトルの法則を使うのが確実である。

必要スレッド数 = 目標スループット（req/sec） × （応答時間 + 思考時間）（sec）

逆に、スループットを固定して測りたい場合は
Constant Throughput Timer（または JMeter 5.0 以降の
Precise Throughput Timer）を使い、スレッド数は余裕を持たせる。
Precise Throughput Timer はポアソン到着を再現でき、
Constant Throughput Timer よりも実際のトラフィックに近い。

なお、**Constant Throughput Timer の単位は「分あたり」**であり、
秒あたりと取り違える事故が多い。

• 前処理のためのコンポーネント。
• 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > 前処理 を選択。

#	プリプロセッサ名	説明
1	BeanShell PreProcessor	BeanShell の前処理を実行
2	BSF PreProcessor (DEPRECATED)	BSF の前処理を実行
3	JSR223 PreProcessor	JSR-223 の前処理を実行
4	JDBC PreProcessor	SQL の前処理を実行

#	プリプロセッサ名	説明
1	HTML Link Parser	応答を解析してリンクとフォームを抽出
2	RegEx User Parameters	応答を正規表現を使って解析してパラメタを抽出

#	プリプロセッサ名	説明
1	Sample Timeout	タイマータスクが完了するまでに時間がかかりすぎると、 サンプルを中断するようにタイマータスクをスケジュールする。
2	User Parameters	個別のスレッドに対してユーザ変数を設定
3	HTTP URL Re-writing Modifier	URL 書き換えを行う Web サービスでセッションを引き回す

• 後処理のためのコンポーネント。
• 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > 後処理 を選択。

#	ポストプロセッサ名	説明
1	BeanShell PostProcessor	BeanShell の後処理を実行
2	BSF PostProcessor (DEPRECATED)	BSF の後処理を実行
3	JSR223 PostProcessor	JSR-223 の後処理を実行
4	JDBC PostProcessor	SQL の後処理を実行

#	ポストプロセッサ名	説明
1	Regular Expression Extractor（正規表現抽出）	応答を正規表現を使って解析してパラメタを抽出
2	CSS/JQuery Extractor	応答を CSS/JQuery ライクなセレクタの文法を使って解析してパラメタを抽出
3	XPath Extractor	応答を XPath クエリー言語を使って解析してパラメタを抽出
4	JSON Extractor	応答を JSON-PATH syntax を使って解析してパラメタを抽出

補足（抽出系＝相関、負荷テストの本体）: この「抽出系ポストプロセッサ」こそが、
記録したスクリプトを動く負荷テストに変える要である。
応答に含まれる __VIEWSTATE、__RequestVerificationToken、
セッション ID などの可変値を次のリクエストに引き継ぐ（相関、correlation）。
具体的な手順は
Jmeterによる可変値の追跡を参照。

なお、JMeter 5.x では Boundary Extractor が追加されており、
「左境界文字列」「右境界文字列」を指定するだけで抽出できる。
正規表現より読みやすく、性能も良いため、
単純な挟み取りには Boundary Extractor を推奨する。

#	ポストプロセッサ名	説明
1	Debug PostProcessor	・・・
2	Result Status Action Handler	サンプラーが失敗したら、スレッドまたはテスト全体を終了する。

• テストをしているサーバから受け取った応答を検査し、その応答が正しい応答かどうかをチェックするためのコンポーネント。
• 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > アサーション > XXXX を選択。

#	アサーション名	説明
1	BeanShell Assertion	BeanShell でアサーションチェックを実行
2	BSF Assertion (DEPRECATED)	BSF でアサーションチェックを実行
3	JSR223 Assertion	JSR-223 でアサーションチェックを実行

#	アサーション名	説明
1	Response Assertion	Perl 互換の正規表現かプレインテキストで比較チェック
2	Compare Assertion	応答の比較チェック（大量のリソースを消費）
3	HTML Assertion	JTidy を使って応答の HTML 文法をチェック
4	XML Assertion	応答の XML 文法をチェック
5	XML Schema Assertion	応答の DTD などの XML Schema への準拠をチェック
6	XPath Assertion	well-formed や DTD のオプションを持つかチェック、もしくは JTidy を通して XPath のチェック
7	MD5Hex Assertion	JTidy を使って応答の MD5 ハッシュをチェック
8	SMIME Assertion	Mail Reader サンプラーの応答の署名をチェック

補足（アサーションは必須）: 負荷テストで
アサーションを置かないのは重大な誤りである。
HTTP 200 が返っていても、本文が
「セッションが切れました」「ただいま混み合っています」という
エラー画面であるケースは非常に多い。
この場合、JMeter は成功として集計するため、
「速くて安定していた」という誤った結論が出る。

最低限、主要な画面に Response Assertion で
正常時にのみ現れる文字列（画面タイトル等）を検査させる。
ただし、アサーション自体も CPU を消費するため、
正規表現ではなく「Contains」の平文一致を優先する。

#	アサーション名	説明
1	Duration Assertion	応答を与えられた時間内に受け取ったかどうかをチェック
2	Size Assertion	応答のサイズ（バイト数）が正しいか（等しい、より大きい、より小さい、等しくない）をチェック

• テスト中に収集した情報を表示したりファイルへ保存したりして、結果をレポーティングするためのコンポーネント。
• CUI（non-GUI）モード
  • 出力ファイルが構成されている場合はデータが保管される。
  • 出力ファイルのデータは、ワークベンチの適切なリスナーにロードして分析する。
• 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > リスナー > XXXX を選択。

#	リスナー名	説明
1	BeanShell Listener	サンプルの結果に対して BeanShell を適用する。
2	BSF Listener (DEPRECATED)	サンプルの結果に対して BSF を適用する。
3	JSR223 Listener	サンプルの結果に対して JSR-223 を適用する。

リソースの消費量が大きいので、負荷テスト時は削除するか設定を変更する。

• レポート用

#	リスナー名	説明
1	View Results in Table（結果を表で表示）	すべてのサンプル結果の行を作成
2	View Results Tree（結果をツリーで表示）	サンプル応答のツリーに、すべてのサンプルの応答を表示
3	Graph Results	すべてのサンプル時間をプロットする簡単なグラフを生成

• アサーション用

#	リスナー名	説明
1	Assertion Results（アサーション）	Assertion エレメントの結果を表示
2	Comparison Assertion Visualizer	Compare Assertion エレメントの結果を表示

移行メモ（正誤）: 原典の「レポート用」の表は
連番が 1, 2, 2 となっていたため、1, 2, 3 に修正した。

リソースの消費量が小さいので、負荷テスト時に利用する。

#	リスナー名	説明
1	Aggregate Report（統計レポート）	テストで異なる名前の要求ごとにテーブル行を作成する。
2	Aggregate Graph	テストで異なる名前の要求ごとに棒グラフを生成し、PNG ファイルを保存する。
3	Summary Report	統計レポートと似ているが、メモリ使用量が少ない点が異なる。
4	Response Time Graph	応答時間を、ラベル付きの要求毎に示す折れ線グラフに描画
5	Simple Data Writer	結果をファイルに記録（GUI には表示されない）
6	Sample Result Save Configuration	結果ログファイル（JTL）に異なる項目を保存するように設定

補足（最新化：本番測定ではリスナーを置かない）: 「リソースの消費量が小さい」と
書かれているリスナーであっても、
GUI モードで実行する限り、測定結果は信用できない。
JMeter 自身が Swing の描画とサンプル保持に CPU とメモリを費やし、
それがボトルネックになるためである。

現在の定石は次のとおり。

1. GUI ではシナリオの作成とデバッグのみを行う。

2. 本番測定は CLI（non-GUI）モードで実行する。

   jmeter -n -t test.jmx -l result.jtl -e -o report_dir
   

3. -e -o で HTML ダッシュボードを生成し、そちらで分析する。

この方式なら、テスト計画にリスナーを 1 つも置かなくても
-l の JTL からすべてのレポートが生成できる。
詳細はJmeterの結果のレポーティングを参照。

#	リスナー名	説明
1	Save Responses to a file	テストの作成のために結果をファイルに記録
2	Generate Summary Results	テスト実行の要約をログファイルおよび/または標準出力に生成
3	Mailer Visualizer	失敗応答を受信するとメールを送る
4	Backend Listener	BackendListenerClient のカスタム実装をプラグインできる非同期リスナー

補足（Backend Listener が実務の主役）: Backend Listener は
測定結果を実行中にリアルタイムで外部に送出する非同期リスナーで、
InfluxDB + Grafana の組み合わせが事実上の標準になっている。

• 非同期なので測定への影響が小さい。
• 長時間テストの途中経過を見られる（劣化の開始時刻が分かる）。
• サーバ側のメトリクス（CPU・メモリ・GC）と
  同一の時間軸で重ねられるため、因果の特定が容易になる
  （因果関係の分析例）。

JMeter 5.x では InfluxDB / Graphite 用の実装が標準同梱されている。

• スレッドグループまたは WorkBench に配置できる。
• Include Controller および Module Controller とともに使用される。

Test Fragment で代替テスト計画に迅速かつ容易に切り替えて実行。

以下で作成した外部の JMX ファイルをインクルードする。

• テスト計画の下にテストフラグメントを作成、
• その下に任意のサンプラー、ロジックコントローラーなどを追加。
• 次に、テスト計画を外部の JMX ファイルに保存。

• すべての JMeter 変数および/またはプロパティの値を含むサンプルを生成。
• サンプルの値は、「結果ツリー・リスナー応答データの表示」ペインに表示される。

• 以前のサンプラプロパティ、JMeter 変数、プロパティおよび/またはシステムプロパティの詳細を含むサンプルを生成。
• サンプルの値は、「結果ツリー・リスナー応答データの表示」ペインに表示される。

補足: この 2 つは相関（可変値の追跡）のデバッグで
最もよく使うため、覚えておくとよい。
実際の使い方は
Jmeterによる可変値の追跡を参照。
なお、本番測定時には必ず削除または無効化すること
（全変数を毎回文字列化するため重い）。

• Apache JMeter - User's Manual: Functions and Variables
  http://jmeter.apache.org/usermanual/functions.html

補足（変数と関数の記法）: JMeter の記法は 2 系統ある。

記法	意味
変数の参照	${変数名}（スレッドごとに独立）
関数の呼び出し	${__関数名(引数,)}（アンダースコア 2 つ）
プロパティの参照	${__P(プロパティ名,既定値)}（全スレッド共通、CLI の -J で外から与えられる）

負荷テストの条件（スレッド数・Ramp-up・持続時間）を
プロパティ参照で書いておくと、
jmeter -n -t test.jmx -Jthreads=100 のように
JMX を編集せずに条件を変えられるため、
CI やパラメタ振りに便利である。

よくわからないが、以下の 3 つがあるもよう。

補足（3 つの関係）: 原典の「よくわからない」に答えると、
これらは「Java からスクリプト言語を呼ぶ仕組み」の世代交代である。

#	仕組み	位置付け
1	BeanShell	Java 風の文法を持つ独立したインタプリタ。JSR-274 として標準化が試みられたが成立せず、規格としては存在しない
2	BSF（Bean Scripting Framework）	Apache のスクリプト呼び出し抽象化。JSR-223 の前身
3	JSR-223（javax.script）	Java SE 6 で標準採用された正式規格。BSF を置き換えた

したがって現在の選択は JSR-223 + Groovy の一択であり、
BSF は JMeter 5.0 で削除、BeanShell は非推奨である
（前掲「スクリプト系」の補足を参照）。

• Apache Jmeter 入門
  https://net-newbie.com/jmeter/
• 今さら聞けない Apache JMeter の基本
  https://qiita.com/aidy91614/items/d96ca0261665abc54f7d

• Component Reference
  http://jmeter.apache.org/usermanual/component_reference.html
• Functions and Variables
  http://jmeter.apache.org/usermanual/functions.html
• Properties Reference
  http://jmeter.apache.org/usermanual/properties_reference.html

---

Tags: 移行, テスト, ツール類