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.
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