
Today I was approached with a solution to a problem, and asked to implement it. Not an uncommon approach around here. The problem – TFS is responding slowly when developers check in or get the latest versions of code. The person approaching me believed the TFS cache was causing this.
Not being at all familiar with this, I started investigating. I found this MSDN page that gives a good explanation of TFS performance:
http://msdn.microsoft.com/en-us/library/dd904316(v=vs.90).aspx
After reading the section on cache size, I found myself at this page Change Cache Settings for an Application-Tier Server, and proceeded change the cache location & size.
After adding a new disk to the server (this is where VMs are worth their weight in gold), and modifying the web.config to point to this location, I found the cache started to form at this new spot. Perfect. I modified the size of the cache to take up to 50% of this new volume (10GB). This would give us a cache size maximum of about 5GB.
Before I started, I took note of the vales given by the TFS web service http://localhost:8080/VersionControl/v1.0/proxystatistics.asmx?op=QueryProxyStatistics, and I also noted the four Windows performance monitor metrics for the “TFS Proxy Service”, specifically cache size, cache hits, total download requests, and total files in cache.
After I made this change, I looked at these figures again. The hit ratio % reported by the server is virtually unchanged, as it the other metrics from windows performance monitor.
I’m yet to get any info from the developers on how their TFS is running. I’ll update this post when it happens.