パフォーマンスを向上させるための 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 の​​共有サブスクリプション​​メカニズムを使用している場合、​​すべてのノードからコンシュームするようにクラスタ設定を変更​​し、やはり ​primaryNodeOnly​ を ​false​ に設定すると良いでしょう。

<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!