[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: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Tue, 8 Mar 2011 17:14:52 +0300

On Tue, Mar 8, 2011 at 17:11, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Mar 8, 2011 at 9:07 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Tue, Mar 8, 2011 at 17:01, John Beranek <john_at_redux.org.uk> wrote:
>>> On 08/03/11 09:34, Ivan Zhakov wrote:
>>>> On Tue, Mar 8, 2011 at 12:21, John Beranek <john_at_redux.org.uk> wrote:
>>>>> On 08/03/11 05:34, Justin Erenkrantz wrote:
>>>>>> On Mon, Mar 7, 2011 at 3:26 PM, John Beranek <john_at_redux.org.uk> wrote:
>>>>>>> Hmm...I'm surprised (and disappointed). No one is interested in
>>>>>>> Subversion 1.7 being lower performance than 1.6?
>>>>>>
>>>>>> You're not telling us something we don't already know (go read the
>>>>>> archives some time).  Many folks are still working on improving the
>>>>>> performance of 1.7...so, general complaints aren't going to be
>>>>>> terribly productive.
>>>>>
>>>>> I think "general complaints" is a bit unfair on me.
>>>>>
>>>>> I posted specific timings using the current trunk code, in case it was
>>>>> news to anyone.
>>>>>
>>>>> I guess from now on I'll just keep my investigations to myself.
>>>>>
>>>> Hi John,
>>>>
>>>> I'm really interested of performance tests especially of ra_serf.
>>>> Performance degradation of svn import over ra_serf looks very strange.
>>>> Could you please provide more details about your configuration?
>>>
>>> OK, I've been a bit more rigorous on my latest ra_serf import tests. So,
>>> on a Fedora 14 x86_64 machine (gcc 4.5.1, APR 1.3.9) I built 1.6.16 with
>>> serf 0.7.1, and trunk(r1078338) with serf 0.7.1.
>>>
>>> I imported the same dataset over HTTP to another server on the LAN. This
>>> server runs Apache 2.2.3 with mod_dav_svn 1.6.15, it is a CentOS 5.5
>>> machine.
>>>
>>> So, the timings:
>>>
>>> 1.6.16 (http-library=neon):
>>> real    0m17.105s
>>> user    0m1.133s
>>> sys     0m1.343s
>>>
>>> trunk (http-library=neon):
>>> real    0m15.881s
>>> user    0m0.968s
>>> sys     0m1.029s
>>>
>>> 1.6.16 (http-library=serf):
>>> real    2m46.610s
>>> user    0m1.277s
>>> sys     0m1.543s
>>>
>>> trunk (http-library=serf):
>>> real    2m45.159s
>>> user    0m1.057s
>>> sys     0m1.169s
>>>
>>> Now, that is looking like a serious problem, rather different to my
>>> previous comparison, which compared a remote ra_neon access to a local
>>> ra_serf access.
>>>
>> Yes, it looks like a serious problem. May I ask you to try build
>> Subversion trunk with serf trunk [1] and repeat your tests?
>>
>> [1] http://serf.googlecode.com/svn/trunk/
>
> Don't the tests show that trunk is slightly faster than 1.6?  It seems
> like the main thing it shows is that when working with a HTTPv1
> server, ra_serf is significantly slower than ra_neon for svn import
> (both in 1.6 and trunk).
>
I don't think that this performance degradation is related to HTTPv1
or HTTPv2. Looking to the source code ra_serf should faster for most
operations except checkout/update/export. It seems something broken in
serf/ra_serf in John's environment.

-- 
Ivan Zhakov
Received on 2011-03-08 15:15:44 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.