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
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
>
>
Received on 2018-10-02 17:37:32 CEST