---
schema_version: "1"
id: a836cf6bbb54a575c3136c8bf694f983b42bc3fd3b57280cb9459475482d3c19
title: IBM MQ のパフォーマンス調整
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/ibm-mq-connector/1.7/ibm-mq-performance.md
canonical_url: https://docs.mulesoft.com/jp/ibm-mq-connector/1.7/ibm-mq-performance
source_site: docs.mulesoft.com
content_type: documentation
content_hash: f459007699668f194e995292eae2f95e3f2981a1620499477ea9ec2db9065904
description: MuleSoft Documentation Site
release: "1.7"
latest: true
---
# IBM MQ のパフォーマンス調整

多くのメッセージを処理する場合、パフォーマンスは重要な要因となります。そのため、IBM MQ Connector のパフォーマンスを最大限に引き出せるように、次の設定を確認してください。

## [](#接続の再利用を無効化しないこと)接続の再利用を無効化しないこと

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

**注意:**

- デフォルトでは、IBM MQ Connector はアグレッシブな ​`caching-strategy`​ を使用します。この戦略では、可能な限り多くのコンシューマーとプロデューサーを再利用します。この設定を少しでも変更すると、アプリケーションのパフォーマンスが低下するおそれがあるため、この設定には触れないことをお勧めします。
- 接続キャッシュを無効化すると、アプリケーションのパフォーマンスが低下します。

## [](#同時メッセージ処理数の増大)同時メッセージ処理数の増大

アプリケーションのパフォーマンスを高めるための良い手段として、同じ宛先からメッセージを同時に受信するコンシューマー数を増やすという方法があります。 IBM MQ Connector では、​`numberOfConsumers`​ パラメーターの設定によって簡単に行うことができます。

`listener`​ は、デフォルトでは同じ宛先に対して 4 つのコンシューマーを使用しますが、実際のニーズに合わせてこの数を増やすことができます。

```xml
<ibm-mq:listener config-ref="config"
     destination="#[vars.destination]"
     numberOfConsumers="20"/>
```

<table><tbody><tr><td class="icon"><i class="fa icon-tip" title="Tip"></i></td><td class="content"><code>numberOfConsumers</code>​ を増やすことが、リスナーのスループットを改善するための最も簡単な方法です。</td></tr></tbody></table>

## [](#クラスター設定の最適化)クラスター設定の最適化

クラスターで動作するアプリケーションの場合は、​**プライマリノード**​の概念と、コネクタの動作に注目してください。クラスターで動作する場合、IBM MQ ​`listener`​ のデフォルト設定では、どのような種類の宛先からメッセージをコンシュームする場合でも、プライマリノードでのみメッセージを受信します。

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

これは ​`primaryNodeOnly`​ パラメーターで行います。

```xml
<ibm-mq:listener config-ref="config"
     destination="${inputQueue}"
     primaryNodeOnly="false"/>
```

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

JMS 2.0 共有サブスクリプションメカニズムを使用していて、すべてのノードからメッセージをコンシュームするようにクラスター設定を変更したい場合も、同じように ​`primaryNodeOnly`​ を ​`false`​ に設定します。

```xml
<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>
```

<table><tbody><tr><td class="icon"><i class="fa icon-tip" title="Tip"></i></td><td class="content">クラスターのキューからリスンする場合は、​<code>primaryNodeOnly</code>​ 設定を ​<code>false</code>​ に変更します。</td></tr></tbody></table>

<table><tbody><tr><td class="icon"><i class="fa icon-warning" title="Warning"></i></td><td class="content">クラスターのトピックからリスンする場合は、共有サブスクリプションを使用しない限り、​<code>primaryNodeOnly</code>​ 設定を使用しないとクラスターが同じメッセージを複数回処理することになります。</td></tr></tbody></table>

## [](#関連情報)関連情報

- [メッセージのコンシューム方法](https://docs.mulesoft.com/jp/ibm-mq-connector/1.7/ibm-mq-consume)
- [トピックサブスクリプションの使用](https://docs.mulesoft.com/jp/ibm-mq-connector/1.7/ibm-mq-topic-subscription)