| Author |
Message
|
| fcho |
 Posted: Tue Sep 24, 2002 3:59 am Post subject: How to indexing a Q |
 |
|
Apprentice
Joined: 29 May 2002
Posts: 28
|
Hi,
I read some of the forums saying about indexing Q, anybody can tell me how to do that? Where can I find the documentation?
_________________
Regards,
fcho |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Sep 24, 2002 9:53 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
fcho,
I'm not sure what you are referring to. There is no way to "index" a queue (in the same way you index a table in a database) because the retrieval method is generally FIFO. Perhaps you could explain what you are trying to accomplish and someone can probably recommend a course of action...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Sep 24, 2002 2:19 pm Post subject: Re: How to indexing a Q |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| fcho wrote: |
| I read some of the forums saying about indexing Q, anybody can tell me how to do that? Where can I find the documentation? |
fcho,
Indexing of a queue is platform-dependent. More preciously, some platform offers a utility to disable any inside indexes, e.g. altmqfls on Tandem.
brandon,
AFAIK, queue files are indexed for MsgId and CorrelId on all platform. But this is resource hungry, so MQ for Tandem allows you to switch off any or both special index. I've never seen S/390, but there is something similar feature. |
|
| Back to top |
|
|
| fcho |
| Posted: Wed Sep 25, 2002 12:15 am Post subject: |
|
|
Apprentice
Joined: 29 May 2002
Posts: 28
|
Hi,
Thanks for the reply.
Basically I'm using AIX box and I've a programA put messages into Q1 by setting Corr-id and I've another programB that get messages from Q1 by Corr-id. In real production, I'll run multiple copy of programA and programB with diff Corr-id, so programB will always base on the Corr-id to getting the neccessary messages for futher processing. The worry here is the performance because base on my estimation, there will be azround 1 million messages per day. Since the the Q is already indexing by corr-id, I think should be no problem and I also thinking of using load balancing.
_________________
Regards,
fcho |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Wed Sep 25, 2002 3:32 am Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Mainframe MQ admins can have their queues indexed by MSgID or CorrelID.
Just my 2 cents
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| nimconsult |
| Posted: Wed Sep 25, 2002 4:17 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
zOS (OS/390) is the only platform that supports explicit indexing of a queue on msgid, correlid or msgtoken. Other platforms may implement optimizations but which are not controlled by the queue definition.
2-3 years ago I have played with this feature on OS/390. It significantly improves the performance. If you do not index the queue, MQ Series performs a linear queue scan, so the performance degrades in a linear way (if your messages are not at the top of the queue).
I have never performed performance test related to this specific feature on other platforms, so I cannot say what kind of optimization is provided.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 11, 2003 7:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I am doing some performance tests to see exactly how this attribute may help.
When I switch the Index type, what needs to happen to make the change take effect? As long as the queue is empty and closed it changes? Or do you have to bounce the QM?
I have done tests and switched the attribute back and forth and seen no difference in the CPU_TIME. The app does a GET by CorrelID. I did tests with the queue at a depth of 10000, 5000, 1000 and zeror with the queue indexed by both CorrelID and None, but by CPU times are almost identical.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Apr 11, 2003 5:37 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
hmm... I have no idea. I'd think it would be similar to the database world, where you just add the index, and there's no need to restart the database for it to take effect, but I guess your tests show otherwise. Did you try restarting the queue manager?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 16, 2003 10:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
At 5.2, the queue manager must be restarted. Or what I found, is to delete the queue and immediately recreate it, this time with indexing the way you want it. It is a lot easier to delete/recreate the queue than schedule an outage of the mainframe QM which effects the whole world.
At 5.3, the change is dynamic as described by a table in the MQSC Command Reference Manual Version 5.3 under DEFINE QUEUE.
FYI, the results of switching the queue to indexed were very good as measured by CPU time that IMS was using. All GETS were by CORRELID. See results below:
| Code: |
10 trans at Q depth Queue Indexed? Average CPU Time
02:15 0 no 50
02:25 1000 no 60
02:35 5000 no 105
02:45 10000 no 165
queue deleted and recreated with index on.
02:55 0 yes 49
03:05 1000 yes 49
03:15 5000 yes 49
03:35 10000 yes 49
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Sat May 17, 2003 10:20 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Thanks for the results Peter... Those performance numbers are pretty interesting. I wonder though if the time to put the messages to the queue is increased because of the indexing... Kinda like what happens with databases. However, in a DB, you might add a record (which is added a bit slower because of an index on the table) but then all the subsequent reads are faster because of the index. However, with queues, you are typically adding a message once, and reading it once, so the performance hit putting the message to the queue might outweigh any speed increase during the MQGET...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
