[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion trunk (r1078338) HTTP(/WC?) performance problems?

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 10 Mar 2011 08:31:23 -0600

On Thu, Mar 10, 2011 at 6:24 AM, John Beranek <john_at_redux.org.uk> wrote:
> On 10/03/11 06:34, Ivan Zhakov wrote:
>> On Thu, Mar 10, 2011 at 01:23, John Beranek <john_at_redux.org.uk> wrote:
>>> On 09/03/2011 20:17, Ivan Zhakov wrote:
>>>> On Tue, Mar 8, 2011 at 22:07, Greg Stein <gstein_at_gmail.com> wrote:
>>>>> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>>>>> ...
>>>>>> It seems I found reason why ra_serf is slower than ra_neon. ra_serf
>>>>>> sends CHECKOUT request for _each_ folder and file that being imported,
>>>>>> while ra_neon perform it only for root directory. Maybe DAV experts
>>>>>> can answer which behavior is correct: should WebDAV client CHECKOUT
>>>>>> each resource being modified or it's fine to CHECKOUT only the root of
>>>>>> commit operation?
>>>>> There is no other WebDAV server to talk to, besides our own. That is
>>>>> one of the primary rationales behind the HTTPv2 effort: recognizing
>>>>> reality, rather than living in an theoretical world.
>>>>> Thus, if Neon's approach works with our server, then ra_serf can go
>>>>> ahead and use that approach, too.
>>>> Hi Greg,
>>>> My investigations was wrong: actually ra_neon doesn't send CHECKOUT
>>>> request only for sub-directories and file of directories being added
>>>> in the same commit. We still have to CHECKOUT directories when using
>>>> HTTPv1 to provide baseline.
>>>> Anyway I've implemented ra_neon's approach in r1079967.
>>>> John,
>>>> Could you please provide timings of 'svn import' with updated
>>>> Subversion trunk and Serf trunk?
>>> Apparently fixed!
>>> To a remote 1.6.15 server:
>>> ra_serf: 18 seconds
>>> ra_neon: 16 seconds
>> I see that ra_serf still little bit slower than ra_neon.
> OK, so I:
> * Changed my benchmark took to allow the test to be reported N times,
> and moved to microsecond timers.
> * Set up a fresh repository on a 1.6.15 server, with no post-commit
> triggers.
> So, with 10 iterations:
>  ra_neon: 16.01
>  ra_serf: 15.94

Having only tangentially followed this thread, I've got a couple of questions:
 * Do the current subversion+serf fixes solve the the large checkout
time problem people have been seeing on trunk?
 * What other scenarios should we be timing/testing?

John, you've been a great help in identifying and testing this. Any
chance you could run similar timing comparisons on other Subversion
operations and report the results? :)

Received on 2011-03-10 15:31:52 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.