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.
>
> 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?
Naive question perhaps, and it may have been answered before (but with
these extremely long threads, I've lost track a bit):
Can someone explain again why ra_serf / serf can't just resend
requests, with C-L, whenever it has received a 411? So (after we know
it's HTTP/1.1) send every request optimistically assuming chunked
encoding, and fallback whenever we get a 411 (and perhaps remember the
fallback, so we downgrade that entire connection / session).
Why is that not possible? Is it because (a) it's too hard to implement
(lots of code paths all over the place), (b) we can't resend requests
because we don't have them available in the right place anymore after
sending, (c) it would potentially break some ordering things (really?
why?), (d) it would require serf 1.4 anyway, or (e) something else?
It seems to me that, if this were possible, that would be the perfect
solution (until serf 1.4 comes around perhaps). It would give no
performance penalty to the 99% ("optimistic chunking"), and we
downgrade transparently for the 1% (at some limited cost).
--
Johan
Received on 2013-07-10 13:13:39 CEST