| Author |
Message
|
| rk400 |
 Posted: Wed Mar 26, 2003 2:06 am Post subject: MQ performance statistics |
 |
|
Apprentice
Joined: 04 Mar 2003
Posts: 27
|
Hi,
Does anyone have idea about the time taken by MQ for transferring 1kb message from REMOTEQ(MACHINE1) TO LOCALQ(MACHINE2) typically over a 100Mbps ethernet??
In general, where can I get the performnace statistics of MQ calls... like
1.Establishing mq connection.
2.Get message from queue.
3.Put message in a queue.
thanx
RK |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 26, 2003 7:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There are support pacs that describe the performance characteristics of MQSeries on different platforms.
Needless to say, the real world performance characteristics you'll see are completely dependant on your own environment, and the programming language you are using.
In general, MQSeries is fast enough for real time transactions. More specifically, you can design and configure your system so that MQSeries will be fast enough for almost anything you need to do that your hardware is capable of supporting. But you need to understand much better than you've indicated what your real performance requirements are before you even think of trying to optimize your system. How fast do you need it to be? One message an hour? A minute? A second? 10 messages a second? 100 messages a second? 1000 messages a second? Faster? |
|
| Back to top |
|
|
| pgorak |
| Posted: Wed Mar 26, 2003 8:38 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
Performance statistics for most MQSeries function calls can be found in SupportPacks - this is system-dependent, e.g. I'm using HP-UX, so I was able to found these information in:
MP6E: MQSeries for HP-UX V5.2 - Performance highlights and capacity
planning guidance
You should be able to locate the corresponding documents for you platform.
Piotr |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Mar 27, 2003 1:04 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Just as an example of how many factors there are in making such a sweeping statement as "it will take x milliseconds to send a message over a 100Mbps network" there is a huge impact depending on what programming language you are using. I ran performance tests with identical programs, one written in C, the other in Perl. Holding all else equal, I noticed that the Perl tests would be up to an order of magnitude slower than its C counterpart. The difference was greatest when I was using small UOWs under syncpoint. Increasing the number of messages in the UOW, using non-persistent messages without syncpoint, etc., would lessen the difference, but Perl was always quite slower than C as you would imagine.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 27, 2003 6:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Brandon -
I would be interested in seeing your Perl code.
While I would expect that Perl would be slower to start up, I did not expect that it would be an order of magnitude slower to run than a straight C program.
Were you really comparing apples to apples? Or were you using the Perl object methods and comparing those against the C MQAPI calls? Using the standard API wrappers in Perl, instead of the object methods, should be *almost* as fast as the straight C calls, since the API wrappers merely invoke the straight C calls.
If you were using the object wrappers and doing some more sophisticated processing of the message body (particularly using additional hash data structures), then I can see the perl code taking longer. I'm still a little surprised it was up to an order of magnitude longer, but I'll believe it.
I expect Java to be slower than Perl, particularly the Perl API calls. JMS is slower than Java, JMS with coordinated transactions is slower than regular JMS, and message driven beans are yet another 30% slower than that, as I understand it.
And none of this has anything to do with the performance of channels. Which again just highlights that you need to understand your performance requirements before you start worrying about measuring performance. |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Mar 27, 2003 2:11 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Jeff, that's a good question. Actually I was not using the object version of the Perl API - I was making straight MQI calls. As I said, in some experiments, like when I was putting a large number of non-persistent messages without syncpoint, Perl was maybe twice as slow as C. But when I was using persistent messages in small UOWs, it was considerably slower. I believe I still have a bunch of excel spreadsheets which show the various measurements, I'll see if I can dig them up.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 27, 2003 2:31 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That continues to seem strange to me.
The only way that makes sense is if the Perl XS wrapper of the MQI is doing different things (data conversions, etc) based on the parameters you're specifiying in the MQI call. I can see persistance and UOW considerations being a reason to do that, but it still seems a little strange.
Well, if I get really curious, I'll just go read the source.
As far as performance goes, though, I do find myself wondering how the Perl object classes compare in speed to the base Java classes. I don't have any real desire (or justification) to test it out though. Oh well. |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Mar 27, 2003 4:23 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Ahh, you made a key point in your previous response:
"While I would expect that Perl would be slower to start up"
As it turns out, the tests where Perl was an order of magnitude slower was when the Perl process would only put 1 message, and I had a script which launched the program 100 times in succession. I did the same with the C program, but as you would expect, since Perl is interpreted rather than compiled, the startup time is what killed its performance. But when I ran each process only once and had it put 100 messages, Perl was only about 1.5 times slower than C.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 28, 2003 6:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That's good to know. I wasn't getting anywhere reading the source...  |
|
| Back to top |
|
|
|
|
