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

Re: svn commit: r1348131 - /subversion/trunk/subversion/libsvn_ra_serf/update.c

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Mon, 11 Jun 2012 03:15:52 -0700

I am not against server-side changes - but, I want to have evidence backing
up that Depth 1 (which should work on older servers) is significantly
slower than modifying the report. If we do get all props with the REPORT
response, we are going to have to do tricks on the client side as we can't
process properties until we open the file through the editor drive much
later on. So, we may give back some of the performance that way when we
get all of the WC props up front. -- justin
On Jun 11, 2012 10:58 AM, "Ivan Zhakov" <ivan_at_visualsvn.com> wrote:

> On Sun, Jun 10, 2012 at 9:19 AM, Justin Erenkrantz
> <justin_at_erenkrantz.com> wrote:
> > On Friday, June 8, 2012, C. Michael Pilato wrote:
> >>
> >> On 06/08/2012 03:15 PM, Ivan Zhakov wrote:
> >> > Wow, but performance will be much more interesting if we inline
> >> > properties to REPORT response. Mike, could you please share your
> >> > incomplete patch for including properties to REPORT response?
> >>
> >> Sure. Attached.
> >
> >
> > I would still prefer the PROPFIND Depth 1 strategy as that won't be
> > dependent upon a server upgrade.
> >
> Well, I still prefer the Mike's inlined properties approach to be
> implemented. May be we can implemented PROPFIND Depth 1 approach as an
> *addition* to support pre-1.8 servers.
>
> My arguments are:
> 1. We already made performance improvements that works only with newer
> servers. Like HTTPv2. See also Greg's "upgrade your server" reply [1]
>
> 2. Note that PROPFIND request for *all* properties is slow on server
> side, because of mod_dav API: mod_dav module asks mod_dav_svn for each
> property one by one. On each call mod_dav_svn reads all properties
> from disk, parses it return only one. Things getting worse with Depth
> 1, because *all* XML response stored in memory before sending it to
> the client.
>
> 3. As Mike noted we already send properties inlined for modified nodes
> even in non-skelta mode. It makes sense to include them in
> file/directory addition.
>
> 4. Properties are relatively small, while directory can contain a lot of
> files.
>
> [1]
> http://groups.google.com/group/subversion-development/msg/b8271785dc17f62c
>
> Also I think that we should implemented new optimized REPORT response
> for editor v2 but this is different story.
>
> > At the least, this patch will give us a ballpark figure to shoot for in
> > reducing the per-file PROPFINDs...maybe we ought to implement both
> > techniques, but I think Depth 1 will bring us pretty close and not
> require
> > server changes...I expect the delta in perf between these two won't be
> > huge...we can always do a bake-off! -- justin
> I don't understand why you trying to avoid server-side changes? We
> made HTTPv2 protocol in the past and added some new compatibilities.
>
> --
> Ivan Zhakov
>
Received on 2012-06-11 12:16:25 CEST

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.