| Author |
Message
|
| noles321 |
 Posted: Tue Aug 18, 2009 5:57 am Post subject: Poor MQ Client get performace when puts are being done |
 |
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
I have test setup where a Mainframe poplulates persistent messages to a queue on a LINUX Machine which is queue manager to queue manager communications, at the same time an AIX machine is client connected to the queue pulling messages. We achevie around 250 messages a second pulling off of the queue when no messages are being put to the queue and only around 30 messages a second pulling when messages are simulataniously being put to the queue. I am a bit stumped here. Any advise would be appreciated.
Jeramy Govert |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Aug 18, 2009 6:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
How stressed is the server/queue manager? What is the number of UNCOM messages? What version and CSD/FixPack/RefreshPack?
_________________
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 |
|
|
| sumit |
| Posted: Tue Aug 18, 2009 6:15 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Did you use identical message each time? What's the avg. size of messages? What do the server performance parameters suggest?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:17 am Post subject: info |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
Server and queue manger do not appear to be stressed. I am running :
WebSphere MQ
Version: 7.0.0.2
CMVC level: p700-002-090421
BuildType: IKAP - (Production)
I am not sure on the uncommited messages. |
|
| Back to top |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:19 am Post subject: Message attributes |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
| The average message size is roughly 4k and it is roughly the same message with a numbering differnence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 18, 2009 6:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Are you searching by messageid/correlid?
_________________
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 |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:24 am Post subject: Datagrams |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
| These are datagrams and we dont mess with msgID correlID. I have never run into this issue before either. To make things worse the client code is from a vendor so I don't have control of it and am just trying to find some suggestions for them at this point. |
|
| Back to top |
|
|
| sumit |
| Posted: Tue Aug 18, 2009 6:32 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Seems like at some point of time, both sending and receving applications are trying to work on same physical message. Can you check with the vendor if the application performing 'put' locks the message so that no other application can access it till 'put' app. commits it.
Similarly, cursor of 'get' app should move to next message as soon as it finds the current message under cursor as locked. The cursor should move back to beginning of the queue as soon as it reaches the end of it.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:36 am Post subject: . |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
| sumit wrote: |
Seems like at some point of time, both sending and receving applications are trying to work on same physical message. Can you check with the vendor if the application performing 'put' locks the message so that no other application can access it till 'put' app. commits it.
Similarly, cursor of 'get' app should move to next message as soon as it finds the current message under cursor as locked. The cursor should move back to beginning of the queue as soon as it reaches the end of it. |
I believe there app is based on the amqsputc app. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 18, 2009 6:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What is the arrival rate of the persistent messages on the Linux queue? In other words, is the channel from the mainframe to the Linux server only putting them at 30 messages a second, maybe because the mainframe is producing them at only 30 a second?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:38 am Post subject: . |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
| PeterPotkay wrote: |
| What is the arrival rate of the persistent messages on the Linux queue? In other words, is the channel from the mainframe to the Linux server only putting them at 30 messages a second, maybe because the mainframe is producing them at only 30 a second? |
No we are putting at 150 messages a second and the client is not keepin up with them only pulling around 30. Once the putting application has finished putting all of the messages the client start dequeing at 250 msg/s. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 18, 2009 6:39 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
As it's test, I'd run some base-lines:
1. send n messages, stop channel, activate client and monitor CPU and memory.
2. client activate and waiting, send n messages, so an active channel, and monitor CPU and memory.
3. Repeat 2. and check UNCOM, Queue Service Interval and anything else that may help.
All I can think of at the moment, sorry.
_________________
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 |
|
|
| exerk |
| Posted: Tue Aug 18, 2009 6:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
Seems like at some point of time, both sending and receving applications are trying to work on same physical message. Can you check with the vendor if the application performing 'put' locks the message so that no other application can access it till 'put' app. commits it.
Similarly, cursor of 'get' app should move to next message as soon as it finds the current message under cursor as locked. The cursor should move back to beginning of the queue as soon as it reaches the end of it. |
No they're not...read the original post! It's queue manager-to-queue manager, therefore the client app has no call on a message until the receiving MCA has committed it.
_________________
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 |
|
|
| sumit |
| Posted: Tue Aug 18, 2009 6:45 am Post subject: Re: . |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| noles321 wrote: |
| No we are putting at 150 messages a second... |
putting 150 msgs/sec in some folder for amqsputc command to process or putting 150 msgs/sec in queue using amqsputc?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| noles321 |
| Posted: Tue Aug 18, 2009 6:45 am Post subject: |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
| exerk wrote: |
| sumit wrote: |
Seems like at some point of time, both sending and receving applications are trying to work on same physical message. Can you check with the vendor if the application performing 'put' locks the message so that no other application can access it till 'put' app. commits it.
Similarly, cursor of 'get' app should move to next message as soon as it finds the current message under cursor as locked. The cursor should move back to beginning of the queue as soon as it reaches the end of it. |
No they're not...read the original post! It's queue manager-to-queue manager, therefore the client app has no call on a message until the receiving MCA has committed it. |
Well at least i am mildly happy that I haven't completly lost my mind... |
|
| Back to top |
|
|
|
|
