hmm ... probably you are right, philip ... i'm now a little clueless.
does somebody of you know/guess, where svn looses speed, resp.
scalability?
possibilities include:
- locking
why lock folders, and not working copy
- http/webdav: too many small connections instead "big" one
- too many files in .svn in general
(the "auth,pwd,user" e.g., gets updated/touched all the time,
and in our case has 350 times the same contents ...)
- too much information in .svn in general
- too many temporary files written and deleted
- files are read more than once
- opening and reading an entries file seems costly
maybe parser is always initialized ...
- somehow strange/slow server operation
btw, microsoft visual source safe has one vss-file per folder. but
you don't notice it the same way in speed/scalability, like you
notice this with svn.
--- Philip Martin <philip@codematters.co.uk> wrote:
> solo turn <soloturn99@yahoo.com> writes:
>
> > these cases were "local", so no proxy, no ssl, no auth files
> touched
> > for an update. in this case it seems to hehave like:
> > - 22 min for 1000 folders (which is excessive imo)
> > - 1.5 min for 1000 files
> > i.e. one folder is 15 times as costly for "svn up" than a file.
>
> Subversion doesn't lock files, it locks directories. Subversion
> doesn't have an entries file for each file, it has one per
> directory.
> So a difference between files and directories is inevitable unless
> someone implements a system that stores working copy metadata in a
> single blob or database. Don't assume that such a system would be
> faster overall :)
>
> --
> Philip Martin
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 7 11:25:05 2003