Must go faster...must go faster!

  • Article

In addition to being Jeff Goldblum's favorite one-liner (apparently), this is a pretty common expression for anyone dealing with computers. My experience has been that, aside from the very day you get a brand new machine, you probably wish it could do something faster than it does - load a program, render your Night Elf, shade those pixels - whatever. If nothing else, boot times seem to get worse as operating speed gets better, so waiting for your speed demon to start doing things not-quite-fast-enough is another possibility.

When it comes to working remotely, the problem is obviously more pronounced. Time to login successfully is substantially slower if you don't have a local domain controller. Time to sync and send email is slower when the Exchange server is a 1000 miles or even a continent or two away. And of course, everything is slower if you have to use VPN to talk to 'the home office'.

Team Foundation Server is intended to support large teams - including teams that are geographically distributed, as most of you probably already know. In fact, the team that developed TFS is itself just such a team, with members located in:

  • Redmond, WA, USA
  • Raleigh, NC, USA
  • India
  • China
  • (In V1, we also had people in Europe and Fargo, ND, USA)

Yet, they all used a single (dogfood) Team Foundation Server, in Redmond.

It became obvious along the way that one of the most obvious bottlenecks for everyone NOT in Redmond was waiting for files from version control to download. That's where the Team Foundation Version Control Proxy (or AppTier Proxy, or just "proxy" for short) comes into play.

Jason (and then Rob, and now me) took note of a blog post from one of the Teamprise devs, Martin, about how he used a TFS proxy to improve his "get" performance substantially. I won't repeat his post (for one thing, his "slick graphics skill" is much higher than mine), but I will repeat (paraphrase) his takeaway:

Even a fairly modest machine on the remote end of a slow ("narrow") connection can yield substantial performance improvements for those remote users. Here in the Raleigh office, our link to Redmond is often characterized as a "soda straw" compared to the bandwidth at main campus (which I can only describe as stupendous - if it was any faster, pages would be loaded before you finished typing the URL).

Yet, with the proxy, everyone (after the first person, of course) can sync even multiple gigabytes of versioned items very VERY quickly. It's been awhile since I ran any performance numbers, but the basic improvement is that you're almost entirely bound by your LAN's bandwidth, instead of your link's (a difference of roughly two orders of magnitude, in our case). As Martin said, incremental updates don't see the gains as much as a 'clean, full' sync; but on the other hand, we also have a couple dozen users in our office (maybe even 50+), and our branches are measured in gigabytes. Yet, we're still using a modest Pentium 4, with 512MB RAM, and (again) neither CPU nor memory has been a bottleneck.

So, if you have remote users of your Team Foundation Server (or are one), you can get a lot of "bang for your buck" by deploying a Team Foundation Proxy. You can read more about the deployment requirements and instructions here: https://msdn2.microsoft.com/en-us/library/ms242919.aspx

Remind me what to do before I'm...