Suggestions for troubleshooting slow TFS server [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_StackOverflow社区

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this 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?

---

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>

---

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

---

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

---

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.

---

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).