Hi All, Currently we are facing some performance issues in of our applications which are using Message Driven Beans (Transaction type is Bean Managed). Also queues are build as persistent.
Appreciate any guidance provided by you on this subject.
Following is the architecture of our application: (Websphere app server 5 and 6 / Websphere MQ JMS provider)
app 1 (deployed on was 5.X) -----> App2 deployed on was 6 --->database.
Issue: There are delays between when the message was sent by application 1 and when it was picked up by the application 2. This issue is exaggerated when the volume of transaction increases.
Out of 57000 (over a period of 3 horus) send by application 1 to application 2, 5000 transactions have delays ranging from 1 to 80 seconds. Out of the 5000 transactions which have delays there are 4 beans on the application 2 which constitutes 80 %. (This is because these beans are called quite frequently)
Current Settings for Application 2: 1 Connection Factory Max Connections: 10 Session Pool : 120
Thread Pool for Listener : 100 Max Sessions for Listener : 40 Max Messages for Listener: 1
Application 2 uses the same connection factory while sending back the reply to application 1.
Is increasing hardware power an option? Also, what is the purpose of message driven beans in your application? For example, they are primarily used for asynchronous communication implying that you aren't particularly interested in when they arrive so long as they arrive in a reasonable amount of time (and with thousands of messages at a time 80 seconds is reasonable).
Alternatively, do you want sychronous behavior? As in the message is sent and response immediately shown? You might want to consider local session beans, also because WebSphere can optimize them accross the same server such that they skip serialization which is a big bottle neck for remote applications and message driven beans.
Finally, have you traced which item is the bottle neck? It could be network communication, the time to prepare the message, the time for server one to send it, etc... Using profiling you may be able to find where the messages are taking the longest and optimize it.