JMeter 基礎編 設定から動作完了まで

公開:2015-01-23 / ツール テスト / , , , ,
更新:2017-05-26

Web案件で負荷テストを実施するとなった場合、 Webサイトに負荷をかけるツールを利用することが多いかと思います。

 

以前、このサイトでも負荷テストの計画という記事の中で、負荷テストで利用する代表的な実施ツールとして、以下の名前をあげさせていただきました。

  • Apache JMeter
  • Apache Bench
  • Load Impact
  • HP LoadRunner

 

2016/4/12
負荷テストで利用するツールと、その選定方法について記事を書きました。コチラも参考ください。

 

それぞれメリット・デメリットがありますが、僕は「Apache JMeter」を利用することが多いです。

(Apache JMeterは、よくJMeterと略されるのでこのサイトでもJMeterと呼んでいます)

 

これまでにJMeterを使って様々は負荷テストを実施してきたわけですが、現状、そのナレッジは僕の頭にしかないのでどこかでアウトプットしたいと常々考えておりました。

 

ちょうど次のお仕事開始までちょっと時間が空いたので、本日は、僕の得意とするJMeterのベーシックな使い方を紹介したいと思います。

 

JMeterの準備

使い方を教える前に、JMeterを利用できる状態にする必要があります。

 

ここでは詳しい説明は割愛いたしますが、JMeterの準備という記事で紹介していますので、そちらを参考にしてください。

 

指標の策定

JMeterの準備ができたら早速ツールを使いたいところではありますが、その前に具体的な目的を決めておいた方が説明しやすいので、決めさせていただきます。

 

ここから先、説明するにあたり、負荷テストの目的を、

 

とあるサイトのトップページにおいて、1分間に1000アクセス処理が問題なく捌けるかを確認したい。

ただし、ユーザは100人とする。

 

と定めて進めていきます。

 

JMererの設定

それでは、JMeter を使っての説明に参ります。

 

JMeterを起動すると以下の画面が表示されます。

006

ここで、テスト計画の名前をつけることが出来ますので、わかりやすい名前に変更し保存します。

(保存しないと、左のメニューの名称が変更されません)

 

続いて、負荷レベルを設定します。

左のメニューから、先ほど名前をつけた計画名の上で右クリックし「追加 > Threads (users) > スレッドグループ」を選択します。

008

 

すると、スレッドグループの画面が表示されますので、名前とコメントを入力します。

009

ここには、コメントにテストシナリオを入れておくと管理しやすいです。

 

名前とコメントの入力が終わったら、その下にあるスレッドプロパティの箇所に、「スレッド数Ramp-Up期間ループ回数」を設定します。

 

この「スレッド数、Ramp-Up期間、ループ回数」の設定を行うことで負荷レベルを調整します。

 

が、名称からしてわかりづらいと思いますので、別記事に機能説明と負荷レベルの調整の仕方についてまとめています。詳しくはコチラをご参考ください。

 

ここでは、説明に必要な点のみを簡単に説明いたします。

  •  スレッド数:一度に実行するアクセスする数です。「アクセスするユーザ数」だと思っていただいてOKです。
  • Ramp-up期間:アクセス実行期間の指定です。なお、時間は秒で指定します。
  • ループ回数:シナリオを何回繰り返すか。

 

また、上記3つの他に

  • テストの総アクセス数 は 「スレッド数」×「ループ回数」で算出されること

 

も理解しておく必要があります。

 

簡単に説明したところで、先ほど定めた、

 

とあるサイトのトップページにおいて、1分間に1000アクセス処理が問題なく捌けるかを確認したい。

ただし、ユーザは100人とする。

 

という目的を実現するための負荷レベルの設定を考えていきます。

 

まず、ユーザが100人なので、スレッド数は100。

また、1分間の指定があるので、Ramp-Up期間はなので60。

最後にループ回数ですが、「総アクセス数」  =  「スレッド数」×「ループ回数」から逆算すると、 10。

 

上記を踏まえると、

  • スレッド数:100
  • Ramp-up:60
  • ループ回数:10

 

と設定することができます。

(実際のJMeterの実行イメージなど詳細をコチラにて紹介していますので参考にしてください)

 

次に、テストシナリオを設定します。

左メニューのスレッドグループ名から、右クリックで「追加 > サンプラー > HTTP リクエスト」を選択します。

010

 

ここでも名前とコメントを入力できます。こちらはページ名称を入れておくのが良いです。

(今回は1ページだけのシナリオですが、複数ページの遷移を確認する場合は、HTTPリクエストがページの数だけ追加されることになります)

011

 

入力したら、アクセスする対象のサーバ名(IP)ポートプロトコルメソッドパスを入力します。

 

サーバ名(IP)は、対象サイトのドメインかIPアドレスを入力します。

ポートは指定がなければ80を入れてください。(SSLの場合は443を指定してください。SSLでフォームを利用する場合は、JMeter httpsリクエストを記憶するを参照)

 

メソッドは、指定がなければGETを選択してください。(GET、POSTで動的に値を渡す場合は、JMeter フォームの負荷テストを参照)

 

パスは、アクセスするページを指定します。プロトコルとドメイン名だけでアクセスしたい場合は、「/」を入れてください。

 

次に、テスト結果を得るための設定をします。

左メニューから、スレッドグループで右クリックをして「追加 >  リスナー > 結果を表で表示」をクリックします。

012

 

こちらも名前を指定できます。

013

 

テスト結果は、もうひとつ設定します。

左メニューから、スレッドグループで右クリックをして「追加 >  リスナー> 統計レポート」をクリックします。

014

 

こちらも名前を指定できます。

015

 

これで、実施の準備が整いました。(長かった、、、)

 

これからテストを実行します!

 

ですが、ちょっと待った!

 

「まだ何かあるのかよ」と言う気持ちをグッと抑えて聞いてください。

 

実行の前には、必ずテスト結果をクリアします。

(当然、初回の場合は必要ないのですが、テスト実施前に前回の結果をクリアする癖をつけたほうがいいです。理由は、実行結果には、前回の結果も含めて表示されるため、テストごとの切り分けが出来なくなってしまうためです)

 

画面上にある、ほうきが2個のアイコンをクリックすればクリアされます。

016

 

さて、お待たせしました。

いよいよテスト実行です!

 

JMeterの実行

テストを実行するには、画面上にある、緑の三角をクリックしてください。

017

 

クリックすると、画面右上の数値が動き出します。

これが、(0/スレッド数)になったら完了です。

018

 

また、テスト結果のほうもリアルタイムで反映されています。

先ほど設定した、「結果を表で表示」「統計レポート」を見ると、以下の画面のように表示されていると思います。

019020

 

しばらくして、画面右上の数値が、(0/スレッド数)になったことを確認したら、テスト結果をそれぞれ見手見ましょう。

「結果を表で表示」はスレッドが最後まで処理されており、「統計レポート」はSamplesがスレッド数になっていると思います。

021022

 

今回は単純にページにひたすらアクセスするだけのテストなのですが、複雑なテストシナリオの場合は、テスト実行後にJMeterが設定したページに正しくアクセスしているかどうかも気になると思います。

そちらの確認方法については、コチラにて紹介していますのでご参考ください。

 

最後に、「統計レポート」の下の「Save table data」をクリックして、CSVを保存してテスト終了です。

(管理しやすい名前をつけてください)

023

 

データがそろったら結果を分析しましょう。

 

たまたま、利用した端末のスペックが低かったり、実施した会社のネットワークに負荷がかかったりとかで結果がおかしいときがあります。

そんなときは、何度か同じテストをすることがありますので、1シナリオごとに結果を分析・考察をすると手戻りが少ないです。

 

注意事項

テスト結果において、

  • 「結果を表で表示」のStatusがエラー
  • 「統計レポート」のErrorが100%

 

の場合は、サイトにアクセスできていないため、設定を見直してください。

024025

 

よくあるのが、

  • サーバ名、ポートなどの設定が誤っている。
  • 対象サイトにベーシック認証をかけている。

 

などです。よく確認してみましょう。

 

最後に

最近は、CATMDESのようなWEBブラウザ上で簡単に負荷をかけられるサービスも出ています。

 

今回紹介した「サイトのトップページで、1分間に1000アクセス処理ができること、また、ユーザの同時アクセスは100とする」のようなテストであればJMeterを利用しなくても、上記のサービスで対応はできると思います。

 

ただし、公開前でベーシック認証がかかった状態で検証したい、ログインなど動的な処理部分も含めて負荷をかけたいとなると、やはりツールが必要です。

(まぁ、自前で負荷かけるプログラム作れるなら作ってもいいですけどね、、、、)

 

なお、JMeterはもっといろいろな条件を指定して負荷をかけることができます。

それらは、以下「JMeter関連の記事はこちら」にリンクがありますので、ご覧いただければ幸いです。

 

Author:yukio iizuka
プロフィール画像
フリーランスとしてUX視点で業務支援しています。 HCD-Net認定 人間中心設計専門家 LEGO®︎ SERIOUS PLAY®︎ メソッドと教材活用トレーニング修了認定ファシリテーター Hi-Standard好きです。
http://yukioiizuka.com
mislead
MISLEADの記事に共感いただけましたら
いいねをお願いします。

コメント一覧

コメントはありません

コメントを残す

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



       

© yukio iizuka All Rights Reserved...