sussman_at_gmail.com wrote on 10/29/2009 04:11:21 PM:
> It's probably just the logic in the ra_dav or ra_serf client network
> module, enforcing proper webdav (and svn?) semantics. Every path
> modified/deleted/added in a commit is a whole separate request. For
> 'adds', the client is likely doing an existence check: does the path
> already exist? If so, fail the commit (the client is out of date).
> Most of the time the answer is "404", i.e. "no, it doesn't exist, so
> go ahead and PUT the file".) If this existence check didn't happen,
> then there's a risk of the PUT simply overwriting an existing object.
>
> Honestly, though: if you're worried about svn's performance over
> HTTP, stop using HTTP. It's a lost battle. HTTP is stateless, slow,
> and WebDAV is really complicated. We already rewrote it to use 30%
> fewer requests earlier this year, and I doubt it can get much leaner.
>
> If you want speed, you'll get an order-of-magnitude speedup by
> switching to svn:// instead of http://.
In my testing, I've seen very little (if any) performance difference
between svn:// and http://... (Both wan and lan links, both large
and small transactions). Possibly I'm doing something wrong, or
possibly it is an artifact of our network topology. I was even
giving svnserve an advantage by not using any authentication in
my tests...
Until recently, the lack of logging in svnserve was a show stopper.
I'd also need to get kerberos authentication setup with
both windows and solaris servers under svnserve. Might be
a real challenge on the windows server.
I'd gladly move to svn:// (or at least support both) if I can
find raw data to validate the performance claims.
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412853
Received on 2009-10-30 00:00:06 CET