[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: DAV is complicated and slow?

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2005-11-24 15:03:29 CET

Greg Stein wrote:
> On Wed, Nov 23, 2005 at 08:51:48AM -0800, Garrett Rooney wrote:
>
>>On 23 Nov 2005 09:21:12 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
>>
>>>Greg Hudson <ghudson@MIT.EDU> writes:
>>>
>>>>We already have the performance benefit of HTTP pipelining (at the
>>>>expense of giving up on generic HTTP caching), and ra_dav is still much
>>>>slower than ra_svn.
>
>
> And will always be slower. Can't do much better than a custom,
> application-specific protocol. No argument there.
>
> I've been talking about simplifying the system and improving the
> overall capacity through caches. We can use normal GET requests and
> PROPFIND and whatnot rather than custom reports.

While that may be the case, doing many GET operations, even in pipelined
connections does increase server load during non-cached operations.
(Or if there is no cache between you and the server) Many places are
using HTTP/DAV SVN internally and are getting very good (or at least
very reasonable) performance without killing the server. Going to
back to the GET method may well undo that.

However, I am all for not using XML (and thus BASE64 encoding) when
the server and client can agree on the format. This would be a reasonably
big win for some repositories (and maybe even many repositories)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 24 15:06:57 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.