|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Increasing the speed for getting message from Q using MQGET |
« View previous topic :: View next topic » |
Author |
Message
|
Rahul999 |
Posted: Thu Oct 23, 2008 7:49 pm Post subject: Increasing the speed for getting message from Q using MQGET |
|
|
 Centurion
Joined: 14 Mar 2007 Posts: 134
|
Hi,
We are having a MQ client running on 1 server and this client is connecting to MQ Server on another machine.
Client is continuosly polling to get messages from the queue and once the message arrive it picks it using MQGET call and write it to the hard disk.
But the speed of arriving of messages into queues is much faster and the picking application is having trouble in getting messages and keeping the pace with the applications who is putting messages.
Is there any way we can increase the speed of Client application so that it can get messages faster from the queue.
Thanx |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Oct 23, 2008 7:55 pm Post subject: Re: Increasing the speed for getting message from Q using MQ |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Rahul999 wrote: |
Is there any way we can increase the speed of Client application so that it can get messages faster from the queue. |
Sure. Either add more hamsters to the server to make it run faster or re-write the client application to be more efficient in what it is doing.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
Rahul999 |
Posted: Thu Oct 23, 2008 8:47 pm Post subject: |
|
|
 Centurion
Joined: 14 Mar 2007 Posts: 134
|
Hi Roger,
How we can improve client application so that it wud process messages faster .
Thanx |
|
Back to top |
|
 |
David.Partridge |
Posted: Thu Oct 23, 2008 11:36 pm Post subject: |
|
|
 Master
Joined: 28 Jun 2001 Posts: 249
|
>Client is continuosly polling to get messages from the queue
What do you mean by that - I hope you are not issuing an MQINQ to get the queue depth ...
Or is it issuing an MQGET with zero timeout (i.e. 2033 immediately if not messages? If so that's not a good approach either.
Typically you'd sit in an MQGET with timeout and terminate on 2033.
Usual logic
Code: |
MCONN, MQOPEN
until getRC ne 0
MGET w/timeout
if getRC eq 0
process message
end
else
handle error if not 2033
end
end
MQCLOSE
MQDISC
|
If that is what you are doing, and the client can't keep up with the messages, then does your application design allow you to run multiple instances of the client, all feeding from the same queue? If so, then do that.
Is the delay caused by the actual processing of the message (as distinct from the MQGET)? If so then it's not MQ that's the problem!
Consider moving the application to the server as bindings mode is generally a lot quicker than client mode (especially if slow network).
Are you issuing an MQCMIT for every message you process, or only when you've processed all messages? If the former, does your business logic require this or can you change to only commit when you complete all messages or every so many messages? _________________ Cheers,
David C. Partridge |
|
Back to top |
|
 |
zpat |
Posted: Thu Oct 23, 2008 11:59 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Polling is a big NO-NO. This usually means the application sleeps and then does a MQGET (and then repeats this).
Don't do this because you won't get the message immediately it arrives.
Instead use MQGET with MQGMO_WAIT. That way the message will be processed without any delay because MQ ends the wait upon message arrival.
You can set the wait interval (which is only the max wait not the min) to a value such as 60 seconds then loop around when a RC 2033 happens (this allows the application to regain control periodically even when there are no messages being processed).
To improve throughput you can run the same program more than once against the same queue (or multi-thread it). MQ will never give the same message to more than one program (unless backed out). |
|
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
|
|
|
|