IBM MQ のパフォーマンス調整
多くのメッセージを処理する場合、パフォーマンスは重要な要因となります。そのため、IBM MQ Connector のパフォーマンスを最大限に引き出せるように、次の設定を確認してください。
接続の再利用を無効化しないこと
接続の確立には多くのリソースが使用されるため、接続はできる限り再利用するようにしてください。
注意:
-
デフォルトでは、IBM MQ Connector はアグレッシブな
caching-strategy を使用します。この戦略では、可能な限り多くのコンシューマーとプロデューサーを再利用します。この設定を少しでも変更すると、アプリケーションのパフォーマンスが低下するおそれがあるため、この設定には触れないことをお勧めします。 -
接続キャッシュを無効化すると、アプリケーションのパフォーマンスが低下します。
同時メッセージ処理数の増大
アプリケーションのパフォーマンスを高めるための良い手段として、同じ宛先からメッセージを同時に受信するコンシューマー数を増やすという方法があります。
IBM MQ Connector では、numberOfConsumers パラメーターの設定によって簡単に行うことができます。
listener は、デフォルトでは同じ宛先に対して 4 つのコンシューマーを使用しますが、実際のニーズに合わせてこの数を増やすことができます。
<ibm-mq:listener config-ref="config"
destination="#[vars.destination]"
numberOfConsumers="20"/>
numberOfConsumers を増やすことが、リスナーのスループットを改善するための最も簡単な方法です。
|
クラスター設定の最適化
クラスターで動作するアプリケーションの場合は、プライマリノードの概念と、コネクタの動作に注目してください。クラスターで動作する場合、IBM MQ listener のデフォルト設定では、どのような種類の宛先からメッセージをコンシュームする場合でも、プライマリノードでのみメッセージを受信します。
キューからメッセージをコンシュームする場合は、この設定を変更して、プライマリノードだけではなく、クラスター内のすべてのノードからメッセージを受信するようにしてください。
これは primaryNodeOnly パラメーターで行います。
<ibm-mq:listener config-ref="config"
destination="${inputQueue}"
primaryNodeOnly="false"/>トピックからメッセージをコンシュームする場合は少し異なり、プライマリノードのみからメッセージを受信するというデフォルト動作は最も一般的なユースケースであるため、これによってクラスター内で同じメッセージが複数回処理されてしまうことを防止できます。
JMS 2.0 共有サブスクリプションメカニズムを使用していて、すべてのノードからメッセージをコンシュームするようにクラスター設定を変更したい場合も、同じように primaryNodeOnly を false に設定します。
<ibm-mq:listener config-ref="JMS_20_config"
destination="${inputTopic}"
primaryNodeOnly="false">
<ibm-mq:consumer-type>
<ibm-mq:topic-consumer
shared="true"
subscriptionName="clusteredEventListener"/>
</ibm-mq:consumer-type>
</ibm-mq:listener>
クラスターのキューからリスンする場合は、primaryNodeOnly 設定を false に変更します。
|
クラスターのトピックからリスンする場合は、共有サブスクリプションを使用しない限り、primaryNodeOnly 設定を使用しないとクラスターが同じメッセージを複数回処理することになります。
|