I connect to the central Teamprise TFS instance over a VPN connection to the head office in Champaign, IL. It is a direct distance of nearly 4,000 miles - but probably much longer depending what route my packets take - on a good day typical ping times for me are ~150ms, but bandwidth is also a major issue. On my current ADSL line (that is booked in for upgrade before the end of the month) I get 140 kbs upstream and about 400 kbs downstream - on a good day. On a bad day, it can be much worse. Last year someone decided to start shooting at bits of fibre optic cable in Ohio and that really messed up my day.
In many ways, the fact that Teamprise has a couple of the core development team working remotely over the VPN is good for Teamprise the product because we certainly complain if we encounter any performance issues during dogfooding - issues that the folks in the office with a gigabit connection to the TFS server might not feel as strong about :-)
TFS mostly works great for me over my VPN connection. The TFS team did a lot of work to optimise TFS traffic for WAN environments, such as use of standard web based protocols for transport, the heavy use of compression, minimization of the SOAP payload, keeping connections cached and not to forget things like inventing the TFS Proxy Server - you can certainly tell that TFS was designed with this type of environment in mind. (I'm sure it helps that the majority of the TFS team are based in Raleigh, NC while their dogfood TFS instance is based in Redmond, WA ;-) ). The only times where I have issues are on the rare occasion when Windows File Shares are used or the client needs to query Active Directory information.
Obviously - Windows file shares are an issue for Teamprise in general (with around 50% of the team using non-Windows systems as their primary machine). But most modern operating systems can talk to CIFS based file systems pretty well. The issue for me is that Windows file shares suck over a high-latency, low bandwidth connection. This was one of the reasons VSS performed so badly over a WAN. Thankfully there are only a couple of main areas in Team System and TFS where Windows file sharing is currently used:-
- Publishing of test results from the client
- Accessing the TFS build drop location (and most annoyingly, the build log file).
Note, it because of these types of issues (and the Active Directory releated ones) that I always recommend people connecting into TFS remotely use a VPN if they want access to the full functionality. While the Windows file sharing bits may perform really badly - at least they will work over a VPN. Try getting file sharing to work securely between firewalls if TFS is exposed on the internet and a VPN is not used...
In a follow up post, I'm going to be talking about how to modify your builds to make them easier to work with over a WAN / VPN. Despite these minor niggles (which don't come up very often), if you are considering using TFS for use over a VPN or Wide Area Network then I would certainly recommend it.
Leave a comment