Slow msysGit performance on mapped network drive

Solution 1:

git status is a command that reads and writes lots of files. Networked storage, even over some LAN connections, can be unacceptably slow when dealing with either lots of files, or lots of data, or both.

The problem is that SMB (Server Message Block, a.k.a. Samba, a.k.a. Windows File Sharing) is a very "chatty" protocol, sending lots of small packets back and forth, and it requires a boatload of "app turns", which scales up the more data you need. A "turn" is a round trip between client and server.

A few things:

• Try pinging your remote host from your local machine. If it's more than, oh, 5 milliseconds, networked storage is probably not suitable for much more than uploading a few kilobytes in a handful of files. Also check for jitter and packet loss. Jitter is when the ping is highly variable between different values, and packet loss is when a ping is completely dropped (it doesn't get responded to). Both are very bad impairments, almost as bad as latency.

• Try using WireShark to observe the traffic back and forth between your host and your router when doing git status. You will probably see a lot of TCP requests that go something like this:

• Packet goes out from your machine

• Your machine waits (does nothing)
• Server sends response

For each packet that is originating from your computer and destined for the remote box, label that packet "O" for "outbound". For each packet that is originating from the remote box and destined for your computer, label that packet "I" for "inbound".

• Count the number of "I" packets in a row without any "O" packets in between.
• Count the number of "O" packets in a row without any "I" packets in between.
• Come up with a rough ratio of the number of "I" packets to the number of "O" packets.
• If you are reading (downloading) files, and the ratio is not highly in favor of "I" packets (packets coming into your computer), then the protocol is chatty.
• If you are writing (uploading or modifying) files, and the ratio is not highly in favor of "O" packets (packets originating from your computer), then the protocol is chatty.
• Check the size of each packet relative to your expected connection throughput on a raw HTTP download of a large file.
• Multiply the latency of the number of round trips, and add in the transfer time of the files, to come up with some number that should be around 25 seconds.

Solution: reduce latency, or use a newer version of the SMB protocol as supported by newer versions of Windows Server (which have fewer app turns and thus higher performance over a WAN), or use something like FTP which has very low chattiness (but still high overhead when accessing lots of files), or just operate on the server directly and only transfer data as needed in bulk (e.g., zip files) to the remote server.