[ changing subject to make topic more visible]
On Sat, Dec 1, 2012 at 9:00 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
Completely agree.
My point was that in theory skelta-mode is cool, but it still needs a
lot of work to get it really done. So let's release ra_serf by
piecemeal, because we also have significant amount of ra_serf issues
unrelated to update editor.
>
>> 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.
>
+1.
--
Ivan Zhakov
Received on 2012-12-01 22:19:20 CET