[cvsnt] Re: cvsnt Vs cvs : Performance!

Tony Hoyle tmh at nodomain.org
Fri Dec 3 12:39:55 GMT 2004

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:
>>>cvsnt is doing more work - cvs does not have access control,
> What access control are we talking about?

Per-file and per-directory inheritable ACLs.

>>>or directory/file rename mapping,
> What is that? Is this to do with handling renames?

Yes.  Every file is mapped from logical-physical on the fly (because of 
the way it's built on old cvs code it's a bit messy at the moment but 
then next stable release will make this much cleaner).

>>>or file-level locking,
> Where does file-level locking come in?

cvs just locks the entire directory (in fact most of the time the entire 
repository) so you get very little concurrency.  cvsnt allows multiple 
concurrent updates by handling the locking per-file.

>>>I get a peak of about 15% for a full update -
> As I mentioned, we are getting a much higher peak than that - 75%. Thats on
> a single-cpu PIII Xeon....
>>>as long as there's unused
>>>CPU that's fine... it's there to be used.
> :-)
> Thats fine for one user.... but when you want 200+ developers using the
> same server... the cpu is there not to be used, but to be shared... :-)

That's the job of the OS, not the application.

A perfectly efficient application would run 100% CPU very quickly.  The 
reason apps don't use 100% CPU is they have to wait for various 
resources - disk, devices, etc.  This slows them down -  an app peaking 
at 5% CPU could theoretically run 20* faster if its bottlnecks could be 

I you ran 5 perfectly efficient apps on a perfect OS they would each use 
20% CPU.  This is only theoretical though - in reality it never happens 
like that.

> Our continuous integration servers also count as quite a large number of
> normal users - given the check frequency

I still don't understand why you're doing this... Just keep an updated 
sandbox updated by postcommit - takes almost no time to setup and maintain.

> But sadly its *significantly* slower than regular cvs and older versions of
> cvsnt.
> When we are talking about 3-4 minute updates.... it becomes a little
> unusable..

Not really.. there's a few % difference but nothing like what you're 
seeing - there must be something else going on.

I regularly use both cvs and cvsnt servers all the time and there really 
isn't a noticable difference in normal use.  I'm always looking at ways 
to speed it up (still far too much going back to the disk etc.) which is 
why cvsnt has had a tencency to get faster with each release these days.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook