I’ve written about our experiences using the version control caching proxy server before, but I thought I’d post a screenshot that nicely shows the difference in bandwidth utilization.

Before I do that, we were recently having a serious problem with our local caching proxy server being slow and sometimes not responding.  Robert Horvick looked into it and figured out that the problem was caused by the NIC setting on the computer being incorrect.  Yet again, we were bitten by the NIC setting not matching the network switch setting.  Not surprisingly, the performance was phenomenally better.

We recently had a large number of files change in our branch due to picking up changes from main.  There were lots of new binaries for the tools, as well as source code.  In the screenshot below, the small hump on the left is the network bandwidth utilization on my machine running a get without the proxy being used.  I was getting 7 Mbps out of the 10 Mbps available over our WAN connection.

I stopped that get, changed the proxy settings in Visual Studio (Tools -> Options -> Source Control -> Team Foundation Server) to use our local proxy server, and started the get again.  The area on the left of the image shows what a difference using the caching proxy made.  When the network setting was incorrect on the proxy server, the benefit of using the proxy was marginal.  With everything set up properly, the network utilization is high.  In fact, the utilization shown in the bottom of the window is 53%.  Of course, if you are downloading a bunch of small files, you won’t see as much of a benefit, but this was a nice demonstration of the improvement when getting a large set of files that includes a number of medium and large files.

You can find out more about using the version control proxy server on the following pages.

• How to: Configure Team Foundation Source Control to use Proxy Server
• Walkthrough: Setting up a Remote Office with Team Foundation Server
• Team Foundation Server Proxy Screencasts