Javaのメッセージング・サービスを速くするには？：WebSphereサーバ・チューニング入門（7）（2/4 ページ）

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

【2】メッセージの永続先（メッセージ・ストア・タイプ）

　「ファイル・ストア」を使用する場合、「ログ」「永続ストア」「テンポラリ」ファイルを保存する場所の管理が、パフォーマンスに影響を与えます。例えば、それらファイルを高速なディスクに配置することにより、書き込み遅延を抑えることが可能です（図5、6、7）。

図5　ファイル・ストアの「ディレクトリー・パス」指定

図6　メッセージ・ストア・タイプの指定：ファイル・ストア

図7　ファイル・ストアの設定

　「データ・ストア」を利用する場合は、JDBCデータ・ソースのチューニングが必要となります。基本的なチューニング・ポイントを以下に記します。

• JDBCコネクション・プール・サイズ（最小および最大接続数の調整）
• ステートメント・キャッシュ・サイズ

　「Tivoli Performance Viewer」「Thread Dump（javacore）」を活用して、上記ポイントを最適に調整します。さらに、必要に応じて、メッセージ永続先であるDBのチューニングを行います。

　WASのデフォルトJMSプロバイダー（メッセージング・エンジン）は、主にSQLの「INSERT」「DELETE」オペレーションを実行します。そのため、DBへの同時接続数の調整やDBログに対する頻繁な書き込みなどが適切に調整されていない場合には、メッセージ永続に対する遅延が発生し、メッセージングシステム全体のスループットに影響を与えるので、特に注意が必要になります。

　データ・ストアへのアクセスが非常に多い場合には、データ・ストアが使用しているテーブルへの同時アクセスがボトルネックになることも考えられます。その際には、テーブルの数を増やすことにより、ボトルネックを解消できる場合があります。詳細は、InfoCenter「並行性ボトルネックを解消するためのデータ・ストア・テーブルの数の追加」を参照してください。

　データ・ストアには、デフォルト設定として「Derby JDBC Provider」が使用されます（図8、9、10）。

図8　「Lifetime in Cache」の設定

図9　データ・ストア用データ・ソース設定　その1

図10　データ・ストア用データ・ソース設定　その2

　また、データ・ストアが使用するデフォルトのデータ・ソースに対して、「ステートメント・キャッシュ・サイズ ＝ 40」（図11）、「接続プール最大接続数 ＝ 50」（図12）が設定されています。

図11　データ・ストア用データ・ソース設定：ステートメント・キャッシュ・サイズ

図12　データ・ストア用データ・ソース設定：接続プール設定

　パフォーマンス性能としては、Apache Derby（Java純正DB、以下、Derby）をデータ・ストアとして使用する場合に比較し、DB2あるいはOracleといったRDBMSを利用することにより性能向上の可能性があります。

データ・ストアおよびファイル・ストアの利用トポロジー

　データ・ストアおよびファイル・ストアの利用として、以下のような構成が考えられます（図13）。

図13　データ・ストアおよびファイル・ストアのトポロジー

　デフォルトのローカル・データストア構成（Derbyを使用）に比較して、DB2やOracleをローカル・データストアとして利用すると性能向上が期待できます。ローカル・データストア構成で、RDBMSとWASが競合してシステム・リソース（特にCPU）を使用するため、WASプロセスに十分なCPUリソースを割り当てることができず、期待される処理性能に達しないというケースに発生しやすいので注意が必要です。

　ローカル・データストア構成とリモート・データストア構成を比較すると、ローカル・データストア構成でWASとRDBMSがCPUリソースを競合している場合には、リモート・データストア構成の方が性能面で有利といえます。ローカル・データストア構成と比較し、ローカル・ファイルストア構成の方が性能面で優れている場合が多いです。

　データ・ストアの利用に際しては（ローカルおよびリモート）、ファイル・ストアとの比較検討を行う必要があります。つまり、性能的にはファイル・ストアに分があるといえますが、信頼性やRDBMSの運用実績など、プロジェクトや環境によってはRDBMSが適することもあります。

コラム　「データ・ストアとしてDB2を使用する場合のヒント」

DB2のデフォルトのテーブル・スペースのページサイズは4kbytesです。1つのメッセージは複数行にまたがることができないため、3360bytesより小さいメッセージは「DATA」カラム（VARCHAR）に保管されます。3360bytesよりも大きい場合は、「LONG_DATA」カラム（BLOB）に保管されます。

BLOBでメッセージを保管する場合、パフォーマンスに影響を与えます。テーブル・スペースのページサイズを32kbytesに変更することにより、VARCHARとして保管できるメッセージサイズが32032bytesになります（32kbytes − 3360 bytes ＝ 32032bytes）。

メッセージサイズが、3kbytesから20kbytesの間の場合、SIBnnnテーブルを32kbytesのテーブル・スペースに保管し、VARCHARカラムのサイズを32032bytesにすることを検討する価値があります（図14）。

図14　DB2データ・ストアのテーブル・スペース・サイズとメッセージサイズ