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

【3】データ・バッファ

　各メッセージング・エンジンは、メッセージを保管するために、「破棄可能なデータ・バッファ」と「キャッシング可能なデータ・バッファ」の2つの領域を持っています（図15）。

図15　データ・バッファ

廃棄可能なデータ・バッファ

　「廃棄可能なデータ・バッファ」には、サービス品質属性が「ベストエフォート非パーシスタント」に対するデータが保持されます。メッセージング・エンジンはこのデータ全体をこのメモリ・バッファ内に保持します。このデータをデータ・ストアに書き込むことはありません。

　メッセージング・エンジンが、このバッファにデータを追加するとき（例えば、メッセージング・エンジンがクライアントからベストエフォート非パーシスタントのメッセージを受信するとき）、メッセージング・エンジンは、スペースを空けるため、すでにバッファ内にあるデータを廃棄する可能性があります。この動作によって、メッセージング・エンジンはベストエフォート非パーシスタントのメッセージを廃棄できます。

　このデータには、アクティブ・トランザクションに含まれるデータと、メッセージング・エンジンが廃棄したり消費したりしていないそのほかのベストエフォート非パーシスタントのデータの両方が含まれます。メッセージング・エンジンは、アクティブ・トランザクションに含まれていないデータだけを廃棄できます。

　メッセージング・エンジンの「sib.msgstore.discardableDataBufferSize」プロパティによって、廃棄可能なデータ・バッファのサイズを制御します。このプロパティの値をバイト単位で指定します。このデフォルト値は「320000」で、約320kbytesです。

　アクティブ・トランザクションに含まれないデータすべてを廃棄した後に、十分なスペースが残っていないとき、メッセージング・エンジンがデータを廃棄可能なデータ・バッファにデータを追加しようとすると、メッセージング・エンジンは「com.ibm.ws.sib.msgstore.OutOfCacheSpace」例外をスローします。クライアント・アプリケーションは、javax.jms.JMSExceptionのようなAPI固有の例外にラップされた、この例外をキャッチできます。

キャッシング可能なデータ・バッファ

　「キャッシング可能なデータ・バッファ」には、サービス品質属性が「ベストエフォート非パーシスタント」以外のデータが保持されます。

　キャッシュ・データ・バッファの目的は、キャッシングしなければメッセージング・エンジンがデータ・ストア（あるいは、ファイル・ストア）から読み込まなければならない可能性のあるデータを、メモリにキャッシングすることで、メッセージング・エンジンのパフォーマンスを最適化することです。

　メッセージング・エンジンは、データをDB（あるいはファイル・ストア）に書き込み、DB（あるいは、ファイル・ストア）から読み取るときに、そのデータをキャッシュ・データ・バッファに追加しようとします。メッセージング・エンジンは、スペースを空けるため、すでにバッファ内にあるデータを廃棄する可能性があります。バッファ内のデータが破棄された場合であっても、DB（あるいは、ファイル・ストア）からデータを取得できますが、パフォーマンス的には不利になります。

　メッセージング・エンジンの「sib.msgstore.cachedDataBufferSize」プロパティによって、キャッシュ・データ・バッファのサイズを制御します。このプロパティーの値をバイト単位で指定します。このデフォルト値は「320000」で、約320kbytesです。

データ・バッファのサイズ調整

　「破棄可能なデータ・バッファ」および「キャッシング可能なデータ・バッファ」のデフォルトサイズは、約320kbytesで、この値は決して大きいとはいえません。

　［サービス統合］→［バス］→「バス名」→［追加プロパティー］→［カスタム・プロパティー］で値を設定・変更できます（図16）。

図16　データ・バッファ・サイズの設定

　「Tivoli Performance Viewer」を使用し、破棄されたメッセージの数をモニタし、破棄されるメッセージ数が小さくなるようにバッファサイズを調節することにより、パフォーマンス向上が期待できます。

【4】処理並列度

　一般に処理の並列度を調整することにより、パフォーマンス向上が期待できる場合があります。連載第4回の「データソース設定チューニング時の6つのポイント」で、DBサーバ接続のための接続プールに関して解説を行いました。JMSアプリケーションにおいても、パフォーマンス向上のために同様の考え方を用いることができます。

　以下に、JMSクライアントの性能向上が期待できる「JMS接続ファクトリの接続プール」について解説をし、その後、MDB（Message Driven Bean）の性能向上のための「MDBの並列度チューニング」について解説をします。

JMS接続ファクトリーのチューニング：接続プール

図17　JMS接続ファクトリー：接続プール設定

　Default JMSプロバイダに対するJMS接続ファクトリの接続プールの設定（最大接続数）を調整することにより、パフォーマンス性能向上の可能性があります。デフォルト値は、「10」接続です（図17）。

　JMS接続ファクトリごとに接続プールを保有しています。　接続プールの空きがなくなると、JMSクライアントが接続を待たされることになるので、接続プール・サイズの調整が必要になります。

　「Tivoli Performance Viewer」を利用して、使用している接続プール・サイズを把握可能です。［管理コンソール］→［モニターおよびチューニング］→［Performance Monitoring Infrastructure (PMI)］→［パフォーマンス・モジュール］→［JCA 接続プール］→［SIB JMS Resource Adapter］→［接続ファクトリー］→「JNDI名」でモニター対象を指定します。

MDBの並列度チューニング：インスタンス・プール、エンドポイント・プール、スレッド・プール

図18　MDB並列度に関するチューニング個所

　MDBの並列度の調整は、スループットに対して影響を与えます。MDB関連の並列度に関する設定は以下の3カ所です（図18）。

　基本的な方針として、「JMSアクティベーション・スペック メッセージ・エンドポイント・プールサイズ」より「JMS Resource Adapter スレッド・プール・サイズ」が大きいという設定が適切です。

MDBインスタンス・プール

　アプリケーションごとにEJB（MDB）インスタンスのプール・サイズを指定できます。JVMシステム・プロパティとして、以下のオプションを指定することにより、MDBインスタンス・プール・サイズの調整が可能です（デフォルト値：最小50、最大500）。

-Dcom.ibm.websphere.ejbcontainer.poolsize 

　ここで指定された最大値が、MDBが同時に受け取れるメッセージの最大数になります。詳細は、連載第5回の「EJBコンテナのプール・サイズ」およびInfoCenter「EJB コンテナーの調整　EJB コンテナー・プール・サイズ」を参照してください。