September 21st, 2005

Working remotely with TFS Version Control

Buck Hodges
Director of Engineering
Here in North Carolina, we have a 10Mb connection to the outside world (it was a 3Mb connection until a few months ago), so we know what it’s like to use TFS remotely.  In addition to minimizing the number of requests from the client to the server, TFS Version Control contains several features that aid in working in a situation where the connection to the server is much slower than the local network: compressed files, compressed SOAP responses, and a caching proxy server.

 
Every file that we upload as part of checking in or shelving is compressed using GZip.  If a file is larger after being compressed, which may be due to it being in a compressed format (e.g., ZIP or JPEG) already or being encrypted, the file will be uploaded without being compressed.  When files are downloaded, they are still compressed as they were when they were uploaded.
 

Communication between the client and server in TFS uses HTTP for everything, and it uses SOAP for everything other than file uploads and downloads.  We support IIS 6 compression of the SOAP responses (requires IIS settings for asmx pages — I expect this is in the installation guide, but I haven’t made time to go check), so the communication with the remote server is compressed.  Since SOAP is XML, responses compress very well.
 

The caching proxy in version 1 caches versions of files, and it does not handle any other parts of the client-server communications.  When a user configures a client to use a proxy server (in VS, Tools -> Options, click on Source Control and then Team Foundation Source Control to get to the proxy settings), the client still calls the server for the list of files to download (e.g., diff, get, view, undo) and calls the proxy server to download the file contents.
 
The first user to download a file must wait until the file is transferred over the remote link, but subsequent downloads are served from the proxy’s local disk copy.  To prevent the lag for the first user, you could, for example, set up a workspace that exists for the purpose of populating the cache by having a Windows task scheduled to run “tf get” every so often (say 30 minutes) or hook into the check-in event from the mid-tier and kick off a get in the workspace (see Continuous Integration Demo Code from Doug Neumann’s TLN301 PDC Talk for an example of hooking into the check-in event generated by the app tier).
 
The amount of disk space used by the proxy is configurable, and it removes the least recently used files first when it needs to reclaim disk space.  With large hard drives being cheap, it’s not hard to have a caching proxy server cache every version of every file in the server and not have to delete anything.
 
Here in North Carolina, we have a proxy server set up that is on our 100Mb network, so downloads are local while the rest of the communication is still over the WAN link.  We also take advantage of the IIS compression for the SOAP responses (it’s turned on for our dogfood server).
 
I wrote back in March that our experience with using TFS had been good, and it’s gotten significantly better since then due to features like the proxy, compressed SOAP responses, and the performance optimizations that have been made.
 
[Update 10/01/05]  When you install the server, SOAP response compression is automatically configured.  You don’t need to make any changes to take advantage of it.

Author

Buck Hodges
Director of Engineering

Director of Engineering, Azure DevOps

0 comments