Author |
Message
|
yortch |
Posted: Tue Mar 27, 2007 11:00 am Post subject: MQGet operation slow on remote queue manager (V6) |
|
|
Apprentice
Joined: 30 Aug 2004 Posts: 34
|
I have a test client application written in .NET that connects to a remote queue manager (V6) running on a VMWare Win2003 server through a server-connection channel. The test app reads 200 messages of 17Kbytes each from a local queue on the remote queue manager. It is taking approximately 48 seconds to complete this operation. If I run this application locally on the virtual server, it only takes about 2 seconds.
I initially thought this was a network latency problem. What is stranger is that if I run the same test remotely with messages of 16K or smaller, the response time drops to about 2 seconds. It seems to me it could be a network problem that is being triggered only with a message size above 16K. I'm looking for suggestions on settings I can tune to alleviate this problem.
The queue managers are using linear logging and the queues are set to persistent, I already tried changing to circular logging and non-persistent queues and the difference is negligible. |
|
Back to top |
|
 |
zpat |
Posted: Tue Mar 27, 2007 11:23 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Messages are persistent, not queues.
.NET may well do it's own buffer management, that could involve attempting a MQGET and increasing the buffer when it fails due to lack of space before trying again. There may be a size value to adjust. |
|
Back to top |
|
 |
tleichen |
Posted: Wed Mar 28, 2007 7:16 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005 Posts: 663 Location: Center of the USA
|
Also, don't forget about the latency time for total security authorization across the channel and on the remote system. Depending on what is in place there, this can be significant.  _________________ IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
Back to top |
|
 |
yortch |
Posted: Wed Mar 28, 2007 10:35 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2004 Posts: 34
|
zpat wrote: |
.NET may well do it's own buffer management |
I tried the same test from a java application, and got very similar results (about 50 seconds for transferring 200 messages of ~17KB each). The MQMessage class has a ResizeBuffer method in both APIs, but increasing it doesn't seem to make a difference.
The same test app puts the message on the queue first, and this only takes a few seconds, it's only the MQGet where this becomes a problem. I'm now back to thinking this could be a network problem, any suggestions on how to confirm/troubleshoot this? |
|
Back to top |
|
 |
yortch |
Posted: Wed Mar 28, 2007 10:51 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2004 Posts: 34
|
tleichen wrote: |
Also, don't forget about the latency time for total security authorization across the channel and on the remote system. |
I can retrieve a larger set of messages (500-1000) within a few seconds, as long as they are less than ~16K. As soon as I go above that message size threshold, even getting just a 100 messages is noticeably slower. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Mar 28, 2007 2:41 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Look into batch size and log sizing issues  _________________ MQ & Broker admin |
|
Back to top |
|
 |
yortch |
Posted: Thu Apr 12, 2007 5:25 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2004 Posts: 34
|
After running further tests, it seems that this issue (slow MQGet with messages over a certain size ~32K) it's only apparent when communicating from a non-VMWare client to a remote queue manager hosted on a VMWare server. Has anyone ever experienced a similar behavior when communicateing with a MQ Server (V6) hosted on VMWare? |
|
Back to top |
|
 |
|