| Author |
Message
|
| tbenyacs |
 Posted: Wed Oct 31, 2007 6:42 am Post subject: WebSphere MQ v6 / WebSphere Message Broker v6 performance |
 |
|
Novice
Joined: 19 Apr 2007
Posts: 18
Location: Budapest, HU
|
Hi, everybody,
I have a message flow application which communicates via MQ queues and HTTP. In AIX environment (very-very strong HW) the throughput of the application is 70 transaction/sec. This throughput in Windows XP environment (Intel Core2 1,87GHz, 2GB RAM) is about 30 transaction/sec.
How can I increase this throughput significantly?
Is there any relevant setting in WebSphere MQ v6 / WebSphere Message Broker v6, or perhaps in the op.sys ?
Thanks forward,
Thomas
_________________
Tamas Benyacs |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Wed Oct 31, 2007 6:44 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| tbenyacs |
| Posted: Wed Oct 31, 2007 8:41 am Post subject: |
|
|
Novice
Joined: 19 Apr 2007
Posts: 18
Location: Budapest, HU
|
Thanks for the reply.
The only doc I found connecting with this topic is the ip74.pdf (WebSphere Message Broker v6.0 For Windows Performance report Version 1.3).
Thomas 
_________________
Tamas Benyacs |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 31, 2007 9:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Have you considered that the performance difference between the two machines may be entirely tied to the hardware and the OS?
It could take quite a lot of effort to properly tune the hardware, OS, MQ and Broker and the flow to get the same transaction rate on a mid-to-low range Windows machine as it does on an untuned AIX machine.
And that may be more expense than the result is worth.
That said, the Performance Report you found will tell you what the performance characteristcs of the platform are, and discusses the tuneable factors that went into achieving those characteristics.
There is also a Performance Report for WMQ on each platform, that will provide the same information for WMQ as that one does for Broker.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Wed Oct 31, 2007 10:09 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
How have you come to the conclusion that it is MQ that is causing the difference in throughput?
The reason I ask is: I can recall very few times (in my own experience) where MQ or WMB was a bottleneck for good throughput. In fact, I can recall very few times when it was a limitation of the hardware, either. It is almost always (for me) a limitation of either the PUTting or the GETting application.
Please, I am not criticising your question at all, just wondering how you have come to this conclusion as it may help us to give you ideas.
Shirley |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 31, 2007 10:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Oct 31, 2007 10:39 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| SAFraser wrote: |
How have you come to the conclusion that it is MQ that is causing the difference in throughput?
The reason I ask is: I can recall very few times (in my own experience) where MQ or WMB was a bottleneck for good throughput. In fact, I can recall very few times when it was a limitation of the hardware, either. It is almost always (for me) a limitation of either the PUTting or the GETting application.
Please, I am not criticising your question at all, just wondering how you have come to this conclusion as it may help us to give you ideas.
Shirley |
He did not say that MQ was causing anything. He was merely inquiring about the performance variance between two different platforms!
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| SAFraser |
| Posted: Wed Oct 31, 2007 10:56 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| Perhaps I read too much into his original post. I assumed he had observed symptoms that required troubleshooting. |
|
| Back to top |
|
|
| tbenyacs |
| Posted: Tue Nov 06, 2007 2:45 am Post subject: |
|
|
Novice
Joined: 19 Apr 2007
Posts: 18
Location: Budapest, HU
|
| SAFraser wrote: |
| Perhaps I read too much into his original post. I assumed he had observed symptoms that required troubleshooting. |
I hope there is a setting where I can control the message forwarding strategy (memory usage, commit, etc.) of the MQ / WMB.
Thomas
_________________
Tamas Benyacs |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Wed Nov 07, 2007 2:27 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Message flow using persistent messages or non-persistent? NP will go faster, but the decision is a business one - if the messages need to be persistent, they need to be persistent.
You should look at normal MQ tuning - refer the the MQ performance support packs for your platform.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| tbenyacs |
| Posted: Thu Nov 08, 2007 12:16 am Post subject: |
|
|
Novice
Joined: 19 Apr 2007
Posts: 18
Location: Budapest, HU
|
| David.Partridge wrote: |
Message flow using persistent messages or non-persistent? NP will go faster, but the decision is a business one - if the messages need to be persistent, they need to be persistent.
You should look at normal MQ tuning - refer the the MQ performance support packs for your platform. |
The messages are persistent.
Thanks for the advice. I will check the support packs.
Thomas
_________________
Tamas Benyacs |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Nov 08, 2007 12:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If the CPUs are running at near 100% then you need to tune the message flow logic.
If the disks are busy then you need to either reduce the I/O or make it go faster.
eg. Get faster (and/or more) disks (15k RPM), separate databases from queues and from logs etc. |
|
| Back to top |
|
|
|
|
