Very slow svn client on windows, very fast svn client on linux

Question

I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.

So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.

I tried forcing the svn client to 'basic' auth with configuration option http-auth-types ( http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html ), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.

The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/

When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.

I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?

---- edit ---- I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !

Answer 1

If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.

Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (ie Certificate Revocation List) . With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.

If it's not your case, then I suggest contacting VisualSVN's support team for investigation .

Answer 2

In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).

After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.

It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.

The initial delay I had was 11-13 seconds. Now next to none.

And I am not using ssh client.

Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).

For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).