| Author |
Message
|
| sandip_gaikwad |
 Posted: Mon Dec 31, 2012 1:41 am Post subject: Why message process slow from application? |
 |
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
Hello expert,
I have mq 6.And I have local queue.Why message process from local queue slowly?What will we be issue?It take time to committed message in fraction of seconds.What will be the ?Kindly do the needful. |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Dec 31, 2012 1:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Are you stating that the putting application is placing messages on the queue within 'fraction of seconds' but the getting application is taking a long time (relatively speaking) to remove those messages?
You need a lot more clarity in your posts for anyone to have a fighting chance of answering your questions.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sandip_gaikwad |
| Posted: Mon Dec 31, 2012 2:08 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
| exerk wrote: |
Are you stating that the putting application is placing messages on the queue within 'fraction of seconds' but the getting application is taking a long time (relatively speaking) to remove those messages?
You need a lot more clarity in your posts for anyone to have a fighting chance of answering your questions. |
Thanks for the quick reply exerk.Actually situation is that we have local queue and we having one application for putting message and one application for getting message from same local queue.I am got confuse with the thing Why message retrieve slowly or process slowly? Because queue is local.If queue has transmit and remote then reason should be network,but queue is local so what will be the reason behind the slow process and retrieved slowly from queue. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Dec 31, 2012 2:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Just because a queue is local to both putting and getting applications does not mean that messages will move to/from it more rapidly than if the queue was serviced by a channel.
There could be any number of reasons why an application is slow in retrieving messages, e.g.:
1. Inefficiently coded application;
2. Resource starvation;
3. Application down-stream resource dependency.
I could add more; and you seem to be focussing more on WMQ being the problem and less on it being the application.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sandip_gaikwad |
| Posted: Mon Dec 31, 2012 2:46 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
| exerk wrote: |
Just because a queue is local to both putting and getting applications does not mean that messages will move to/from it more rapidly than if the queue was serviced by a channel.
There could be any number of reasons why an application is slow in retrieving messages, e.g.:
1. Inefficiently coded application;
2. Resource starvation;
3. Application down-stream resource dependency.
I could add more; and you seem to be focussing more on WMQ being the problem and less on it being the application. |
Following is the queue definition for your information.
dis qs(ABC.LQ) type(queue) all
3 : dis qs(ABC.LQ) type(queue) all
AMQ8450: Display queue status details.
QUEUE(ABC.LQ) TYPE(QUEUE)
CURDEPTH(1085) IPPROCS(1)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MONQ(OFF) MSGAGE( )
OPPROCS(1) QTIME( , )
UNCOM(NO)
dis qs(ABC.LQ) type(handle) all
4 : dis qs(ABC.LQ) type(handle) all
AMQ8450: Display queue status details.
QUEUE(ABC.LQ) TYPE(HANDLE)
APPLTAG(ABCAPP.exe) APPLTYPE(USER)
BROWSE(NO) CHANNEL( )
CONNAME( ) HSTATE(INACTIVE)
INPUT(NO) INQUIRE(NO)
OUTPUT(YES) PID(4556)
QMURID(0.7302011) SET(NO)
TID(1)
URID(XA_FORMATID[MQM ] XA_GTRID[56BAD15020B3418E515048514D4752] XA_BQUAL[0000
0001])
URTYPE(XA) USERID(mquser@RESOURCE)
AMQ8450: Display queue status details.
QUEUE(ABC.LQ) TYPE(HANDLE)
APPLTAG(ABCAPP1.exe) APPLTYPE(USER)
BROWSE(NO) CHANNEL( )
CONNAME( ) HSTATE(INACTIVE)
INPUT(SHARED) INQUIRE(YES)
OUTPUT(NO) PID(4824)
QMURID(0.0) SET(NO)
TID(1)
URID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
URTYPE(QMGR) USERID(mquser@RESOURCE)
kindly suggest if any changes required in parameter. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Dec 31, 2012 2:50 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Thank you, but the information above is of little use to me as I do not have access to your systems, applications, or other information necessary to carry out full fault diagnosis - all I can do is provide pointers to what may affect your installation.
That said, I'd look very closely at No.3 in the list in my previous post.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 31, 2012 3:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| exerk wrote: |
Thank you, but the information above is of little use to me as I do not have access to your systems, applications, or other information necessary to carry out full fault diagnosis - all I can do is provide pointers to what may affect your installation.
That said, I'd look very closely at No.3 in the list in my previous post. |
Don't forget to consider his #2 either. I have seen application set up (WAS) that was purposefully starving the resources needed. And the app folks did not even realize that they were shooting themselves in the foot. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 31, 2012 5:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Was the getting app recently changed? Or was it always slow?
Does the getting app do anything else that might account for the slow-down? Like update a database?
_________________
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 |
|
|
| sandip_gaikwad |
| Posted: Tue Jan 01, 2013 1:45 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
| bruce2359 wrote: |
Was the getting app recently changed? Or was it always slow?
Does the getting app do anything else that might account for the slow-down? Like update a database? |
Application is remain same not changed.But it show sometime uncommitted message for fraction of seconds time in that local queue if I observing queue message monitoring via command prompt.It showing uncommitted message why this thing happened because of MQ setting or application resource or coding fault?
dis qs(ABC.LQ) type(queue) all
75 : dis qs(ABC.LQ) type(queue) all
AMQ8450: Display queue status details.
QUEUE(ABC.LQ) TYPE(QUEUE)
CURDEPTH(1215) IPPROCS(1)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MONQ(OFF) MSGAGE( )
OPPROCS(1) QTIME( , )
UNCOM(YES) |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 01, 2013 5:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sandip_gaikwad wrote: |
| It showing uncommitted message why this thing happened because of MQ setting or application resource or coding fault? |
It's the responsibility of the code to commit the message (rather than any MQ setting) but a message being uncommitted for a fraction of a second is hardly unexpected and certainly not an immediate cause of alarm.
I echo the comments of my associates. You seem to have fixated on WMQ being the issue without any real evidence. What standard are you using to determine the messages are being processed "slowly"? If you're disappointed that it's only processing at 45,000 messages a second you may have to live with it. What's "slowly"? What portion of the machine resources is being used; if the box you're using is at capacity again you're done.
Also what has brought you to the conclusion that WMQ is the issue? Is it simply that the application team can't or won't find the problem and have simply thrown the blame? If the applications are only processing (for example) 2 messages a second and (by your own admission) only have the message uncommitted for a fraction of a second what's being done for the rest of the time? What is being done in that?
You need to provide a lot more information to demonstrate this is a WMQ problem, which will only come from the sort of detailed investigation you should have done from the first. Rather than posting here if anyone knew where the magic speed control was.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 01, 2013 6:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Uncommitted messages in queues is normal behavior for apps that create units-of-work. This behavior is not usually a performance issue.
Tell us about the server hardware and software. What hardware platform and O/S? What version of WMQ? How many processors? How many CPUs?
Is this app (or any others) missing its SLAs (service-level agreements)? Or, does it just seem to be running slowly?
You need to capture real performance data, not just with DISPLAY QLOCAL type of commands. What performance monitoring software do you have?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Jan 01, 2013 7:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Fractions of a second? You have the ability to issue and read the display command multiple times a second?
What is likely happening is the message is uncommitted for much longer than a fraction of a second. My bet is the app asks MQ to put or get the message under syncpoint, goes off and does some other work, perhaps updating a database, and then finally comes back to commit and move onto the next message. Odds are the actual MQ portions of this are taking milliseconds.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sandip_gaikwad |
| Posted: Fri Feb 01, 2013 1:34 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
| bruce2359 wrote: |
Uncommitted messages in queues is normal behavior for apps that create units-of-work. This behavior is not usually a performance issue.
Tell us about the server hardware and software. What hardware platform and O/S? What version of WMQ? How many processors? How many CPUs?
Is this app (or any others) missing its SLAs (service-level agreements)? Or, does it just seem to be running slowly?
You need to capture real performance data, not just with DISPLAY QLOCAL type of commands. What performance monitoring software do you have? |
We don't have any MQ monitoring tool .Kindly suggest free MQ monitoring tool. |
|
| Back to top |
|
|
| sandip_gaikwad |
| Posted: Fri Feb 01, 2013 1:37 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2011
Posts: 95
|
| PeterPotkay wrote: |
Fractions of a second? You have the ability to issue and read the display command multiple times a second?
What is likely happening is the message is uncommitted for much longer than a fraction of a second. My bet is the app asks MQ to put or get the message under syncpoint, goes off and does some other work, perhaps updating a database, and then finally comes back to commit and move onto the next message. Odds are the actual MQ portions of this are taking milliseconds. |
I don't understand what you are trying to say? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 01, 2013 4:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sandip_gaikwad wrote: |
| PeterPotkay wrote: |
Fractions of a second? You have the ability to issue and read the display command multiple times a second?
What is likely happening is the message is uncommitted for much longer than a fraction of a second. My bet is the app asks MQ to put or get the message under syncpoint, goes off and does some other work, perhaps updating a database, and then finally comes back to commit and move onto the next message. Odds are the actual MQ portions of this are taking milliseconds. |
I don't understand what you are trying to say? |
Meaning (and forgive me PeterPotkay if I'm stepping on your toes) that:
1. App gets message under syncpoint - time in WMQ = 1ms
2. App processes message content - time in WMQ = 0, time in App = 10ms
3. App updates database - time in WMQ = 0, time in App/DB = 3s
4. DB, App and WMQ commit changes - time in WMQ = 1ms, time in App = 1ms, time in DB = 1ms
So, total time in WMQ = 2ms but in App/Other Resource = over 3s. The symptom is messages moving off the queue slowly but the cause (in the above example) is a slow database.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
