| Author |
Message
|
| jkfriends |
 Posted: Thu Oct 14, 2010 6:27 am Post subject: MQ client 6.1 delay in writing to queue |
 |
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
Hi, I'm using MQ client 6.1 and coding it in .NET 3.5 using C#.
The following code snippet works great however I notice that when there's no activity in the queue for a while, the next time when we do the queue write, it takes about 17 seconds to do a simple write however when the system is hot and processing hundreds of messages, it takes only <100 milliseconds. So there's definitely makes the queue write process sleep behind the scene.
| Code: |
MQQueueManager queueManager = null;
MQQueue requestQueue = null;
MQMessage requestQueueMessage = null;
try
{
// connect to the QueueManager
queueManager = GetQueueManager(env);
// open queue for output, but not if MQ is quiescing
requestQueue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
// put the request message
requestQueueMessage = new MQMessage();
requestQueueMessage.Format = MQC.MQFMT_STRING;
requestQueueMessage.WriteString(message);
requestQueue.Put(requestQueueMessage);
}
catch (MQException mqex)
{
/* Exception logic */
}
finally
{
CloseQueue(requestQueue);
CloseQueueManager(queueManager);
}
|
Do you know of any control in the MQ queue setup that does this or something on the C# code, we can control that. Please let me know.
Thanks, JK |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Oct 14, 2010 7:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What I suspect is that you have used that queue as a parking space.
Keep the queue empty and you should not have to wait 17 seconds for the queue to be loaded. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jkfriends |
| Posted: Thu Oct 14, 2010 8:45 am Post subject: |
|
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
fjb_saper, I don't understand your reply. When I drop a message into that queue, it will be immediately picked up by other application to process the message. So the queue would be empty most of the time.
I don't use the queue as the "Parking space". What do you mean by that?
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 14, 2010 10:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| when there's no activity in the queue for a while, the next time when we do the queue write, it takes about 17 seconds to do a simple write |
Sounds to me like much of the 17 seconds is to instantiate the application.
_________________
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 |
|
|
| jkfriends |
| Posted: Thu Oct 14, 2010 11:22 am Post subject: |
|
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
| I understand but anything we can do to keep it "hot" all the time? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 14, 2010 11:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jkfriends wrote: |
| I understand but anything we can do to keep it "hot" all the time? |
I think my most worthy associate was speculating that it takes your application 17 seconds to go from cold to hot, rather than the write to queue taking 17 seconds.
To expand on the question - how is that 17 seconds measured? Where does the clock start and stop? If there's been a pause in processing, how does the application respond? How does that differ from continual processing of messages? Does the application close the queue and disconnect? Does the SVRCONN channel time out? After how long a pause do you see this 17 second delay?
More importantly, how does the system react when your application is inactive for a time? Is it paged out of memory & have to be reloaded?
Find the 17 seconds, prove it's WMQ, prove which function of WMQ and concentrate on tuning that. Or prove it's not WMQ and tune whatever it is. The queue manager is constantly "hot" and doesn't take 17 seconds to respond to a put request from an already connected application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jkfriends |
| Posted: Thu Oct 14, 2010 12:10 pm Post subject: |
|
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
Ok - here's what I observed. It is definitely the queue write (put command) actually takes 17 seconds....
I have a trace line that displays "About to invoke put" command - time stamp.
Then the process stops when it is excuting the put command (only for the first time after non-activity period)
Then I print another line "Finished put" command - time stamp.
It is consistently proven that it shows 17 seconds to finish the put command in the log file by calcuating the end-time subtract start-time. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 14, 2010 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jkfriends wrote: |
| It is consistently proven that it shows 17 seconds to finish the put command in the log file by calcuating the end-time subtract start-time. |
Seems clear cut. If the line is directly above the put; see below.....
I notice the code snippet you provided is connecting & disconnecting before and after each put. Is that just an example or what you're really doing? If it is you should change it; connecting to a queue manager is a CPU expensive operation (hence my caveat above about an already connected queue manager) and you should seek to do as few times as possible.
I also notice your code appears to be (gulp!) Java. Is it an MDB or similar? Does it obtain the connection to the queue manager directly or from an app-server managed pool? Could there be a delay with your MDB being paged back into the app server and/or obtaining a fresh connection from the pool? The code as written should have a 17 second delay for each put as a new connection is established, implying a pool, but advice from me on Java subjects should be viewed with some dubiousness.
But points to ponder at least.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 14, 2010 12:19 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You posted a code snippet.
What else does the application do besides putting one message in a queue?
Where does it get the input data?
Does it access a data base?
What is the size of the message?
_________________
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 |
|
|
| jkfriends |
| Posted: Thu Oct 14, 2010 1:22 pm Post subject: |
|
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
The code snippet above is .NET C# and not JAVA!!
* Application does several things besides putting a message in a queue.
* The application creates XML messages (about 4000 to 6000 bytes size) and puts it into this MQ queue for the back-end legacy system to pick it up and process it.
Ok - I'll see if I can cache the Queue Manager connection object as you suggested to see if it makes a difference and let you all know.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 14, 2010 1:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| .NET C# and not JAVA!! |
Wow. Caps and two bang symbols. I think jkfriends took offense at the Java comment.
_________________
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 |
|
|
| jkfriends |
| Posted: Thu Oct 14, 2010 1:31 pm Post subject: |
|
|
Novice
Joined: 09 Oct 2009
Posts: 20
|
| Sorry....I didn't mean to. It did not me an offence. Both C# and Java code look alike. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 14, 2010 6:35 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Both the operation of connecting to a queue manager and the operation of opening a queue are expensive compared to the operation of put and get.
You should do both of those operations as few times as possible.
Both the operation of put and get are made significantly more expensive as the depth of the queue increases. That is, the more messages there are on the queue in the first place, the longer it takes to either get or put a message.
You should keep your queues as empty as possible.
An MQ connection has a built in timeout value - at several levels and at various degrees of tunability. Once an mq connection has gone stale, an attempt to use it again will either result in a reason code that tells you it's gone stale or in an under the covers reconnect that is (as stated before) expensive.
At a minimum, you should reorganize your code such that connections and queue open (AccessQueue) calls are handled outside of the main processing loop. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 15, 2010 5:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
...as a (fine) tuning exercise.
However, it is doubtful that the additional internal code required to manage a queue with some or many messages could explain 17 seconds delay. A few milliseconds or so on a busy cpu would be more like it.
| Quote: |
| * Application does several things besides putting a message in a queue. |
Please be more specific. Does it do database searches/updates?
| Quote: |
| * The application creates XML messages (about 4000 to 6000 bytes size) and puts it into this MQ queue for the back-end legacy system to pick it up and process it. |
Please be more specific. How many XML messages per application instance? One, one hundred, one thousand?
How is the application instantiated? That is, what event causes the app to be launched?
_________________
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 |
|
|
| MCardinal |
| Posted: Mon Oct 18, 2010 7:25 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
| mqjeff wrote: |
An MQ connection has a built in timeout value - at several levels and at various degrees of tunability. Once an mq connection has gone stale, an attempt to use it again will either result in a reason code that tells you it's gone stale or in an under the covers reconnect that is (as stated before) expensive.
|
Yes I have seen this, The channel will go in status "Inactive" instead of "Running" which is different than "Stopped". When he get a message in "Inactive" status he has put the application on wait, while it start then process message in the queue.
Check this out. |
|
| Back to top |
|
|
|
|
