Author |
Message
|
kotagiriaashish |
Posted: Tue Jan 03, 2012 7:49 am Post subject: Delay In MQ Client Server |
|
|
 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 |
|
 |
Vitor |
Posted: Tue Jan 03, 2012 7:57 am Post subject: Re: Delay In MQ Client Server |
|
|
 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 |
|
 |
zpat |
Posted: Tue Jan 03, 2012 8:26 am Post subject: |
|
|
 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 |
|
 |
kotagiriaashish |
Posted: Tue Jan 03, 2012 8:32 am Post subject: |
|
|
 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 |
|
 |
kotagiriaashish |
Posted: Tue Jan 03, 2012 8:38 am Post subject: |
|
|
 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 |
|
 |
mqjeff |
Posted: Tue Jan 03, 2012 8:39 am Post subject: |
|
|
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 |
|
 |
kotagiriaashish |
Posted: Tue Jan 03, 2012 8:46 am Post subject: |
|
|
 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 |
|
 |
mqjeff |
Posted: Tue Jan 03, 2012 8:48 am Post subject: |
|
|
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 |
|
 |
kotagiriaashish |
Posted: Tue Jan 03, 2012 8:49 am Post subject: |
|
|
 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 |
|
 |
bruce2359 |
Posted: Tue Jan 03, 2012 8:54 am Post subject: |
|
|
 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 |
|
 |
mqjeff |
Posted: Tue Jan 03, 2012 8:56 am Post subject: |
|
|
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 |
|
 |
kotagiriaashish |
Posted: Tue Jan 03, 2012 9:06 am Post subject: |
|
|
 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 |
|
 |
mqjeff |
Posted: Tue Jan 03, 2012 9:11 am Post subject: |
|
|
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 |
|
 |
bruce2359 |
Posted: Tue Jan 03, 2012 9:17 am Post subject: |
|
|
 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 |
|
 |
JasonE |
Posted: Wed Jan 04, 2012 3:41 am Post subject: |
|
|
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 |
|
 |
|