Announcing TFS Performance Report Pack

Update 6/23/2009: Due to popular demand, Jim from the Developer Support team at Microsoft has re-created the three reports that required SQL2008 Reporting Services. See the support team blog for more details.

Update 7/13/2010: These reports also work with TFS2010.  When you setup the data source, just specify the name of a collection DB instead of TfsActivityLogging.

I’m on the team that runs the busiest Team Foundation Server at Microsoft. The Developer Division instance has over 3,500 active users and processes over 10,000,000 source control and work item tracking requests per day (not including the requests that our 5 proxy servers handle).

We have a responsibility to ensure that the server is performing as expected and to identify any efficiencies that can be made in the server or the tools.  To do this, we have created a number of reports that we use ourselves and make available to our own users.

Download

We’re now making these reports available to you to install on your own server and monitor your TFS server’s performance. The plan is to eventually roll these into a power tool release or a subsequent release of VSTS but I’ll let you know more about that when it happens.

• Download from here TFS Performance Report Pack.zip (~250Kb)
• Download the SQL Server 2005 compatible reports from here SRS2005CompatibleReports.zip  (~13Kb)

Requirements

• SQL Server Reporting Services
• A user with read-only access to the TfsActivityLogging database
• A shared datasource to connect the report to (see below)
• Command Logging enabled - This logging is enabled by default in TFS 2008.
  • In TFS 2005 you will have to enable the commandLogging flag in the Global Web.Config file (and the query for the report will be a little different).

Installing

The report pack consists of a ZIP file with a number of Report Definition (*.rdl) files.  These files are designed to be deployed onto your existing TFS reporting server, e.g. http://your-tfsserver/Reports/

1. As a TFS administrator, extract the files to your PC
2. Open http://your-tfsserver/Reports/
3. Create a new folder in Reporting Services called “Server Status”
4. Create a new shared data source called “TfsActivityReportDS” and set the connection string to:
   1. Data Source=localhost;Initial Catalog=TfsActivityLogging
   2. Credentials: domain\user that has access to the TfsActivityLogging database
   3. Use as windows credentials when connecting to the data source

Here’s an overview of what the reports look like and what questions you can answer with them.

Execution Time Summary

This report visualizes the load, in this case reflected by total execution time, on the server from two axis: users and commands.

Use this report when you want to know:

• Which commands account for the largest load on the server?
• Which tools / or users are putting the biggest load on the server?

Server Status - Source Control Request Queue

Source Control is undoubtedly the application that consumes the most resources on an Application Lifecycle Management (ALM) Server. Across the day, a series of requests get queued to be processed as transactions are committed to the database. This report provides a view into that queue.

Use this report when you want to know:

• If a request is blocking source control operations and for how long
• How healthy is the performance of version control on this hardware?

Lots of red means that you have some long running operations and you may have some problems.

Server Status - Top Users Bypassing Proxies

In the past, I’ve blogged a query to get this information – How many user’s are not using a TFS Proxy server? Internally, we have setup a scheduled subscription that emails this report twice a week.

IT departments strive to provide the best level of service to their users. Hardware requirements planning and setting up proxies are activities that ensure optimal performance for their internal teams when interacting with team Foundation Server. This report allows administrators a view into which users are not complying with internal guidelines and hence decreasing overall server performance.

Server Status - Historical Performance Trends

This report serves as a summary of the average response time for two of the Team Foundation Server subsystems: Work Item Tracking and Version Control

Use this report when you want to know:

• How long are users, on average, waiting for a subsystem to process their request
• Which days of the week are the most critical when it comes to performance

Server Status - Recent Performance Trends

This report provides more data granularity about the performance of the server. We start with a view into the server average response time, now looking at the entire picture instead of broken down by subsystem. We then follow with charts relating information about version control downloads and average response time distributions for the same time period.

Use this report when you want to know:

• The correlation between degraded server performance and average response times by the subsystems
• How does a large number of downloads affect overall server performance
• Overall health indicator of the server

I hope that you find these reports useful. Please send any questions or feedback as comments to this post, or contact me via email.