| Author |
Message
|
| Maximus |
 Posted: Thu Mar 05, 2009 4:44 am Post subject: INDXTYPE(CORRELID) with non persistent messages... |
 |
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
Hi,
I am currently reading the MP16: WebSphere MQ for z/OS - Capacity planning & tuning and its suggesting to use INDXTYPE(CORRELID) in a request/response model where the client will send a request and wait for the response by matching the messageID of the request with the correlID of the response. In this case, when using INDXTYPE(NONE) a sequential scan of the queue is done to retrieve the proper message and by using INDXTYPE(CORRELID) and index is created and permit faster access to the desired message.
My question is, is it worth to do this change knowing the response messages are non-persistent? Is INDXTYPE(CORRELID) only useful for persistent messages?
Thanks.
Last edited by Maximus on Thu Mar 05, 2009 4:50 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Mar 05, 2009 4:50 am Post subject: Re: INDXTYPE(CORRELID) with non persistent messages... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Maximus wrote: |
| My question is, is it worth to do this change knowing the response messages are non-persistent? Is INDXTYPE(CORRELID) only useful for persistent messages? |
It depends - will you have a large number of messages in the queue, with a requirement for fast retrieval times? We know from the non-persistent nature of the messages they're not required to survive restart but that tells us nothing about how they're being used.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Maximus |
| Posted: Thu Mar 05, 2009 4:56 am Post subject: Re: INDXTYPE(CORRELID) with non persistent messages... |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| Vitor wrote: |
| It depends - will you have a large number of messages in the queue, with a requirement for fast retrieval times? |
Our tests show that the response queue can accumulate up to 200 messages before the queue is emptied by the clients. Also I forgot to mention that the response messages become expired after 30 seconds.
And yes the retrieval must be as fast as possible.
So is it worth the overhead of the INDXTYPE(CORRELID) in this particular case? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 05, 2009 5:04 am Post subject: Re: INDXTYPE(CORRELID) with non persistent messages... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Maximus wrote: |
| Vitor wrote: |
| It depends - will you have a large number of messages in the queue, with a requirement for fast retrieval times? |
Our tests show that the response queue can accumulate up to 200 messages before the queue is emptied by the clients. Also I forgot to mention that the response messages become expired after 30 seconds.
And yes the retrieval must be as fast as possible.
So is it worth the overhead of the INDXTYPE(CORRELID) in this particular case? |
On a z/OS box I'd not have considered a depth of 200 messages "large", especially as you have expiry set so there's no danger of a build up of unread messages.
IMHO you need to firm up the requirement "as fast as possible". Anyone asked how fast a computer system needs to go gives this response; the question is what's the longest time they can absolutely handle? Unless it's unreasonably short you might well be able to manage without indexing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Maximus |
| Posted: Thu Mar 05, 2009 5:24 am Post subject: Re: INDXTYPE(CORRELID) with non persistent messages... |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| Vitor wrote: |
| IMHO you need to firm up the requirement "as fast as possible". Anyone asked how fast a computer system needs to go gives this response; the question is what's the longest time they can absolutely handle? Unless it's unreasonably short you might well be able to manage without indexing. |
Basically if with indexes its faster then without... the client will want it, because overall they are trying to optimize the response time for all the layers.
Thanks for the advise, I will do some performance test, with and without indexes and see what is the difference. If the difference is minimal (not noticeable), I won't bother suggesting this setting for the production environment. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 05, 2009 5:39 am Post subject: Re: INDXTYPE(CORRELID) with non persistent messages... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Maximus wrote: |
| Basically if with indexes its faster then without... the client will want it, because overall they are trying to optimize the response time for all the layers. |
Basically this is true; it's as simple as does the time taken to update the index negate the increase in retrieval time.
| Maximus wrote: |
| I will do some performance test, with and without indexes and see what is the difference. |
Ideal plan. You may need some fairly large depths before you notice a significant difference.
I'd be interested in what you find. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 05, 2009 5:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Most applications that process reply messages by correlid tend to use non-persistent messages.
I would turn it on. It will stop the response times increasing under stress which is when you need the performance boost. |
|
| Back to top |
|
|
| Maximus |
| Posted: Thu Mar 05, 2009 5:48 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| I will go stress test, with and without and share my finding. |
|
| Back to top |
|
|
|
|
