「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 各種の設定方法と負荷テストの実施手順についてまとめる。
を行う。
設定 †
HTTPリクエスト †
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 ヘッダだけを送る。
- リクエストで送るパラメータ
クエリ・ストリングとして送るパラメータを指定する。
- リクエストと一緒に送信されるファイル
アップロードするファイルを指定する。
- Proxy Server
- サーバ名またはIP
- ポート番号
- ユーザー名
- パスワード
- Embedded Resources from HTML Files(画像, JavaScript, CSS等)
- 全てのイメージとアプレットを繰り返しダウンロードする(HTMLファイルのみ)
HTML ファイルをパースし、埋め込みリソースをGET。
- Use concurrent pool.
同時並行コネクションプールを使う。
- Size:
同時並行コネクションプールのサイズ
- URLs must match
GETする埋め込みリソースのURLとしてマッチさせたいものを正規表現で指定。
- Source address(HTTPClient 実装における HTTP リクエストのみ)
- ソースアドレスの型
ソースアドレスの値を区別するために型を選択する。
- ソースアドレスの値
・・・
- オプションタスク
- モニタとして使用
モニタ結果リスナーで使用する。
- Save response as MD5 Hash?
- 応答が結果に格納されなくなる。
- 代わりに、32 文字の MD5 ハッシュが格納される。
HTTPリクエスト初期値設定 †
認証設定 †
- 以下の認証がある場合、
- Basic
- Digest
- NTLM
- Kerberos
設定項目 †
- 基底URL
- ユーザー名
- パスワード
- Mechanism
Mechanism=KERBEROSの場合 †
追加で、以下の設定が必要。
- system.properties
- java.security.krb5.conf
- java.security.auth.login.config
- *.conf
- krb5.conf(Kerberos 構成ファイル)
- jaas.conf(JAASログイン構成ファイル)
HTTP関連の設定 †
Cookieの有効化 †
「設定エレメント」の「HTTP クッキーマネージャ」を追加する。
Cacheの有効化 †
「設定エレメント」の「HTTP Cache Manager」を追加する。
起動設定 †
プロキシ設定 †
自身がプロキシとして動作するが、
更に、プロキシを経由させる場合、起動オプションでプロキシ設定を行う。
jmeterWithProxy?.bat的なbatファイルを準備しておくと吉。
なお、この時、jmeter.batへのパスを、フルパスで記述しておくこと。
CUI(non-GUI)モード †
- 負荷テストの実行時は、CUI(non-GUI)モードで起動する。
- オプション
項番 | オプション | 説明 |
1 | -n | CUI(non-GUI)モードモードで起動 |
2 | -t [ファイル名] | テスト計画を格納するJMXファイル名 |
3 | -l [ファイル名] | テスト結果を保存するJTLファイル名 |
4 | -j [ファイル名] | 実行ログを保存するログファイル名 |
5 | -g [CSVファイル名] | (テストは実行せずCSVファイルを読み込んで)レポートを出力 |
6 | -e | 負荷テスト後にレポートを出力 |
7 | -o [フォルダ名] | レポートを出力するフォルダを指定。 存在しないフォルダ名か空のフォルダを指定。 |
負荷設定 †
多重度(仮想ユーザ数) †
多重度(仮想ユーザ数)は、スレッド数で設定する。
スループットの調整 †
の何れかで調整する。
- タイマを使用した方法
入力時間、思考時間を考慮してタイマを設定する。
- 定数タイマ
- スレッドグループやコントローラーなどのシナリオ以下に定数タイマを追加する。
- 以下の計算式を参考にして、スレッド遅延時間を設定する。
3,600秒
──────────────────── (秒/ページ) - 目標レスポンスタイム(秒/ページ) = スレッド遅延時間(秒/ページ)
x(シナリオ実行回数/時) * yページ/シナリオ
- 例えば、10ページのシナリオを10回実行する場合の目標レスポンスが3秒の場合
3,600秒
──────────── (秒/ページ) - 3(秒/ページ)
10 * 10 (ページ/時)
= 3,600/100(秒/ページ) - 3(秒/ページ)
= 36(秒/ページ) - 3(秒/ページ)= 33(秒/ページ)
- 定数スループット・タイマ
- スレッドグループやコントローラーなどのシナリオ以下に定数スループット・タイマを追加する。
- 以下の計算式を参考にして、1仮想ユーザ中のターゲットスループット(サンプル数/分)を設定する。
サンプル数/シナリオ (シナリオ実行回数/時)
──────────── * ──────────── = 1仮想ユーザ中のターゲットスループット(サンプル数/分)
1仮想ユーザ 60分
- 例えば、10サンプルのシナリオを10回実行する場合の目標レスポンスが3秒の場合
10サンプル/シナリオ 10シナリオ/時
──────────── * ────────
1仮想ユーザ 60分
100(サンプル/時)
= ───────── = 100/60(サンプル/分) = 1.666(サンプル/分)
1仮想 * 60分
手順 †
Jmeterの起動 †
以下に注意して、jmeter.batを起動する。
Java関係のパラメタ設定 †
必要に応じて、jmeter.batに、Java関係のパラメタ設定を行う。
管理者実行 †
jmeter.batを右クリックして、「管理者として実行」を選択する。
プロキシ設定 †
必要に応じて、jmeter.batに、プロキシ設定のコマンドライン引数を指定する。
言語の選択 †
必要に応じて「オプション → 言語の選択 → 日本」を設定。
初期設定 †
スレッドグループの追加 †
テスト計画に、スレッドグループを追加。
- ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
- 最低限、Webサーバ(サーバ名またはIP、ポート)項目の設定を行っておく。
- HTTP認証がある場合があるので、有効化しておく。
- なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
- 大概のWebアプリには、以下が使用されているので有効化しておく。
- Session Cookie
- Cookie認証Ticket
- なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
- 大概のWebサイトは静的コンテンツをキャシュ可能にしているので有効化しておく。
- なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
ワークベンチ設定 †
v4から表示されないので「テスト計画」側に追加する。
保存の設定 †
ワークベンチのSave Workbench チェック・ボックスをチェックにする。
負荷テストのワークロード(電文)のキャプチャを行う。
- 設定
- ポート番号は既定で「8888」になっているので、必要に応じて変更する。
- Test Plan Creationタブ > Test plan contents
- 記録先を指定するため、
[対象となるコントローラー]ドロップダウンリストから「テスト計画 > スレッドグループ名」を選択する。
- また、ページ単位でリクエストをまとめて記録するようにするため、
(Simple Controller以下に、HTTPリクエストのサンプラーが並ぶようになる)
[グループにする]ドロップダウンリストから「新規コントローラーへ各グループを置く」を選択する。
- リスナーの追加
- プロキシサーバー機能が記録したワークロードを確認するためにリスナーを追加する。
- HTTPプロキシサーバ(Test Script Recorder)に、「結果をツリーで表示」リスナーを追加する。
- 開始
- 設定画面中にある開始ボタン ( [▶] ) を押下する。
- HTTPプロキシサーバ(Test Script Recorder)が開始したかどうかは「netstat -a」で確認できる。
Webアプリの電文を記録 †
- ココまで来たら、一度、テスト計画(テスト計画-nnnnnn.jmx)を保存しておく。
- なお、この*.jmxファイルは、backupフォルダに10世代分、自動的に保持される。
ブラウザの設定 †
- その他、必要に応じて、各種ブラウザ設定を
サイトユーザのメジャー設定に合わせて変更しておく。
HTTPプロキシサーバ(Test Script Recorder)を開始しておく。
ブラウザを操作してワークロードを記録 †
- 以下は、当該PukiWiki?のページの新規作成と編集(削除)の操作をスクリプト化した例である。
- PukiWiki?の仕組みを知らなかったため、ソレを理解しつつ、スクリプトの整理を行った。
- このページは基本認証で守られているため、部外者は、新規作成と編集(削除)できません。
- また、実際に、このページに負荷テスト・ツールを使用して負荷をかけないで下さい。
ブラウザの設定を元に戻す †
先程のブラウザ設定を元に戻しておく。
スクリプトのデバッグ・検証と修正 †
- 必要に応じて「スクリプトのデバッグ・検証と修正」を実施する。
スクリプトのデバッグ・検証 †
スクリプトのデバッグ・検証と修正には、
HTTPとアプリケーションの知識が必要になる。
デバッグ実行 †
再生ボタンを押して、デバッグ実行してみる。
デバッグ †
正常に動作しない場合、以下の方法でデバッグする。
「結果を表で表示」リスナーを使用してデバッグする。
「結果をツリーで表示」リスナーを使用してデバッグする。
「アサーション(Response Assertion)」アサーションを使用してデバッグする。
- スレッドグループ以下に「アサーション(Response Assertion)」アサーションを追加する。
- 400 Bad Requestを検出する。
応答コード、一致する、400
- 500 Internal Server Errorを検出する。
応答コード、一致する、500
- カスタムのエラー画面を検出する。
テキストのレスポンス、含む、「開発用エラー画面」(等、任意の文字列)
問題を発見した場合 †
上記のデバッグで問題を発見した場合、下記のスクリプト修正を行う。
スクリプトの修正 †
スクリプトのデバッグ・検証と修正には、
HTTPとアプリケーションの知識が必要になる。
可変値の追跡 †
リクエスト → レスポンス → リクエストと持ち回る値を追跡し変数化する。
抽出系の後処理を使用して可変値を追跡 †
はじめに、
追跡した可変値をリクエストに組込 †
次に、リクエストに「抽出系の後処理」に準拠した「参照名」を使用する。
「可変値の追跡」後のスクリプト動作確認 †
CSVの前に、入力値を編集してみて、スクリプトが正常に動作するか確認する。
- ここでは、入力値の page と msg のパラメタを以下のように変更した。
- page="aaa" ---> page="bbb"
- msg="bbb" ---> msg="ccc"
- 下記のように、
- digest値の追跡前は編集(削除)に失敗するが、
- digest値の追跡後は編集(削除)が成功することを確認できた。
入力値にテストデータを組込む †
- 入力値に、CSVファイルなどを使用してテストデータを組み込む。
- これにより、現実に近いシミュレーションやデータ競合の回避が可能になる。
追加の可変値の追跡 †
同様にして、
- 入力値(page と msg)に関連するパラメタを、
- 可変値として追跡し(正規表現でリクエストから抽出)、
- 追跡した可変値をリクエストに組込に組み込む。
入力値にCSVファイルからの入力を適用 †
- 「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ファイル(csv.csv)
csv_page,csv_msg
aaa,bbb
bbb,ccc
ccc,ddd
ddd,eee
eee,fff
fff,ggg
CSVの変数をリクエストに組込 †
- Variable Namesに指定した変数は、
${変数名}としてリクエストに組み込み、使用できる。
- 上記の例では、
- pageのユーザ入力:${csv_page}
- msgのユーザ入力:${csv_msg}
と設定して、ユーザ入力をCSV入力に切り替える。
処理をループさせる †
- 全体をループさせる場合、
スレッドグループの設定でループさせることができる。
- 部分的にループさせる場合、
- ループコントローラーにループ回数を指定して部分的にループさせることができる。
- ログイン/ログアウト処理を一度だけ行い、内部をループさせる場合などに使用する。
CSV変数の組込後のスクリプト動作確認 †
CSVの変数をリクエストに組み込んだ後のスクリプトの動作確認を行う。
クライアントのCookie操作の再現 †
前処理を行うBeanShell PreProcessorにCookie操作の処理を記述する。
機能テスト、負荷テスト †
機能テスト †
1多重で、機能テストを行う。
負荷テスト †
n多重で、負荷テストを行う。
各種設定を行う。
GUIの利用 †
大規模なテストを行う場合 †
必要に応じて、複数のクライアントを準備して、
コントローラーから複数のエージェントを制御できる。
負荷テストの結果のレポーティング用のリスナーを設定する
注意事項 †
HTTPS対応 †
キャプチャの際、ブラウザにJmeterプロキシの証明書をインストールする。
- Jmeterプロキシの証明書は、
「HTTPプロキシサーバ(Test Script Recorder)」の開始後に、
「Jmeterを解凍したフォルダ\bin\」以下に生成される。
リダイレクト †
自動リダイレクト †
- 利用中の http プロトコルハンドラがリダイレクトに自動追従するようにする。
- 自動リダイレクトの応答は、Jmeterのサンプルとして追加されない。
※ 自動追従したリクエストにはクッキーが送信されないので注意。
リダイレクトに対応 †
- 「自動リダイレクト」が無効の場合、
応答がリダイレクトかどうかを チェックし、そうであればそれに従う。
- この場合のリダイレクトの応答は、Jmeterのサンプルとして追加される。
参考 †
株式会社ケイズ・ソフトウェア †
JMeter の利用方法
Tags: :テスト, :ツール類