| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Optimize Throughput |
« View previous topic :: View next topic » |
| Author |
Message
|
| Tristan23 |
 Posted: Tue Jun 14, 2011 4:41 am Post subject: Optimize Throughput |
 |
|
Newbie
Joined: 25 May 2011
Posts: 9
|
Hi there,
my application uses one queue, one channel (SYSTEM.DEF.SVRCONN) and one listener.
I have several multithreaded writer processes and one multithreaded reader process.
Questions:
- How can I optimize the throughput of my little application?
- Does it help to create one channel/listener for the reader and one channel/listener for the writer process?
Kind Regards,
Tristan |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 14, 2011 4:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Don't use SYSTEM.DEF.SVRCONN.
Read the performance reports.
90% of the work that needs to be done to improve the performance of a given application is to improve the performance of the application itself.
Don't create more than one listener.
Don't create additional channels or connections unless you know SPECIFICALLY why you are doing it.
If you are creating an application that other people will be using, make EVERY part of the connections process completely user customizable. Make ALL queue names completely user customizable.
Don't make any attempts to resolve performance problems until you have a) a set of actual performance criteria, b) an actual set of metrics that shows where the performance criteria are not being met.
Otherwise you are changing the oil in your car because the windshield is dirty. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 4:51 am Post subject: Re: Optimize Throughput |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Tristan23 wrote: |
| my application uses one queue, one channel (SYSTEM.DEF.SVRCONN) and one listener. |
Applications should not use SYSTEM objects. A subject of much discussion in here.
| Tristan23 wrote: |
| - How can I optimize the throughput of my little application? |
Write good application code that properly follows the threading rules for WMQ-aware applications.
| Tristan23 wrote: |
| Does it help to create one channel/listener for the reader and one channel/listener for the writer process? |
The listener is only used to establish connectivity to the queue manager. You don't need more than one unless the queue manager has more than one connect point (2 IP addresses for instance)
You might get more admin control with 2 channels, but I doubt you'd see much performance improvement. You're better off ensuring the queue manager's limits are set high enough to allow all the channel instances you need for all the threads you're running.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 4:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Don't make any attempts to resolve performance problems until you have a) a set of actual performance criteria, b) an actual set of metrics that shows where the performance criteria are not being met.
Otherwise you are changing the oil in your car because the windshield is dirty. |
A point so good I'm ashamed I didn't say it.
An analogy so good I wish I'd thought of it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Tristan23 |
| Posted: Tue Jun 14, 2011 5:44 am Post subject: |
|
|
Newbie
Joined: 25 May 2011
Posts: 9
|
> Don't use SYSTEM.DEF.SVRCONN.
It's only for testing - not for the life system.
Is it disadvantageous for the performance to use SYSTEM.DEF.SVRCONN?
> Don't make any attempts to resolve performance problems until you have a) a set of actual performance criteria, b) an actual set of metrics that shows where the performance criteria are not being met.
That exactly is my case. I have a throughput of about 8.000 messages/sec. But I need about 20.000 messages/second.
Hardware is not the problem (multi-CPU machines, SDD drives, Gigabit network with link aggregation, etc).
What are the basic parameters I could use to tune MQ? At the moment I only have a default installation. (e.g what to set for "Hardened get backout", ...?).
cheers,
Tristan |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 5:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Tristan23 wrote: |
| Is it disadvantageous for the performance to use SYSTEM.DEF.SVRCONN? |
No, but it limits the changes you can make to channel settings to improve performance. Much better to set up your own and change the settings in safety.
| Tristan23 wrote: |
That exactly is my case. I have a throughput of about 8.000 messages/sec. But I need about 20.000 messages/second.
Hardware is not the problem (multi-CPU machines, SDD drives, Gigabit network with link aggregation, etc). |
So exactly where is the performance bottleneck? Fiddling with the channel isn't going to help if the problem is the queue access, nor is hardening the backout count (!) if it's a connection issue.
Most importantly, a badly written application (e.g. one that connects and disconnects for each message) will always perform badly and no amount of tuning will change that.
So identify where the problem(s) is/are and tune there. Do not randomly change parameters in the hope it will help. Read the perfomance papers and with more care than you seem to be reading the product documentation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 14, 2011 6:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Tristan,
The MQ Listener is used to listen for new connection attempts, and it then hands it off to the channel "pool". One Listener can deal with a lot of connection attempts. If you are making more connection attempts than a single Listener can handle from one app, the design needs to be looked at. You don't want to connect, open, put or get, close and disconnect for each message. For each thread, connect once, open the queue once, and start looping on your puts or gets. One listener can deal with that.
Client channels, like SYSTEM.DEF.SVRCONN, are only used as a template for spawning new instances of channels by that name. If 10 apps, or 10 instances of the same app, ask to connect over that channel name, you will get 10 instances of the channel running. So more channel definitions will not help for performance. Starting and running 10 channels by the same name or 10 different names will perform the same. Separate channel names ("templates") may be needed for other other reasons (security, ease of administration and debugging, etc)
The 2 biggest ways to improve performance are:
- connect once, open the queue once, and start looping on your puts or gets.
- use non persistent messages
There are others, but these are usually the biggest bang for the buck.
Otherwise find out if you are CPU or I/O or network constrained, and focus on how you can remove that bottleneck, by increasing capacity, or more likely optimizing application design / options used.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
