Scalability Testing This Week (was: Re: Repos corruption continued)

[tn...@lexmark.com]

Hi Ben:

I have been monitoring the users list for a few weeks now.  We are working
on a revamp of our SCM capabilities, and are planning to wrap our process
on top of Subversion, for deployment in the 2Q04 time frame.

Management has asked repeatedly what the "robustness" of Subversion is for
our application.  The big issue from my perspective is that I have about
120 developers in Lexington, and will have upwards of 50 "off shore"
comming in over a WAN.  (luckilly, 12 hour time difference, so not all at
the same time).

So, I was wondering if you and the folks doing scalability testing this
week are planning on concurrent user scalability testing.   i.e., what
happens when 120 people (or 500) are banging in lots of commits
"simultaneously".  I am being asked if it will hold up, and I don't know
what to say, yet.

Also, I'm soliciting opinions on how concerned I should be about all the
buzz re: repository corruption.  I have 3 code bases.  One is about 30,000
files, one is about 10,000 files, and one is about 2000 files.  (These are
'C' and C++ sources and headers, makefiles, perl scripts, etc, used to
cross compile code for embedded cards in our printers).

Best Regards,
Tim Noell




Ben Collins-Sussman <su...@collab.net>@collab.net on 10/10/2003 08:38:17
AM

Sent by:    sussman@collab.net


To:    "Jan Hendrik" <ja...@bigfoot.com>
cc:    users@subversion.tigris.org
Subject:    Re: Repos corruption continued


"Jan Hendrik" <ja...@bigfoot.com> writes:

> At least from following the list I got the impression that SVN is
> perhaps not particularly happy with large imports/commits. It
> seems to me that irrespective of the system there are latent
> problems. Not with the final size of the repos or the number of files,
> but with commits.

Well, yes, we have heard of "latent problems with commits", but none
of the developers seems able to reproduce them yet.

However, a bunch of us have started scalability tests this week.
Maybe we'll reveal something.  For example, yesterday I started doing
repeated imports of the mozilla source tree (340M, 42k files), looking
for problems.  The only problem we found was a memory leak, no
timeout problems.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Scalability Testing This Week (was: Re: Repos corruption continued)

[Mike Mason <mg...@thoughtworks.net>]

C. Michael Pilato wrote:

>
>>Also, I'm soliciting opinions on how concerned I should be about all the
>>buzz re: repository corruption.  I have 3 code bases.  One is about 30,000
>>files, one is about 10,000 files, and one is about 2000 files.  (These are
>>'C' and C++ sources and headers, makefiles, perl scripts, etc, used to
>>cross compile code for embedded cards in our printers).
>>    
>>
>
>To this, I dunno what to say.  Subversion has been hosting its own
>source code for years now, with (thank you, God) not a single case of
>repository corruption.  In all the previous scalability testing I've
>performed, I've never been able to corrupt a Subversion repository.
>  
>
I've got 6 developers working on an 8,000 file repository, merging 
changes from another (bigger) team so regularly changing several hundred 
files. Never had any corruption problems, never had any performance 
problems. I realise this isn't 120 users and 30,000 files, but it 
definitely signals to me that Subversion pretty much works. I'd trust it 
as much as CVS, and more than VSS or StarTeam, but less than Perforce 
(which rocks, but costs money).

The only problem I've had is the Windows client "access denied" 
problems, but there's a workaround being put into place for that.

Cheers,
Mike.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Scalability Testing This Week (was: Re: Repos corruption continued)

[kf...@collab.net]

mark benedetto king <mb...@lowlatency.com> writes:
> I think that in practice this is reasonably unlikely; you'd have to
> be crazy to have 120 people working on the same files at the same time.
> However, the bubble-up nature of directory versioning may exacerbate
> this problem.

Directory bubble-up in Subversion does not affect whether or not
people get out-of-date errors on commits (except that a directory must
be updated to head before you set a property on the directory itself,
but that's not particularly common).

> It would certainly be interesting to hear how well the *model* scales,
> as opposed to the *software*.

Should scale the same as CVS's model, since it's the same :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Scalability Testing This Week (was: Re: Repos corruption continued)

[mark benedetto king <mb...@lowlatency.com>]

On Fri, Oct 10, 2003 at 10:49:01AM -0500, C. Michael Pilato wrote:
> tnoell@lexmark.com writes:
> 
> > So, I was wondering if you and the folks doing scalability testing this
> > week are planning on concurrent user scalability testing.   i.e., what
> > happens when 120 people (or 500) are banging in lots of commits
> > "simultaneously".  I am being asked if it will hold up, and I don't know
> > what to say, yet.
> 
> Yes, part of our testing will involve concurrency.  I should note,
> though, that if all 120 of your developers are committing at the same
> time -- well, you might consider blanket pay raises for the
> Engineering department! :-)
> 

One potential issue is the "up to date" check at commit time.   If your
120 people are banging in lots of commits, there is a potential for some
amount of starvation; if you're never up to date, you can never commit.

I think that in practice this is reasonably unlikely; you'd have to
be crazy to have 120 people working on the same files at the same time.
However, the bubble-up nature of directory versioning may exacerbate
this problem.

It would certainly be interesting to hear how well the *model* scales,
as opposed to the *software*.

For Very Large Software Projects, features like ClearCase's "winking"
of derived objects and it's notion of "LATEST" configurations may
justify the enormous software and management expense.

--ben


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Scalability Testing This Week (was: Re: Repos corruption continued)

["C. Michael Pilato" <cm...@collab.net>]

tnoell@lexmark.com writes:

> So, I was wondering if you and the folks doing scalability testing this
> week are planning on concurrent user scalability testing.   i.e., what
> happens when 120 people (or 500) are banging in lots of commits
> "simultaneously".  I am being asked if it will hold up, and I don't know
> what to say, yet.

Yes, part of our testing will involve concurrency.  I should note,
though, that if all 120 of your developers are committing at the same
time -- well, you might consider blanket pay raises for the
Engineering department! :-)

> Also, I'm soliciting opinions on how concerned I should be about all the
> buzz re: repository corruption.  I have 3 code bases.  One is about 30,000
> files, one is about 10,000 files, and one is about 2000 files.  (These are
> 'C' and C++ sources and headers, makefiles, perl scripts, etc, used to
> cross compile code for embedded cards in our printers).

To this, I dunno what to say.  Subversion has been hosting its own
source code for years now, with (thank you, God) not a single case of
repository corruption.  In all the previous scalability testing I've
performed, I've never been able to corrupt a Subversion repository.
And yet we get these reports...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org