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

Re: merge very slow

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Sun, 15 Jun 2008 18:38:29 +0200

Ivan Zhakov wrote:
> On Sun, Jun 15, 2008 at 5:42 AM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>> Stefan Küng wrote:
>>> Lieven Govaerts wrote:
>>>> Stefan Küng wrote:
[..]
>>> I guess many people will get really annoyed/angry with the 1.5 release of
>>> Subversion. I've ran some tests with different builds, all tests done with
>>> the command line:
>>> svn merge -r11761:11762
>>> http://tortoiosesvn.tigris.org/svn/tortoisesvn/branches/1.4.x --dry-run
>>>
>>> (for the 1.5 clients, I also added '--accept postpone' to the command
>>> line).
>>>
>>> Here are my results:
>>>
>>> my build from 1.5.x branch, built with VS2008:
>>> 5:17 .. 5:34
>>>
>>> 1.5.0-RC9 from open.collab.net:
>>> 2:22 .. 2:50
>>>
>>> 1.4.6 client:
>>> 0:12 .. 0:15
> Bah! That's awfull. IMHO it could be showstopper of 1.5.x :(
>
>>> * Serf is twice as fast as neon for merges, but only if IPv6 support is
>>> disabled.
>> I did a merge from a range of revisions of svn /trunk to a svn 1.5 working
>> copy with a trunk svn and ra_serf. This is the result:
>>
>> Nr. of opened sessions: 7
>> Nr. of reports sent to the server: 149
>> Nr. of opened sockets: 241
>>
>> This was a debug build, so the total time is not really important.
>>
>> The difference in nr. of reports and nr. of sockets is the fact that ra_serf
>> opens more than one socket per report, in order to send multiple requests
>> in parallel.
>>
>> Anyway, no less than 241 sockets is way to high. It should be possible to
>> reuse those sockets more, but this should be solved in the ra layers. I'll
>> have a look at ra_serf to see what we can do.
>>
> Reusing sockets in ra layers is bad idea. It's will be very implicit
> behavior, so problem will just hide one more level deeper.
>

If the merge code can be optimized to make less ra calls, sure, that's
better. But in the case that those 149 merge/update reports are really
needed, I don't see a reason why we cannot reuse earlier idle
connections in the ra_serf library. Isn't one of the principles of serf
to allow maximum number of requests over a minimum number of sockets?

> I've looked to merge.c code and I've shocked: we create many ra
> sessions when merging. This is source of all slowdowns. And also there
> is no comments why we doing so. Could someone explain why we creating
> new sessions instead of reusing?
>

Did you look at the numbers I got from my test case? Only 7 sessions,
and all of those were created at the start of the merge. So either you
misinterpreted the code or my code tracing was incorrect. I don't know
the merge code well enough to know who's right or wrong.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-15 18:38:52 CEST

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.