| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ performance issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQNETrookie |
 Posted: Tue Feb 16, 2010 11:32 am Post subject: MQ performance issue |
 |
|
Novice
Joined: 20 Jun 2009
Posts: 19
|
I developed an .NET app (Windows base) to send/receive message from the MQ (Unix). Everything is working fine, except when I use WinShark to trace the packet, it is taking 54 steps to complete 1 transaction. Is there any way for me to change the code so that I can cut down the number of steps? Here is my code....
MQEnvironment.Hostname = QHostName;
MQEnvironment.Channel = QChannelName;
MQEnvironment.Port = QPort;
MQEnvironment.SSLCipherSpec = qSSLCipherSpec;
MQEnvironment.SSLKeyRepository = qSSLKeyRepository;
qMgr = new MQQueueManager(QueManager);
int InOpenOptions = MQC.MQOO_FAIL_IF_QUIESCING | MQC.MQOO_OUTPUT;
int OutOpenOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_FAIL_IF_QUIESCING;
InputQueue = qMgr.AccessQueue(InQueName, InOpenOptions);
OutputQueue = qMgr.AccessQueue(OutQueName, OutOpenOptions);
MqsMsg = new MQMessage();
MqsMsg.ReplyToQueueName = OutQueName;
MqsMsg.Expiry = Expiry;
MqsMsg.WriteBytes(RequestStream);
MqsMsg.Persistence = MQC.MQPER_NOT_PERSISTENT;
MqsMsg.Format = MQC.MQFMT_STRING;
MqsMsg.MessageType = MQC.MQMT_REQUEST;
MQPutMessageOptions pmo = new MQPutMessageOptions();
InputQueue.Put(MqsMsg, pmo);
InputQueue.Close();
.
.
.
.
retrievedMessage = new MQMessage();
retrievedMessage.CorrelationId = MqsMsg.MessageId;
retrievedMessage.MessageType = MQC.MQMT_REPLY;
gmo = new MQGetMessageOptions();
gmo.Options = MQC.MQGMO_FAIL_IF_QUIESCING | MQC.MQGMO_WAIT;
gmo.WaitInterval = WaitInterval;// wait time
gmo.MatchOptions = MQC.MQMO_MATCH_CORREL_ID;
OutputQueue.Get(retrievedMessage, gmo);
msgText = retrievedMessage.ReadString(retrievedMessage.MessageLength); |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 16, 2010 11:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Unless you have intensely tight performance requirements, it's a waste of time to count packets.
If you have intensely tight performance requirements, you shouldn't be using the network at all but should be running your application directly on the qmgr machine using server bindings.
It's extremely unlikely you have performance requirements that tight. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 16, 2010 11:53 am Post subject: Re: MQ performance issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQNETrookie wrote: |
| Everything is working fine, except when I use WinShark to trace the packet, it is taking 54 steps to complete 1 transaction. Is there any way for me to change the code so that I can cut down the number of steps? |
If everything's working fine, what's the problem? How long do these 54 steps take to complete? If the whole 54 go through in 2 seconds then what's the problem?
If they take 54 seconds, where's the delay indicated?
(Note that I've no idea what WinShark is, what it does or why anyone would care. This is a deficientcy on my side)
Just glancing down the code, nothing unnecessary leaps out.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQNETrookie |
| Posted: Tue Feb 16, 2010 12:10 pm Post subject: |
|
|
Novice
Joined: 20 Jun 2009
Posts: 19
|
| Thanks mqjeff and Vitor for responding. The situation the mq machine is own by the customer, which my app need to connect to and get data, so I can't put my app there. Also, right now it is taking 1.8 sec on average to complete 1 transaction, that to me is fast. However, they are comparing this tool new with their existing tool, the new one is 0.4 sec slower. I am just doing everything I could to speed it up. Any idea? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 16, 2010 1:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQNETrookie wrote: |
| However, they are comparing this tool new with their existing tool, the new one is 0.4 sec slower. I am just doing everything I could to speed it up. Any idea? |
If they're that worried about half a second it's probably not worth worrying. You could tune your code to within an inch of it's life and still fail this comparision if the network is busy the day they do the test.
I'd also wonder if they're comparing like with like. For instance, if their existing tool is running on the same machine as the queue manager; as my worthy associate points out that's significantly faster. Also is their measurement end to end or simply shovelling data from one queue to another?
Or is their existing tool not using WMQ at all but some other (possibly database) related mechanism? And this rather nitpicking question of performance a rearguard action not to change technologies?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 16, 2010 1:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Everything is working fine, except when I use WinShark to trace the packet, it is taking 54 steps to complete 1 transaction. |
If everything works fine, except when you use WinShark, stop using WinShark.
If you are still after improving network throughput, you might consider data compression.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Feb 16, 2010 2:03 pm Post subject: Re: MQ performance issue |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| MQNETrookie wrote: |
| I developed an .NET app (Windows base) to send/receive message from the MQ (Unix). Everything is working fine, except when I use WinShark to trace the packet, it is taking 54 steps to complete 1 transaction. Is there any way for me to change the code so that I can cut down the number of steps? |
By 54 steps, I assume you mean 54 TCP packets are transmitted over the network between the .NET client app and the queue managers. That seems a bit high.
Each MQIC call should be 2 packets (couple of extra for MQCONN), and if the message data is longer than 32K there will be additional packets to contain the rest of the data.
So to connect, open 2 queues, put a message, get a message, close 2 queues and disconnect, that should be less than 20 packets.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 16, 2010 2:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| That seems a bit high. |
Could be. There is nothing about the number 54 that provide any real insight. Some analysis of what the packets contain would shed some light.
If the network is dropping packets (or other errors), there will be re-transmissions.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 16, 2010 2:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| If the network is dropping packets (or other errors), there will be re-transmissions. |
Hence my comment above that all the code tuning in the world won't help if the test is done over a dubious network link.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
