The message selector is a bit like getting a message from the queue by msgid or correlid when the queue is not indexed.
If there are 500 messages on the queue, and you want to get the 500th message then the queue manager
scans the queue of messages sequentially to see if it matches matches the msgid or correlid.
It takes CPU to get each message and check it.
Use of the INDXTYPE attribute on the queue allows MQ to scan the index and directly access the required message.
The message selector logic is more complex than this.
Instead of simply checking one field for msgid or correlid, during each MQGET, the queue manager has to check the message payload for the specified fields.
Each properties in the RFH2 header has to be checked.
If you want to use multiple selectors, even more work has to be done for example "colour=blue or colour=red" means there are two fields to check.
This means that MQGETS with message selectors will be more expensive than a simple MQGET-next (or MQGET-specific on indexed queue).
The selectors are specified at open time, so the open costs will increase.
What are the costs?
As an example,
1500 messages were put on a queue, 500 with colour=blue, 500 with colour=red, and colour=green. The putting jobs ran concurrently so the messages were mixed up on the queue.
We ran a getting job which selected colour=green, and got the 500 messages.
- The CPU for the open went from 40 to 130 microseconds.
- The average CPU time for the get was 350 microseconds compared to 60 for a simple get first.
- The SMF data showed that 188580 messages were skipped.
The first MQGET may have skipped 2 messages, the last MQGET may have skipped 499 messages - depending on the layout of the messages on the queue.
What can I do to reduce the costs?
- Avoid deep queues - for example use a queue each for PAYROLL_REPLY and PAYMENTS_REPLY and avoid a common reply to queue
- Only have as many message properties as you use
- Specify the minimum number of selection properties.
Thanks to Tony Sharkey for his help (and numbers).