| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Urgent Performance Questions |
« View previous topic :: View next topic » |
| Author |
Message
|
| skytorch |
 Posted: Tue Oct 08, 2002 8:18 am Post subject: Urgent Performance Questions |
 |
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Hi,
We're tuing up our MQ 5.1 on Tru64 platform with 4 processors. We encountered the following questions:
1. we noticed that originally we got 1000msg/second to inqueue msg into a queue. If we start a C app to dequeue messages from the same queue, the rate on both enqueue and dequeue drop to 600 msg/ second. Is it supposed to be so ?
2. Is the MQ max message rate per queue or per queue manager ? We also noticed that if we've other programs to inqueue/dequeue from queues other than Q1, the inqueue/dequeue rate from Q1 is dropped. That raised that assumption that performance on all the queues within one QM is correlated to each other, which is certainly not desirable. Is this true ?
3. I ran a Java app to constantly send messages to a queue. I got 300 msg/second, meanwhile, i noticed the CPU time is *not* max-ed out. Why is so ? Does it imply that this is the hard limit of MQ message rate, i.e. if i increase machine power, the message rate won't increase ?
4. Can MQ 5.1 utilize multiprocessor servers ( I guess so, but what support does it have ?)
Thanks in advance.
Sky |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Tue Oct 08, 2002 10:26 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well we had a similar issue on HPUX. If you start more than 3 applications againist of queue it will also get worse.
IBM had us enable multi-threaded agents. I just looked on the website your OS doesnt support this feature, I would look into upgrading to v5.2 or
v 5.3
http://www-3.ibm.com/software/ts/mqseries/txppacs/mp02.html
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| pgorak |
| Posted: Tue Oct 08, 2002 9:57 pm Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
I also noticed a similar drop in performance on HP-UX with v5.2. However, in distributed queuing (which is my case), performance can be also affected by LAN/WAN throughput.
Piotr |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Oct 08, 2002 10:33 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Hello Skytorch,
I am neither Tru64 expert, nor an IBM developer knowing the internals of MQ, but here are some speculations:
On point 1:
Well that's already good news at least, you increased the global throughput on the queue from 1000 MPS to 1200MPS.
But I am convinced that the throughput will not increase forever, because API calls do not run entirely in parallel. When you call MQ, some part of the work is done in your own process, and some part is done in the MQ processes. These MQ processes may appear as bottlenecks for the increase of performance. One of the thing they do is maintain the internal structure of "linked list" of messages, which is protected by some critical sections of code (serialized). Another thing they do is write to the log, and here again, you will find some serialization. Yet another thing they do is to manage the queue buffers (and swapping on disk when they become too small), and here again you will find some serialization. I am sure that there are plenty of other critical sections of code in MQ Series.
On point 2, you have partial response as in point 1.
On point 3: the first simple answer is that MQ is working with the disk, either because you are playing with persistent messages (but considering the throughput I assume not), or because you have gone above the queue buffer size and MQ is writing the messages on disk (even non persistent messages). Let us now suppose that there is no IO activity. Which CPU time are you talking about? Remember that you are running on a multi-processor machine, so the explanation may be that your Java process is waiting responses from MQ processes (inter-process communication).
I am sure that running multiple Java applications in parallel will increase the global throughput, until you reach the limit of MQ processes.
To confirm the speculation what you can do is run your performance benchmarks on different queue managers.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Oct 09, 2002 4:01 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well if his problem is like the HPUX issue I had the more process's you add the slower it goes overall. ie if 1 process yields 1000/msgs per second, and 2 process yeild 800 msgs/second(400msg per process).
One of the things that make this happen is that for every MQ Application
that you start it creates a agent process amqzlaa0. When multithreaded agents are used it will only create one amqzlaa0 process for x(20) applications started, but True64 doesnt support this. The only thing you might try and assuming your application is well behaved is trusted(fastpath bindings) this will prevent any agent process from starting and your application will communicate directly to Qmgr instead of going throught the agent process.
WARNING: Poorly behaved applications can corrupt the queue manager !!!!! By poorly behaved I mean programs that have bugs in them and write to memory where they shouldnt.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| 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
|
|
|
|
