| Author |
Message
|
| llaros |
 Posted: Fri Sep 18, 2009 12:32 am Post subject: How to improve deployment performance |
 |
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Similar problem: http://www.mqseries.net/phpBB2/viewtopic.php?t=50117&sid=2a5c370fb5803f65cfe1542892407382
Environment:
System Model: IBM,9119-595
Processor Type: PowerPC_POWER5
Processor Implementation Mode: POWER 5
Number Of Processors: 2
Processor Clock Speed: 1902 MHz
Memory Size: 12288 MB
Good Memory Size: 12288 MB
Platform Firmware level: SF240_358
Firmware Version: IBM,SF240_358
AIX 5.3 ML 08 & HACMP
WMQ 6.0.2.6
WMB 6.0.0.3
Configmgr has its own qmgr which is different from broker qmgr. Both qmgrs are on the same machine.
We have a serious and increasing problem with the deployment process. We wrote fully automated scripts which deploy whole set of new broker flows during a release. At present we have 147 flows in 30 execution groups (plus one messageset per eg). Deployment time consumes over half hour what begins to be unacceptable on production. Forking is not an options since a deployment locks configmgr. What can be done about that?
P.S. We are going to upgrade to latest 6.0.0.9 but we are not sure that this will solve the issue. The problem is a snowball because number of flows and execution groups is not constant.
Thanks for your advises.
Regars |
|
| Back to top |
|
 |
| Luke |
| Posted: Fri Sep 18, 2009 1:48 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
Hi,
Is this really similar to the problem in the link you posted? i.e. Do you find the time taken to deploy the same thing increases significantly every time you deploy? Or does it just take longer to deploy when you are deploying more flows/msgsets to more execution groups?
There are a lot of variables involved (not least the complexity of your flows, and whether you have traffic going through the Broker when you're deploying), but 147 flows and 30 msgsets deployed to 30 execution groups in somewhere in the region of half an hour doesn't sound all that bad to me. I remember the deploys in version 2.1 though, so maybe my expectations are just very low ... |
|
| Back to top |
|
|
| llaros |
| Posted: Fri Sep 18, 2009 2:06 am Post subject: |
|
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Thanks for your reply.
We haven't noticed that the time of the deployment is increasing during configmgr life time. The problem is just related to the poor deployment performance. I doubt this is the same issue.
The customer needs high availability of the environment even at night when the releases are being made.
Thanks for your suggesions
Regards |
|
| Back to top |
|
|
| Luke |
| Posted: Fri Sep 18, 2009 2:21 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
OK, other people may have views on whether the deployment performance should be considered poor. It's been a while since I had the joys of night time deployments to production.
Regarding the high availability, what's your current approach here? I used to work at a 24/7 site where we had two production Brokers on separate LPARs, and traffic was routed to both under normal circumstances - but during deployments (at night when volumes were lower) we routed to one Broker and deployed to the other, then switched traffic on to the Broker we'd deployed to, checked everything looked OK, then deployed to the second Broker.
Luke |
|
| Back to top |
|
|
| llaros |
| Posted: Fri Sep 18, 2009 3:37 am Post subject: |
|
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Hi
We have active-passive HACMP cluster - just one instance of Broker is runnig.
We would like to optimize the deployment process without a need to change environment architecture.
Thanks again. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Sep 18, 2009 3:59 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Deployment time consumes over half hour what begins to be unacceptable on production. Forking is not an options since a deployment locks configmgr. What can be done about that?
|
How many times a day/week/month are you going to deploy to production?
or is that per Flow (I hope not as it brings back memories of V2.0.1 Ugh, 18hours to deploy inc a restart after every deploy)
does the 30mins indicate the time to deploy ALL the flows and message sets? How often are you going to do everything?
IMHO, this is not excessive and can normally be managed in a planned outage of say 1hour when you need to update production flows etc.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Fri Sep 18, 2009 9:29 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
| Quote: |
Hi
We have active-passive HACMP cluster - just one instance of Broker is runnig.
We would like to optimize the deployment process without a need to change environment architecture. |
How are you failing over the Broker instance to other node in case of failure ?
Cheers,
Aditya |
|
| Back to top |
|
|
| JLRowe |
| Posted: Sat Sep 19, 2009 4:02 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
1) deploy one big bar file per execution group, this will batch the deploy and reduce latency
2) create additional brokers, you can then deploy concurrently
3) only deploy the flows that have changed, you could automate this with the CMP java API and query deploy flow properties to see if a flow has changed
4) perhaps running your broker database locally may help |
|
| Back to top |
|
|
| ranganathan |
| Posted: Mon Sep 21, 2009 2:42 am Post subject: Re: How to improve deployment performance |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
|
| Back to top |
|
|
| bloomy |
| Posted: Mon Sep 21, 2009 10:18 am Post subject: |
|
|
Acolyte
Joined: 11 Feb 2009
Posts: 61
Location: Bloomington, IL USA
|
We have had similar issues with slow connections from toolkit and slow deployment responses.
All these were found out to be due to the configmgr problems with WMB 6102. we had 6103 and it too was not impressive, currently we are on 6104 for both runtime and toolkit, we are not seeing such issues with deployments or connecting from toolkit to configmgr.
Please see the below post where we had a discussion on these issues, please read the whole post and you will find the fixes I applied which solved the problem at the last
http://www.mqseries.net/phpBB2/viewtopic.php?t=48253&postdays=0&postorder=asc&start=15
WMB 7 has no Configuration manager which is a good thing with respect to these problems.  |
|
| Back to top |
|
|
| llaros |
| Posted: Tue Sep 22, 2009 1:29 am Post subject: |
|
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Thanks you for your replies. I will write as soon as we deal with this problem. We could use CMP java API as JLRowe suggested. I didn't know that it is possible to query bar version through that API.
Thanks again. |
|
| Back to top |
|
|
|
|
