Web屋のネタ帳

久しぶりに技術的な話題。Apache JMeter(ジェイメーター)というオープンソースソフトがある。負荷テストツールと呼ばれるもので、大量のHTTPアクセスを発生させてWebサーバなどに負荷をかけ、どの程度のアクセス数に耐えられるかを調査するためのソフトだ。

短時間のうちに大量のアクセスが予想されるWebサイト、例えば、コンサートチケットの予約サイトや、人気ゲームの予約販売サイトなどを構築する際にこうしたツールがよく利用される。 商用の負荷テストツールもあるが、高機能だが値段も高いので、 apacheと同系統のオープンソースソフトであるJMeterも重宝されている。

ところが、ちょっとした誤解がもとで、JMeterは使い物にならないという間違った判断を下してしまうケースが意外と多いらしい。

JMeterの実行時の設定として「スレッドグループ数」と呼ばれる値がある(一般にはリクエストの多重度とも呼ばれる)。 例えばこれを10に設定すると、あたかも10台のPCのブラウザが同時にアクセスするかのようなHTTPリクエストを発生することができる。 では、100に設定すれば100台ぶんの、10000に設定すれば10000台ぶんのHTTPリクエストを同時に発生させることができるのだろう ・・・と考えてしまいがちなのが罠であり注意すべき点だ。 無限に大量のHTTPリクエストを発生させることができるはずがない。

数年前に筆者がJMeterを試したときも、あやうくこの罠にひっかかるところだった。

1. スレッド数１０で実行してみる・・・Webサーバからのレスポンス速度平均が1秒
2. スレッド数２０で実行してみる・・・Webサーバからのレスポンス速度平均が1.3秒
3. スレッド数６０で実行してみる・・・Webサーバからのレスポンス速度平均が5.6秒
4. スレッド数１００で実行してみる・・・Webサーバからのレスポンス速度平均が5.5秒・・・って、なんでスレッド数60のときと値が変わらないんだ！？！？

スレッド数を増やす（≒多重度を上げる）とおかしな値になるということは、 JMeter自体にやはり何らかのバグでもあるのだろう。信頼できないなあ・・・ という感想を残して終わってしまうケースが意外に多いのではないだろうか。 筆者が最近聞いた話で、そういう判断を下してしまっていたケースが実際あった。

真相は、単にJmeterを実行しているマシンの性能限界に達していたために、 設定したスレッド数ぶんのリクエストを発行できなかっただけである。 どんなに優れたソフトだろうと高性能なハードだろうと必ず限界があるのは当然だ。 JMeterを利用する場合には、PCのリソースメーターでも見ながらテストとしていくつかのスレッド数で実行してみて、 マシンの性能限界に達しない程度のスレッド数を事前に見極めておく必要があるのだ。 筆者が試したのはもう数年も前のことだが、確かPentium400Mhz程度のマシンでスレッド数50前後でCPU利用率が100%に達してしまった覚えがある。

なお、JMeterには、親マシンを1台指定して、 複数台の子マシンを操ってリクエストを発生させることで、 この性能限界問題を解決する機能がある。 解説はこちら。

最近ではJmeterに関する雑誌記事や解説サイトも増えてきたが この落とし穴に言及している内容は意外に少ない。注意したほうがいいだろう。