[cvsnt] Stress Tests results for CVSNT/CVS/Subversion

Tony Hoyle tony.hoyle at march-hare.com
Tue Feb 14 22:39:57 GMT 2006


Rahul Bhargava wrote:
  > That was a typo.  He replied to the wrong email :-), sorry about it. 
The
> details that Arthur asked for
> have already been posted to this forum, so you should have gotten them.

You said what platform you were using but not what you were doing to 
cause the load.

I ran a script all day today (approx. 6 hours in total) with 100 
simultaneous users doing rlog w/ a random sleep (so there was a certain 
amount of overlap - it peaked at about 190 processes)... the system 
remained responsive and the lockserver never got above 0% (CVSNT 
processes were about 7% each using 9MB memory). It wasn't the most 
sophisticated script in the world but proves to me there's no general 
problem with rlog.

If you have found a load pattern that causes problems I'm going to have 
to see the script you used, or a fairly detailed description of it at 
least, otherwise it's just your word against ours, and we can't repeat it.

> In prior posts you and Arthur seemed to say that the version we ran the 
> tests was "rejected
> for commercial customers". If I could get a stable version# from you, we 
> could go back and run
> the tests. If there are no issues with it then we can just recommend 
> that to our customers using
> WANdisco with CVSNT. There would be no need to debug etc if its just a 
> build issue. You also stated
> you ran stress tests on some build of 2.5..01 ?  Are those stress tests 
> not part of the CVSNT src base ?

No they're cooked up to stress particular problems.  In the 2.5.01 era 
lockserver load was an issue (eventually the cause turned out that 
stricmp is about 100* slower than strcmp).  In general we rely on 
feedback from real world installations... apart from an issue with large 
binary files (partly caused by the way things are stored in RCS 
unfortunately.. to be fixed by 3.x when there will be more efficient 
storage) it takes a lot to stress a cvsnt server to breaking point.

Issues we *have* found are things like antivirus affecting the socket 
closedown and causing a lot of connections to be held open - which 
effectively causes a buildup of running cvs executables on the server. 
That can't be solved (AFAIK) by the executable itself.

The opensource and commercial releases are mostly separate (the 
cvsnt.org domain, servers and list are owned and paid for by my own 
money and not run by march hare).  This list covers the opensource 
releases, in which case I'd recommend using the latest testing release 
(which is a stable release candidate) for a fast turnaround of bug fixes.

Commercial customers use the latest commercial stable by march hare, as 
that is what they support (currently a 2.5.02 version.. would need to 
check which build).  Arthur generally can't help with any other version 
as that's march hare policy (keeps support manageable).  I know he's big 
on pushing companies to use the commercially supported releases and 
that's what he's good at.  If you're supporting commercial customers 
that's the way we would prefer you go.

The current testing release is an RC with a known problem with cluster 
authentication (which *might* be fixed in CVS already but needs some 
testing first).

New development is shifting to 2.6.x, which is a new core (with its own 
set of bugs).  If you want to submit patches for that then feel free - 
in general cvsnt patch policy is it goes in if it's useful to a 
reasonable number of people and doesn't break anything.  However since 
2.5.x development is slowing down I'm a lot more wary of introducing 
patches to that.

No patches will usually be considered without some discussion on this 
list first - closed email discussions are historically unproductive (of 
course if it's an obvious fix/improvement it'll probably get in anyway - 
however I still prefer it to go via the list so it's in the public 
record).  If everyone agrees on a patch it usually gets in quite quickly 
though.

Tony



More information about the cvsnt mailing list