| Author |
Message
|
| elikatz |
 Posted: Wed Jun 10, 2009 12:33 pm Post subject: MQ testing |
 |
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
hi all,
I wasn't sure what to right in the search so i'm opening a new topic...
we have some MQ servers in our lab (version 6.0.2.6) that we use for testing.
our developers want to check our client with big amount of message (800,000) on several queues.
the problem is that it take them around 6 hours to load all those messages so they asked me if i know of a better way to load huge amount of messages to MQ as soon as possible.
thanks,
Eli |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jun 10, 2009 12:48 pm Post subject: Re: MQ testing |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elikatz wrote: |
| the problem is that it take them around 6 hours to load all those messages |
Using what currently?
| elikatz wrote: |
| i know of a better way to load huge amount of messages to MQ |
The qload utility would be an obvious possibility.
Important questions unanswered are:
What platform?
What hardware?
What amount of tuning performed on the queue manager?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed Jun 10, 2009 1:11 pm Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
hi,
sorry for the lack of information... usually I don't do this...
| Quote: |
Using what currently?
|
I was terrified to find that there are renaming the whole IBM when the queue are full, using the application to pull the messages and then renaming again and restarting the server.
| Quote: |
What platform?
What hardware?
What amount of tuning performed on the queue manager?
|
- Windows 2003 server 64bit, MQ is 32bit (reason is you utilize more memory...)
- Some of the machine are HP servers but some of them are PC's with local disks.
- not sure in understand the last question... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 10, 2009 2:40 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...want to check our client with big amount of message (800,000)... |
Are you saying that you are testing a client bindings application to put a 800k messages? If so, this will endure lots of network flows, and will be verrrrrrrry slow. For this quantity, I'd suggest qmgr to qmgr channels. Much faster.
_________________
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: Wed Jun 10, 2009 5:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
| ...want to check our client with big amount of message (800,000)... |
Are you saying that you are testing a client bindings application to put a 800k messages? If so, this will endure lots of network flows, and will be verrrrrrrry slow. For this quantity, I'd suggest qmgr to qmgr channels. Much faster. |
If the goal is to have the putting application complete as fast as possible, I agree. 800,000 MQPUTs will be a lot faster to a local QM in bindings mode versus to a remote QM via an MQ Client connection.
If the end goal is to have those 800K messages available for MQGETs, then I don't think it will be much faster. The MQ Client channel and the QM to QM channel has to deal with the same network overhead.
| elikatz wrote: |
| I was terrified to find that there are renaming the whole IBM when the queue are full... |
We don't know what that means. Make sure the app connects to the Queue Manager ONCE, opens the queue ONCE, loops 800K times for the MQPUT, then closes the queue ONCE and disconnects ONCE. If they are connecting and opening for each message, performance will be bad.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 10, 2009 6:50 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Any attempt to solve this problem at the file system level will lead to heartache and even worse to unreliable results. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 10, 2009 11:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elikatz wrote: |
| I was terrified to find that there are renaming the whole IBM when the queue are full, using the application to pull the messages and then renaming again and restarting the server. |
A valid reaction I think! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 11, 2009 5:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The MQ Client channel and the QM to QM channel has to deal with the same network overhead. |
Yes, the same number of messages will flow across the network. QM-QM channels can batch messages reducing the overall load on the network. Client apps will drive more bi-directional flows.
_________________
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 |
|
|
| elikatz |
| Posted: Thu Jun 11, 2009 6:36 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
thanks everyone for the responses...
especially for:
| Quote: |
I was terrified to find that there are renaming the whole IBM when the queue are full, using the application to pull the messages and then renaming again and restarting the server.
A valid reaction I think!
|
QM to QM sound good to me, I thought suggesting the dev guys to prepare one queue manager full with messages as a resource for messages and I'll supply them a script using qload to copy the messages from one QM to another... |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Jun 11, 2009 10:03 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| You might look at MA0T as well. |
|
| Back to top |
|
|
|
|
