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

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

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Sat, 1 Dec 2012 00:36:30 -0500

On Fri, Nov 30, 2012 at 4:54 PM, <cmpilato_at_apache.org> wrote:

> Author: cmpilato
> Date: Fri Nov 30 21:54:35 2012
> New Revision: 1415864
>
> URL: http://svn.apache.org/viewvc?rev=1415864&view=rev
> Log:
> Implement in ra_serf "send-all" mode support for update-style REPORTs
> and their responses. (Currently disabled by compile-time conditionals.)
>
> (This one goes out to Ivan Zhakov.)
>

I've stated for a long time that I think the send-all mode is a huge
mistake architecturally because it is too prone to double-compression and
TCP pipeline stalls and is a tremendous burden on a properly-configured
httpd (by not taking advantage of server-side parallelism), it's nice to
see it's not *too* hard to shoehorn this bad idea back into ra_serf. We'd
never be able to shove the non-send-all approach into ra_neon. =)

Here's my suggestion for consideration - let's experiment with this setting
in the beta release process with the setting as-is - that is we always do
the parallel updates unconditionally (except perhaps when svnrdump is being
stupid). If we get real users complaining about the update during that
cycle, we can then figure out either switching the default and/or adding a
config-option or even allowing some control via capabilities exchange.

Does that sound reasonable? -- justin
Received on 2012-12-01 06:37:08 CET

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.