Subversion unbearably slow on Windows 7

Question

My company is currently using TortoiseSVN 1.6.16 32-bit on Windows XP to connect via HTTPS to a VisualSVN-Server 2.1.19 running on a Windows Server 2003 residing in the same network (no proxy). We use a self-signed certificate and Kerberos authentication using windows credentials (I suppose this is a VisualSVN-specific feature). In this setup, everything works dandy.

When my company decided to move on to Windows 7, we tried TortoiseSVN 1.7.6 64-bit on Windows 7 64-bit which resulted in the following problem:

• Any operation involving the server (repo-browser, checkout, update, checkin, ...) is unbearably slow e.g.
  • opening the repo-browser (10 projects): 15 min
  • update on a fresh checkout of 50 files: 1 min
  • checkin of a single empty file: 30 sec
• Tortoise shows alternatively normal transmission speeds and 0 byte/s. Many small files seem to be slower than a few big ones.
• The slow connection results in various failures when using neon as http-lib (serf is still slow, but operation finishes successfully without errors)
• EasySVN, SmartSVN and the SVN command line client that comes with TortoiseSVN show the same behaviour. Same with TortoiseSVN 1.6.16 64-bit.
• Changing the server protocol to HTTP (no SSL) does not improve the situation

On the other hand

• TortoiseSVN 1.7.6 32-bit on Windows XP works fine with our server
• Access via browser/WebDAV works well even under Windows 7
• Server side logs do not show errors or even warnings

I found several posts which also complained about slow behaviour on Windows 7, but they didn't fit my bill because they were local operations or were restricted to TortoiseSVN.

As there is no indication that there is a general problem with Subversion on Windows 7, I suspect that it could be our OS' networking parameters or protocol versions. Are there any parameters which are known to influence Subversion's performance?

I have to admit I am not familiar with how exactly Subversion (or rather neon/serf) relies on the OS and on which parts. Any information on that would be greatly appreciated.

Are there any parameters in the subversion 'servers' file which I should test? How would you consider my chances that Wireshark'ing the connection will help me?

Similar experiences, opinions, hints, help and straws are welcome.

Wireshark shows sporadic gaps of ca. 5 sec in the TCP stream apparently caused by VisualSVN Server.

• https: the server acknowledges the client hello then waits for 5 secs before sending its server hello
• https: the server acknowledges the client key and than takes 5 secs before supplying its encrypted handshake data
• https: even outside the handshake, server sometimes sends an ACK (on TCP level) and then waits for 5 sec before sending something back to the client (the data is encrypted so it's hard to tell whether the break occurs at some point of interest)
• http: at both server side transmissions during the NTLM authentication
• http: before server sending a FIN flag

Zug

did you get anywhere with this? – Kreiker

Thanks for reminding me. See my own answer on that. – Zug

Domain Name Resolution was my issue added a local hosts entry and it sprang to life. – Sepalous

Answer 1

The issue was never properly cleared up. Most probably, the company internal network path between the client and the server was somehow at fault. The matter became obsolete when we moved the SVN server to another machine. The very same setup of server and clients works fine now, even with Windows 7.

Zug

Answer 2

A typical fail with Windows 7 against an older server is IPv6 networking.

If your machine does not have an SVN server listening on an IPv6 address Windows 7 might still try to do a TCP6 connect first (you can see it in Process Explorer if you look at the open sockets of the TortoiseSVN process while trying an operation), this has a timeout of a few seconds and then retries with IPv4.

Simple solutions are either upgrade your server to an IPv6 capable one or disable IPv6 for the Windows 7 clients.

Blus

Answer 3

Another thing you could verify (the answer above didn't work for us) is the Internet Explorer settings especially if you have IE9. We found that by disabling the option Automatically detect settings in the Internet Options -> Connection tab -> LAN settings, SVN started working normally again.

Corking

I updated your answer with English option names; I hope you don't mind. – Buffo

Answer 4

I had the same symptom of a very slow repository browse, slow updates, slow everything.

My SVN server has two Ethernet cards, so it has two Ethernet IP addresses. The SVN server was only listening on one of the IP addresses. So a name resolution via WINS or NetBIOS could resolve to the 'wrong' IP address.

TortoiseSVN would retry, eventually the name resolution would find the 'correct' IP address, and things would work.

Hermaphroditism