パフォーマンスを向上させるための JMS のチューニング

大量のメッセージを処理する場合、パフォーマンスは大きな要因になり得ます。そのため、JMS コネクタを最大限に活用するには、おそらく以下の設定を確認する必要があるでしょう。

接続の再利用を無効化しないこと

接続の確立には多くのリソースが使用されるため、接続はできる限り再利用するようにしてください。

デフォルトでは、JMS コネクタはアグレッシブな caching-strategy を使用します。この戦略では、可能な限りコンシューマとプロデューサを再利用します。この設定を変更すると、アプリケーションのパフォーマンスが低下するおそれがあるため、変更しないことをお勧めします。

接続のキャッシングを無効にすると、アプリケーションのパフォーマンスが低下します。

同時メッセージ処理数の増大

アプリケーションのパフォーマンスを改善する良い方法の 1 つとして、同じ宛先からメッセージを受信する同時コンシューマ数を増やすという方法があります。これは、numberOfConsumers パラメータを設定することで JMS コネクタで簡単に実行できます。

特に設定しないと、listener は同じ宛先で同時に 4 つのコンシューマ​を使用しますが、この数はニーズに合わせて増やすことができます。

<jms:listener config-ref="config" destination="#[vars.destination]" numberOfConsumers="20"/>
numberOfConsumers を増やすことが、リスナのスループットを改善するための最も簡単な方法です。

クラスタ設定の最適化

クラスタで実行するアプリケーションの場合、​プライマリノード​の概念およびコネクタの動作を念頭に入れておく必要があります。クラスタで実行されている場合、JMS listener のデフォルトの動作は プライマリノードでのみのメッセージの受信​であり、これはコンシューム元の宛先の種別に関係ありません。

キュー​からメッセージをコンシュームする場合、プライマリだけでなく、クラスタの​すべてのノードでメッセージを受信するようにこの設定を変更する​と良いでしょう。これは primaryNodeOnly パラメータで行います。

<jms:listener config-ref="config" destination="${inputQueue}" primaryNodeOnly="false"/>

トピック​からのメッセージのコンシュームは少し異なります。これは、クラスタ内で同じメッセージを複数回処理するのを回避することを考えれば、デフォルトの動作である​プライマリノードでのみのメッセージの受信が最も一般的なユースケースである​ためです。

JMS 2.0 の​共有サブスクリプション​メカニズムを使用している場合、​すべてのノードからコンシュームするようにクラスタ設定を変更​し、やはり primaryNodeOnlyfalse に設定すると良いでしょう。

<jms:listener config-ref="JMS_20_config" destination="${inputTopic}" primaryNodeOnly="false">
     <jms:consumer-type>
         <jms:topic-consumer shared="true" subscriptionName="clusteredEventListener"/>
     </jms:consumer-type>
 </jms:listener>
クラスタの​キュー​からリスンする場合は、primaryNodeOnly 設定を false に変更します。
クラスタの​トピック​からリスンする場合は、共有サブスクリプションを使用しない限り、primaryNodeOnly 設定を使用しないとクラスタが同じメッセージを複数回処理することになります。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub