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 » General IBM MQ Support » Delay In MQ Client Server

Post new topic  Reply to topic Goto page 1, 2, 3, 4  Next
 Delay In MQ Client Server « View previous topic :: View next topic » 
Author Message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 7:49 am    Post subject: Delay In MQ Client Server Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

We have a MQ client in one machine and MQ server in another machine where both bounded with MQ client-server connection. We are dropping around 5000 records(each record of size 100 bytes) in MQ client machine, it is taking 40 minutes of time to reach the MQ server machine queue.

I do not understand whats causing the delay to transfer 5000 messages from MQ client to server. I have checked with the network team and Intel team but no issues have been identified either in network or from Client Machine side.

Could anyone please look into this and help me out.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Jan 03, 2012 7:57 am    Post subject: Re: Delay In MQ Client Server Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

kotagiriaashish wrote:
Could anyone please look into this and help me out.


No we can't. We can't see your configuration, log files or any other useful stuff.

To be clear, you're sending 5000 100 byte messages using an application with a client connection. Assuming that:

- does it take 40 minutes for all 5000 messages to arrive on the queue (i.e. the 5000th arrives 40 minues after the first) or do 5000 messages turn up at once?

- How do you know it doesn't take the client application 40 minutes to generate 5000 messages?

- Are all the messages in a single unit of work?

- Are the messages persistent or non-persistent (if you reply with the default queue persistence setting I'm not answerable for the outcome!)

- What version of WMQ?

- How is the queue manager tuned? How much power does the machine have? What OS?

- Are the messages going into an empty queue or one with significant existing depth?

- Are there any error messages from queue manager or application?

- etc

- etc

Basically what have you done to find the problem apart from posting here & bleating at the network / support teams? How have you determined this is a WMQ problem?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
zpat
PostPosted: Tue Jan 03, 2012 8:26 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Based on long experience, I would suspect the client application program design as the first thing to check.
Back to top
View user's profile Send private message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 8:32 am    Post subject: Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

Quote:
No we can't. We can't see your configuration, log files or any other useful stuff.
Which log files do you want me to provide?

To be clear, you're sending 5000 100 byte messages using an application with a client connection. Assuming that:

- does it take 40 minutes for all 5000 messages to arrive on the queue (i.e. the 5000th arrives 40 minues after the first) or do 5000 messages turn up at once?


Yes, 5000th arrives 40 minutes after the first on the queue.

Quote:
- How do you know it doesn't take the client application 40 minutes to generate 5000 messages?

NO, All 5000 messages are there in single file and if same application when run in server it is takes 30 seconds of time to put those 5000 messages.

Quote:
- Are all the messages in a single unit of work?

Yes.

Quote:
- Are the messages persistent or non-persistent (if you reply with the default queue persistence setting I'm not answerable for the outcome!)

Non-Persistent

Quote:
- What version of WMQ?

6.0

Quote:
- How is the queue manager tuned? How much power does the machine have? What OS?

Windows

Quote:
- Are the messages going into an empty queue or one with significant existing depth?

Yes empty queue

Quote:
- Are there any error messages from queue manager or application?

No, there are no failures.

[edit "moderator"]added quotes to make it more readable[/edit]
Back to top
View user's profile Send private message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 8:38 am    Post subject: Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

zpat wrote:
Based on long experience, I would suspect the client application program design as the first thing to check.


We have been using the same application since ages, and the same version is running without any lag on a different client for the same server.


Last edited by kotagiriaashish on Tue Jan 03, 2012 8:39 am; edited 1 time in total
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jan 03, 2012 8:39 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

How long does it take for the CURRDEPTH of the queue to reach 5000 - this is not the same thing *at all* as asking how long it takes for the 5000th message to arrive on the queue?

How are you measuring the time? Are you measuring the amount of time it takes for the code to return from each MQPUT? Or are you measuring how long it takes the code to start up, connect, open, start the transaction, put 5000 messages, commit, close, disconnect and ext?
Back to top
View user's profile Send private message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 8:46 am    Post subject: Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

mqjeff wrote:
How long does it take for the CURRDEPTH of the queue to reach 5000 - this is not the same thing *at all* as asking how long it takes for the 5000th message to arrive on the queue?

How are you measuring the time? Are you measuring the amount of time it takes for the code to return from each MQPUT? Or are you measuring how long it takes the code to start up, connect, open, start the transaction, put 5000 messages, commit, close, disconnect and ext?


We are calculating time diff between First message on the queue and the last message on the queue.

10 sec pass by and I see 20 or 30 messages
30 sec --- a hundred
40min--all 5000 are in the queue....
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jan 03, 2012 8:48 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Measure how long it takes each put to complete.

And, again, measure how long it takes the CURRDEPTH to increase and NOT how long it takes the messages to be visible.
Back to top
View user's profile Send private message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 8:49 am    Post subject: Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

which logs will help you in pointing out the problem.... i will be more than happy to post them
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jan 03, 2012 8:54 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

Display the attributes of the local queue, and post them here.

Has the application been modified in any way recently? Look at the compile date in the executable.

Does the application use MQPUT? Or MQPUT1?

Does the application MQCONNect and MQDISC for each of the 5000 messages?
_________________
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
mqjeff
PostPosted: Tue Jan 03, 2012 8:56 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You have to modify the code to measure how long each PUT takes.

You have to monitor the queue depth either manually or using qstats to determine when it has reached 5000. This is, again, NOT the same thing as looking at the messages on the queue.
Back to top
View user's profile Send private message
kotagiriaashish
PostPosted: Tue Jan 03, 2012 9:06 am    Post subject: Reply with quote

Disciple

Joined: 06 Aug 2011
Posts: 165

mqjeff wrote:
You have to modify the code to measure how long each PUT takes.

You have to monitor the queue depth either manually or using qstats to determine when it has reached 5000. This is, again, NOT the same thing as looking at the messages on the queue.


We only have the binary with us... we cant edit the code...
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jan 03, 2012 9:11 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You don't have the source to your own application?

Well, you can at least enable mq tracing on the client side.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jan 03, 2012 9:17 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

kotagiriaashish wrote:
We only have the binary with us... we cant edit the code...

Please read replies to your OP very, very carefully. Also, please be precise (technically accurate) in your posts.

Why can't you view the executable (binary) as I asked you to do? Use Notepad or any other primitive editor to view the binary. The compile time and data should be clearly visible.
_________________
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
JasonE
PostPosted: Wed Jan 04, 2012 3:41 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Are you connecting / disconnecting each time - that would be the first step.

Trace a portion of the client side, then grep the trace for >> and <<, and work out the time differences from the entry to the exit for each API call, to give an indication of (a) the API calls being made (conn, open, put, close, disc etc), and (b) where the time is being spent. If you put a trace somewhere I can access it, I dont mind taking a quick look as I have a tool which helps with this.

Any idea what language is the app written in (.net? C? java? C++?)?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2, 3, 4  Next Page 1 of 4

MQSeries.net Forum Index » General IBM MQ Support » Delay In MQ Client Server
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.