| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Performance Primer |
« View previous topic :: View next topic » |
| Author |
Message
|
| Prophet |
 Posted: Mon Sep 02, 2002 4:17 pm Post subject: Performance Primer |
 |
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
Hello everyone. We are currently under going performance testing of our MQSeries connectivity at my company. I was wondering if anyone had any specific performance/scaling tips with dealing with MQ? We have been working on some performance testing at my company and currently we top out around 12-15 messages(sent and recieved) per second. This is over a distributed MQ Network communicating between an IBM MVS mainframe and a dual processor, 2gb ram Windows 2000k box. The typical message send size is about 500bytes. The typical message recieved is about 5-10kb. The application is an OLTP application but for the purpose of these tests, we have built multi-threaded stubs to concentrate only on the MQSeries connection handler.
I know I have seen numbers much higher then this in scalability tests and the best I can figure, we have something configured really wrong. Resources(cpu, memory, file handles, threads) on the WIN2K box are minimal when we run these tests which tells me the configuration or network is constraining the results. The network is a dedicated T3 circuit back to the mainframe dropping down to 16mb Token Ring on our side of the network(using SNA to connect to mainframe). During these tests, it also shows very little traffic.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
 |
| mgrabinski |
| Posted: Mon Sep 02, 2002 9:22 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Some time ago I did a performance test. I was sending messages from an OS/390 manager to Win2000 and back. I measured time on the mainframe between MQPUT and MQGET of the same message. The best response time (on average) I got was ca. 25ms, so it gives some 40 meesages per second. But it was for nonpersistent messages over a fast channel. The same measurment for persistent messages resulted in response time of ca. 50ms
There are several support packs dealing with MQSeries performance. To list just a few:
MD16
MP00
MP16
MP74
You will find them at http://www-3.ibm.com/software/ts/mqseries/txppacs/txpm2.html#cat2
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Sep 02, 2002 11:00 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Well, it sounds strange.... MQSeries over SNA to OS/390 is not the fastest in this world, I've seen half a second turn arround time in avg. After chaning to TCP/IP it was reduced to allmost nothing (few ms.).
It seems to me that IBM's default implementation/setup of SNA in MQSeries might be point of optimization. I've been looking on it, but stopped because the time critical applications was moved to TCP/IP.
But one of my customers want SNA for some reason.......
just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| pgorak |
| Posted: Tue Sep 03, 2002 3:17 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
| mgrabinski wrote: |
| Some time ago I did a performance test. I was sending messages from an OS/390 manager to Win2000 and back. I measured time on the mainframe between MQPUT and MQGET of the same message. The best response time (on average) I got was ca. 25ms, so it gives some 40 meesages per second. |
Marcin,
I have some technical questions:
1. Were the two machines in the same LAN?
2. If the response time could not be decreased below 25ms, what was the bottleneck?
3. Were messages processed sequentially or in parallel on Windows2000?
Piotr |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Tue Sep 03, 2002 4:17 am Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Answering Piotr:
1) Both machines were on the same LAN
2) I suspect two factors:
a) my test program was written in REXX and was interepreted during the execution, so it could degrade the time needed to call MQ functions
b) I tried to simulate normal work, so I did the test in our peak hours - there was plenty of telnet, ftp, www, mail and other net traffic. The have a full picture, I would have to come to work on Sunday 
3) Sequential. The logic was as follows:
generate a MSGID and store it
get time stamp
MQPUT a message
[the message goes to Win2000, where it is routed back (via remote queue, no program involved) to the mainframe]
MQGET (wait for msg with matching MSGID)
get time stamp and store results
I made the measurments for messages with the size of 1K, 5K, 10K, 50K, 100K, 500K and 1M. Each test was repeated 10 000 times, and from each test I got min, max and average values. The best I got was 23,5ms for nonpersistent 5K message over a fast channel. The worst - 2,2s (!) in the same test.
On average I was getting ca. 55ms for a persistent message, 45ms for nonpersistent over normal channels and 32ms for nonpersistent over fast channels
BATCHSZ was set to 1 for all tests.
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| jhalstead |
| Posted: Tue Sep 03, 2002 6:06 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Are you just doing a single connect and open for all messages or are you performing these operations for each message put/get? These operations have serious overheads...
I may have misunderstood, however I rekon that due to your method you're only going to get low throughputs, you're waiting for the response to come back before doing any more sends...
Additionally the batchsize 1 is goint to increase the time to send many messages...
Jamie |
|
| Back to top |
|
|
| Prophet |
| Posted: Tue Sep 03, 2002 9:42 am Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
Thanks all for the resposes.
I left out some testing data I should have included: We are using non-persistent messages and a Correlation ID lookup during these tests. Max handles, MaxChannels, and MaxActiveChannels have all been increased to 1000 for testing purposes.
We also have no connection pooling right now. So I know there is a lot of overhead associated with the connect and disconnects. Assuming we implement a connection pooling mechanism this maybe will double the throughput. Still way lower then what it should be.
However, we are not waiting on one message to come back before sending another. The testers that are sending the requests are multithreaded with each client connection on its own thread. Now, individual threads do wait on responses. We have built the handler using three methods; C++ utilizing MQ API, MQAX utilizing MQAX200, and C# utilizing kolban's MQSeries.NET API wrapper. The MQAX is apartment threaded and has blocking issues so for this size of an application, it really isnt a possiblity. The other two methods however are completely threadsafe and there are no blocking/contention issues that we can see.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| 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
|
|
|
|
