| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMQ perfomance increase? if # of cores are increased? |
« View previous topic :: View next topic » |
| Author |
Message
|
| visionR32 |
 Posted: Thu Dec 03, 2009 12:54 am Post subject: WMQ perfomance increase? if # of cores are increased? |
 |
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
Hi All,
I could not find any thing concrete on google -
Running Websphere MQ 6.0 on a multi-core solaris system - eg. 16 cores / VS. running it on a high spec'd SINGLE core CPU, if i assign all 16 cores (CPUs essensially) to the MQ server will all of the cores access MQ at the same time?
1. Will i gain perfomance increase on MQ?
2. Is MQ designed to levarege multi-core processors?
3. OR only ONE of the 16 cores will process ALL mq needs at a given time? - if so then i will be loosing out on the other idle processors, is int?? |
|
| Back to top |
|
 |
| manicminer |
| Posted: Thu Dec 03, 2009 1:04 am Post subject: |
|
|
Disciple
Joined: 11 Jul 2007
Posts: 177
|
MQ is multi-threaded and multi process, it will make very good use of multi-core / multi-processor systems. (do you think it would be so popular and so widely used for high performance messaging if it couldn't make use of multiple core's or CPU's?)
however.....
It's impossible to say whether or not you will see a performance gain purely by assigning more CPU. It depends on whether or not the CPU is a bottleneck in your messaging system.
For example if you are doing lots of persistent messaging with very large messages it is more likely that your disk access will the bottleneck that than CPU because you will be needing to write lots of data to disk.
_________________
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 |
|
|
| mvic |
| Posted: Thu Dec 03, 2009 3:30 am Post subject: Re: WMQ perfomance increase? if # of cores are increased? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| visionR32 wrote: |
| 1. Will i gain perfomance increase on MQ? |
Please say something about what type of MQ messaging work (persistent, non-persistent, transactional, batched, online) your system is doing.
In answer to the question, it depends. If you have only one MQ application, you will see little gain from an increase in number of cores. However, if you have 100 MQ applications running at the same time then there will be a gain.
| Quote: |
| 2. Is MQ designed to levarege multi-core processors? |
It is designed to use many threads, which is not the same thing precisely, but is probably a "yes" to the underlying question.
Also please appreciate, a system with 16 cores does not process its work 16 times faster than a system with one core. All processors must work together for short periods of time to successfully manage shared resources (disk, shared memory). This means the gain from additional processors is dependent on what work exactly they are doing on behalf of MQ and your applications.
If your MQ system is making heavy use of persistent messages, then the first priority should be performance of your disk and I/O capability. Or if non-persistent messages are in heavy use then CPU is more important.
The only way to be sure is to run some tests on various hardware simulating your real world workloads.
| Quote: |
| 3. OR only ONE of the 16 cores will process ALL mq needs at a given time? - if so then i will be loosing out on the other idle processors, is int?? |
No. MQ uses many threads so will indeed make use of your processors.
Did you find the Performance Reports that are published on the MQ SupportPacs page? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 03, 2009 6:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Performance tuning is more complicated than just adding cpus or i/o- or network-bandwidth or RAM.
The performance of MQ is heavily influenced by the entire workload, not just MQs workload. The aggregate workload is referred to as concurrency. How much and how many things can take place and still meet SLAs.
Generally, an under-provisioned server will present a bottleneck where there is most demand OR the least resource. (Think of a one-lane road to Grandmas house.)
Too little RAM will cause paging, which causes (needless) i/o, which creates the next bottleneck: i/o. Increasing RAM will reduce the needless paging i/o, but will then present the next bottleneck.
As pointed out in a prior post, 2 cores doesn't guarantee that you get twice the work done as compared to a single-core. More cpus will get more instructions processed concurrently, which will lead to more demand on RAM and i/o - the next bottlenecks.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 03, 2009 7:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Performance Monitoring forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| 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
|
|
|
|
