On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote:
>> The option doesn't seem like a big barrier when you're applying it to
>> a handful of machines for yourself. Scale that effort up to a user
>> base of 20,000 users and the option stops looking like a reasonable
>> response. Resolving the proxy may not be possible in those cases as
>> well because the developers and the people running the Subversion
>> servers may have absolutely no control over the proxies. They may be
>> proprietary and not even have a way to resolve this. If you're a
>> large enterprise this solution just flat out doesn't help you much.
>
> I think this is a very important point.
>
> How many people use auto-props? Not many. Still, having auto-props
> configured at the client side made configuring this feature correctly
> in large deployments very inconvenient. Until 1.8 it requried central
> control over every client configuration. This was a concern in several
> companies I've visited.
>
> How many people are using proxies that don't support chunked requests?
> Probably not many. But the same argument applies.
>
>> I agree that chunked requests are very good for us. But I want to do
>> it in a way that is maximally compatible without making our users jump
>> through hoops.
>
> +1
>
> With so many other performance issues being fixed all the time,
> I don't think we should be worried about one extra request.
> We should be able to get the time spent on this extra request back
> somewhere else.
>
> 'svn merge' in 1.8 opens more connections that 1.7 did, and that is
> a performance hit but it didn't prevent the 1.8 release either.
So we had a conversation on IRC this morning about solutions.
This is what several of us seemed to agree was a reasonable compromise:
Have a tri-state option called http-chunked-requests. It would have
three states:
auto = Run the extra OPTIONS request and detect if chunked requests is
supported or not.
yes = Assume that HTTP/1.1 servers have chunked requests support (our
1.8.0 default behavior) and always use it against HTTP/1.1 servers.
no = Never use chunked requests.
With the default being auto.
This provides us a lot of flexibility in handling this. With a
tri-state we can reasonably change the default behavior if the proxy
environment changes or we find the auto detection to be too costly in
the wild. If we find a better way of automatically handling this we
can change what auto does.
This avoids the need for users to set an option in order to
interoperate, but users that want maximum performance can set it to
yes (assuming they don't have such a proxy in line).
Thoughts?
Received on 2013-07-09 19:34:21 CEST