- PR -

負荷テスト時のスレッド数について

1
投稿者投稿内容
sumin
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 93
投稿日時: 2003-08-11 22:07
早速ですが、ウェブ・アプリケーションの負荷テストを行っています。

WebContainerのスレッド数の最大値を100まで増やしておいて、ツールを使って同時接続ユーザ数150人の負荷を掛けて見ましたがWebSpereのリソース・アナライザーで確認した結果、WebContainerで生成されたスレッド数は各テストごとに30から40の間でした。ウェブサーバの同時接続数も150にして置いたのでウェブ・サーバでのボトルネックは無かった筈ですが。。CPUもまだ少し余裕がありましたし、メモリーも余裕がありましたけどなぜでしょうか？これって普通ですか？

ついでに、ガーベッジ・コレクションがほぼ5秒置きに発生していますがこれは大丈夫でしょうか？あまり頻繁しすぎのような気がしますが。。ただ、各ガーベッジ・コレクション時のメモリー開放率は85％以下でしたが。。

ご指導お願いします。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2003-08-12 00:43
一般に、同時接続クライアント数とサーバ側のスレッド数は一致しません。
クライアントが150人いても、実際にポートをリッスンしているスレッドは一つです。
ソケット接続をacceptして順次サーブレットの処理を行うスレッドに割り当てる部分は直列化されています。つまり150人同時にアクセスしても、150人目の受け付け処理を始めるときにはすでに何人分かのレスポンスを返し終わっているのではないでしょうか。
また、最大スレッド数を100にしても、実際にスレッドが100コにもなったらコンテクストスイッチが大変な負荷になってしまうため効率的ではないかもしれません。
CPU数、アプリケーションの作り、VMの特性によって最適な値は変わるので試行錯誤するしかありませんが、15〜40くらいの間で試すのが妥当かもしれません。

JVMヒープサイズ/各ヒープ領域サイズ/スレッドサイズを変えて負荷をかけていくと、CPU使用率やGC時間に傾向が見られるはずです。うまく最適な値を見つけ出してください。
また、チューニングの際はサーブレット（場合によってはJSPも）の更新チェックをしないようにすると結構パフォーマンスに差がでるかもしれません。

CPUを使い切れないのであれば、プロセスを2つ立ち上げてWebServer(IHSでしたっけ？)で振り分けるようにすると効率よく裁けるかもしれません。

下のリンクは WebLogicのものですが、チューニングの内容はWebSphereも概ね同様でしょう。
IBMのVMについては載っていませんが・・・・。
・[Java 仮想マシン (JVM) のチューニング]
http://edocs.beasys.co.jp/e-docs/wls/docs81/perform/JVMTuning.html

あ、本家のもありました。
・[第1回 「WebSphere Application Server V4.0における基礎的なチューニング]
http://www-6.ibm.com/jp/software/websphere/developer/performance/v40/1.html

[ メッセージ編集済み 編集者: インギ 編集日時 2003-08-12 00:47 ]
sumin
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 93
投稿日時: 2003-08-12 13:43
ご返事ありがとうございます。勝手ながらより詳しい事をお聞きしたいと思います。

＞つまり150人同時にアクセスしても、150人目の受け付け処理を始めるときにはすでに何人分かのレスポンスを返し終わっているのではないでしょうか。

これは、今使っているツールの設定でマックス150人になった状態でも別途停止コマンドを打たない限りはずっとリクエストを送りつつありますので少なくとも150個のリクエストがずっと送られていると思います。ただ、またツールの設定で、要求したレスポンスが来るまで待っている時間はあると思います。

＞また、最大スレッド数を100にしても、実際にスレッドが100コにもなったらコンテクストスイッチが大変な負荷になってしまうため効率的ではないかもしれません。

コンテキストスイッチと言うのは何でしょうか？

＞JVMヒープサイズ/各ヒープ領域サイズ/スレッドサイズを変えて負荷をかけていくと、CPU使用率やGC時間に傾向が見られるはずです。うまく最適な値を見つけ出してください。

上記で各ヒープ領域サイズとは何でしょうか？

頂いたリンクは非常に参考になりました。
ありがとうございます。

山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2003-08-12 15:23
1)窓口（最大スレッド数）が１００コある
2)行列に人（リクエスト）が常に１５０人並んでいる
3)窓口へ案内する係員（ポートのリスンを行っているスレッド）が１人いる
と考えてください（フォーク並びともいいますね）。窓口に案内されてしまえば、それぞれ並列にサービスが行われますが、行列に並んでから窓口にたどり着くまでにタイムラグがあります。
3)の係員が、窓口へ順に案内（スレッド１へどうぞ、スレッド２へどうぞ・・）するわけですが、案内しているうちに最初の方に案内した窓口のサービスは完了している可能性があるわけです。

>コンテキストスイッチと言うのは何でしょうか？
プロセスやスレッドの切り替えを行うことです。プロセスは一つのマシン内で複数、スレッドは一つのプロセス内で複数存在することができますが、実際に処理を行うCPU数よりも多いのが一般的です。OSやJVM(ThinThreadの場合)が次はこの処理を行うべきだ、とCPUに常に割り振りを行っているわけです。

一つのJVMの中では複数のスレッドが動いているわけですが、各スレッドを順に処理していく必要があります。このスレッドの切り替えは一瞬で済みますが、スレッド数が多くなると結構馬鹿にならない時間なのでメモリが足りる限りスレッド数を増やせばよいものではないというわけです。
人間でも一つの仕事に集中して順に仕上げていくのと、複数の仕事を同時にこなしていくのとでは効率がちがいますよね？人間の場合、気晴らしという要素があるので必ずしも複数の仕事をすると効率がわるくなるわけではありませんが。

>上記で各ヒープ領域サイズとは何でしょうか？
一般的なJVMでは、オブジェクトが GC の対象となるかどうかの判断を効率化するために、ヒープ内を複数の領域に分けています。
アプリケーションの特性により、オブジェクトの生成の具合が異なるため、この領域をチューニングすることによりGC時間が短縮され、パフォーマンスが向上します。
SunのJDKでは new世代領域、old世代領域があり、さらにnew世代が edenと２つのsurvivor領域に分けられています。JRockitでは nurselyとoldかな。IBMのJVMも同等の概念があるかと思います。
詳しくは先に示しましたWebLogicのパフォーマンスチューニングのページに書いてありますのでご参照ください。

・[WebLogic Server パフォーマンス チューニング ガイド]
-[関連情報 : パフォーマンス ツールと情報]
http://edocs.beasys.co.jp/e-docs/wls/docs81/perform/appa_reading.html
1

スキルアップ／キャリアアップ（JOB@IT）