JMS/XLAアプリケーションのチューニング

JMS/XLAアプリケーションのチューニングに関する考慮事項

JMS/XLAでは、オーバーヘッドが発生するため、C XLA APIを使用した場合より低速となります。

C APIでは、レコードがユーザーにバッチで戻されます。JMSモデルでは、オブジェクトがインスタンス化され、MessageListenerメソッドonMessage()に対するコールバックで各レコードが1つずつ示されます。高パフォーマンスのアプリケーションでは、チューニングを行ってこのオーバーヘッドの一部を回避できます。

xlaPrefetchパラメータの構成

トランザクション・ログを読み取るJMSレイヤーの基礎となるコードは、オブジェクト/行をユーザーに示す前にできるかぎり多くの行をフェッチ可能な場合、より効率的になります。プリフェッチの量は、xlaPrefetchパラメータが指定されたjmsxla.xml構成ファイルで制御されます。

プリフェッチ数は、100、1000などの大きい値に設定します。

更新確認の頻度の減少

JMS/XLAでは、更新の確認によってブックマークが移動し、システム表が更新されます。確認の発行前は、いくつかの更新が検出されるまで待機することで、通常はアプリケーションのパフォーマンスを向上させることができます。次のいずれかのモードで、確認の頻度を制御できます。

「XLA更新確認」を参照してください。

DUPS_OK_ACKNOWLEDGEでは、xlaprefetch設定に従ってJMS/XLAはレコードをプリフェッチし、プリフェッチされたブロックの最後のレコードが読み取られると、応答は自動的に送信されます。
CLIENT_ACKNOWLEDGEでは、希望に応じて、MapMessageインスタンスでacknowledge()メソッドを手動でコールします。

確認の頻度の適切な選択は、アプリケーション・ロジックによって決まります。たとえば、100の更新ごとに確認が正常に使用されてきました。ただし、トレードオフがあることに注意してください。確認はXLAログの保持に影響を与え、確認の頻度が低すぎると、好ましくないログ・ファイルの蓄積につながることがあります。(「XLAブックマークおよびトランザクション・ログの保持」も参照してください。)

ノート:

DUPS_OK_ACKNOWLEDGEまたはCLIENT_ACKNOWLEDGEモードでは、リーダー・アプリケーションで同じレコード・セットが複数回戻されることを許容できる必要があります。

高いイベント率への対応

同期インタフェースは、イベント率が低いアプリケーションと、AUTO_ACKNOWLEDGEまたはDUPS_OK_ACKNOWLEDGE応答モードを許容できるアプリケーションにのみ適しています。

CLIENT_ACKNOWLEDGE応答モードを必要とするアプリケーションと、イベント率が高いアプリケーションでは、更新を受信するために非同期インタフェースを使用する必要があります。それらのアプリケーションで応答モードとしてCLIENT_ACKNOWLEDGEを使用する場合は、コールバック・スレッド自体のメッセージに応答する必要があります。「更新の受信および処理」を参照してください。