Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
nick.minutello at uk.bnpparibas.com wrote: > We are talking about command-line updates (for the same module) going from > 20 seconds to 3 minutes as a result of our upgrade! It's pretty much always one of: 1. AV 'realtime' scanning (sounds like a prime candidate from those figures) 2. Dodgy connection to the PDC/ADC (this wouldn't have such a major effect though... it would slow certain operations) 3. DNS (affects startup) 4. Broken Hub/Switch on network (rare, but it happens). > We have had *more* CruiseControl instances running every 60s against > regular cvs on linux and had no perf problems at all (hence my other > questions on linux vs windows perf / cvs vs cvsnt perf) Linux is far better at managing that kind of situation, in my experience - it's much fairer in the way it hands out CPU time. >>>Make sure you're using lockserver which will reduce the locking hits >>>(that's not a cure though). > > I thought that was the default on cvsnt 2.x > We have the lock server running. Is there something else we need to do? It should be OK if you've not disabled it. > We have to have them running more frequent than that. We do a full > build/test every time there is a checkin (we know within minutes of > breaking the build/tests) Why not do the update on postcommit? Polling like that is really inneficient unless you really are committing major updates every few seconds. > We can take steps to reduce the cruisecontrol load - but I have to come up > with an answer why the perf dropped so dramatically after our upgrade. There will probably be differences but I wouldn't expect them to be too bad... maybe noticeable if you jump suddenly from one to the other. Tony