Message listener port maximum sessions
When using MDBs within an application it is recommended that advantage is taken of the ability to process messages simultaneously. This is done by increasing the maximum number of sessions on any listener ports that are configured. By default, Maximum sessions is set to 1.
Component: Message Listener Applies to specific messaging topologies: No - as long as using MDBs Requires specific usage of JMS in application: Yes Location of setting: Servers | Application Servers | MyAppServer | Message Listener Service | Listener Ports | MyListenerPort | Maximum sessions Deciding on the number to increase this value by is going to have to involve a performance testing and tuning exercise as there a number of factors that will affect this value. The testing is necessary as there are many variants, making it difficult to estimate an optimum value for Maximum sessions. Ultimately it comes down to two factors:
- Time to complete onMessage method of MDB
The time that it takes to process a message off the message queue is going to determine how long resources will be in use. When a message is passed to an onMessage method of an MDB there will be one listener port session, one session and one listener service thread in use. All of these resources will be locked whilst that message is being processed. The shorter the service time of the onMessage method the less time the resources are locked and so the sooner they are free to process another message.
The average time it takes for the onMessage to complete on an MDB can be found using the Tivoli Performance Viewer. To be accurate this average time must be measured when a realistic application workload is being tested in a realistic production environment.
- Peak workload arrival rate
The advantage of having multiple sessions is that up to x messages from the destination may be processed simultaneously, where x is the free number of listener port sessions. The peak workload will affect the value for the number of maximum sessions as it defines the time when the system will be at its busiest.
In a system where the time between each message arriving is more than the time it takes to process one message, adding more message listener sessions is not going to give any performance improvement as there will be no messages waiting on the queue.
However if the messages cannot be processed faster than the arrival rate then there is scope for increasing the Maximum sessions value to prevent a backlog of messages occurring.
The total processing time for a message includes not only how long the message takes to be processed once it has been delivered to the MDB but also the time it takes waiting to be processed. It is only the time that it spends waiting that can be optimized by changing the maximum number of sessions.
Understanding the peak and average workload arrival rates are essential in configuring the optimal value for maximum sessions for your application running in your environment.
If possible, come up with an estimate of the maximum number of messages that will arrive on the message queue over a given amount of time that makes sense in your application (second, minute, etc.).
As with all performance tuning, the correct balance between efficient usage of system resources and maximizing throughput needs to be reached. If the workload does arrive faster than messages can be processed then increasing the maximum number of sessions on a listener port will only increase performance if there is spare resource available on the physical server to perform the simultaneous processing of messages.
It is always worth monitoring the number of sessions in use on a listener port. If a test shows that setting the Maximum sessions to 10 did not perform any faster than Maximum sessions set to 5, check to make sure that all 10 sessions were actually in use using the Tivoli Performance Viewer. It might be the case that not enough workload is arriving to push the system to use all 10 sessions, in which case look at the frequency that the message sender is capable of placing messages on the queue.
There is, however, going to be a limit to increasing the number of Maximum sessions that is not to do with hardware restrictions. This is because there is only one queue reader thread per queue per JVM. This is the thread that is farming out work to the sessions. So as you increase Maximum sessions, the queue reader thread will be kept more busy.
The messaging system topology and WAS topology will make a difference on how the peak workload arrival rate is measured and how long a message takes to process. The topology used in Clustered Trade3 application WebSphere MQ and WebSphere Business Integration Event Broker has two appservers pointing at the same message queue for redundancy purposes. This means that the message queue is not solely accessed by one message listener service.
Whilst the time to complete the message and the workload arrival rate have a significant impact on how many sessions should listen for messages, they are not the only settings, and are in themselves affected by a great number of other factors. The only reliable way to determine the appropriate number of maximum sessions on a listener port is through thorough performance testing and tuning.
Having trouble getting the Maximum sessions value to increase above 1 in tests? Your messages are probably being processed faster than the next one is arriving. One way to simulate the peak workload arriving at the message queue is to stop the message listener port in the Administrative Console, but continue to forward messages to the message queue. This will fill up the queue with messages. Once the number of messages on the queue has reached the desired amount, start the message listener port up again.
One final point to reemphasize, increasing the maximum number of sessions on a listener port requires increasing other values too, check Component relationships when using MDBs to find out what else needs to be increased.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.