Suggestions for troubleshooting slow TFS server

Question

We're running TFS 2010 on a dedicated box off our LAN and connecting to it with VS2010. Over the last few weeks access times and time taken to check in/out files have got ridiculous. Sometimes it can take several minutes even to get a view on the repository.

We've checked network access times and everything seems in order - e.g. RDP and shares mounted off the server are not painfully slow so it would appear that TFS is the culprit. Can anyone suggest any obvious areas we should investigate?

If you log into the server directly - how fast is it there? Is the problem over the network only or both locally and remote? — tsells, Sep 16 '11 at 00:01

score 21 · Answer 1 · answered Sep 05 '12 at 19:46

Just ran into this problem after upgrading to Windows 7 for the TFS client. Only the Windows 7 TFS clients were having problems, the XP TFS clients were fine. In our case, the problem was that the TFS client was going to our internet proxy server even though it should have bypassed the proxy server for the TFS machine. The solution was to modify the %VSINSTALLDIR%\Common7\IDE\devenv.exe.config file to add the defaultProxy line as follows:

<system.net>
    <defaultProxy enabled="false"/>
    <settings>
        <ipv6 enabled="true"/>
    </settings>
</system.net>

This setting, particularly on Win7 clients, is an absolute crippler in terms of performance. You'll see hundreds of times more network IO once the default proxy is disabled. +1, Best practice analyzer is useful, but I'd recommend this is the first thing to try. — SpaceBison, Sep 06 '12 at 12:52

score 4 · Accepted Answer · answered Sep 15 '11 at 13:23

4

Did you try the Best Practice Analyzer from the TFS Power Tools

answered Sep 15 '11 at 13:23

Ewald Hofman

12,688
3
39
44

Nope. Will have a look at them now. Thanks. – immutabl Sep 15 '11 at 13:33

score 3 · Answer 3 · edited May 23 '17 at 11:51

3

I thought it was something like the above that was causing my problem but it turned out to be just removing some unused workspaces solved my particular problem. Now it's much quicker. Visual Studio 2013, TFS is very slow

edited May 23 '17 at 11:51

Community

1
1

answered Jul 31 '15 at 16:17

David Barrows

758
7
20

This is not an answer to the question. – Daniel Mann Aug 01 '15 at 01:43
9

@Daniel Mann: I respectfully disagree. The question is, "Can anyone suggest any obvious areas we should investigate?" And my answer is, "I had the same problem and I tried the answers on this page, and it turned out to be something else: obsolete workspaces which were causing the performance problem." That's information that solved the problem in my case. Others googling who find this page might also have the same problem I had. So it is an answer, and very well might solve someone else's problem in the same way it solved mine. – David Barrows Aug 02 '15 at 08:29

score 2 · Answer 4 · answered May 08 '12 at 05:24

Check the size of the Constants table in your collection databases, we got into a situation where VS would take a extremely long time to start up for users who would show team explorer on startup whilst for users who do not by default show team explorer it would manifest as an extremely poor check in event (first time per session). We ended up deleting the content of the build global lists and performance increased dramatically; it would appear VS is slow when loading up this meta data from the VS cache. We did have about 150,000 builds in the system however (we didin't destroy the builds, just clear the global list content).

score 2 · Answer 5 · answered Sep 15 '11 at 09:10

I'd check the TFS Database for starters.

If it is of enormous size, things can get slow just for that. We had tables that were on multiple Gigabyte scale & were holding (in our case) test results - which were of little or no interest to us.

By deleting them, we actually got a more performant TFS.

Suggestions for troubleshooting slow TFS server

5 Answers5