Author |
Message
|
Vin |
Posted: Tue Aug 06, 2002 10:10 pm Post subject: Performance with Dynamic Queues |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
I had a question on the performance with Dynamic Queues. Our app uses request/response kind of mechanism where a request is made to a remote system and the response expected on a temporary dynamic queue which we create on our end. As we know in this case the transmission queue name should be the same as the remote queue manager name which precludes us from having multiple transmission queues for improving performance. The thing here is our app performance is reduced since we only have one transmission queue to ship all the messages back. Is there any other way to increase the performance of this app?as far as having more transmission queues and channels? The remote machine from where we are recieving responses from has only one Queue Manager. Thanks for all the ideas. |
|
Back to top |
|
 |
Vin |
Posted: Fri Aug 09, 2002 9:38 am Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Any ideas on this? Thanks. |
|
Back to top |
|
 |
kolban |
Posted: Fri Aug 09, 2002 10:16 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2001 Posts: 1072 Location: Fort Worth, TX, USA
|
Sounds like you have a couple of questions here ... on dynamic queues, with MQ 5.2 or MQ 5.3, performance of these queues is excellent.
With transmission queues, you should only need one of them. Why do you feel you need more? |
|
Back to top |
|
 |
Vin |
Posted: Fri Aug 09, 2002 10:52 am Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Kolban,
The reason for we wanting to have more transmission queues is that the response is looking linear. When ten threads submit a request each one is processed linearly since all the message come back on the same transmission queue right? If we had more transmission queues we could add additional remote queue definitions pointing to this new transmission queue and that would definelty scale better? I wanted to ask if any one had the same problem and what did they do to overcome that. Appreciate your ideas. |
|
Back to top |
|
 |
sgopal |
Posted: Fri Aug 09, 2002 3:49 pm Post subject: |
|
|
Acolyte
Joined: 30 Jul 2002 Posts: 63
|
Quote: |
the transmission queue name should be the same as the remote queue manager name which precludes us from having multiple transmission queues for improving performance |
You can define more than one transmission queue for sending messages to remote queue manager.
I tested by defining two transmission queue, 2 remote queues, 2 sender channel on the local queue manager and 2 local queues, 2 receiver channels on the remote queue manager. I could send messages from local to remote queue manager.
Try defining sender channels by setting appropriate batchsize or batch interval values, Please refer Chapter 6 of "MQSeries Intercommunication Guide " for channel attributes. |
|
Back to top |
|
 |
Vin |
Posted: Fri Aug 09, 2002 8:15 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Gopal,
Thanks for the input. But the question is whether I can have multiple transmission queues with the same name? This is not possible I guess right? I can only have one transmission queue with the name of the remote queue manager if I'm using a request/reply kind of mechanism right? correct me If I'm wrong. Thanks very much. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Fri Aug 09, 2002 9:00 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
No. You cannot use duplicate names. Each queue (MQ Object) must have a unique name.
Your only solution for parallelism is to do what sgopal suggested.
Note: Two years ago, I worked for a financial institution in the mid-west (USA). One of the MQ applications running on Solaris did request / reply to an OS/390 queue manager. Each transaction (started on Solaris) created a local temp-dynamic queue for the mainframe MQ appl to reply to. There was only one channel used for this application / scenario. Average daily volume was about 8 – 10 million transaction (per day). I think the payload size per message was 10KB.
I learnt 2 things from the engagement. (1) MCAs can really move messages and (2) the overhead for creating a temp-dynamic is almost nothing.
later
Roger... |
|
Back to top |
|
 |
Vin |
Posted: Sat Aug 10, 2002 6:21 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Thanks roger. We have an application which does exactly what you experienced back in your financial institution firm. My question is I can't change this application not to have temporary dynamic Queues, it's already in place. What else can I touch to improve the performance of this system. As gopal has suggested I need to be looking into the Batch size and the Batch Interval for the channels. Is this the only fix which I can do or is there anything else which you can suggest from your past experience? Again thanks so much for all the input. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sun Aug 11, 2002 6:40 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Are the messages persistent? If they are, do they really need to be?
Also, maybe the MQ part is just fine. Who's to say the replying app isn't the slow link? Maybe it takes to long to do its work! _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vin |
Posted: Mon Aug 12, 2002 11:00 am Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Al the messages are non-persistent. As I cannot have multiple transmission queues with the same name, what else can I do to performance tune this system? it seems like the response is just linear? Thanks. |
|
Back to top |
|
 |
Vin |
Posted: Mon Aug 12, 2002 11:01 am Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
I just wanted to know if anyone played around with the batchsize and batchintl attributes of the channel? What should these be set to? What's a good value for these attributes assuming non-persistent messages and no synpointing? Thanks. |
|
Back to top |
|
 |
|