bharry's WebLog

We've nearly completed our full line of load testing to determine the recommended server configurations for various sizes of teams using Team Foundatation Server V1. Everything we've published before now were "goals". This is the first comprehensive publishing of actual measured (simulated) results. That said there is a huge disclaimer here. You may not experience the same results as we do. Many factors can affect your performance, including network traffic, data size, load per user, software or hardware configuration differences and more. These are only guidelines for planning purposes. The only way to know for sure what hardware will work for you is to try it in your environment.

Before I get to the numbers I want to remind you of what we are measuring. We are measuring the size of "team" that a given hardware configuration will support. We define team to be all people who are spending most of their time on projects using the Team Foundation Server. This means all roles - developers, testers, analysts, project managers, etc. Different roles will, of course, put different amounts of load on the system and in different ways. You can read previous blog posts that I have written to see the methodology we have used to generate these numbers.

We've tried to be very conservative - generally rounding down the actual results we achieved by 10-20%. Of course every team varies and if you have a team of people who run queries every 30 seconds all day, you'll need more server than we're recommending here. These numbers were based on the load we've experienced using TFS internally for the past year or so. Again, you can read more detail in previous blog posts but this turns out to be about 0.1 peak requests per second per user.

Here's the results we have gotten.

We are still working on our Unisys 8 proc data tier numbers. Our initial results were not what we expected and we are investigating why.

We're going to work on getting this info published through "official" channels. I hope this is useful in planning your server capacity planning exercises.

Brian