| Author |
Message
|
| PeterPotkay |
 Posted: Tue Aug 05, 2008 12:19 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Perhaps the original question was from this point of view:
We have 1000 messages on a q. Who cares why they are there, or for how long. Ignore that. Maybe he wants to know will MQ perform any differently if the Max Q depth for this q is set to 1,200, or 10,000, given the 1,000 messages sitting in that queue.
The answer in this context is there is no difference.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| KeeferG |
| Posted: Wed Aug 06, 2008 6:36 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Does anyone else have an issue with the part about "Retrieving messages from a queue by message or correlation identifiers will reduce application performance"
I have posted my complaint on the page
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 06, 2008 7:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Keith, Can you explain what don't you agree with? Selective gets take longer than just asking the QM to give you the first available message on the queue. If there is only 1 message on the queue, I suppose a selective get will perform the same as a non selective one (as far as you can tell), but the deeper the queue gets, the slower the selective gets get.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| KeeferG |
| Posted: Wed Aug 06, 2008 7:26 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Using correlid has little to no performance impact. When getting by correlid the queue manager does not search through the messages on the queue until it finds one with a matching corelid. Instead the queue manager keeps a seperate linked list for each correlid. So when you request a mesasge with a certain correlid the queue manager immediately knows what message that is. There is no searching of the queue.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 06, 2008 8:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9487
Location: US: west coast, almost. Otherwise, enroute.
|
Hmmm. z/OS-only queue attribute allows us to specify which index type to maintain: msgid, correlid, grpid, msgtoken. One of these.
So, if your app wants to match on msgid, but the index is correlid; then there is going to be some cpu effort involved.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Aug 06, 2008 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Indexing definetly helps. On the mainframe, were q indexing is turned off by default, we saw great performance improvements for an app that was doing selective gets by correlid once we indexed the q by correlid.
The question I have is then why wouldn't the mainframe have indexing turned on by default? Could it be that the indexing itself imparts a performance hit of its own compared to a non indexed queue?
On distributed we don't have the option to toggle indexing, so the indexing overhead is a moot point. I don't have any mumbers to back it up, but I would think doing selective gets till empty for a q with 100,000 messages would be slower that draining the q via non selective gets, even if the q is indexed.
Maybe not much slower, but then again when talking performance its all relative, eh? A centi-second to customer A may mean nothing, to App B it may be the proverbial straw.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| KeeferG |
| Posted: Wed Aug 06, 2008 9:26 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
We have done some latency tests recently across servers to test how it changes over high load.
We ran the the tests with and without correlid in the server application and found no difference at all to our round trip times.
Our local tests also showed no difference.
Having said that, we always try and run with empty queues for better performance and I don't know if running a loaded queue would perform differently with correlid or not. I do know the guys in Hursley worked very hard on the correlid specifically for performance reasons. Other indexes will defintately be slower as they have not been optimised for inside the queue manager.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 06, 2008 9:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Keith - I'm sure your tests were predicated on having all CorrelID's be unique.
Not all people view this as a necessary requirement, and do things like put application or subfunction names or business level data into CorrelIDs... |
|
| Back to top |
|
|
| KeeferG |
| Posted: Thu Aug 07, 2008 12:31 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Hi mqjeff
I believe our tests ran a number of putting threads with each thread having a unique correlid so many messages would share a correlid to replicate a correlid per application.
Our test showed little difference between get any message and get by correlid.
This was on Solaris at 6.0.2.1
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 07, 2008 2:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| mqjeff wrote: |
Keith - I'm sure your tests were predicated on having all CorrelID's be unique.
Not all people view this as a necessary requirement, and do things like put application or subfunction names or business level data into CorrelIDs... |
MQ 7 is a little bit better at this. But if you wanted speed and performance you had better have used the provider native form of the correlID in your selector.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
