On Sat, Dec 1, 2012 at 12:36 AM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> On Fri, Nov 30, 2012 at 4:54 PM, <cmpilato_at_apache.org> wrote:
>>
>> Author: cmpilato
>> Date: Fri Nov 30 21:54:35 2012
>> New Revision: 1415864
>>
>> URL: http://svn.apache.org/viewvc?rev=1415864&view=rev
>> Log:
>> Implement in ra_serf "send-all" mode support for update-style REPORTs
>> and their responses. (Currently disabled by compile-time conditionals.)
>>
>> (This one goes out to Ivan Zhakov.)
>
>
> I've stated for a long time that I think the send-all mode is a huge mistake
> architecturally because it is too prone to double-compression and TCP
> pipeline stalls and is a tremendous burden on a properly-configured httpd
> (by not taking advantage of server-side parallelism), it's nice to see it's
> not *too* hard to shoehorn this bad idea back into ra_serf. We'd never be
> able to shove the non-send-all approach into ra_neon. =)
Just to be clear, I do not believe anyone is suggesting we completely
abandon the non-send-all approach. I like that this approach can
offer good performance on a well-configured server as well as enable
new features/ideas such as not even fetching the full-texts that we
already have locally. I think the question is simply what is the best
way to deliver this.
> Here's my suggestion for consideration - let's experiment with this setting
> in the beta release process with the setting as-is - that is we always do
> the parallel updates unconditionally (except perhaps when svnrdump is being
> stupid). If we get real users complaining about the update during that
> cycle, we can then figure out either switching the default and/or adding a
> config-option or even allowing some control via capabilities exchange.
I feel pretty strongly that we should at minimum use the send-all
approach when talking to pre-1.8 servers. Even though in some
situations it could still offer good performance. I just think it
would be more respectful to our users (server admins in this case) to
not change this behavior in a way that could surprise them. Maybe we
could come up with exceptions, such as older servers that are using
the SVNAllowBulkUpdates off directive. In that situation we should
use the new behavior since that is basically what that directive is
asking for.
As I said in another thread, I think we should treat a 1.8 server the
same way and require someone that was upgrading to add some new
directive to enable the new feature. This would allow a server admin
to setup his server correctly, including using things like
mod_deflate, and turn on the new behavior rather than get it
automatically simply because they upgraded their binaries.
This seems like it satisfies everyone. Existing users, especially
those running older server versions, would not be surprised by new and
unwanted client behavior, and it would still be easy to configure a
new server properly to support the non-send-all mode when it was
desired. I just do not see what the downside would be to approaching
it this way.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-12-01 18:00:51 CET