TFS Performance Tips & Tricks - Part Two

As promised, here is part two of Brett Keown TFS performance tips and tricks.


Technorati Tags: Team Foundation Server Performance Tips



Client Side Performance Tips

There are a few things I’ve found which can help with client side performance.

· General Settings -

· Launch of Visual Studio -

· Jeff Lucovsky’s blog has lots of great info on creating things like RSS Feeds for TFS alerts, performance automation, etc.

· 947751  FIX: The shortcut menu does not appear for many seconds when you right-click a project name in Visual Studio Team System 2008 Team Explorer:;EN-US;947751


You can use cloaking as a performance optimization when you want to prevent a part of the source control tree from being retrieved. The following are typical scenarios for using cloaking:

· You want to build the project locally and a folder is not needed for the build, for example a documentation folder.

· You are part of a large team project and you only want to retrieve part of the project.

For either of the above scenarios you can cloak folders to stop the client retrieving those folders. You cloak folders on the client by editing the workspace and changing the status of the working folder from active to cloak.

Keep the following recommendations in mind when using cloaking:

· Do not cloak individual files. This is likely lead to maintenance problems later in the project.

· For a large project, map out the root folder and cloak sub folders rather than creating multiple workspaces for the project.

SQL Server Performance

Due to the plethora of information available for tuning SQL Server performance; I will instead list a few items which apply specifically to Team Foundation Server:

A large user operation against Microsoft Visual Studio 2005 Team Foundation Server may cause the Microsoft SQL Server 2005 Database Engine to escalate to a table lock. Typically, this behavior occurs during large source code control operations. Here is the Knowledge Base article which discusses this issue and how to resolve it:;EN-US;934005

When performing a large checkout in TFS 2005 while utilizing the exclusive check-out option; upon check-in you may experience very slow performance. The delay varies depending on the number of files. You will need to contact Support for a hotfix to this issue. Here is the KB article:;EN-US;940295.

923605 FIX: A deadlock occurs and a query never finishes when you run the query on a computer that is running SQL Server 2005 and has multiple processors;EN-US;923605

Team System Web Access

The following tips were taken from a great document written by Hakan Eskici which discuses Team System Web Access 2008 Scalability Limits. If you would like to review the full article (which I highly recommend), you can find it here…

Change Asp.Net Cache Memory Settings in Web.config

This change will cause Asp.Net to be more aggressive with reclaiming the memory from the cached objects.



<cache disableMemoryCollection = "false"

disableExpiration = "false"

privateBytesLimit = "1000000000"

percentagePhysicalMemoryUsedLimit = "60"

privateBytesPollTime = "00:01:00"



Use a scheduled task to recycle Web Access IIS AppPool and clear the metadata cache files

This will cause active user sessions to be terminated and the entire metadata cache to be refreshed. It is strongly recommended that you schedule this to run at times when there are no users actively using Web Access. Metadata cache files are stored in %WebAccessInstallDir%\Cache by default. To learn the actually location, see the WorkItemTrackingCacheRoot entry in web.config:

<add key="WorkItemTrackingCacheRoot" value="C:\Program Files\Microsoft Visual Studio 2008 Team System Web Access\Cache"/>

Install additional Web Access instances

If none of the other workarounds help you improve the Web Access scalability further, it is recommended to distribute the load to multiple servers by installing separate Web Access instances on separate servers. Team System Web Access 2008 does not support Network Load Balancing; therefore each Web Access instance will have a separate URL. One option is to install a Web Access instance for each large team so that the team members will always use the server dedicated to them.

Build Performance

If you are using Team Foundation 2008 Build, TFS SP1 introduced the targestnotlogged property.  A recent hotfix implements this properly.  A wonderful side effect is that it significantly improves performance on top of removing the noise from the log!  Please note that you must have TFS 2008 SP1 installed on the Build Server to implement this fix.  Here is a brief description from the hotfix article:

The TargetsNotLogged property was introduced in Visual Studio 2008 Team Foundation Server SP1. The goal was to reduce the many noisy log entries for Team Foundation 2008 Build projects that contain project-to-project references. For example, before Visual Studio 2008 Team Foundation Server SP1, a Team Foundation 2008 Build project that contains project-to-project references results in many log entries that resemble the following:

Project "<project>" is building project "<dependent project>" with target(s) "GetTargetPath".

Project "<project>" is building project "<dependent project>" with target(s) "GetNativeManifest".

Project "<project>" is building project "<dependent project>" with target(s) "GetCopyToOutputDirectoryItems".

The TargetsNotLogged property is used to prevent the ProjectStartedEvents function from logging the specified targets. By default, the Microsoft.TeamFoundation.Build.Targets file initializes this property to ignore the following targets:

· GetTargetPath

· GetNativeManifest

· GetCopyToOutputDirectoryItems

Here is the link to the hotfix KB: