先日、仕事でJMeterを使わせていただく機会がありました。Y-Kanohと申します。とはいえ、新卒2年目の私には何のことかさっぱりで...先輩に教えていただきながらの作業でした。

せっかくブログを書く機会があるので、同じ境遇の人が、「え、LatencyとSample Timeってどう違うの？」「実際にテストしたらコンピュータがフリーズした!!」「2時間たっても終わらないけど、どうすれば...(焦)」とならないように、簡単な例を用いてJMeterの使い方を紹介します。

そもそもJMeterって？

JMeterはApacheソフトウェア財団が開発しているオープンソースの負荷検証ツールです。サーバに対して指定した量のリクエストを送り、そのレスポンスを受けることで、パフォーマンス計測することができます。

JMeterはApacheの公式サイトからダウンロードできます。（Javaを入れていない方は、インストールしてからご使用ください。）

JMeterはGUIモードとNon-GUIモードがありますが、ここではGUIモードの説明をします。今回は例として、サーバ192.168.99.100のtest.htmlに2つのパラメータ「param1」と「param2」を送信する例を考えます。

スレッドグループの追加

以下がJMeterの起動画面です。

ダウンロードしたファイルのbinディレクトリにあるjmeter.bat(Windows) もしくはjmeter(Unix)を実行することで開きます。

まず、テスト計画を作成するため、スレッドグループを作成します。左上の「テスト計画」を右クリックし、 追加 > Threads(Users) > スレッドグループ を選択してください。新しいスレッドグループが作成されます。

スレッドグループの設定画面でも設定することがあるのですが、今はひとまず置いておきましょう。

送信するHTTPリクエストの追加と設定

次にスレッドグループで送信するリクエストを設定します。

今回は一番基本的なHTTPリクエストを送るため、左画面のスレッドグループ名を右クリックし、追加 > サンプラー > HTTPリクエスト を選択し、作成された「HTTPリクエスト」にてWebサーバとリクエストの設定を行います。

まず、リクエストを送信するWebサーバの設定。「プロトコル」にはhttpを入力し、「サーバ名またはIP」には負荷検証を行うサーバを指定します。

次に、HTTPリクエストの設定です。

「メソッド」には、送信メソッドを指定します。とりあえず、今回は「GET」を指定。

「パス」には、リクエスト送信先のリソースを指定します。

送信するリクエストパラメータを設定します。画面下の「追加」ボタンから複数追加することができ、パラメータの名前と値をそれぞれ指定することができます。

これで、送信するHTTPリクエストを設定できました。

スレッドグループの設定

さて、HTTPリクエストが設定出来たら、スレッドグループの設定に戻りましょう。

スレッドグループでは、先ほど設定したHTTPリクエストをどのように、どれぐらいの量、どれぐらいの期間で送信するかを設定できます。*1

これらを決定するのが、スレッド数、Ramp-Up期間、ループ回数です。

Ramp-Up期間

Ramp-Up期間が一番わかりやすいでしょうか。

Ramp-Up期間は、全リクエストの作成時間です。

「スレッド数」で設定したリクエスト群を、何秒間で作成するかを決めるのがRamp-Up期間です。

例えば、Ramp-Up期間を100(秒)、スレッド数を10とすると、 JMaterは100秒かけて10スレッド分のリクエストを送信しようとします。

ただし、Ramp-Up期間はあくまで「リクエストの作成時間」であり、テストの実行時間ではありません。負荷検証するサーバの処理速度がテストに追いつかない場合は、この時間を大幅にオーバーしてしまいます。

もし、一定時間でテストを中断したい場合は、同画面の「スケジューラ」にチェックを入れて、終了時間を設定してください。

スレッド数とループ回数

スレッド数は、「リクエスト群を送信する回数」のことです。

ここで重要なのことは、スレッドは「リクエスト」ではなく「リクエスト群」であること。

1スレッドでは複数のリクエストを送信することができます。

では、この「リクエスト群」内のリクエスト数はどうやって設定するかというと、「ループ回数」で指定します。

要するに、ループ回数は「1スレッドで送信するリクエストの量」を決める値です。

テスト実行時に送られる総リクエスト数は、この「スレッド数」と「ループ回数」の積によって決まります。

総リクエスト数 = スレッド数 × ループ回数

※スレッド数 = 総リクエスト数ではありませんよ。

この3パラメータの関係を時系列で図にまとめると、以下のような感じですね。

また、スレッドグループでは、スケジューラを用いることでテストの開始時間や終了時間を設定できます。

テスト実行中はリクエストを送信する端末にも負荷がかかるため、これで夜間などにテストを実行させておけば楽(?)できますよ。

テスト計画作成の注意点

スレッド数、Ramp-Up期間、ループ回数を用いてテスト計画を作ることができますが、ここであまりに大量のリクエストを投げようとすると、 JMeterを実行する端末のCPUが食い散らかされてしまします。

デフォルト設定のJMeterは、たとえRamp-Up期間が長時間だったとしても、テスト開始と同時に、スレッド数で指定したスレッドを作ってから、テストを実行するそうで、スレッド数の量によっては、一発でフリーズしてしまいます。*2

この場合、スレッドグループの設定画面にあるDelay Thread creation until neededにチェックを入れることで、スレッドの作成をずらすことができます。*3

JMeter has an option to delay thread creation until the thread starts sampling, i.e. after any thread group delay and the ramp-up time for the thread itself. This allows for a very large total number of threads, provided that not too many are active concurrently.

Apache JMeter - User's Manual: Best Practices

リスナーの追加

テストの実行結果を表示するリスナーを追加します。

左画面のスレッドグループを右クリックし、 追加 > リスナー > 結果を表で表示 を選択します。

続けて 追加 > リスナー > 統計レポート も追加しておきます。

他にも下図のように様々な結果の表示方法があるので、用途によって使い分けてください。

ただし、あまりリスナーを増やしてしまうと、メモリをたくさん使ってしまいますので、必要最低限にする必要があります。

（特に、今回用いる「結果を表で表示」は、全サンプルの結果を表示するのでたくさんメモリを使ってしまうそうです。）

また、各リスナーは、テスト実施前にファイル名を指定することで、全てのデータをファイルに出力することができるので、テスト結果に対して実行後に何らかの処理を加えたい場合は指定してください。

ここまでで作ったテスト計画は、ファイルとして保存できます。

テスト計画を選択したうえで保存ボタンを押下し、保存しておきましょう。

テスト計画の実行と結果の見方

いよいよテスト実施です。

まずはあまり負荷が高くない条件で動かしてみましょう。

画面上部の「開始」ボタンでテストを開始でき、テストを開始すると、画面右上のアイコンが緑色になり、終了すると灰色に戻ります。

以下の画面では、スレッド数:5、Ramp-Up期間:10秒、ループ回数:20 でテストを実施した場合の「結果を表で出力」画面です。

表項目それぞれの意味は次の通り。

項目名	意味
Sample	リクエストの番号
StartTime	リクエストの送信を始めた時間
Sample Time(ms)	リクエストの送信からレスポンスを受け終わるまでにかかった時間
Status	レスポンスのステータスを示す
Bytes	受信データのバイト数
SendByte	送信したバイト数
Latency	リクエストを送ってからレスポンスが届いた時間
Connect Time(ms)	JMeterがサーバとの接続確立にかかった時間

ちょっと時間にかかわる用語がややこしいので、図で説明します。また、結果をファイルへ出力する際に出力できる「Elapsed time」についても併せて説明します。

JMeterが1リクエストを送信してレスポンスを受信するまでの処理は、上の図のように行われます。

Start Timeはその名の通り、処理を開始した時刻です。（結果をファイル出力した場合はマシンタイムで表されます。）

JMeterは、処理開始後、サーバとのHTTP接続の確立を行います。この接続の確立にかかる時間がConnect Timeです。もし、このConnect Timeに時間がかかる場合、JMeterからの接続要求が待たされている可能性があるので、サーバの同時接続条件などを見直したほうがいいかもしれません。

JMeterは、接続が確立されると、リクエストを送信し始めます。

全てのリクエストが送信されると、サーバの処理が終わるまで待機し、サーバからレスポンスが返ってくるとレスポンスを受信し始め、すべてのレスポンス情報を受け取ると処理終了となります。

余談ですが、JMeterはブラウザと違い、受信したレスポンスに対して処理を行いません。したがって、（当たり前ですが）JavaScriptのようなブラウザ側での処理は、JMeterの結果に影響することはありません。

Elapsed Timeはリクエストを送信し始める直前から、すべてのレスポンスを受信した直後までの時間です。

Latencyは、日本語に訳すと「潜時」と言って、「刺激が与えられてから反応するまでの時間」のことです。

JMeterでは、「処理開始時間」から、「最初のレスポンスが返ってきた直後」の時間を指します。

（少しややこしいのですが、JMeterの公式リファレンスの「Connect Time」の項によると、LatencyはConnect Timeを含んだ時間になるそうです。そのため、接続エラーが起きたリクエストでは、Connect Time = Latency になります。）*4

Sample Timeは、これらの処理すべてにかかった時間です。

ちなみに、全リクエストの通し番号である「Sample」は、この終了時間の昇順で割り当てられているらしいので、Start Timeが前後していても気にしなくていいそうですよ。*5

「統計レポート」リスナーには、全サンプルの統計情報が記載されます。

たくさんのリクエストを送信するテストの場合、どうしてもすべてを見ることは不可能なので、統計情報を参考にしてください。

おわりに

さあ、これでざっくりですが、JMeterの基本的な機能は使えるようになりました。

リクエスト数を増やして、いざ、テスト！ ...と考えた方、ちょっと待ってください！

これだけ説明しておいてですが、ApacheはGUIモードでの本番テストを推奨していません!! *6

Don't run load test using GUI mode !

GUI mode should only be used for creating the test script, NON GUI mode must be used for load testing

Apache JMeter - User's Manual: Getting Started

Non-GUIモードのほうがより正しい結果を得られるため、GUIモードはテスト計画の作成のみに使い、実際のテストはNon-GUIモードを使ってほしいそうです。

斯く言う私も、この記事を書くため公式ドキュメントを読んで気づきました(^^;)

より正確な結果が求められるテストを行う場合は、GUIモードでテスト計画を作成、上部メニューの保存ボタンから保存したのち、 Non-GUIモードから読み込んでお使いください。

以上、基本的な内容ですが、私が業務で使ったJMeterの使い方について、説明しました。

もし、はじめての負荷検証であたふたしている人の助けになれば、幸いです。

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム

https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！