Author |
Message
|
guest468 |
Posted: Wed Aug 26, 2009 7:53 am Post subject: MQ input and output |
|
|
Centurion
Joined: 30 May 2006 Posts: 146 Location: NY
|
Hi,
I am trying to understand the impact of MQPUT and MQGET that are taking place on a queue at the same time. Is there any performance impact ofone on another? The MQGETs are always FIFO so I would guess the queue file should be available to both with minimal impact? (We use SAN)
Actually we have one moderately used(100 thousand messages /hour) queue where several applications put messages and one app does GET using multiple thread. And once every couple of hours there is a sudden spike in the mq resp time lasting couple of minutes. I saw queue depth also spiking at the same time. The messages are all persistent and are under XA and consumer app does database update as well.
Thanks, |
|
Back to top |
|
 |
Vitor |
Posted: Wed Aug 26, 2009 10:57 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
I'd be surprised if you noticed any adverse effects from this. There are many other possible bottlenecks in this scenario (which you're clearly on top of - you mention multi-threading). _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Aug 26, 2009 11:41 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I agree with Vitor that if you have already tuned for optimum performance (processors, RAM, buffers) and have sufficient I/O capability (bandwidth and concurrency), you will see very little impact. But there are usually other opportunities for enhancing performance.
Take a look at http://www.ibm.com/developerworks/websphere/library/techarticles/0712_dunn/0712_dunn.html _________________ 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 |
|
 |
fjb_saper |
Posted: Wed Aug 26, 2009 6:30 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You mentioned multithreading. However for it to be efficient you need to make sure that each thread uses it's own connection otherwise you are single threading all that work through the connection (this is a synchronized object for MQI calls)... I'm sure you're doing that already but it bears repeating for our newbies... Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Sam Uppu |
Posted: Thu Aug 27, 2009 6:37 am Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
Do you see any spikes on database?. May be database is the culprit. How your CPU is reacting with the resources where MQ manager is running?. Is the database and MQ are running on the same physical box?.
I dont think MQ is the bottleneck here. How MQ being used by the peripherals is causing the issue.
Thanks. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Aug 27, 2009 8:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
It could be the queue file reorg task. |
|
Back to top |
|
 |
guest468 |
Posted: Thu Aug 27, 2009 8:59 am Post subject: |
|
|
Centurion
Joined: 30 May 2006 Posts: 146 Location: NY
|
Thanks guys for the info.
There was a pattern occuring every 2 hours. And application team confirmed they have some batch process which runs during this time which dumps a lot of messages (there was an increase of 10-15k messages; from 100k to 115k during the proboem period when i checked the statistics). The average queue time was also high during that period(8sec compared to usual 1sec). The database is doing fine. They are using separate connection per thread.
I will monitor I/O today and see if there is an issue there. I am also pesruading them to go with semi-persisetn queue since these messages can be retriggered if lost (though it is pain for them)
Jeff, you mentioned reorg; are you referring to periodic(not sure of this, since I hear MQ does it when it feels right) clearing of queue file by MQ?
Thanks |
|
Back to top |
|
 |
|