On Thu, Jul 11, 2013 at 7:15 PM, Greg Stein <gstein_at_gmail.com> wrote:
> My current concern with the tri-state is people who set "=no". They
> will permanently degrade to C-L requests. That is problematic today,
> and especially as ra_serf advances. If the server admin upgrades to a
> chunked-enabled proxy, the client would still be in suckage-land.
>
> Further: consider if a client is thrown down in the C-L pit, then
> hey.. why NOT throw in some dynamic detection? Can't hurt them much
> more, so go ahead and detect.
The whole purpose of the tristate is to allow the following sort of
configurations
[groups]
nochunks = badadmin.example.com
chunks = gooddadmin.example.com
[globa]
httpd-chunked-requests=auto
[nochunks]
httpd-chunked-requests=no
[chunks]
httpd-chunked-requests=yes
This helps the following groups of users:
1) Average User: They leave their configuration completely at default.
They are able to talk to every Subversion server. They have a
reasonable latency to the server, they never even notice the delay
added by the check.
2) Power User: This guy tweaks his configuration highly. He knows
what all the options do and makes sure they are set to optimal values.
He gets maximal performance possible no matter what the server on the
other end is doing.
3) Admin That Centrally Controls Client Config: This site is
controlling the configuration used by their users, maybe they're using
auto-props. They know they what their servers are capable of and set
a group for those servers with the proper value. They also don't want
their users who might use checkout code from open source projects to
break, so they leave the global default to auto.
4) Super Slow Connection: This user is using a satellite link to reach
the Internet. Their latency is really high. They find the delay
added by the automatic check unacceptable. So they set their default
to yes and add specific entries for any site they run into that needs
no.
Everyone is happy. The Average User stays blissfully unaware,
everyone else gets a configuration they find most acceptable.
> I believe the bigger point with tri-state is the change of the
> *default* from "assumed chunked-request capability" to "perform
> detection".
>
> For 1.9.x, I would be +1 on a default of "perform detection" because I
> know that with a bit of effort, that detection could be performed with
> the "next request" after the original OPTIONS negotiation request.
> That's some work that is absolutely not backportable, if we want to do
> it right. I can easily see a situation where 1.9.x would auto-detect
> capability and never need to send an additional OPTIONS probe. The
> easy path is to send, but we *can* reach a point where we don't have
> to.
>
> So let's just say that 1.9.x will *always* auto-detect because the
> typical cost is "near zero". We don't even need an option. So whatever
> is in trunk today would just disappear (or we could keep it for expert
> users to improve perf a smidgen).
I really don't understand how you can say this AND object to the no
value in the tristate. You say they'll be stuck in a permanent
degraded state, but at the same time you suggest you believe we'll get
to the point that there is no overhead at all in detecting. If that's
the case then we simply remove the option entirely in 1.9.x and users
who have set themselves to no will have the best of all worlds when
they upgrade to 1.9.x. So why exactly would we deny the users who
might want to use no for now for some specific purpose the ability to
do so? If we really go down the path you're laying out here user's
will never end up with permanently degraded performance.
Based on your suggested method and the one that Branko made on IRC
earlier today (pipelining two requests one with and one without
chunking on the first request you'd use chunking with), I can see a
point where we see no reason to have a knob at all. Ultimately this
is where I want to see us get. But like you I don't think we'll get
there in 1.8.x.
> That leaves the 1.8.1 release. There are several possibilities here:
>
> 1) stick to the current trunk/backport implementation: users should
> tweak a config knob or get the repos to upgrade their proxy
>
> 2) switch the (current) knob to default=on. users eat a bit of request
> cost, experts can kill that off.
>
> 3) switch to tri-state for full control. no cost to users (w.r.t
> on/off chunked capability), or a bit in the "auto/default" state to
> perform detection.
>
> This seems to be the current set of possibilities. Any others??
Only ones that I think will not gain a consensus, so no point in
pointing them out.
> Personally, my thoughts related to the above actions:
>
> 1) +1. default is "off" for 1.8.x. becomes "on" for 1.9.x since we can
> make detection very cheap. (while I like this, not sure if a default
> change is advisable?)
-0.8 on this. I don't think our users should have to worry about
this, I'd prefer no option at all, but it's clear that there is too
much cost to the detection at current to avoid it entirely. I won't
veto it if this is what our consensus really is, but I think it's
wrong.
> 2) +0. the extra request is a perf regression. (and while I like
> breser's test, I think the test suite is not a good vehicle for this
> kind of test)
+0.5 on this. This leaves some users without a path to the best
performance they can get. While for most users I don't think the
detection is going to be noticeable, users with particularly slow
connections that must also talk to servers with these proxies will be
hit hard. Sadly, if these users can't convince the admin to fix the
proxy, they will be really stuck. Granted, these users are probably
already suffering even without the detection. I'd be fully for this
if our detection scheme had a fixed cost, but it has a variable cost
based on something we have no control over.
> 3) -something. I don't like the "no" option. Moving towards the
> future, I think the *typical* detection overhead will be so small,
> that we barely need the config knob, let alone a setting that can be
> Bad if set inappropriately.
+1. See above.
> Note: my request to apply the -9117 group is still there. It needs to
> be applied for any of three options. Please update STATUS.
I'm getting there...
Received on 2013-07-12 08:09:10 CEST