DB連携のパフォーマンスはどうすれば速くなるのか？：WebSphereサーバ・チューニング入門（4）（3/3 ページ）

» 2007年10月18日 00時00分公開

[上野憲一郎，日本アイ・ビー・エム]

【3】最大接続数

　物理接続の最大数を指定します。デフォルト値は10です。これらは、DBへの物理接続です。一度この数値に到達すると、新規の物理接続は確立されず、現在使用中の物理接続がプールに戻されるか、ConnectionWaitTimeoutExceptionがスローされるまで待機します。

　例えば、最大接続数が5に設定されていて、5つの物理接続が使用中の場合、プール・マネージャーは、接続タイムアウトに指定された時間が経過するまで、物理接続が空くのを待ちます。

【4】最小接続数

　維持する物理接続の最小数を指定します。デフォルト値は1です。実際にDBと接続している接続プールのサイズが、最小接続プール・サイズ（最小接続数で指定した値）と同じか、またはそれより小さい場合、「未使用タイムアウト」スレッドは物理接続を破棄しません。

　例えば、「最小接続数」の値が3に設定されていて、物理接続が1つ作成されている場合、その接続が「未使用タイムアウト」スレッドによって廃棄されることはありません。

　また、経過タイムアウトの値を設定すると、最小プール・サイズ設定にかかわらず、経過時間の有効期限が切れた接続は破棄されます。

【5】未使用タイムアウト

　未使用またはアイドルの接続が廃棄されるまでの時間（秒）を指定します。デフォルト値は1800秒（30分）です。

　物理接続が廃棄されるまでの時間（秒）を指定します。デフォルト値は0です。「経過タイムアウト」を0（デフォルト値）に設定すると、アクティブな物理接続を無制限にプールに残しておくことができます。

【6】ステートメント・キャッシュ・サイズの調整

　WASのデータソースは、“prepared statement”および“callable statement”の処理を最適化するために、アクティブな接続で使用されていないそれらのステートメントをキャッシュし、パフォーマンス向上に役立ちます。

　“prepared statement”とは、Java標準のPreparedStatementクラスに保管されているプリコンパイルされたSQLステートメントです。

　WASはこのオブジェクトを使用して、アプリケーション・ランタイムの要求に応じて、ランタイムで判別された値でSQLステートメントを複数回実行します。JDBCアプリケーションの中で、PreparedStatementを使用することにより、リクエストごとにDBサーバがSQLコードをコンパイルする必要がなくなり、性能が向上します。WASは、そのPreparedStatementをキャッシュする機能を提供することで、さらなる高速化が図られます。

　“callable statement”とは、ストアード・プロシージャーへの呼び出しを含むSQLステートメントです。ストアード・プロシージャーは、タスクを実行し、結果を戻す、プリコンパイルされたステートメントのセットです。ステートメントは、Java標準のCallableStatementクラスに保管されます。

　WASはこのオブジェクトを使用して、アプリケーション・ランタイムの要求に応じて、ランタイムで判別された値で、ストアード・プロシージャーを複数回実行します。

図10　ステートメント・キャッシュ・サイズの指定

　ステートメント・キャッシュ・サイズ（デフォルト値：10）が小さい場合は、有用なエントリーであっても、新しいエントリーを作成するために廃棄されます。キャッシュが破棄されないようにするために、キャッシュ・サイズを適切な値に指定するには、このデータソースを使用するアプリケーションごとに、prepared statementおよびcallable statementの数を指定します。

　ステートメント・キャッシュ・サイズに指定した値は、特定の1つの接続上にキャッシュできるステートメントの最大数です。

ツールを利用してデータソース設定を最適化

　連載第1回で紹介したTivoli Performance Viewerを使用すると、ステートメント・キャッシュ・サイズに指定した値が小さい場合には、破棄されたステートメント数（PrepStmtCacheDiscardCount）が表示されますので、チューニングの有無を容易に理解できます。

　また、接続プールの数の推移（PoolSize：接続プール数、FreePoolSize：プールにある秋接続数）、接続待ちスレッド数（WaitingThreadCount）、接続が許可されるまでの待ち時間（WaitTime）、JDBC呼び出しにかかった時間（JDBCTime）なども把握できます。

図11　Tivoli Performance Viewerによるデータソースの最適化

　ステートメント・キャッシュ・サイズの調整は、不必要に大きなサイズを設定してもメモリ領域を無駄に消費してしまうことがありますので、何度かテストを繰り返しながらサイズを変更し、適切な値を見つけ出すようにします。

　また、プール・サイズの調整についても注意が必要です。これは、接続先のDBサーバの設定とも関連してきます。

　この値が少ない場合には、十分なDBサーバへの接続が確保できずに待たされる場合があります。逆に、多過ぎるとDBサーバへ過剰な負荷（接続）を掛けてしまう場合があります。適宜、DBサーバ管理者と連携を取りながら調整するようにします。

次回はトランザクションとEJB

　今回は、DBアクセスを行うアプリケーションを前提としたWASのチューニングを解説しました。特に、「JDBCドライバ」および「データソース」の2点に焦点を当てて説明を行いました。ポイントをおさらいすると、以下のようになります。

JDBCドライバ
- JDBCドライバ・タイプ（タイプ1〜4）
- JDBCドライバのバージョン（DB2 Universalドライバ vs DB2 CLIドライバ）
- ローカルDB接続 vs リモートDB接続
- XAドライバ vs. Non-XAドライバ
データソース
- 接続プール
- ステートメント・キャッシュ・サイズ

　今回は、DBアクセスを行うアプリケーションを構築するうえで重要となる「トランザクション」および「EJB（特に、Entity Bean）」についてのチューニングには触れませんでした。次回以降に解説を行う予定ですので、楽しみにお待ちください。

＠IT関連記事

【トラブル大捜査線】失われたコネクションを追え！
現場から学ぶWebアプリ開発のトラブルハック（7）　DBコネクションのclose漏れでTomcatが無応答に！すべてのコードを見る時間なんてない… 漏れているのはどこなんだ!?
「Java Solution」フォーラム 2007/9/25

DBアクセスのトラブルは終盤で発覚しがち……
現場から学ぶWebアプリ開発のトラブルハック（4）　今日もまたトラブルが発生！分析すると、どうもDBアクセスの部分で問題があるようだ。もうすぐリリースなのに……
「Java Solution」フォーラム 2007/6/27

JDBC接続を高速化−PreparedCacheの活用
事例に学ぶWebシステム開発のワンポイント(11) PreparedStatementキャッシュを使うとJDBC接続を高速化することができる。実際の評価結果も含め解説する
「Java Solution」フォーラム 2003/4/18

DB2チューニング・ベストプラクティス
パラメータの調整、スナップショットの取得と解析、インデックスの設計など、DB2のチューニングにおけるベストプラクティスを紹介する。IBM developerWorks好評記事の翻訳版
第1回これがDB2パフォーマンス向上の9カ条だ
 第2回最適なバッファ・プール、表スペース、表の設計
 第3回索引のチューニング・テクニックを一挙公開
 第4回データベースの問題を発見するスクリプト
 第5回スナップショット・モニタに基づくチューニング
 第6回 SQLを分析する高度なテクニック
 第7回表／索引のメンテナンスとパーティション設計
 最終回 DBシステム全体のボトルネックを突き止める
 連載各回の解説
「Database Expert」フォーラム

プロフィール

日本アイ・ビー・エム東京基礎研究所　アドバイザリー・リサーチャー

上野憲一郎（うえのけんいちろう）
kenueno@jp.ibm.com

日本アイ・ビー・エムに入社後、システム・エンジニアとして10年ほど活動した後、米国IBMへ赴任。米国IBM Raleighソフトウェア開発研究所にて、WebSphere Application Server開発部門のパフォーマンス専門グループのメンバーとして活動。2003年に帰国後、IBM東京基礎研究所にて、XML、Web サービス、SOA関連技術の研究開発に従事。WebSphere Application Serverパフォーマンス専門家として、セミナーなどで講演も実施。

主な著書
「WebSphere V3.5 Handbook」（Prentice Hall）

主な訳書
「Webサービスプラットフォームアーキテクチャ」（エスアイビーアクセス）

「次回」へ

「WebSphereサーバ・チューニング入門」バックナンバー