JMS Tuning For Performance
Performance can be a big factor when processing loads of messages, which means that you probably want to check the following configurations to make sure you get the most out of the JMS Connector.
Don’t Disable Connections Reuse
Connections are expensive to create, so it’s important to reuse them as much as possible.
By default, the JMS Connector uses an aggressive caching-strategy that reuses as much Consumers and Producers as possible. It is recommended to keep this configuration untouched, since any modification could reduce the performance of your application.
| Disabling connections caching will reduce the performance of your application. |
Increasing Concurrent Messages Processing
A good way of improving the performance of your application is to increase the number of concurrent consumers that receive messages from the same destination. This can be done easily in the JMS Connector by configuring the numberOfConsumers parameter.
Out of the box, the listener will use four consumers concurrently on the same destination, but you can increase this number to the one that fits better your needs:
<jms:listener config-ref="config" destination="#[vars.destination]" numberOfConsumers="20"/>
Increasing the numberOfConsumers is the easiest way to improve the throughput of your listeners.
|
Optimize Your Configuration For Clusters
For applications running in clusters, you have to keep in mind the concept of primary node and how the connector will behave. When running in a cluster, the JMS listener default behavior will be to receive messages only in the primary node, no matter what kind of destination you are consuming from.
In case of consuming messages from a Queue, you’ll want to change this configuration to receive messages in all the nodes of the cluster, not just the primary. This can be done with the primaryNodeOnly parameter:
<jms:listener config-ref="config" destination="${inputQueue}" primaryNodeOnly="false"/>Consuming messages from a Topic is a bit different, since the default behavior of receiving messages only in the primary node is the most common use case, given that it avoids processing the same message multiple times across the cluster.
If you are using the JMS 2.0 shared subscriptions mechanism, then you’ll want to change the cluster configuration to consume from all the nodes, again setting primaryNodeOnly to 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>
When listening from a Queue in a cluster, change the primaryNodeOnly configuration to false.
|
When listening from a Topic in a cluster, not using the primaryNodeOnly configuration will cause the cluster to process the same message more than once, unless shared-subscriptions is used.
|