Webアプリケーションの高速化実験：J2EEパフォーマンスチューニング（4）（3/4 ページ）

「アプリケーション・サーバを使いJ2EEべースのWebアプリケーションを構築できたのはいいが、どうも本来のパフォーマンスが出ていない」とは、よく聞く話である。本連載では、そういった事態に遭遇した場合に、具体的にどのように対処してパフォーマンスを向上させるかについて解説していく。（編集局）

[池田俊彦，日本BEAシステムズ]

チューニング例2　「実行スレッドの設定」

　第3回「APサーバのチューニング項目を知る」の中で、詳しく実行スレッドについて解説しています。復習になりますが、表6のチューニング・ポイントを押さえながら、今回のチューニングで適切な設定値を求めてみましょう。

スレッド数が多すぎる場合	スレッド管理のためのオーバーヘッドが増し、逆に性能が劣化する。CPU使用率がピークに達したような状態では、スレッド数を減らすことで性能が改善する場合もある
スレッド数が少なすぎる場合	CPU使用率の低下と処理待ちを引き起こす可能性がある。このような場合、スレッド数を増やすことで性能が改善することがある
表6　チューニング・ポイント

チューニング・テストの実施

　実行スレッド数を下記の設定値で、アプリケーション・サーバに最大負荷（仮想ユーザー数40個）を10分間かけたときのパフォーマンスを測定します。条件としてネイティブ・パフォーマンス・パックを使用し、また、JDBC接続プール初期数およびJDBC接続プール最大数は、実行スレッド数に合わせて設定します（JDBC接続プール数に関するチューニングについては、本連載のhttp://www.atmarkit.co.jp/fjava/rensai/j2eeprfm03/j2eeprfm03_4.htmlを参照してください）。

テスト番号	実行スレッド数	JDBC接続プール初期数および最大数
1	15	15
2	20	20
3	30	30
4	40	40
5	50	50
表7　チューニング・テスト項目表

実行スレッド数の決定について

　アプリケーション・サーバに最大負荷をかけたときに、WebLogic ServerのGUI管理コンソール画面（図12）の「パフォーマンス・モニタ画面」からペンディング要求数のグラフおよびアイドル・スレッド数を監視します。大体の目安としては、ペンディング要求数がたまらない程度に実行スレッド数を上げる必要がありますが、あまり実行スレッド数を上げすぎると、アイドル・スレッド数が上がり、CPUリソースの有効活用ができなくなります。図13、図14にスレッド15とスレッド30のペンディング要求数のグラフ比較を示します。実行スレッド数15に比べ実行スレッド数30は、ペンディング要求数の波が少なくなっているのが分かります。

図12　GUIの管理コンソール「パフォーマンス・モニタ画面」（クリックすると拡大します）

図13　「パフォーマンス・モニタ画面」のペンディング要求数（実行スレッド数15）

図14　「パフォーマンス・モニタ画面」のペンディング要求数（実行スレッド数30）

　そのほか、パフォーマンス測定中、監視するGUIの管理コンソール画面は、下記図の「アクティブな実行キューのモニタ」（図15）で、アプリケーションごとの実行スレッドの状態を監視することができます。

図15　アクティブな実行キューのモニタ（クリックすると拡大します）

チューニング・テストの結果

　表8と図16にパフォーマンスの測定結果を示します。今回は、アプリケーション・サーバが1CPUであったので際立ってパフォーマンスの違いが現れなかったと思われますが、複数CPUのサーバでは違いが大きく出るかもしれません。複数CPUの実行スレッドの目安は、1CPU当たり15程度で計算してください。4CPUサーバの場合は、実行スレッド数（60）＝1CPU当たりの実行スレッド数（15）×CPU数（4）となります。

	15	20	30	40	50
TPS	67.223	70.451	75.023	78.03	77.23
表8　実行スレッド数の設定を変えたときの秒ごとのトランザクション数（TPS）