Working remotely with TFS Version Control

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.
Comments (11)

  1. Joe Sango says:

    Just caught up with a bunch of webcasts and one of them was Rick L’s Channel 9 vid. I thought it was interesting when he was briefly talking about working remotely with TFSSC and I thought to myself it would be cool to hear more about that…and here it is! Nice post Buck. Stop reading my mind! :P


  2. John says:

    Any upcoming posts on the laptop/disconnected features in TFS?

  3. buckh says:

    Glad to help, Joe. ;-)

    John, I’ll go ahead and get the disappointing part over with. Our support for working in a disconnected mode is not very good in v1, because pending edits (aka checking out files), etc. requires contacting the server. Having said that, we do plan to provide a tool that will find writable files in your workspace that do not have pending edits and pend edits on them. I hope to be able to provide more info about that in the near future.

  4. Buck Hodges says:

    Now that the RC is out, I thought I’d post a summary with links to version control posts from the last…

  5. We’ve had quite a few folks asking about TF Version Control’s performance, especially in the remote access…

  6. Buck Hodges says:

    One of the features from VSS that TFS does not support "out of the box" is shadow folders.  Last…

  7. Buck Hodges says:

    I’ve written about our experiences using the version control caching proxy server before, but I thought…

  8. Buck Hodges says:

    One of the features from VSS that TFS does not support "out of the box" is shadow folders . Last year,

  9. Q. How often does the proxy server synchronize with the server? Is it a continuous synchronization as

  10. annie says:

    I have been trying to setup TFS proxy ,but I am not sure how to do it. I have setup a machine to work as proxy server with all the components in it as decribed in MSDN documents,but the server is not caching any data,it shows 0 counters.I want to put that server on the DMZ,but then how will it connect to the Team FOundation Server?If I put it in a different domain,then how should I configure it to connect to TFS.Please help me,I am new to this arena.

  11. buckh says:

    Annie, the service account used to run the proxy must be trusted by the TF server.  So, if you put the proxy in a different domain, the TF server must trust that domain in order to authenticate the proxy server’s service account.

    The proxy only caches files that are requested from it by clients.  So, you’ll need to make sure that your clients are configured to use your new proxy server.  Until a client connects to it and requests a file, you’ll see zero counters.