On Thu, Jul 11, 2013 at 7:15 PM, Greg Stein <gst...@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...
