On Tue, Oct 2, 2018 at 5:37 PM Bert Huijben <bert_at_qqmail.nl> wrote:
> On Tue, Oct 2, 2018 at 4:30 PM Branko Čibej <brane_at_apache.org> wrote:
>>
>> On 02.10.2018 02:38, Johan Corveleyn wrote:
>> > I haven't looked deeply into it yet, but it seems that the
>> > conflicts-tests (the C tests) are very slow when testing over
>> > svnserve. I noticed this while testing 1.11.0-rc2, but I see the same
>> > with trunk and with 1.10.x.
>> >
>> > Running the entire conflicts-test.exe (on a ramdisk):
>> > - ra_local: 23s
>> > - ra_serf: 70s
>> > - ra_svn: 982s (16m22s)
>> >
>> > The difference between ra_local and ra_serf strikes me as normal
>> > (after all, the conflict resolver contacts the repository a lot to
>> > fetch information). The time of ra_svn not really :-).
>> >
>> > The slowdown seems to be spread over all the tests of conflicts-test
>> > (the dots of the test progress come evenly spread).
>> >
>> > Is anyone else seeing this? Only on Windows, or on *nix too?
>> > A performance problem with tree conflict resolution specific to svnserve?
>>
>> How do you set the URL for win-tests.py? I've noticed that using
>> svn://localhost is orders of magnitude slower than svn://127.0.0.1,
>> apparently because the Windows resolver attempts a DNS search for
>> 'localhost' first (and failing) before resolving it locally.
>>
>> -- Brane
>>
> It resolves to both ::1 and 127.0.0.1 on Windows, and as (per RFC) ipv6 is tried before ipv4... things timeout before trying the address used by default (hardcoded) in svnserve.
> (We used to default to ipv6 for some time... But we decided to explicitly default to ipv4 when not passing the later added -6)
>
> More recent Windows versions have a workaround/speedup for this problem. They will swap the DNS results after a few failed attempts.
>
> Bert
Yep, that's it. Thanks all.
When using svn://127.0.0.1 conflicts-test.exe takes around 28s for
1.11.0-rc2 on my machine. Much better :-).
--
Johan
Received on 2018-10-02 23:52:35 CEST