| Author |
Message
|
| techno_freak |
 Posted: Tue Nov 23, 2010 7:02 am Post subject: Best Configuration |
 |
|
Novice
Joined: 23 Nov 2010
Posts: 12
|
Hey Guys,
I got an opportunity to build new WMQ server with best configuration or you could say for performance and fine tunning.Where i could get a doc to prepare checklist for it.
Box is Solaris, planning to install WMQ V7.
Let me know if you need more information to help me out.
Regards
Freak |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Nov 23, 2010 7:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want an MQ box that runs in the best configuration for performance, availability, and fine tuning, then you want MQ on zOS not on Solaris.
If you want to know how to fine tune a Solaris box for running WMQ as best as Solaris can, then you have a lot more homework to do than just asking for free links here. Start with the manual oddly enough called "Quick Beginnings for Solaris".
Read it all the way through, twice or three times. consider what it's said.
Then review the Performance Report SupportPac for Solaris and WMQ v7.
Read through it twice or three times, all the way through. Consider what it's said.
Then decide if you have the necessary skills to actually implement it. If not, tell your boss to hire a consultant. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Nov 23, 2010 4:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
MQ performance is generally very good "out of the box". IBM has gone to a lot of effort to make that so. However, there is some fine tuning that can be done for particular usage scenarios, particularly with file system layout and application design. YMMV.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 23, 2010 4:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| MQ performance is generally very good "out of the box". |
But is not configured out-of-the-box to support large/production workloads - on any platform.
The out-of-the-box (see how I can deliberately avoid using the word 'default') is usually (more than) adequate for testing, proof-of-concept, etc..
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Nov 23, 2010 7:30 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| But is not configured out-of-the-box to support large/production workloads - on any platform. |
Depends what you mean by "configured". Are you referring to the default minimum recommendations for MQ installation, and creating a queue manager with all default settings (including recovery logs) ? Even that can work very well in some production situations.
The original poster was concerned with fine tuning, and I intepreted that to mean they already considered the basics of file systems, log sizing, CPU, memory, kernel settings etc requirements for their usage, and did their installation and created their queue managers accordingly. Then they wanted to look at tweaking performance even more.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 23, 2010 9:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I intepreted that to mean they already considered the basics of file systems, log sizing, CPU, memory, kernel settings etc requirements for their usage, and did their installation and created their queue managers accordingly. |
That's odd... I interpreted the OP to mean the exact opposite. How can that be??
_________________
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 |
|
|
| techno_freak |
| Posted: Wed Nov 24, 2010 12:05 am Post subject: |
|
|
Novice
Joined: 23 Nov 2010
Posts: 12
|
| Thanks guys for your response .. Let me see how well i can perfomr in this task. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 24, 2010 11:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Poorly written apps can negate any and all efforts on our part to fine tune the Queue Manger.
When looking for performance gains, I think the application area is the first place to look - Persistence, syncpoints, looping MQCONNs, looping MQOPENs, client versus binding, big messages versus little, browsing instead of just getting, checking q depth before doing a get  , etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 24, 2010 11:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Things I always change on a new queue manager
1. Increase log file sizes
2. Increase maxchannels (and maxactive)
3. Enable Keepalive
4. Disable OCSP
5. Make the system default queues persistent (since 99% of our data needs this) and maxdepth increased on the default local.
MQ performance is largely determined by the application behaviour. There are some tunable options but it's most important that the apps are written properly before trying to tune it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 24, 2010 11:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
5. Make the system default queues persistent (since 99% of our data needs this) and maxdepth increased on the default local.
|
IMHO, If an app needs persistent messages, they can take the minimal effort to code the 1 line of code needed to specifically choose this. If they are to lazy to do that, the heck with them, they can default to non persistent.
If they specifically code yes or no for persistence, they control it. Its not my job or responsibility to insure the queue property is something they need when its so easy to code themselves. The only time I think queue persistence needs to use the queue attribute is when you think you will need to toggle it back and forth often and its easier to alter the queue than the app.
LogBufferPages is another attribute I jack up to the maximum value for every QM I build.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Nov 24, 2010 3:00 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
Things I always change on a new queue manager
1. Increase log file sizes
2. Increase maxchannels (and maxactive)
3. Enable Keepalive
4. Disable OCSP
5. Make the system default queues persistent (since 99% of our data needs this) and maxdepth increased on the default local.
MQ performance is largely determined by the application behaviour. There are some tunable options but it's most important that the apps are written properly before trying to tune it. |
Most of these are Capacity Planning, not Performance Tuning. If you want the fast possible processing, don't use peristent messages! Persistence is an application design choice, not a MQ infrastructure / admin choice.
Increasing the default maxdepth can be dangerous, as it tends to delay the detection of application problems.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 24, 2010 4:38 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Increasing the default maxdepth can be dangerous, as it tends to delay the detection of application problems - for poorly tested applications.
_________________
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 |
|
|
| techno_freak |
| Posted: Wed Nov 24, 2010 8:39 pm Post subject: |
|
|
Novice
Joined: 23 Nov 2010
Posts: 12
|
| PeterPotkay wrote: |
Poorly written apps can negate any and all efforts on our part to fine tune the Queue Manger.
When looking for performance gains, I think the application area is the first place to look - Persistence, syncpoints, looping MQCONNs, looping MQOPENs, client versus binding, big messages versus little, browsing instead of just getting, checking q depth before doing a get , etc. |
Thanks to all for their inputs. Which doc is a best one which help me to understand application design for WMQ from adminstrator prospects. I mean i can suggest few guideline to application team which they can consider while they design their application.
Rgeards
Freak |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 24, 2010 9:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There are two manuals: WMQ Application Programming Reference, and WMQ Application Programming Guide.
The Ref documents WMQ data types, structures and MQI calls. The Guide documents how each MQI call behaves.
Although WMQ behaves asynchronously (application A puts a message in a queue), developers can construct synchronous-behaving applications. The usual 'synchronous' app design is called the request-reply model.
_________________
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 |
|
|
| exerk |
| Posted: Wed Nov 24, 2010 11:56 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And to add to bruce2359's missive, there is also THIS...
_________________
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 |
|
|
|
|
