| Author |
Message
|
| touchofcrypticthunder |
 Posted: Tue Jun 08, 2010 5:29 am Post subject: Performance difference between BROWSE and GET in MQ |
 |
|
Apprentice
Joined: 08 Jul 2009
Posts: 30
|
Hi,
Here is a proformance query when BROWSE and GET messages from WMQ.
There is an application that reads data arriving in the form of MQ messages and loads them into the database. DataStage MQ connector being used to read messages off an IBM MQ. There are two ways in which we read messages off the queue, one destructively and the other non-destructively. We are reading around 5,000 messages at a time with many thousands of messages waiting on the queue. We are reading messages using the correlID. We are observing that the non-destructive MQ read is reasonably fast in most cases. However, the destructive MQ read takes a long time (thrice as much as the non-destructive MQ read), especially when there is a large number of messages waiting on the queue. Why would this be? And what can we do on the MQ side to alleviate this problem?
Is there something that we can do to increase the overall read performance from MQ?
If there is really a performance issue with GET from MQ, I thought of suggesting BROWSE msg from MQ and asking source application to set expiry so that just BROWSE of messages will not cause queue full problem.
Any help will be greatly appreciated.
NOTE: This is an issue raised in internal community and not faced my me. Posting it here on behalf of issue requester. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 08, 2010 6:00 am Post subject: Re: Performance difference between BROWSE and GET in MQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| touchofcrypticthunder wrote: |
Is there something that we can do to increase the overall read performance from MQ?
|
Don't keep thousands of messages on a queue. When a message is read destructively the queue manager has to reorganise the queue to flag the message as read, then re-flag it once the read is committed. There's no valid reason to keep so many messages on a queue when you, by your own admission, have a database to keep them in. A database is far better at finding a given piece of data by key (a key such as the correl id) than the queue manager is.
Message expiry should be a function of the business purpose of the data. If the data has a limited lifespan, the expiry should reflect that. Hence if these messages are replies and you have thousands of messages on a queue because the request has timed out then this is a good idea.
Non-destructive reading is seldom a solid design and is typically slower than a destructive read (except in your special case as I mention above). If you're uncertain if you want the message removed it not (because of business or processing logic) read it destructively under syncpoint and roll it back if you have to.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 08, 2010 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9406
Location: US: west coast, almost. Otherwise, enroute.
|
Are you saying that the only difference in your application behavior is between MQGET and MQGET with MQGMO_BROWSE? The app does the CorrelId match in both cases?
Is the time difference causing you (your apps) to miss SLAs?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| touchofcrypticthunder |
| Posted: Tue Jun 08, 2010 8:57 pm Post subject: |
|
|
Apprentice
Joined: 08 Jul 2009
Posts: 30
|
| Code: |
| When a message is read destructively the queue manager has to reorganise the queue to flag the message as read, then re-flag it once the read is committed. |
When you say this, does it not contradicts with below statement
| Code: |
| Non-destructive reading is seldom a solid design and is typically slower than a destructive read |
| Code: |
| Don't keep thousands of messages on a queue |
Messages are not being kept is a queue. Application is reading the messages from queue as soon as it arrives and store them in database. Issue is when reading/browsing messages from the queue. |
|
| Back to top |
|
|
| touchofcrypticthunder |
| Posted: Tue Jun 08, 2010 9:02 pm Post subject: Re: Performance difference between BROWSE and GET in MQ |
|
|
Apprentice
Joined: 08 Jul 2009
Posts: 30
|
[bruce2359 wrote]Are you saying that the only difference in your application behavior is between MQGET and MQGET with MQGMO_BROWSE? The app does the CorrelId match in both cases? [/bruce2359 wrote]
Yes, there is a performance difference between GET and BROWSE(where BROWSE is claimed to be relatively faster than GET). In both the cases CorrelId is being used. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 09, 2010 5:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| touchofcrypticthunder wrote: |
| Messages are not being kept is a queue. Application is reading the messages from queue as soon as it arrives and store them in database. |
Doesn't this contradict
| touchofcrypticthunder wrote: |
| We are reading around 5,000 messages at a time with many thousands of messages waiting on the queue |
If messages are not kept in a queue and the application is reading them as soon as they arrive, what are these many thousands of messages waiting on the queue for?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 09, 2010 5:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9406
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Yes, there is a performance difference between GET and BROWSE(where BROWSE is claimed to be relatively faster than GET). |
Where is this so claimed?
What other differences? How is the actual processing of the message different when you do the browse vs. when you do the destructive get?
You mentioned in your post that there is database activity? Is this activity exactly the same with one of these, but not the other?
How did you determine (read: measure) that one way took longer? Is this a batch job? Interactive? What other differences?
| Quote: |
| We are reading around 5,000 messages at a time with many thousands of messages waiting on the queue. We are reading messages using the correlID. We are observing that the non-destructive MQ read is reasonably fast in most cases. |
Does at a time mean that you are creating ONE unit-of-work that contains 5,000 messages?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Wed Jun 09, 2010 6:12 am; edited 1 time in total |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jun 09, 2010 6:10 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
If you do a GMO_BROWSE, don't you still need to do the destructive GET?
Also, are these persistent messages and are you doing single phase or two phase commits?
_________________
-wayne |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 09, 2010 6:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9406
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If you do a GMO_BROWSE, don't you still need to do the destructive GET? |
To paraphrase: does the application do a combination of browse, AND then a destructive get - for all or some of the messages browsed? If so, then you app is doing two MQI calls - one to browse AND one to destructively get each message.
Does the app always browse NEXT? Or does your app browse from the front of the queue each time?
Are your other MQ qmgrs or applications experiencing performance issues?
[edit] It has been my experience that most application performance issues are from poorly/badly coded applications
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 09, 2010 6:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9406
Location: US: west coast, almost. Otherwise, enroute.
|
...and is this a new application? If not, did it always behave this way? If not, what has changed in the application?
If this is a new application, AND your other MQ apps are behaving well (within SLAs), I'd look more closely at the application code.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Jun 10, 2010 4:47 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| It should be obvious that BROWSE is faster than desctructive read. Destruction does not come for free, especially when you have a lot of messages in the queue and the queue manager has to access the queue file to be able to destruct the message. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 10, 2010 5:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9406
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| It should be obvious that BROWSE is faster than desctructive read. |
Obvious? But twice as fast as a destructive get?
It's been my experience that performance problems arise most frequently due to bad application design and/or bad application coding.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Jun 10, 2010 5:32 am Post subject: Re: Performance difference between BROWSE and GET in MQ |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| touchofcrypticthunder wrote: |
| We are reading around 5,000 messages at a time with many thousands of messages waiting on the queue. We are reading messages using the correlID. We are observing that the non-destructive MQ read is reasonably fast in most cases. However, the destructive MQ read takes a long time (thrice as much as the non-destructive MQ read), especially when there is a large number of messages waiting on the queue. Why would this be? And what can we do on the MQ side to alleviate this problem? |
The bad design in this case could be committing after each MQGET? If you have thousands of messages in the queue, committing a destructive get operation is expensive even with non-persistent messages, because the in-memory buffer for non-persistent messages is full and the QM is storing even non-persistent messages in the file system. If the application committed messages in larger batches the difference between destructive and non-destructive consume would be insignificant.
If I were touchofcrypticthunder I would try to figure out if DataStage MQ connector could be configured to commit messages in batches. The answer is propably yes, at least Transformation Extender can do that. |
|
| Back to top |
|
|
| wbimb |
| Posted: Wed Jun 16, 2010 10:41 pm Post subject: |
|
|
Centurion
Joined: 17 Aug 2006
Posts: 144
|
| Even we had faced the similar situation earlier and came to a conclusion that it was becasue of bad application coding |
|
| Back to top |
|
|
|
|
