ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Performance Monitoring » MQ performance issue

Post new topic  Reply to topic
 MQ performance issue « View previous topic :: View next topic » 
Author Message
MQNETrookie
PostPosted: Tue Feb 16, 2010 11:32 am    Post subject: MQ performance issue Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Feb 16, 2010 11:51 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Feb 16, 2010 11:53 am    Post subject: Re: MQ performance issue Reply with quote

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
View user's profile Send private message
MQNETrookie
PostPosted: Tue Feb 16, 2010 12:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Feb 16, 2010 1:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Feb 16, 2010 1:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
gbaddeley
PostPosted: Tue Feb 16, 2010 2:03 pm    Post subject: Re: MQ performance issue Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Feb 16, 2010 2:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Feb 16, 2010 2:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Performance Monitoring » MQ performance issue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.