こんにちは、Apache JMeter の使い方について3回目の記事となります。

今回はちょっと目先を変えて、負荷テスト中に何を監視するのか、まとめてみたいと思います。
何も監視しないという方針もあるかと思いますが、それは置いといて、監視する対象について考えてみると、以下のように分類できると思います。

1) JMeter 自体に表示される情報
2) 負荷テスト対象となるサービスの情報

さて、これで十分でしょうか？

負荷テスト対象となるアプリが、PHP で構築された HA(冗長) 構成の WEB アプリだとすると(ルータとかFWは省略してますが)こんな感じになると思います。

実は負荷テストを実行することで影響を受ける箇所はテスト対象となるサービスだけではないことがわかります。負荷テストを実行するとネットワークにも負荷をかけますし、テスト対象のサーバに対して負荷をかけることで、そのサーバが利用している（他のサーバで実行されている）サービスに影響を与得ることもあるわけです。

上の図では直接 WEB サーバに対して負荷テストを実行しようとしていますが、影響範囲は直接的に見てもキャッシュサーバ、NFS、DB(マスター、スレーブ)に及んでいます。

また、JMeter を実行しているマシン(クライアント)の状態を監視することも意外に大事です。ここがボトルネックになっていたら負荷テストの意味合いがぼやけてしまいますので・・・。これらを追加すると、

1) クライアント側
1-1) JMeter 自体に表示される情報
1-2) JMeter 実行マシン(クライアント)の情報
2) サーバ側
2-1) 負荷テスト対象となるサービスの情報
2-2) 負荷テスト対象となるサーバの情報
2-3) 対象サーバ以外のサーバ・サービスの情報
3) 途中経路
3-1) クライアント・サーバ間のネットワーク帯域利用率
3-2) FW、ロードバランサ等

という感じになると思います。途中経路についてはサーバ・ネットワークチーム、DB サーバについては DB チーム(?) に助けを求めないといけないケースもあるでしょう。いずれにしても、JMater のリスナーを見ているだけではそんなに多くの情報は得られないという事がわかると思います。

一番上からそれぞれ監視項目を確認してみたいと思います。
1-1) JMeter 自体に表示される情報
JMeter で監視できる項目は大きく分けると二つ、

・どれくらいの時間をかけてレスポンスが返ってくるのか
・どれくらいの回数呼べるのか

になります。JMater で計測できるのは最終的な出入口ですから、内部はブラックボックスという事になるわけです。上記の2つをもう少し用語を使って言うと、

・画面や API の表示にかかる時間(ターンアラウンドタイム、ラウンドトリップタイムともいう)
・画面や API の秒間コール数(rps = request/sec)

という事になります。これらの 2 点について実際にテストする際には以下のような点について注意が必要です。

・短時間実行した場合に問題が無かったり、よいスループットが出た場合でも、長時間実行していくと問題が出ることがある。

・シングルスレッドでの実行では問題が無くても多スレッドで同時実行すると問題が出ることがある。逆にシングルスレッドでは十分性能が出ないこともある。

上記についてはいっぺんにテストする事は普通難しいので、別々にテストしたほうが良いでしょう。精度の高いテスト・予測ができます。
1-2) JMeter 実行マシン(クライアント)の情報
これはどういう事かというと、クライアント側の PC なりサーバなりが計測結果のボトルネックになっている事が意外にあるからです。Linux 等の Unix 系サーバから流す場合各種監視方法がありますが、Windows 上でもタスクマネージャを見れば最低限の情報は取れるので確認してみてください。

CPU 利用率だけではなくて、ネットワークのトラフィックも監視できます。これはぜひ確認してください。これを確認することでネットワークがボトルネックになる可能性について考慮する事ができます。100Mbps 程度の回線ですと単なる情報提供系のホームページや画像を多く含んだサービス等では帯域を使い切るケースがあります。意外と見落としやすい点ではないかと思います。
2) サーバ側

では次にサーバ側の監視についてです。サーバ側監視をせずに負荷テストを実施した、というケースが実際に結構あるのですが、テストの目的が想定負荷に耐えうるかという点だけならばともかく、思わぬバグの発見や将来サービスの利用が伸びて想定負荷を変更する事になった、という幸運なケースでもあらかじめ「どこを次には拡張する必要があるか」という事が明確にできます。

2-1) 負荷テスト対象となるサービスの情報
負荷テスト対象となるサービスは通常群となって複数のサーバが属しています。Web サーバに負荷をかけるからといって監視対象を Web サーバだけにしてしまうのは片手落ちです。Web サーバにアクセスする事によって間接的にリクエストが発生するサーバを洗い出しましょう。

ちなみにこのタイミングで実はそのテスト環境から外部のサービスを参照していた、というような場合はたとえそれが外部サービスのテスト環境であったとしても何らかの対応はしておいた方が無難ですよ。「これくらいのリクエスト量が何時から何時まで流れます」という連絡をしておくとか、そもそもそこはモックで代用するとか。モックで代用した場合はその外部サービスのパフォーマンスについてはテストされない事になるので注意が必要ですが。

2-2) 負荷テスト対象となるサーバの情報

ミドルウェア特有の監視点についてはあまり詳しくもないのであまり書いていませんが、ご参考に。

2-2-1) Webサーバ
以下程度をファイル出力しておいて、後で確認したり、グラフ表示してみたりするとよいと思います。

・ロードアベレージ
> sar -q 3
w コマンドでも uptime でも、コマンドはなんでもかまわないのですが、まずはこれを確認です。

・CPU使用率
> sar 3
等のコマンドを使ってください。”3″ という引数は3秒に一回ログ表示、という意味です。
user, system, iowait, idle あたりを確認します。

・メモリ使用率（cache の used と free ・Swap の used）
> free -s 3
used, free, swap の used あたりを確認します。

・ディスク IO
> iostat -x 3
r/s, w/s あたりを確認します。iowait でもある程度把握できるので参考程度というところですが問題の切り分けに役に立つ場合もあるので、一応とっておくといいです。

・ディスク使用量
> df -k
-h オプションの方が人間が読む分にはわかりやすいですが、3.9Gなんて表示されてしまうと 99 MBの増分ですら丸められてしまいますので、-k か -m 位を指定しておいた方が監視用としては無難です。3秒毎にこれを記録する必要はないと思いますが、テスト実行開始前、後で取っておくと差分を比較することで増分がわかります。リクエストあたりの増分もわかりますので、ディスクの消費量を予測する上では重要な情報です。

・Web サーバミドルウェア特有の監視項目
上記以外に、ミドルウェア特有の監視項目が存在する場合があります。apache であれば起動しているプロセス数や使用メモリ量、などなど。これはミドルウェア依存になるので割愛しますが重要なポイントではあったりします。

2-3) 対象サーバ以外のサーバ・サービスの情報
間接的に利用されるサーバ、サービスについても監視をします。たとえば「Web サーバのロードアベレージは低いのだけど、それ以上性能が出ない・・・」という場合はおそらくそれら間接的に利用されるサーバ、サービスがボトルネックになっている可能性が高いという事になるわけです。

2-3-1) DBサーバ
2-3-1-1) マスター
2-3-1-2) スレーブ
マスター、スレーブ、それぞれに監視をしたほうが無難です。監視項目は Web サーバと同じですが、DB の場合より精緻な情報が取れる事が多いですので、調べて見るのもよいと思います。select、update といったファンクションが発行された回数や、バッファプールから溢れた回数等、うまく使うと有用なヒントになる事があります。

2-3-2) NFSサーバ
2-3-3) キャッシュサーバ
製品次第ですが、Web サーバと同様の監視項目をまずは試してみましょう。

3) 途中経路
3-1) クライアント・サーバ間のネットワーク帯域利用率
3-2) FW、ロードバランサ等
これまでのところのいずれにも大きな負荷は発生していないのになぜかそれ以上性能が出ない・・・という事が実際にあります。スイッチの性能が出ておらず、そこがボトルネックになっていたという事が実際にありました。またロードバランサは意外に重く、ボトルネックになっている事があります。可能性の一つとして頭にとどめておきましょう。最低でもネットワークの帯域がどの程度消費されているのかは把握しておく方が無難です。
以上、ざっとまとめてみました。いかがでしたでしょうか？

この記事に関するご意見、ご感想、ご質問、お待ちしています！ blog@keis-software.com までお願いします。(間違いの指摘も大歓迎です)

よろしくお願いします。

 

【関連記事】
JMeter の利用方法(1) – Ramp－up、スレッド数、ループ回数の誤用
JMeter の利用方法(2) – テスト結果の確認方法
JMeter の利用方法(3) – 負荷テスト中に何を監視するのか？
JMeter の利用方法(4) – タイマによるスループットの制限方法

Performance Testing With Jmeter 2.9
JMeter バージョン 2.10 について
JMeter バージョン 2.11 について