Package Build OPtimization

Hello,

I am looking for steps to optimize package build, I have tried make sure no antiviruses running and the package build i s done on the deployment server. What else can be done to optimize this. Can some one share his or her experince here

Appreciate any helpful comments

Re: Package Build Optimization

One of the best ways to improve the package build performance is to setup a high-speed link between your enterprise server and deployment server. For instance, if you run 100mbps try installing a 1gbps link between the two machines. The package build is a network intensive operation. Therefore you will get more bang for your buck by optimizing the network over say processing power.

If you have ample processing power, (and you haven't already tried this), enabling the simultaneous busbuild option usually improves performace on the client package build as well.

You do not specify what platform you are running. If you are running on an AS400, it helps to configure your JOBQ for deployments as multi-thread.

We are on Win Nt SQL plat form

Depending on the specs of your deployment server and to a large extent on the network connection between the build box (I am assuming the dep server), the database server, and the enterprise server your full package should take about 2-3 hours for the client portion and 1-1.5 hours for the server portion.

Go with the fastest NIC's you can (1Gbps).
Ensure that the duplex settings on the NICS agree or are autonegotiate.
Ensure the boxes are on the same LAN switch.

I have found that the network configuration makes the most biggest difference.

Check your Anti-Virus.
Just choosing disable from an icon does not actually stop the service(s).
Also, "when" you choose to run the package build can help, by not running during a busy workday, try evenings or weekends. Definitely don't run your build during backup periods or large data extracts (Cognos). There is so much I/O going on it will really slow you down.

I'm going to have to agree with the NIC recommendation. We saw a 50% drop in overall package build time simply by replacing a 100Mb NIC (operating at 100/Full Duplex) with a fiber based GigE card. You need to look at cutting down on latency during the package build process. Updating statistics on all of the CO tables can help if that hasn't been done in some time. Also, placing the tablespaces on disk subsystems that can deliver optimal read performance is another thing to look at. Obviously NAS storage for Central Objects usually isn't the way to go for quick package build times.

Running a full package on a fat client as opposed to the deployment server can also slow things down somewhat. It just depends on how your server is configured (i.e. optimized for applications or file serving) and whether or not your fat client has the same speed connection as the server hosting the Central Objects datasource and your deployment server. Best bet is to have the database and deployment servers on the same subnet, same switch if possible and setup with the same speed network interfaces. It might even be a good idea to use the same make and model cards on a network switch known to work well with the NIC hardware. I've heard of issues with certain Broadcom chips not playing well with Cisco switches, but 3COM works great. Same goes for other vendors and 3COM switches, so it isn't a Cisco problem. I read an article the other day about the dirty secrets behind GigE driver implementations, so be warned that "your mileage may vary".

Try defragmenting your deployment server drives where you've installed the application. As others have said, turning off AV software and realtime scanning agents can speed things up tremendously. Making sure your deployment server drives are also up to snuff as far as high performance read/write operations is also a good idea. A fast caching RAID adapter can help somewhat.