ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » a basic question related to performance

Post new topic  Reply to topic
 a basic question related to performance « View previous topic :: View next topic » 
Author Message
Srinivasan
PostPosted: Fri Nov 25, 2005 10:31 am    Post subject: a basic question related to performance Reply with quote

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
View user's profile Send private message Yahoo Messenger
jefflowrey
PostPosted: Fri Nov 25, 2005 10:44 am    Post subject: Reply with quote

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
View user's profile Send private message
hopsala
PostPosted: Sat Nov 26, 2005 2:21 pm    Post subject: Re: a basic question related to performance Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Sun Nov 27, 2005 4:54 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sun Nov 27, 2005 11:07 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
hopsala
PostPosted: Sun Nov 27, 2005 11:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sun Nov 27, 2005 11:21 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Srinivasan
PostPosted: Mon Nov 28, 2005 8:58 pm    Post subject: a basic question related to performance Reply with quote

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
View user's profile Send private message Yahoo Messenger
EddieA
PostPosted: Mon Nov 28, 2005 9:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
hopsala
PostPosted: Tue Nov 29, 2005 7:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » a basic question related to performance
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.