Skip to content

MS_JMeterWebAppLoadTest

Jump to bottom
nishi_74322014 edited this page Aug 18, 2026 · 1 revision

JmeterによるWebアプリの負荷テスト

概要

設定

HTTPリクエスト

HTTP リクエストのサンプラーを追加して使用する。

プロパティ

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

  • 名前
    HTTP リクエストの名前（ID？）。
  • コメント
    HTTP リクエストのコメント。
  • Web サーバ
    • サーバ名または IP
      テストするサーバ名または IP アドレス（http:// は書くとエラーになるので注意）
    • ポート
      http なら 80、https なら 443 など。
  • プロトコル
    HTTP（既定値）/ HTTPS / FILE のいずれか。
  • メソッド
    GET（既定値）, POST, HEAD, TRACE, OPTIONS, PUT, DELETE, PATCH
  • パス
    • / から始まる（サーバ名または IP アドレスを除いた）パス
    • パスは URL エンコードされないので注意（URL エンコードされたものを指定）。
    • クエリ・ストリングを付加したい場合は後述の「リクエストで送るパラメータ」に記載。
    • フルパスの場合、サーバ名または IP、ポート、プロトコル、クエリ・ストリングは無視される。
  • Timeouts(millisecond)
    • Connect
      接続タイマー
    • Response
      応答タイマー
  • HTTP リクエスト
    • Implementation
      • Java, HttpClient3.1, HttpClient4（既定値）
      • 既定値は Jmeter の jmeter.httpsampler プロパティの値にも依存。
    • Content encoding
      • （POST, PUT, PATCH, FILE に対して）使われる Content encoding。
      • HTTP の Content-Encoding ヘッダには影響しない。
    • KeepAlive を有効にする
      • Jmeter に Connection: keep-alive ヘッダをセットさせる。
      • Apache HttpComponents の HttpClient 実装であれば正しく動作する。
    • multipart/form-data
      • Use multipart/form-data for POST
        multipart/form-data もしくは application/x-www-form-urlencoded を使った POST リクエストを使用。
      • Browser-compatible headers
        multipart/form-data を使う際、Content-Type および Content-Transfer-Encoding ヘッダを使わず、Content-Disposition ヘッダだけを送る。
    • リクエストで送るパラメータ
      クエリ・ストリングとして送るパラメータを指定する。
    • リクエストと一緒に送信されるファイル
      アップロードするファイルを指定する。
    • Redirect
  • Proxy Server
    • サーバ名または IP
    • ポート番号
    • ユーザー名
    • パスワード
  • Embedded Resources from HTML Files（画像, JavaScript, CSS 等）
    • 全てのイメージとアプレットを繰り返しダウンロードする（HTML ファイルのみ）
      HTML ファイルをパースし、埋め込みリソースを GET。
    • Use concurrent pool.
      同時並行コネクションプールを使う。
    • Size:
      同時並行コネクションプールのサイズ
    • URLs must match
      GET する埋め込みリソースの URL としてマッチさせたいものを正規表現（MS_RegularExpression.md）で指定。
  • Source address（HTTPClient 実装における HTTP リクエストのみ）
    • ソースアドレスの型
      ソースアドレスの値を区別するために型を選択する。
    • ソースアドレスの値
      ・・・
  • オプションタスク
    • モニタとして使用
      モニタ結果リスナーで使用する。
    • Save response as MD5 Hash?
      • 応答が結果に格納されなくなる。
      • 代わりに、32 文字の MD5 ハッシュが格納される。

補足（Implementation は既定のままでよい）: HttpClient3.1 は JMeter 5.0 で削除され、
現在の選択肢は Java / HttpClient4 の 2 つである。
HTTP/2 を測定したい場合は、JMeter 5.x 同梱の
HTTP2 サンプラー（別プラグイン、または bolt 系と同様の追加要素）を使う。
HttpClient4 は HTTP/1.1 までしか話せない。

なお、「モニタとして使用」は JMeter 3.2 で削除された
（Tomcat の status ページを監視する機能で、現在は
Backend Listener + Grafana に置き換わっている）。

補足（埋め込みリソースの扱いが結果を大きく変える）: 「全てのイメージとアプレットを
繰り返しダウンロードする」を有効にすると、
1 リクエストが実際のブラウザに近い数十リクエストに膨らむ。
これは現実的な一方、次の点に注意が要る。

  • 測定対象が静的ファイル配信になりがちである。
    アプリのボトルネックを探すのが目的なら、
    URLs must match で自ドメインの動的パスだけに絞る。
  • ブラウザのキャッシュが効く分、実運用より過大な負荷になる。
    HTTP Cache Manager を併用して現実に寄せる。
  • CDN 配信のリソースまで叩くと、
    他社のサービスに負荷をかけることになる。必ず除外する。

HTTPリクエスト初期値設定

認証設定

設定項目

  • 基底 URL
  • ユーザー名
  • パスワード
  • Mechanism

Mechanism=KERBEROSの場合

追加で、以下の設定が必要。

補足（現在の Web アプリはトークン認証）: ここに挙がっているのは
いずれも HTTP 標準の認証方式（WWW-Authenticate ヘッダを使うもの）であり、
HTTP 認証マネージャで扱えるのはこの範囲である。

一方、現在の Web アプリの主流である
フォーム認証・Cookie 認証・OpenID Connect / OAuth 2.0 は
HTTP 認証ではないため、HTTP 認証マネージャでは扱えない。
これらは次のように、通常のリクエストとして記録・相関する。

認証方式 JMeter での扱い
フォーム認証 ログイン POST を記録し、Cookie マネージャでセッションを保持
Cookie 認証チケット 同上（Cookieの有効化）
Bearer トークン トークン取得リクエストの応答から抽出し、HTTP ヘッダマネージャで Authorization: Bearer ${token} として付与
OIDC / OAuth 2.0 認可コード フローを一連のリクエストとして記録し、code / state を相関する

トークンの抽出方法は
Jmeterによる可変値の追跡を参照。

HTTP関連の設定

Cookieの有効化

「設定エレメント」の「HTTP クッキーマネージャ」を追加する。

Cacheの有効化

「設定エレメント」の「HTTP Cache Manager」を追加する。

起動設定

プロキシ設定

自身がプロキシとして動作するが、
更に、プロキシを経由させる場合、起動オプションでプロキシ設定を行う。

jmeter -H my.proxy.server -P 8000 -u username -a password

jmeterWithProxy.bat 的な bat ファイルを準備しておくと吉。
なお、この時、jmeter.bat へのパスを、フルパスで記述しておくこと。

CUI（non-GUI）モード

  • 負荷テストの実行時は、CUI（non-GUI）モードで起動する。
  • 「テスト計画-nnnnnn.jmx」に定義されたテストを実施して log.jtl に結果を出力。
jmeter -n -t テスト計画-nnnnnn.jmx -l log.jtl
  • オプション
項番 オプション 説明
1 -n CUI（non-GUI）モードで起動
2 -t [ファイル名] テスト計画を格納する JMX ファイル名
3 -l [ファイル名] テスト結果を保存する JTL ファイル名
4 -j [ファイル名] 実行ログを保存するログファイル名
5 -g [CSVファイル名] （テストは実行せず CSV ファイルを読み込んで）レポートを出力
6 -e 負荷テスト後にレポートを出力
7 -o [フォルダ名] レポートを出力するフォルダを指定。
存在しないフォルダ名か空のフォルダを指定。

移行メモ（体裁）: 原典の表 1 行目は
「CUI（non-GUI）モードモードで起動」と
「モード」が重複していたため修正した。

補足（実務で追加したいオプション）: 上記に加え、次の 2 つを覚えておくとよい。

オプション 説明
-J<プロパティ名>=<値> JMeter プロパティを上書き。${__P(threads,10)} と組み合わせ、JMX を編集せずに条件を変える
-G<プロパティ名>=<値> 分散実行時、全リモート エージェントにプロパティを配布
-R <host1>,<host2> 指定したリモート エージェントで分散実行
-r remote_hosts プロパティのエージェント全てで分散実行

典型的な実行例は次のとおり。

jmeter -n -t test.jmx -l result.jtl -e -o report \
       -Jthreads=200 -Jrampup=120 -Jduration=600

-e -o を付ければ HTML ダッシュボードまで一気に出力される
（Jmeterの結果のレポーティング）。
なお、-o に指定するフォルダは空でなければエラーになるため、
CI で回す場合は実行前に削除する処理を入れておく。

負荷設定

多重度（仮想ユーザ数）

多重度（仮想ユーザ数）は、スレッド数で設定する。

スループットの調整

  • スループットは、

    • Ramp-up期間（秒）

      １秒中の同時アクセス仮想ユーザー数 = （仮想ユーザ数 * ループ回数） / Ramp-up期間（秒）

    • タイマ

      • 定数タイマ
      • 定数スループット・タイマ

    の何れかで調整する。

  • Ramp-up期間（秒）を使用した方法
    本来、「Ramp-up 期間（秒）」は、
    多重度（仮想ユーザ数）を徐々に増加させるための用途で使用するため、
    スループットの調整には、「タイマ」を使用した方法が推奨される。

  • タイマを使用した方法
    入力時間、思考時間を考慮してタイマを設定する。

    • HTTPリクエストのサンプラー以下に、下記タイマを追加する。
    • 定数タイマ

      • スレッドグループやコントローラーなどのシナリオ以下に定数タイマを追加する。

      • 以下の計算式を参考にして、スレッド遅延時間を設定する。

                         3,600秒
──────────────────── (秒/ページ) - 目標レスポンスタイム（秒/ページ） = スレッド遅延時間(秒/ページ)
   x(シナリオ実行回数/時) * yページ/シナリオ

      • 例えば、10 ページのシナリオを 10 回実行する場合の目標レスポンスが 3 秒の場合

                3,600秒
 ──────────── (秒/ページ) - 3（秒/ページ）
   10 * 10 (ページ/時)

 = 3,600/100(秒/ページ) - 3（秒/ページ）

 = 36(秒/ページ) - 3（秒/ページ）= 33(秒/ページ)

      • 定数タイマ : 33(秒/ページ)

    • 定数スループット・タイマ

      • スレッドグループやコントローラーなどのシナリオ以下に定数スループット・タイマを追加する。

      • 以下の計算式を参考にして、1 仮想ユーザ中のターゲットスループット（サンプル数/分）を設定する。

           サンプル数/シナリオ       (シナリオ実行回数/時)
 ──────────── * ──────────── = １仮想ユーザ中のターゲットスループット（サンプル数/分）
       １仮想ユーザ                   60分

      • 例えば、10 サンプルのシナリオを 10 回実行する場合の目標レスポンスが 3 秒の場合

           10サンプル/シナリオ       10シナリオ/時
 ──────────── * ────────
       １仮想ユーザ              60分

     100(サンプル/時)
 =  ───────── = 100/60(サンプル/分) = 1.666(サンプル/分)
       １仮想 * 60分

      • 定数スループット・タイマ : 1.666(サンプル/分)

補足（この 2 つの計算式が本ページ最大の実用情報）: 見落とされがちだが、
ここは「業務要件（1 時間に何回、何ページ）から
ツールの設定値を機械的に導く」という手順を与えている。

  • 定数タイマは「1 ページあたりどれだけ待つか」を求める式。
    総所要時間からレスポンスタイムを引いた残りが思考時間である、
    という素直な引き算になっている。
  • 定数スループット・タイマは「1 分あたり何サンプル流すか」を求める式。
    前掲のとおり**単位が「分あたり」**である点が要注意。

なお、定数スループット・タイマには
「Calculate Throughput based on」という設定があり、
「this thread only」（既定）のままだと
上式のとおり1 仮想ユーザあたりの値になる。
全体で 100 サンプル/分にしたい場合は
**「all active threads」**を選び、全体値を入れる。ここは事故が多い。

また、これらのタイマはスループットを上げることはできない
（待ち時間を挿入するだけなので、上限を抑えるのみ）。
目標に届かない場合はスレッド数を増やす必要がある。

手順

Jmeterのインストール

Jmeterの起動

以下に注意して、jmeter.bat を起動する。

Java関係のパラメタ設定

必要に応じて、jmeter.bat に、Java関係のパラメタ設定を行う。

管理者実行

jmeter.bat を右クリックして、「管理者として実行」を選択する。

プロキシ設定

必要に応じて、jmeter.bat に、プロキシ設定のコマンドライン引数を指定する。

言語の選択

必要に応じて「オプション → 言語の選択 → 日本」を設定。

初期設定

スレッドグループの追加

テスト計画に、スレッドグループを追加。

HTTPリクエスト初期値設定

  • ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
  • 最低限、Web サーバ（サーバ名または IP、ポート）項目の設定を行っておく。

HTTP認証の有効化

  • HTTP 認証がある場合があるので、有効化しておく。
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

Cookieの有効化

  • 大概の Web アプリには、以下が使用されているので有効化しておく。
    • Session Cookie
    • Cookie 認証 Ticket
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

Cacheの有効化

  • 大概の Web サイトは静的コンテンツをキャッシュ可能にしているので有効化しておく。
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

ワークベンチ設定

v4 から表示されないので「テスト計画」側に追加する。

保存の設定

ワークベンチの Save Workbench チェック・ボックスをチェックにする。

補足: 前項のとおり v4 以降にワークベンチは存在しないため、
この「保存の設定」も v4 以降では不要である（v3.x 向けの記述）。
v4 以降はテスト計画の一部として .jmx に保存される。

HTTPプロキシサーバ（Test Script Recorder）

負荷テストのワークロード（電文）のキャプチャを行う。

  • 追加
    ワークベンチに、Jmeter の「HTTP プロキシサーバ（Test Script Recorder）」機能を追加する。
  • 設定
    • ポート番号は既定で「8888」になっているので、必要に応じて変更する。
    • Request Filtering タブ
      「挿入するパターン」に記録対象となるURLを正規表現で追加する。
    • Test Plan Creation タブ > Test plan contents
      • 記録先を指定するため、
        ［対象となるコントローラー］ドロップダウンリストから「テスト計画 > スレッドグループ名」を選択する。
      • また、ページ単位でリクエストをまとめて記録するようにするため、
        （Simple Controller 以下に、HTTPリクエストのサンプラーが並ぶようになる）
        ［グループにする］ドロップダウンリストから「新規コントローラーへ各グループを置く」を選択する。
    • リスナーの追加
      • プロキシサーバー機能が記録したワークロードを確認するためにリスナーを追加する。
      • HTTP プロキシサーバ（Test Script Recorder）に、「結果をツリーで表示」リスナーを追加する。
  • 開始
    • 設定画面中にある開始ボタン（ [▶] ）を押下する。
    • HTTP プロキシサーバ（Test Script Recorder）が開始したかどうかは netstat -a で確認できる。

補足（除外フィルタを必ず入れる）: 「挿入するパターン」（include）だけでなく、
**「除外するパターン」（exclude）**の設定が実務では重要である。
何も除外しないと、ブラウザが裏で出す
証明書失効確認・テレメトリ・拡張機能の通信まで記録され、
スクリプトが読めなくなる。

JMeter の Test Script Recorder には
「Add suggested Excludes」ボタンがあり、
.*\.(bmp|css|js|gif|ico|jpe?g|png|swf|woff|woff2) 相当の
静的リソース除外を一括で入れられる。まずこれを押すとよい。

なお、静的リソースを除外して記録しても、
HTTPリクエストの
「埋め込みリソースをダウンロード」で実行時に取得させれば、
記録は読みやすく、負荷は現実的という両立ができる。

Webアプリの電文を記録

  • ココまで来たら、一度、テスト計画（テスト計画-nnnnnn.jmx）を保存しておく。
  • なお、この *.jmx ファイルは、backup フォルダに 10 世代分、自動的に保持される。

ブラウザの設定

  • プロキシ設定で Jmeter プロキシを設定する。
  • 閲覧履歴（キャッシュ）を削除しておく。
  • その他、必要に応じて、各種ブラウザ設定を
    サイトユーザのメジャー設定に合わせて変更しておく。

HTTPプロキシサーバ（Test Script Recorder）の開始

HTTP プロキシサーバ（Test Script Recorder）を開始しておく。

ブラウザを操作してワークロードを記録

  • ブラウザを操作してワークロードを記録する。
  • 記録の度に、Simple Controller 以下に、HTTPリクエストのサンプラーが追加されていく。
  • このため、「結果をツリーで表示」リスナーで都度 電文を確認しつつ、以下を行う。
    • 不要な HTTP リクエストのサンプラーを削除。
    • 必要な HTTP リクエストのサンプラーの階層構造の整理。
    • Simple Controller、HTTP リクエストのサンプラーのリネーム。
  • 以下は、当該 PukiWiki のページの新規作成と編集（削除）の操作をスクリプト化した例である。
    • PukiWiki の仕組みを知らなかったため、ソレを理解しつつ、スクリプトの整理を行った。
    • このページは基本認証で守られているため、部外者は、新規作成と編集（削除）できません。
    • また、実際に、このページに負荷テスト・ツールを使用して負荷をかけないで下さい。

採取したワークロードを再現するスクリプト

補足（記録は「そのままでは動かない」）: 記録直後のスクリプトが
再生で失敗するのはむしろ正常である。
記録された電文にはその 1 回限りの値（セッション ID、CSRF トークン、
ここでいう digest 値など）が固定文字列として埋め込まれており、
2 回目以降はサーバに拒否されるためである。

これを可変値として取り出し直すのが
次章以降の可変値の追跡であり、
負荷テスト構築作業の実質的な本体である。

HTTPプロキシサーバ（Test Script Recorder）の停止

  • HTTP プロキシサーバ（Test Script Recorder）を停止、
  • 再び、テスト計画を保存しておく（テスト計画-nnnnnn.jmx）。

ブラウザの設定を元に戻す

先程のブラウザ設定を元に戻しておく。

スクリプトのデバッグ・検証と修正

スクリプトのデバッグ・検証

スクリプトのデバッグ・検証と修正には、
HTTP とアプリケーションの知識が必要になる。

デバッグ実行

再生ボタンを押して、デバッグ実行してみる。

スクリプトのデバッグ実行１

デバッグ

正常に動作しない場合、以下の方法でデバッグする。

「結果を表で表示」リスナーの追加

「結果を表で表示」リスナーを使用してデバッグする。

  • スレッドグループ以下に「結果を表で表示」リスナーを追加する。
  • 再度デバッグ実行し、「結果を表で表示」リスナーで、デバッグ実行を確認する。

「結果をツリーで表示」リスナーの追加

「結果をツリーで表示」リスナーを使用してデバッグする。

  • スレッドグループ以下に「結果をツリーで表示」リスナーを追加する。
  • 再度デバッグ実行し、「結果をツリーで表示」リスナーで、デバッグ実行を確認する。

「アサーション（Response Assertion）」アサーションの追加

「アサーション（Response Assertion）」アサーションを使用してデバッグする。

  • スレッドグループ以下に「アサーション（Response Assertion）」アサーションを追加する。
    • 400 Bad Request を検出する。
      応答コード、一致する、400
    • 500 Internal Server Error を検出する。
      応答コード、一致する、500
    • カスタムのエラー画面を検出する。
      テキストのレスポンス、含む、「開発用エラー画面」（等、任意の文字列）
  • スレッドグループ以下に「アサーション結果」リスナーを追加する。
  • 「アサーション結果」リスナーで、「Successes」を選択する。
  • 再度デバッグ実行し、「結果をツリーで表示」リスナーでデバッグ実行を確認する。

補足（「カスタムのエラー画面を検出する」が最重要）: 400 / 500 は
JMeter が既定で失敗と判定するため、実はアサーションが無くても検出できる。
本当に必要なのは 3 つ目の
**「HTTP 200 で返ってくるエラー画面」**の検出である。

.NET の Web アプリでは customErrors や例外フィルタにより
エラー画面を 200 で返す設定が珍しくなく、
この場合 JMeter は全件成功として集計してしまう。
負荷をかけた結果が「エラー率 0%、応答時間も良好」でも、
実は全リクエストがエラー画面だった、という事故になる。

対策として、正常時にのみ現れる文字列（画面のタイトル等）を
「含む」で検査する形にしておくのが確実である。

問題を発見した場合

上記のデバッグで問題を発見した場合、下記のスクリプト修正を行う。

スクリプトの修正

スクリプトのデバッグ・検証と修正には、
HTTP とアプリケーションの知識が必要になる。

可変値の追跡

リクエスト → レスポンス → リクエストと持ち回る値を追跡し変数化する。

抽出系の後処理を使用して可変値を追跡

はじめに、

追跡した可変値をリクエストに組込

次に、リクエストに「抽出系の後処理」に準拠した「参照名」を使用する。

「可変値の追跡」後のスクリプト動作確認

CSV の前に、入力値を編集してみて、スクリプトが正常に動作するか確認する。

  • ここでは、入力値の page と msg のパラメタを以下のように変更した。
    • page="aaa" ---> page="bbb"
    • msg="bbb" ---> msg="ccc"
  • 下記のように、
    • digest 値の追跡前は編集（削除）に失敗するが、
    • digest 値の追跡後は編集（削除）が成功することを確認できた。

スクリプトのデバッグ実行２

入力値にテストデータを組込む

  • 入力値に、CSV ファイルなどを使用してテストデータを組み込む。
  • これにより、現実に近いシミュレーションやデータ競合の回避が可能になる。

追加の可変値の追跡

同様にして、

  • 入力値（page と msg）に関連するパラメタを、
    • 可変値として追跡し（正規表現でリクエストから抽出）、
    • 追跡した可変値をリクエストに組み込む。
  • 「可変値の追跡」後のスクリプトの動作確認を行う。

スクリプトのデバッグ実行３

補足（データ競合の回避が「現実に近い」の本質）: 全仮想ユーザが
同じキーのデータを更新すると、
DB のロック待ちで詰まり（SQL Server でのデッドロック）、
実運用ではあり得ない性能劣化を測ってしまう。
逆に、全員が同じ 1 件を照会すると、
キャッシュに乗り切ってしまい過大に速い結果になる。

どちらも「測定用のデータ設計が現実と違う」ことに起因する。
CSV でユーザ・データを散らすのは、
単なる入力バリエーションではなく
測定を成立させるための前提条件である。

入力値にCSVファイルからの入力を適用

  • スレッドグループ以下に、「設定エレメント」の「CSV Data Set Config」を追加する。
  • 「CSV Data Set Config」には以下の設定を行い利用する。
    • Filename
      CSV ファイルのファイルパス
    • File Encoding
      CSV ファイルのエンコーディング（既定値は JavaVM の既定値）
    • Variable Names
      カンマ区切りの変数名（CSV のヘッダ行と同じ）
    • Ignore first line
      CSV ファイルにヘッダ行がある場合、true に設定しておく。
    • Delimiter
      CSV ファイルの区切り文字
    • Allow quoted data?
      改行を含むデータ等は、" で囲んだりする。
    • Recycle on EOF?
      CSV ファイルの終わりに到達した場合、先頭から再利用する。
    • Stop thread on EOF?
      CSV ファイルの終わりに到達した場合、仮想ユーザーを停止する。
    • Sharing mode
      CSV ファイルの共有モード
      • All threads
        全てのスレッドで共有
      • Current thread group
        スレッドグループで共有
      • Current thread
        個々のスレッドで利用（共有しない）
      • Identifier
        同じ識別子を共有するスレッドで共有
  • 「CSV Data Set Config」の設定例

    • 設定例

      CSV Data Set Config

    • CSV ファイル（csv.csv）

      csv_page,csv_msg
aaa,bbb
bbb,ccc
ccc,ddd
ddd,eee
eee,fff
fff,ggg

補足（File Encoding は必ず明示する）: 既定値の「JavaVM の既定値」は
Windows の日本語環境では MS932（Shift_JIS）、
Linux では通常 UTF-8 になるため、
同じ JMX が環境によって文字化けする。
分散実行や CI では特に問題になるので、
UTF-8 を明示しておくこと。

また、Recycle on EOF? と Stop thread on EOF? は
目的で使い分ける。

目的 設定
長時間の負荷テスト（データを使い回してよい） Recycle=true, Stop=false
データを 1 件ずつ消費（登録データが重複してはいけない） Recycle=false, Stop=true

後者で Recycle=true にすると、
2 周目以降が一意制約違反で全部エラーになる。

CSVの変数をリクエストに組込

  • Variable Names に指定した変数は、
    ${変数名} としてリクエストに組み込み、使用できる。

  • 上記の例では、

    • page のユーザ入力：${csv_page}
    • msg のユーザ入力：${csv_msg}

    と設定して、ユーザ入力を CSV 入力に切り替える。

処理をループさせる

  • 全体をループさせる場合、
    スレッドグループの設定でループさせることができる。
  • 部分的にループさせる場合、
    • ループコントローラーにループ回数を指定して部分的にループさせることができる。
    • ログイン/ログアウト処理を一度だけ行い、内部をループさせる場合などに使用する。

CSV変数の組込後のスクリプト動作確認

CSV の変数をリクエストに組み込んだ後のスクリプトの動作確認を行う。

結果

クライアントのCookie操作の再現

前処理を行うBeanShell PreProcessorに Cookie 操作の処理を記述する。

補足: 前掲のとおり BeanShell は非推奨であるため、
現在は JSR223 PreProcessor + Groovy で書く。
Cookie の操作は次のように行える。

import org.apache.jmeter.protocol.http.control.Cookie
def cm = sampler.getCookieManager()
cm.add(new Cookie("name", "value", "example.com", "/", false, 0))

なお、サーバが発行した Cookie を引き回すだけであれば
HTTP クッキーマネージャが自動で行うため、
スクリプトは不要である。ここで手書きが要るのは、
JavaScript がクライアント側で生成・書き換えする Cookie
（画面サイズの記録、A/B テストの割り当てなど）を
再現する場合に限られる。
JMeter はブラウザではないため JavaScript を実行しない、という
原理的な制約に由来する
（Jmeterによる3層C/Sの負荷テストも参照）。

機能テスト、負荷テスト

機能テスト

1 多重で、機能テストを行う。

負荷テスト

n 多重で、負荷テストを行う。

各種設定

各種設定を行う。

GUIの利用

  • GUI は電文の記録時やスクリプト修正時に使用し、負荷テスト実行時には使用しない。
  • 負荷テストの際は GUI で起動をしない。CUI（non-GUI）モードで起動する。

大規模なテストを行う場合

必要に応じて、複数のクライアントを準備して、
コントローラーから複数のエージェントを制御できる。

補足（分散実行の前に確認すること）: 分散実行に踏み切る前に、
本当にクライアント側が限界なのかを確認する。
「サーバが遅い」と思っていたら
JMeter 自身が飽和していたというのが最も多い失敗である。

確認項目 対処
JMeter 側の CPU 使用率が高い（80% 超） リスナー削除、GUI 停止、スクリプト系要素の見直し
GC が頻発 ヒープ拡張（Jmeterのインストール）
エフェメラル ポート枯渇 KeepAlive 有効化、TIME_WAIT の見直し
クライアントの NIC 帯域が飽和 分散実行が必要

分散実行では、コントローラー（マスタ）は結果の集約のみを行い、
負荷はエージェント（スレーブ）が生成する。
-R / -r オプションで起動し、
全ノードの JMeter バージョンと Java バージョンを揃えること。
また、集約通信は RMI であるため、
ファイアウォールとポート設定（server.rmi.localport 等）に注意する。

結果のレポーティング

負荷テストの結果のレポーティング用のリスナーを設定する。

注意事項

HTTPS対応

キャプチャの際、ブラウザに Jmeter プロキシの証明書をインストールする。

  • HTTPS を使用する場合、Jmeter プロキシの証明書を、
    クライアント端末の「信頼されたルート証明機関」にインストールする。
  • Jmeter プロキシの証明書は、
    「HTTP プロキシサーバ（Test Script Recorder）」の開始後に、
    「Jmeter を解凍したフォルダ ＼bin＼」以下に生成される。

移行メモ（正誤）: 原典は「HTTS」と誤記されていたため「HTTPS」に修正した。

補足: 生成されるのは ApacheJMeterTemporaryRootCA.crt で、
有効期間は 7 日である（既定。proxy.cert.validity で変更可）。
期限切れ後は再生成されるため、再度インポートが必要になる。
また、記録が終わったら
クライアント端末からこの証明書を削除すること。
残したままにすると、そのルート CA を信頼し続ける状態になり、
セキュリティ上望ましくない
（ネットワークの脆弱性対策）。

リダイレクト

自動リダイレクト

  • 利用中の http プロトコルハンドラがリダイレクトに自動追従するようにする。
  • 自動リダイレクトの応答は、Jmeter のサンプルとして追加されない。

※ 自動追従したリクエストにはクッキーが送信されないので注意。

リダイレクトに対応

  • 「自動リダイレクト」が無効の場合、
    応答がリダイレクトかどうかをチェックし、そうであればそれに従う。
  • この場合のリダイレクトの応答は、Jmeter のサンプルとして追加される。

補足（どちらを選ぶか）: 認証やセッションを伴う Web アプリでは、
「リダイレクトに対応」（Follow Redirects）を選ぶのが原則である。

設定 追従の主体 Cookie サンプルへの記録
自動リダイレクト（Redirect Automatically） HTTP クライアント実装 送られない されない
リダイレクトに対応（Follow Redirects） JMeter 本体 送られる される（子サンプル）

「自動リダイレクト」で Cookie が送られないのは、
HTTP クライアント実装が JMeter の Cookie マネージャを
経由しないためである。
ログイン後のリダイレクト先でセッションが失われる、という
典型的な不具合はこれが原因になる。

なお、リダイレクトを含む応答時間は
リダイレクト先を取得し終えるまでが計上される点にも注意する。

参考

株式会社ケイズ・ソフトウェア

JMeter の利用方法

移行メモ（体裁）: 上記 4 件の URL は
日本語タイトルを URL エンコードした非常に長いものであったため、
日付までのパスに短縮した（記事は日付から辿れる）。

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally