On Thu, Jun 20, 2013 at 9:18 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> Big +1. HTTP protocol options added mostly for debugging purpose, not
>> for regular users.
>
> Of course. I agree.
>
> Note that I didn't ask for adding http-max-connections to the release
> notes. But the skelta-mode and bulk updates behavior are not debugging
> options IMO, they have important user-visible (or admin-visible)
> effects. So I don't think these are just "every single feature or
> toggle".
>
> Remember all the discussions we had during 1.7 and 1.8 development
> about serf increasing the amount of requests and subsequent increase
> of access logs (which was by some considered quite important that we
> at least point admins' attention to it). If this skelta/bulk behavior
> isn't important enough to mention it in the release notes, why did we
> have all those discussions then?
I think it is worth documenting. However, to answer your question,
all of those discussions led to the defaults which are very sane, IMO.
A 1.8 client behaves like a 1.7 client when talking to an older
server. It uses bulk-update mode as the table shows. So that removes
all of those issues and surprises for those server admins. A server
admin that installs 1.8 does "enable" this new behavior unless they
take advantage of the directive that can somewhat turn it off.
BTW, in our new Subversion Edge release we added some new features to
our logging configuration which allows the admin to decide not to log
many of those additional requests. That idea and implementation also
came out of those discussions.
> Until now, I hadn't seen any good overview of the possible config
> knobs and their interactions (also with older servers) regarding the
> skelta/bulk update stuff. Okay, perhaps it's now documented in the svn
> book, but a lot of admins looking to upgrade from 1.7 to 1.8 will
> mainly look at the release notes to find out the important changes. I
> consider this an important change (mainly for the network traffic and
> logging effects that we discussed at length before).
>
> But, as I said: if others consider this too much clutter, or too
> confusing, feel free to revert. I won't lose sleep over it (I already
> have :-).
>
> (though: I think that table that lays out the possible combinations of
> client-side and server-side is great :-). So if this is yanked from
> the release notes, please put it somewhere else where it's
> discoverable by users.)
The only thing I did not like about the documentation is I thought it
was overly negative. You kind of read it and think "why the hell did
they add this feature and why is it on by default?". I really did not
like the strong recommendation about the proxy cache either. I think
that is still unproven. Justin did some tests that I think showed the
cache is used but no one, to my knowledge has done any real testing
and we do not even know how much or how little having one helps or
hurts. One thing is certain, the number of existing customers already
using a proxy cache is 0, since it would not have worked. So to say
those are the only users to use this new feature that is on by default
is crazy.
To me, the main thing an admin needs to be aware of is that a 1.8
client, talking to a 1.8 server will send significantly more requests
to the server. The increased log files is something to be aware of,
but the main concern is probably for some authentication systems. For
example, an LDAP or AD authentication that does not cache the
credentials lookup could really see a change in behavior. If the
admin cannot "fix" those aspects of their configuration, then we have
a directive they can use to mitigate it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-06-20 15:29:41 CEST