Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
One of the concerns I hear pretty frequently is about the number of Team Projects that a TFS server will support. Bill Essary wrote an extensive paper a while back on what limits TFS has, why and what behavior you will see as you approach and exceed the "limits".
Tackling this problem was not one of our objectives in Orcas. We've targeted Rosario as our release to really eliminate this limit for all practical purposes. None-the-less, some of the changes we've made will help.
First, we made some performance improvements to how we manage work item meta-data. We did this to generally improve performance but since work item tracking cache performance is the primary limiting factor for the number of Team Projects on a server, it helps.
I had another realization the other day that may help people who are looking at this problem. Jim Newkirk and a couple of other people from the CodePlex team were out visiting us in North Carolina and we were discussing the future directions and challenges for CodePlex (as you probably know, CodePlex is built on TFS). Jim was explaining that the number of projects is really taking off and they are planning for how they will get to 10's of thousands of projects. Their measurements show they can get up to 750-800 per server with their process template before the performance becomes undesirable. Unfortunately, even that becomes cost prohibitive when you want to be able to host 30,000 projects or more and you database hardware runs $30,000 or more per server (they are constrained by what standard Microsoft operations will purchase for data center database servers).
As we talked I realized we had a solution in Orcas that would help them a great deal. It won't completely solve the problem but I'll bet we can cut their costs by a factor of 4 or more.
In Orcas, we implemented support for SQL named instances. What I recommended to Jim is that, rather than buying a new database server for every TFS server, they just use a new application tier and share the database server between multiple application tiers. The app tiers are much cheaper than the data tiers. In fact, you could probably even use VMs on the app tiers and run multiple app tiers on a single piece of hardware given that the load on the app tier is comparatively light.
It's not a perfect solution. You are still limited to ~500 projects per TFS server. You still have to buy a TFS server license for each of the TFS servers. But it should substantially reduce the hardware and some of the software costs (due to sharing the SQLServer).
Anyway, just a thought and I hope it will help some of you out there.