| Author |
Message
|
| woolmerc |
 Posted: Thu Nov 04, 2004 9:05 pm Post subject: Network Performance Tuning |
 |
|
Novice
Joined: 12 May 2004
Posts: 21
|
Hi guys,
I was wondering if anyone knows some knowledge on how to tune/tweak MQ over a network?
I have just released an MQ infrastructure of mine into a Production environment and recorded some very slow response times. The area identified as the bottleneck is where messages are sent between 2 queue manages residing in 2 different locations. Messages seem to bottleneck on the transmission queue and 4MB segments are taking 33secs on average to transmit to the destination QM.
This performance is not adequate for us. We have noticed that smaller message sizes are transmitted much quicker (as expected for a network related issue). A firewall sits between the 2 queue managers that scrambles packets as they get sent through.
Does anyone have any advice on how to tweak MQSeries settings to improve this performance issue?
Many thanks,
_________________
Chris Woolmer
Programmer
KAZ Group Limited |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Fri Nov 05, 2004 1:07 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Your problem is the network speed, not WMQ.
Ask your network guys why 4Mb takes 33 seconds to transfer. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Fri Nov 05, 2004 5:21 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
My guess here is that your server infrastructure is not isolated from the rest of your network or you have a real pig of an application running somewhere, like streaming video or filesharing (like KAZAA/Limewire/etc.). Ideally, you would have your servers more or less removed from the other computers in the system.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 05, 2004 7:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You might look at adjusting the channel batch size. Try some experiments and see if this improves performance.
You might also see if your performance is significantly different when MQ channels don't pass through this firewall.
If the firewall is the source of the slowdown, then you need to either speed up the firewall somehow, or live with the speed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| woolmerc |
| Posted: Sun Nov 07, 2004 2:19 pm Post subject: |
|
|
Novice
Joined: 12 May 2004
Posts: 21
|
Thanks for the responses guys.
Agree that the problem is mostly network speed. I do have a strong feeling that the firewall is the main cause of bottleneck.
What I am trying to do is get the most out of MQ given the network I am running it accross. I just thought there may be some stuff I could improve.... even if I get 4 or 5 secs better performance.
Jeff: I have tried playing with the message batch size and a batch size of 1 gives the best performance, but still not adequate.
Any other ideas?? Otherwise I guess I will just live with it.
_________________
Chris Woolmer
Programmer
KAZ Group Limited |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Nov 08, 2004 12:56 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Channels run most efficiently if the batch is full or nearly full. This reduces the number of times that the getting of msgs from the xmitq is suspended while the batch is confirmed. So, the BATCHSZ attribute should be set to slightly less than the expected backlog of msgs on the xmitq while the channel confirms the previous flow. If this is not determinable, or msgs arrive slower than they can be read from the xmitq, then setting BATCHINT may be useful. This causes the channel to wait this number of milliseconds before sending a batch of msgs after the xmitq is empty, in case a msg arrives during that time.
Another possibility if to use pipelining, aka dual unit of work. This has to be enabled at both ends of the channel by adding PipeLineLength=2 to the Channels stanza of qm.in. The effect of setting this parameter is that the channel runs 2 threads. After the first thread has completed a batch and is waiting for the confirm flow, the second thread continues to read msgs from the xmitq. This may not be of any use to you, since the major benefit is seen when msgs are arriving on the xmitq faster than the channel can send them; this is not the case here if a BATCHSZ of 1 helps. |
|
| Back to top |
|
|
| woolmerc |
| Posted: Mon Nov 08, 2004 3:43 pm Post subject: |
|
|
Novice
Joined: 12 May 2004
Posts: 21
|
hmmm, some interesting ideas there Nigel.
I will continue trying to tweak and get the best results. I am not 100% sure that BATCHSZ == 1 is best. Over the network, performance is inconsistent and I sometimes get varied results. I will have to run more tests to work it out.
The pipeLineLength idea is definetely a good one and a chance to improve some performance. I will advise of my results.
_________________
Chris Woolmer
Programmer
KAZ Group Limited |
|
| Back to top |
|
|
|
|
