|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
a basic question related to performance |
« View previous topic :: View next topic » |
Author |
Message
|
Srinivasan |
Posted: Fri Nov 25, 2005 10:31 am Post subject: a basic question related to performance |
|
|
Apprentice
Joined: 12 Jul 2005 Posts: 41 Location: Chennai
|
Hi,
I have an MQ receiving program which works under triggering mechanism.
Im working in AS/400 platform. when a message arrives at local queue a trigger message is sent to the initiation queue, trigger monitor calls the application which gets the message from the local queue. Every time the application receives message from local queue it is getting connected to the queue manager and then opens the queue and after receiving mesasge, it closes and gets disconnected.
Can we have the queue manager cnnected and queue opened in a program and then call another program which gets the message and processes. assume the calling program as server. the called program gets called about 10000 times a day(this is not a single call for 10000 messages but 10000 calls of 1 message per call). Once we get the server down can we use MQCLOSE and MQDISC once to get disconnected from the MQ manager.
the above talks above
1 MQCONN, 1 MQOPEN, 1 MQCLOSE, 1 MQDISC
adn 10000 MQGETS (for each call to the calling program)
Can we do this in any way? else if we get the MQCONN, MQOPEN and MQCLOSE and MQDISC 10000 times, will that cause a performance overhead?
Regards,
Srinivasan _________________ Srinivasan for MQ discussion |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Nov 25, 2005 10:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
MQCONN is expensive.
Your application, at a minimum, should not get only one message when it is triggered. It should keep processing messages until the queue is empty (a 2033 return code is given from MQGET).
There are various design patterns discussed, although not formally as design patterns, in the Application Programming Guide. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
hopsala |
Posted: Sat Nov 26, 2005 2:21 pm Post subject: Re: a basic question related to performance |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
I am getting the distinct feeling there's a misconception lurking within your question logic, but I can't quite pinpoint it; I say this due to the following:
Srinivasan wrote: |
Im working in AS/400 platform. when a message arrives at local queue a trigger message is sent to the initiation queue, trigger monitor calls the application which gets the message from the local queue. Every time the application receives message from local queue it is getting connected to the queue manager and then opens the queue and after receiving mesasge, it closes and gets disconnected. |
Srinivasan wrote: |
Can we have the queue manager cnnected and queue opened in a program and then call another program which gets the message and processes. |
So let me make sure one thing is clear: When a trigger monitor calls an application it must immediately MQCONN; it is impossible to "receive a message" if you didn't connect. Then it must MQOPEN the queue, and as jeff said, simply read it until it gets 2033. In short, triggered programs *usually* look something like this:
Code: |
[*]Parameters <QMName>, <QName>
MQCONN <QMNAme>
MQOPEN <QName>
While (RC != 2033)
MQGET
if (RC = 2033)
Wait 5 minutes
MQGET
end if
end while
MQCLOSE
MQDISC |
This may not precisely fit your particular case scenario - read the programming manual, as jeff had suggested, to see other options.
Srinivasan wrote: |
Can we do this in any way? else if we get the MQCONN, MQOPEN and MQCLOSE and MQDISC 10000 times, will that cause a performance overhead? |
Lastly, the answer to this is YES; not only "an" overhead, but a huge overhead, I would estimate (crudely) a 400% overhead or more, if messages are relatively small. And don't forget that if you raise one application instance per message, you have added uptime, memory usage etc. |
|
Back to top |
|
 |
zpat |
Posted: Sun Nov 27, 2005 4:54 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Always perform any wait as a MQGET WAIT, that way you get any subsequent message immediately it arrives. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Nov 27, 2005 11:07 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
From your wording I suspect that you are triggering with EVERY instead of first. We do that type of triggering only on the mainframe when the transaction is Tclassed so that we have a limited number of threads working the queue.
Any program servicing the triggered queue should keep reading the queue until empty, regardless of whether the trigger be FIRST or EVERY.
Doing a read with wait(x) will help performance as it bridges tiny gaps in arrival.
However the good design of a triggered app is
a) get invoked in the background so as to free the qmgr from waiting on the process to finish before invoking the next call (resource efficiency)
b) to limit the number of instances servicing the queue (resource efficiency / thread efficiency)
c) to remove itself from memory / working storage by shutting itself down once the queue is empty. (releasing unused resources / resource /memory efficiency)
Enjoy 
Last edited by fjb_saper on Sun Nov 27, 2005 11:17 pm; edited 1 time in total |
|
Back to top |
|
 |
hopsala |
Posted: Sun Nov 27, 2005 11:13 pm Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
zpat wrote: |
Always perform any wait as a MQGET WAIT, that way you get any subsequent message immediately it arrives. |
Woops! You're perfectly right zpat - a better option would be to remove the wait completely. I was aiming at getting control back to the application, for logging and other processing purposes - for example a log line such as "12/12/2012 12:43 no messages in queue, retrying...". |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Nov 27, 2005 11:21 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
hopsala wrote: |
zpat wrote: |
Always perform any wait as a MQGET WAIT, that way you get any subsequent message immediately it arrives. |
Woops! You're perfectly right zpat - a better option would be to remove the wait completely. I was aiming at getting control back to the application, for logging and other processing purposes - for example a log line such as "12/12/2012 12:43 no messages in queue, retrying...". |
That would not be my choice for a triggered app. It would be "no messages in queue shutting down"...
Now if you have a listener pattern implemented through a receiver it does make sense.... But that should not be a triggered app. |
|
Back to top |
|
 |
Srinivasan |
Posted: Mon Nov 28, 2005 8:58 pm Post subject: a basic question related to performance |
|
|
Apprentice
Joined: 12 Jul 2005 Posts: 41 Location: Chennai
|
Hi all,
thanks for all your Ideas. Now I have opted another method and implemented the solution. My new solution is implemented as follows, This works under listener pattern. A program will always look into the local queue and once a message comes to the queue, it picks up and delivers to another program to process.
The problem here is there is a job always running on the local queue. Do anybody see advantage of this method over triggering?
Can I have this solution as such or do you want me to go to triggering itself?.
I need your suggestion
Regards,
Srinivasan _________________ Srinivasan for MQ discussion |
|
Back to top |
|
 |
EddieA |
Posted: Mon Nov 28, 2005 9:33 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Quote: |
A program will always look into the local queue and once a message comes to the queue, it picks up and delivers to another program to process. |
As long as the listener process starts the other applications in the background, so it's not waiting for it to finish before handling the next message.
It all comes done to the choice between a constantly running daemon, listening for messages, or firing a triggered application when messages arrive, coupled with a delay, to allow more messages, before terminating. Only you know your message pattern, and which scenario makes sense for that pattern.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
hopsala |
Posted: Tue Nov 29, 2005 7:54 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
Your solution is valid, but there's a big problem with it - if your application crashes, it won't go up again without manual intervention, aside from the fact you won't even know about it...
I'd go with a dual solution: code your appl to always MQGET on queue as you suggested (though I'd not opt for a forever delay, rather a limited one that writes a line to log from time to time), and use triggering on first; if/when your prog crashes an implicit MQCLOSE will be issued, and will thus restart your application automatically.
Oh, and don't forget about implementing a backout scheme, or poisoned messages will wreak havoc upon the unsuspecting bit population. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|