| Author |
Message
|
| Sreejith |
 Posted: Thu Jul 06, 2006 1:05 pm Post subject: MQ Performance |
 |
|
Newbie
Joined: 06 Jul 2006
Posts: 3
|
I have 9000 messages on the Queue with message selector as Subsystem=’PS’ and priority =4. When I send a message with message selector as Subsytem=’CO’ and priority=7 , the receiver picks the message after 40 seconds. I want instantiations response. The receiver is also defined with message selector subsystem=’CO’.
Is the receiver check each and every message in the queue to find the match? (i.e message selector) |
|
| Back to top |
|
 |
| mvic |
| Posted: Thu Jul 06, 2006 1:36 pm Post subject: Re: MQ Performance |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Sreejith wrote: |
| Is the receiver check each and every message in the queue to find the match? (i.e message selector) |
Yes, it does.  |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Jul 06, 2006 4:13 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| I have 9000 messages on the Queue with message selector as Subsystem=’PS’ and priority =4. |
sounds like "good" response time to me. MQ is NOT a database. Why do you have so many messages on the queue in the first place?
_________________
-wayne |
|
| Back to top |
|
|
| 8davitt |
| Posted: Fri Jul 07, 2006 2:26 am Post subject: |
|
|
Apprentice
Joined: 06 Feb 2003
Posts: 37
Location: Seated in front of monitor
|
If you want faster response when using Message Selectors then you should use the IBM provider specific format of "ID:hexstring".
Refer to the Websphere Using Java manual for more information.
/s |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jul 07, 2006 2:37 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 8davitt wrote: |
| you should use the IBM provider specific format of "ID:hexstring". |
Helpful, but with MsgId and CorrelId only, I think. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 07, 2006 2:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I still think wschutz had the best idea for improving performance - shrink the queue size! 
If you've got a backlog of 9000 messages, you either need a faster reader or more readers. Or a database that can scan 9000 rows in milliseconds (i.e. most of them  ) and a small little app to load it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sreejith |
| Posted: Fri Jul 07, 2006 4:37 am Post subject: MQ Performance |
|
|
Newbie
Joined: 06 Jul 2006
Posts: 3
|
We have only one Queue for the application. Different subsystem uses same queue for receiving and sending messages. At the peak time there could be 2000-5000 messages in the queue. Due to this we are facing some performance related issues.
thanks. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Jul 07, 2006 6:02 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| We have only one Queue for the application. Different subsystem uses same queue for receiving and sending messages |
Thats a very bad design point... you should either the system so each "subsystem" has it's own input queue, and then use either a broker to route the messages or change the sending applications.
_________________
-wayne |
|
| Back to top |
|
|
| Sreejith |
| Posted: Fri Jul 07, 2006 6:38 am Post subject: MQ Performance |
|
|
Newbie
Joined: 06 Jul 2006
Posts: 3
|
How actually receive works? Is JMS client browse all the message at the server or client? Because I could see lot of network packet send and receive during this period.
thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 07, 2006 11:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Best practice would be to have an app listening to your queue and receive every message, evaluate the attributes and redirect the message to the particular queue of each subsystem.
Each subsystem has to have their own queue.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Jul 07, 2006 12:04 pm Post subject: Re: MQ Performance |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Sreejith wrote: |
How actually receive works? Is JMS client browse all the message at the server or client? Because I could see lot of network packet send and receive during this period.
thanks |
and yes...every message is retrieved by the client until a matching message is found.....
_________________
-wayne |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 07, 2006 12:43 pm Post subject: Re: MQ Performance |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sreejith wrote: |
How actually receive works? Is JMS client browse all the message at the server or client? Because I could see lot of network packet send and receive during this period.
thanks |
It's like reading a database with a cursor.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 07, 2006 3:31 pm Post subject: Re: MQ Performance |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| It's like reading a database with a cursor. |
I hope not! As far as I know, the MQ JMS Provider implementation of the Listener has to browse all of the messages on the queue for each instance that is listening to that queue. So if I have an MDB with five instances, and there are 100 messages on the queue, the provider will browse 500 times!
I hope that database cursors have better implementations, because they should have better indexes behind them. MQ is *not* a database, so it doesn't perform like one when you try and treat it like one.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jul 09, 2006 11:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This is exactly the point I was making - using a cursor is massively more inefficient than a SELECT...WHERE! 
There's also seldom a compelling reason for using one. Certainly if I'm QAing the code.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
