OSS iPedia

詳細

JBentoGohanの仕組み

JMeterとJBentoGohanのスレッド/ソケット構成の比較を図1に示す。

図1 JMeterとJBentoGohanのスレッド/ソケット構成の比較

JMeterでは、Webサーバに対して接続する1コネクションごとに1スレッドを割り当てる。Webサーバから見ると、1コネクション=1クライアントとなるため、クライアント数を増やすとスレッド数が増えてしまうことになる。スレッドを増やし過ぎると、スレッド切り替えのコンテキストスイッチのオーバヘッドや、使用するメモリ量が多くなり、負荷ツールを動作させるマシンの負荷が高まってしまう。

JBentoGohanでは、Java SE 1.4から使用可能なJava NIOを使用して、1スレッドで複数のコネクションを処理する。そのため、クライアント数を増やしてもスレッド数は増やす必要は無く、スレッド切り替えのオーバヘッドや使用するメモリ量を抑えることができる。

なおCPUが複数ある場合にCPUを有効活用するために、JBentoGohanでは複数のスレッドを起動することも可能である。

以下では、JBoss AS 4.0.5.GA Buddy Replicationの8台構成に対し、JMeter/JBentoGohanで負荷をかけた結果を示す。なお、JMeterではFixed Delay、JBentoGohanはFixed Rateで思考時間500msで負荷をかけている。Fixed Delay、Fixed Rateの違いを図2に示す。

図2 Fixed DelayとFixed Rateの違い

Fixed Delayでは、レスポンスを受信した時点を基点として思考時間経過後、次のリクエストを送信する。そのため、応答時間が遅くなるとクライアント側でかけている負荷を下げてしまうことになり、全体的にスループットが理想値(クライアント数/思考時間)より低くなる傾向にある。一方Fixed Rateでは、レスポンスを送信した時点を基点として、思考時間経過後、次のリクエストを送信する。応答時間が思考時間として設定した値を超えない限り、スループットは理想値となる。実際のシステムではFixed Delayのモデルで負荷がかかることになるが、負荷試験においては、スループット/レスポンスタイム/理想値の関係を把握しやすいFixed Rateも多く使用される。

Throughput

各測定データからスループットのグラフを比較する。横軸はJMeter/JBentoGohanのクライアント数、縦軸は1秒間あたりの処理リクエスト数(Throughput)である。

図3 スループット比較

JMeter	JBentoGohan

グラフから読み取れることを、以下に示す。

• JMeterは300クライアント、578tpsまではほぼ理想値上だが、400クライアント以上ではスループットは横ばい、もしくは若干の減少傾向にある。ピークは400クライアント、600tpsである。
• JBentoGohanは500クライアント、928tpsまではほぼ理想値上だが、600クライアント以降は理想値から外れていく傾向がある。しかしスループット自体は伸び続け、1000クライアントにおいて横ばいとなった。ピークは900クライアント、1476tpsである。

Response Time

各測定データから、応答時間のグラフを比較する。横軸はJMeter/JBentoGohanのクライアント数、縦軸は平均応答時間[ms]である。

図4 平均応答時間比較

JMeter	JBentoGohan

グラフから読み取れることを、以下に示す。

• JMeterはスループットが横ばいになる400クライアント付近で応答時間が大きく悪くなり、その後は横ばいとなっている。これはクライアント数が増えているにも関わらずスループットが横ばいになっていることを考慮すると、期待しない結果である。
• JBentoGohanは800クライアントまでは徐々に応答時間が悪くなっているが、900クライアント、1000クライアントでは大きく悪くなっている。900クライアント時には400msに達しているが、これはFixed Rateの思考時間である500msに達していない。1000クライアント時には530msに達している。これはスループットは900クライアントまでは伸び続け、1000クライアントで横ばいになっていることを考慮すると、妥当な結果と言える。

CPU Utilization

各測定データから、CPU使用率のグラフを比較する。横軸はJMeter/JBentoGohanのクライアント数、縦軸は平均CPU使用率である。

図5 CPU使用率比較

JMeter	JBentoGohan

kuma01が負荷ツールが動作するマシン、kuma02がWebサーバ、kuma03-kuma10がAPサーバである。グラフから読み取れることを、以下に示す。

• JMeterは400クライアント以上でCPUを使い切っている。スループットも400クライアント以上では伸びていない事を考慮すると、負荷クライアントのCPUネックと言える。応答時間が横ばいになっていたのが400クライアントからであることを考慮すると、リクエスト送信−レスポンス受信間以外のJMeterの内部処理において、CPUを使用する箇所がありそこがボトルネックになっていた事が想定される。
• JBentoGohanはJMeterがCPUネックとなった400クライアントで25%程度の使用率であり、JMeterよりも4倍性能が良いといえる。1000クライアントでもCPUを使い切っていない。APサーバのCPUは900クライアント付近から使い切っているため、スループットやレスポンスタイムが劣化したのはAPサーバのCPUネックと言える。

GC Time

各測定データから、JMeterネックとなった400クライアント時のkuma01(負荷ツールマシン)のFull GC時間のグラフを比較する。横軸は経過時間、縦軸はFull GCにかかった時間を積み上げた値である。

図6 GC時間比較

Target	Full GC Time
JMeter
JBentoGohan

JMeterでは、測定開始から数多くのFull GCが走っており、10分測定のうち1分近くをFull GCに費やしている。Full GCが起こるとJavaのアプリケーションスレッドが動作を停止するため、高負荷な試験においては、予期しないスループットの低減や、応答時間の極端な劣化が見られることになる。今回の検証結果において、平均応答時間が良いにも関わらずスループットが伸びていない理由は、Full GCによるものであったと想定される。

JBentoGohanでは測定期間内にFull GCは一回も起こっていない。

まとめ

今回の比較から分かったことをまとめる。

JBentoGohanの効果について

測定に使用したJBentoGohanでは、1000クライアントにおいてもCPU使用率も低く抑えられ、十分な負荷をかけることができ、8台クラスタに対する性能試験も行うことができた。しかし、CPU使用率も低くはあるもののクライアント数に応じて上昇している。2000クライアント、3000クライアントというさらに高負荷な試験を行う場合には、JBentoGohanのさらなる軽量化や、複数サーバから負荷をかける機能が必要となってくるであろうことも分かった。

JBentoGohanとJMeterとの比較について

性能差としては、CPU使用率で4倍程度、JBentoGohanの方が有利なことが分かった。しかしJBentoGohanでは、HTTP1.1への対応やHTTPSでの負荷試験にまだ対応していない等の機能的な制約がある。またシナリオはJavaクラスで記述しなければならないなど、ユーザが使いやすい形にはなっていない。低負荷や簡単な測定に対してはJMeter、より高負荷な測定が必要な場合にはJBentoGohanと言った使い分けが有効だろう。

このデータの性能データ

• JBentoStore(JMeter利用)によるJBoss AS 4.0.5.GA + JGroups2.4.0 TCP repl-sync buddyReplication 8台の性能測定結果
• JBentoStoreによるJBoss AS 4.0.5.GA + JGroups2.4.0 TCP repl-sync buddyReplication 8台の性能測定結果

関連する考察データ

• JBentoStoreによるJBoss/Tomcatクラスタ1～8台構成でのスケーラビリティに関する考察
• JBentoStoreによるTomcatのレプリケーションモードについての考察