On Tue, Jul 9, 2013 at 7:33 PM, Ben Reser <ben_at_reser.org> wrote:
> 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.
First: I prefer the solution currently merged to the 1.8.1 branch
(fail first, tell the user to change the busted-proxy option, then
automatically detect), because of two advantages over your proposed
solution:
a. It doesn't impact those users that have no 'busted' proxies between
them and their repositories.
b. It gives a sign that a busted or at the minimum less optimal proxy
is being used. We have seen over the last week that the latest
versions of the nginx proxy support chunked encoding for requests
without problems, and that sometimes it's just a question of reporting
this issue for an admin to take action.
Second: The basic decision to take here is if we want to give all
users a transparent solution to connect to any svn server, whatever
proxy being used. Do we want to bother a user with such technical
details as busted proxies?
Personally I can live with that, given that svn 1.8.1-branch now has a
simple workaround and is (reasonably) clear in its communication about
it with the 411 error message.
Now, if there's consensus between svn devs that the highest priority
for the solution is transparency for the user then I'll accept that,
at least for the 1.8.x line.
> 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?
Suppose that this is the consensus, then honestly I don't see a reason
why we would add the http-chunked-requests option.
Auto we don't need because that's what's implemented, and we can
always change that even without option. Yes and No will probably used
by no one expect for the few people that have followed this
discussion. Then I rather have no option at all, ra_serf now already
has too many different combinations in which it can be used
(http/https,v1/v2,bulk,authn,http1.0/1.1,chunked encoding,...) for us
to test and support.
Lieven
Received on 2013-07-10 00:51:40 CEST