Here are some tips for users of WebSphere MQ JMS Client API to improve performance. The performance reports in the product SupportPac website gives detailed description about performance. In this blog we'll look at programming tips that can be easily adopted by a programmer using JMS API and connecting to a WebSphere MQ queue manager. There are several features that the JMS provider offers. Features provided can be used easily used with some simple configuration on the connection factory and the destination.
Using non-persistent messages
JMS client can set delivery mode for the message. By default messages are persistent so that the JMS provider can take extra care to ensure that the message is not lost due to JMS provider failure. The delivery mode can be set to non persistent while the message is sent. For example:
producer.send(message, DeliveryMode.NON_PERSISTENT, Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
Significant performance difference can be observed by testing with very less number of messages also.
Using Binding mode
Bindings is a direct connection to the queue manager that is on the same computer as the JMS client. It can be easily set on the connection factory using:
More details can be found here.
Using Correlation ID while using selectors
When using the JMS message selectors to receive messages, its always recommended to use the correlation ID field for message selection. In WebSphere MQ V7 the message selection happens at the server side. But correlation ID still has its advantages still as it maps to the queue manager's internal representation of the message. More details can be found here.
Asynchronous Put Feature
The applications can transmit JMS messages at rapid sequence without waiting for the acknowledgment from the queue manager for every sent message using this feature. This property can be set on the destination object. Programmatically it can be set using:
Read ahead to receive messages
For non-persistent messages, the messages can be sent to the client before its requested using this feature. This property can be set on the destination programmatically using:
Multiplexed Sockets and Conversation Sharing
This is a feature having many advantages for a JMS client. While programming for performance, the feature needs to be carefully configured. Using SHARECNV(1) allocates a socket for each application thread which reduces the overhead of Multiplexing. This is a configuration on the queue manager and not on the JMS client.
A non-transacted mode and acknowledgment mode
A non-transacted JMS session is always easier to use and gives higher performance. A non-transacted session can be created using:
senderSession = jmsConnection.createSession(false, Session.DUPS_OK_ACKNOWLEDGE);
If non-persistent messages are used in non-transacted session, higher performance can be seen. If the DUPS_OK_ACKNOWLEDGE mode is used, there could be instances when duplicates can arrive, but can deliver slightly better performance but not very significant.
There are several other JMS best practices for performance ... You can post them as comment.
Links that caught my attention this week while writing this blog:
- WebSphere and Messaging blog (Focuses more on WAS and MQ integration)
Disclaimer : The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.