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?
Best Answer
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
ping
ing 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
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".
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.