I have a development web server with an application directory mapped to my local machine as drive Z: (e.g. \\web_server\wwwroot). The shared folder requires domain credentials to access (my domain account is a Co-owner on the folder).

I am able to read and write files fine, but msysGit performance is slow.

Web server:

patrick@web_server /c/inetpub/wwwroot (master) $ time git status > /dev/null
real    0m1.887s
user    0m0.015s
sys     0m0.015s

Local machine (accessing mapped network drive Z)

patrick@local_machine /z (master) $ time git status > /dev/null
real    0m25.500s
user    0m0.000s
sys     0m0.015s

So how can I troubleshoot what is causing the 25 second hang?


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.

  • Thanks allquixotic. The ping is <1ms with average reported at 0ms ... which is as expected as its in the same domain. I'm going to pursue installing an OpenSSH server on Windows (itefix.no/i2/copssh) and see if I can access git remotely via Putty or so -- that way, "git status" should be executed remotely. I had been using Remote Desktop to access the server previously, but now all I want is something like shell access to manage the git repo. The repo has thousands of files so I imagine the latency just adds up if it must scan all of them. – pztrick Mar 5 '13 at 3:10
  • Just remember the rule of thumb comparison: a local RAM access is around 0.5 to 1 nanosecond for DDR3; a local hard disk access is around 30 milliseconds. Git works much faster on a local system than the network because the disk will read several megabytes in a row "while it's there" and cache that in RAM, so essentially you might pay a 30 - 60 millisecond price once up-front to read the git repo metadata from your HDD, and then every successive file access after that comes from RAM with a nanosecond per access. That's why it's so much faster. – allquixotic Mar 5 '13 at 14:41
  • Also, in many cases, on systems with lots of RAM, the entire repository might be completely in RAM all or most of the time due to features like Windows SuperFetch. So that's where the blazing fast speed comes from. By comparison, over the network, each file retrieval is going to eat up about a millisecond once you factor in buffering, and there's no way to fetch multiple files with one command to reduce the round trips (not using SMB protocol, anyway). – allquixotic Mar 5 '13 at 14:43
  • 1
    I was successful in getting copssh + msysgit to work. Basically comprises copying the git-core binaries into the copssh Bin directory. – pztrick Mar 6 '13 at 16:33

See this question for things you can do to speed up the network drive, such as putting it in "slow-link" mode so files are eventually sync'd. That helps a ton because you are reading and writing to the local disk instead of the network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.