Evaluating Team Foundation Server Performance
You can configure performance counters and monitoring tools to evaluate Team Foundation Server performance. Reviewing and interpreting this data over time can help you evaluate the overall performance of your Team Foundation Server deployment. In addition, reviewing performance data can help pinpoint issues and troubleshoot problems.
Team Foundation Server itself is an ASP.NET SQL Server application that uses SQL Server to store data. If you are familiar with monitoring this kind of application, you can use the same approach to monitor Team Foundation Server and evaluate its performance.
Establishing Baselines
Every deployment of Team Foundation Server is unique. Differences in hardware, software, the number of users, the number of projects, the process template that is used for each project, and the amount of source data and work items all affect Team Foundation Server performance. It is important to establish baseline performance data for your specific Team Foundation Server deployment. These data will enable you to identify any significant variations in performance when variations occur. Also, over time, you will have a better understanding of the overall performance demands on your Team Foundation Server hardware.
The scope of the infrastructure for Team Foundation Server is quite large. You should proactively decide what you want to monitor and how to decide whether some value that you notice requires action. For example, you might decide to act if a CPU peaks at more than 80% for longer than 10 minutes. You can document this decision so that others on the project have a defined threshold. If you collect all these variables and states in one location, you have a documented information model about the health state of your environment for Team Foundation Server. This strategy is also referred to as the health model or health information. The health model is a set of observable conditions that define the states of the system. The previous example defines the threshold for monitoring the CPU usage. As this example shows, the health model is more about convention and consensus than science and math.
As an administrator of Team Foundation Server, you must decide what to monitor and how to assess whether a state has changed by using the thresholds as reference points. Without a health model, there are no reference points against which you can measure the health of your deployment.
Tools for Establishing Baselines
Performance monitoring is quite different from monitoring logs. Performance monitoring requires observing a specific set of performance counters during a specified period. For example, you might want to monitor performance in order to address concerns about response time. It is difficult to respond to user complaints about the response time for downloading the source tree for a specific project if you do not have any data about usual download times. Although Team Foundation Server does not include one specific set of tools for monitoring server performance, you can use monitoring tools and options available in Windows Server 2003, Microsoft SQL Server 2005, and the.NET Framework to monitor your Team Foundation Server deployment. Moreover, you can create your own tools for monitoring Team Foundation Server performance. For more information, see Understanding Monitoring Tools for Team Foundation Server.
Evaluating Data
Logging data, tracing data, performance monitoring data and service monitoring data all require a different approach to understand and interpret. You must first understand and verify that something has happened. Then, if necessary, you must determine which action will return the system to a healthier state. Each deployment has its own process for acquiring this understanding and determining courses of action. However, any process will require a concentrated effort over time. You can develop your own customized response information more easily if you keep a record of the data that you gather as you monitor your deployment and the actions you take to respond to unfavorable changes. You might invest in a commercial software suite to help you automate the collection and retention of this data.
As soon as you have established baselines for your Team Foundation Server deployment, you will be able to better determine the overall health and status of Team Foundation Server. For example, if you regularly see a runtime database exception in Event Viewer, you might not have sufficient processor or memory resources available on your Team Foundation data-tier server. Similarly, if you see a sudden decline in one of the Team Foundation Server performance counters, you will know to investigate the application for that performance counter in addition to overall performance of the Team Foundation application-tier server. For more information, see Monitoring Performance.
Monitoring Version Control Performance
You must address many variables when you monitor version control and a team build environment. If you have a good understanding of development cycles, you can more accurately predict what to closely monitor in Version Control. Additionally, if you understand their limits, you can more proactively address any issues.
Team Foundation Server includes many performance counters for monitoring Version Control. Depending on your focus, the counters in the following table might interest you. For a complete list of counters, see Monitoring Performance.
Monitoring Team Foundation Build Performance
As with any toolset, the usage defined by your deployment will vary dramatically. For example, a project with a single build environment with a single build script will differ significantly in usage from a team project with multiple build environments and many build scripts. To effectively monitor Team Foundation Build performance, you must determine monitoring criteria that suit your deployment needs. The following list includes some items that you might want to monitor in Team Foundation Build:
Average time to execute a build
Number of times that a build occurs
For example, a daily build should occur only once per day.
Number of failed builds that occurred within a specific timeframe
Number of builds that occurred outside of business hours
Standard performance criteria from the server running Team Foundation Build
For example, you can monitor percentages of CPU utilization.
Average time for a long build
Notification of successful builds
The following tools and procedures might help you in determining some of the important factors in your Team Foundation Build environment:
By viewing a Team Foundation Build summary, you can determine failure and how long a build required to complete. For more information, see How to: View Build Summary Status.
By monitoring build progress, you can determine what steps or items are causing a build to take longer than expected to complete. For more information, see How to: Monitor Build Progress.
By receiving build notifications, you can determine the state of current builds. For more information, see How to: Receive Build Notification E-Mail.
See Also
Concepts
Understanding Monitoring Tools for Team Foundation Server
Other Resources
Monitoring Team Foundation Server