[cvsnt] Re: CVS slower after upgrade...

nick.minutello at uk.bnpparibas.com nick.minutello at uk.bnpparibas.com
Thu Nov 25 00:37:10 GMT 2004



>>1. AV 'realtime' scanning (sounds
The scan on access av is disabled on the server.

>>2. Dodgy connection to the PDC/ADC (this wouldn't have such a major
Not sure how i would check for this...

>>3. DNS (affects startup)
We have the 'dont resolve client name' option enabled.... and we get the
problem after connection as the update is progressing...

In fact... if anywhere, I see a big delay at the *end* of the update...

>>4. Broken Hub/Switch on network (rare, but it happens).
We have other networked things on the server that work fine.
And nothing has changed there. Our updrade is our only change.

Anything  else we should check?
A 10-fold increase in update times is pretty big. We must have something
screwed up.


cheers
Nick



Internet
tmh at nodomain.org@cvsnt.org - 24/11/2004 13:03


Sent by:    cvsnt-bounces at cvsnt.org



To:    cvsnt

cc:


Subject:    Re: [cvsnt] Re: CVS slower after upgrade...


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
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
 http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt



This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.




More information about the cvsnt mailing list