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

Re: Tri-state for http-detect-chunking config option

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 12 Jul 2013 11:53:27 +0200

On Thu, Jul 11, 2013 at 10:15:34PM -0400, Greg Stein wrote:
> That leaves the 1.8.1 release. There are several possibilities here:

My opinion is:

We've switched from neon to serf. Serf needs chunked requests
for some future features, neon didn't. That's fine, but serf should
send an extra request to keep working with server configurations that
worked fine with neon. Because if it doesn't work out of the box,
that's a *regression* from neon. Tough, we don't get around that,
no matter how much the extra requests annoy us from a performance
standpoint. It would have been nice to use chunked-requests without
probing, but the internet is a rough place, and regressions are bad.

Going forward, we can tweak Subversion to amortize the cost of this
new extra request. For example, 1.8 already has patches to avoid
some RA requests in specific situations, so it is already faster than
1.7 in some cases. We could make more such fixes and backport them.

And there have already suggestions for further improvements to make
auto-detection cheaper in 1.9. So, eventually, the performance of serf
will improve because it can probe more efficiently. In my mind,
that's a performance improvement that does not cause a regression,
so that's fine.

So I think we should just accept the penalty of an extra request in 1.8.
And perhaps have a knob to turn auto-detection off if users really care
about a bit of extra latency.

On a personal note, I think it's hilarious that you're advertising
for a config knob to be added, and I'm advertising against it. I usually
find myself on the other side of that conversation with you :)
Received on 2013-07-12 11:54:06 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.