Author |
Message
|
elikatz |
Posted: Sun Apr 19, 2009 8:20 am Post subject: priority vs. fifo, performance issues? |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
hi all,
are there any known results for priority vs. fifo from performance point of view?
the question is for both client side and server side.
we are working with priority on server side (default) but not using it on the client code so we are not sure what's the implication on performance.
we are working with java code for client side, currentley mq 5.3 we are in process of moving to mq 6.0.2.5
thanks! |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Apr 19, 2009 8:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You will see significantly more performance gain by moving to 6.0.2.5 than you will with PRIORITY or FIFO.
But you should always set the queue order to the one that matches how the application is reading the queue. It should be FIFO unless you specifically know that the application is specifically using Priority. |
|
Back to top |
|
 |
elikatz |
Posted: Sun Apr 19, 2009 8:49 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
thanks for the fast replay!
if i leave the status as is, would it affect performance? |
|
Back to top |
|
 |
JosephGramig |
Posted: Mon Apr 20, 2009 12:56 pm Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Jeff,
I would agree with the FIFO comment, but isn't it interesting that the default is PRIORITY? |
|
Back to top |
|
 |
elikatz |
Posted: Tue Apr 21, 2009 8:27 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
It is interesting...
that's from the documentation.
Is there a place i can find the recommendation regarding you suggestion Jeff?
I need to prove this to my developers...
thanks much.
Eli |
|
Back to top |
|
 |
vol |
Posted: Tue Apr 21, 2009 11:14 pm Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009 Posts: 69
|
Any miniscule performance difference between the types of queue access will be completely lost in the slow client connection over the network and the slow performance of the java app.
To improve performance, go for the big hitters first - make a direct connection to the qmgr, and use a faster app written in C. |
|
Back to top |
|
 |
zpat |
Posted: Tue Apr 21, 2009 11:16 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Look at MQ V7 - lots of client performance improvements there - especially for JMS. |
|
Back to top |
|
 |
JosephGramig |
Posted: Wed Apr 22, 2009 4:26 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
zpat,
I have to ask, do you foresee any issues if the MQ Client is upgraded to V7 but the QMGR is not?
And will the performance improvements still be realized? |
|
Back to top |
|
 |
manicminer |
Posted: Wed Apr 22, 2009 4:42 am Post subject: |
|
|
 Disciple
Joined: 11 Jul 2007 Posts: 177
|
To realise the main JMS performance improvements you will require a new client and server as there are changes to the way remote communications work and the way gets are performed inside the server itself (selectors) _________________ Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime. |
|
Back to top |
|
 |
zpat |
Posted: Wed Apr 22, 2009 4:43 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
My understanding is that V7 clients will work with V6 queue managers but will not enable most of the improvements.
In particular the JMS performance improvements come from moving function from the JMS client into the queue manager base code.
Quote: |
Version 6.0 and 7.0 WebSphere MQ Clients can connect to Versions 6.0 and 7.0
WebSphere MQ queue managers. The base features of WebSphere MQ Client
Version 6.0 are available in all four combinations, but most of the new features of
Version 7.0 are only available when a Version 7.0 client connects to a Version 7.0
queue manager.
The new features that are available for a Version 7.0 client connected to a
Version 6.0 queue manager are:
Weighted selection on CLNTCONN channels
Reconnecting via a previously used channel
Maximum message length increased on MQSERVER environment variable
The new feature that is available for a Version 6.0 client connected to a version
7.0 queue manager is instance limits on SVRCONN channels. |
|
|
Back to top |
|
 |
elikatz |
Posted: Fri Apr 24, 2009 11:32 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
Hi,
I know the discussion went to different places but i would like to get back to my original question:
should I change my server to FIFO if the client is not using priority?
is it mentioned anywhere in the documentation?
thanks for your help... |
|
Back to top |
|
 |
gbaddeley |
Posted: Fri Apr 24, 2009 8:29 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
elikatz wrote: |
Hi,
I know the discussion went to different places but i would like to get back to my original question:
should I change my server to FIFO if the client is not using priority?
is it mentioned anywhere in the documentation?
thanks for your help... |
If your app is not using various values of Priority on messages, the performance should be the same whether the server is set to fifo or priority. _________________ Glenn |
|
Back to top |
|
 |
|