I am currently looking into this issue. It seems like there is
somewhat of an inherent slowness with WebDAV/DeltaV because of the
amount of requests and the format in which they return data. The
gigabytes of data do seem odd though.
I think that it will always be slow to a certain extent, but there
should be ways to improve it. One current issue is that mod_dav_svn
(the apache module part of the subversion server). Is taking it's
sweet time to answer certain requests that involve many different
elements.
Here is a simple example of a dav request - note that this is running
in a debugger, in a VM so the times are simply examples:
1. There are a couple requests going to the server to resolve the
proper folder (5 seconds of chatter).
2. Then the "proper" dav request is made that will list a folder.
(mod_dav_svn takes 10 seconds to reply).
3. The folder listing is sent back to the client. (23 seconds of
active network traffic).
The parts that could be reasonably cut down would be 1 and 2. There is
unfortunatly no simple solution for #3. There is alot of data being
sent back. In your specific case given that you are effectively doing
a ton of lists (-R), the amount of data likely comes from #3. If you
could send me an ethereal log (assuming your stuff isn't too private)
I could confirm this for you.
Regards,
Jean-Marc
On 8/20/05, Tobias Ringström <tobias@ringstrom.mine.nu> wrote:
> Ben Collins-Sussman wrote:
>
> > This is one of many situations where "being a DAV client" is hurting
> > the svn client's performance. In DAV-land, the proper way to get a
> > list of children in a collection (directory) is to do a depth-1
> > PROPFIND. This has the unfortunate side effect of not just listing
> > all children, but also all of their properties -- both user-generated
> > and server-generated ones. All in XML.
> >
> > If we were to just say "forget it, the svn client isn't a DAV client"
> > (which has been discussed before), we could make up yet another
> > custom protocol response/request that only svn and mod_dav_svn would
> > understand. We're already doing that in many places where subversion
> > concepts don't line up with WebDAV/DeltaV. Doing it for the sake of
> > performance gains would be a new policy. I don't think everyone is
> > (yet) in agreement yet about this.
>
> Anyone who's interested in making 'svn ls' faster over http should take
> a look at issue 2151.
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2151
>
> In this case, I'd say it's more a problem of how we use DAV, than a
> problem with DAV itself.
>
> /Tobias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 21 08:49:47 2005