TFS 2010 – Application Tier Version Control Cache Configuration

Sometimes people experience some kind of disk pressure on the Application Tier due to the cache filling up and then go hunting on how to set the cache settings so that they can manage the disk pressure. This is not yet (as of the time of writing this blog post) well documented in the MSDN documents for the 2010 version of the product.

One of our developers ( Remi )had passed this tip on how the TFS Application Tier cache settings are factored into the operations. Without this information some shops are left with the choice of just expanding disk space in a situation, where cache build up occurs but does not get cleared.

The following applies to the AT cache only (the real proxy is close but not identical as it does not have access to the TFS registry)


The TFS registry is the first place we look for settings:

· /Service/VersionControl/Settings/FixedSizeBasedPolicy indicates a fixed size cache (in MB)

· /Service/VersionControl/Settings/CacheLimitPercent is the alternative (i.e. % of the available disk space occupied rather than fixed size)

· /Service/VersionControl/Settings/CacheDeletionPercent is how much of the cache should be deleted when the threshold is reached (think of it as hysteresis)

· /Service/VersionControl/Settings/StatisticsPersistTime is how often the statistics file is saved to disk (not so interesting)

· /Configuration/Application/DataDirectory indicates where the AT cache will live


We then validate those settings (or come up with default if not found).


· If nothing is set, the default is CacheLimitPercent = 75%

· If both CacheLimitPercent and FixedSizeBasedPolicy are set, FixedSizeBasedPolicy wins.

· If CacheDeletionPercent is not set, it defaults to 20%

· StatisticsPersistTime defaults to one hour (any value above one hour is acceptable).

· DataDirectory can be overridden by adding a node in the web.config file like so (in which case it overrides the /Configuration/Application/DataDirectory setting):



        <add key="applicationDatabase" value="Data Source=dbserverhere;Initial Catalog=Tfs_Configuration;Integrated Security=True;" />

        <add key="WorkItemTrackingCacheRoot" value="C:\Windows\Temp\TFTemp" />

        <add key="traceWriter" value="false" />

        <add key="traceDirectoryName" value="%TEMP%\\TFLogFiles" />

        <add key="applicationId" value="GUID here" />

        <add key="dataDirectory" value="E:\" />



Important considerations:

· In an NLB environment, the TFS registry settings apply to ALL nodes, which is why the web.config settings take priority.

· CacheLimitPercent is a bit misleading in that if you have a 100GB drive and 50GB of other content, the TFS Cache can only use 50GB, so by default, the cleanup will occur when the cache reaches: (CurrentCacheSize + AvailableSpace) * (CacheLimitPercent / 100) = 50GB * .75 = 37.5 GB

· The Cache Cleanup can take a long time (hours on a very large drive) - so I would recommend changing the default Idle Time out on the Application pool to at least 60 minutes if you have a large cache and infrequent requests.


Caution: Be aware that doing this requires careful consideration and deliberate thought and proceed with systematic approach to tweaking the cache. I would try it on a test system OR change a few parameters (and not all at once) and iteratively reach a balanced approach.