TFS Performance with 1.1

Feb 16, 2011 at 10:39 PM

We noticed with the 1.1 release that it has become painfully slow.  Every action seems to take minutes to complete.  Even just bringing up the UI or the package console takes minutes.

Digging in, I noticed the CPU was flat but network traffic was spiking.  As it turned out it was sending a lot of requests to the TFS server.  These appeared to be checking to see if we had the latest version in the /packages folder.  It appears that what it is doing is recursively navigating this packages tree and doing a get latest, although I'm not entirely certain.  To generate that many TFS activities I'm wondering if it isn't doing it multiple times.

I dug into the source to see if I could pinpoint it, but haven't really had time.  However looking at the changesets for the 1.1 release it does appear that this TFS integration was added recently and that would explain then why it started behaving this way with 1.1 when we didn't have problems with 1.0.  As I understand the workitem, it was to integrate the packages folder with TFS where I know before we had to manually do these checkins.

 

Is anyone else seeing this behavior?  It may be aggravated on our side because our TFS server is located in Kentucky while development is in Minnesota so latency is a bit higher then someone running locally might see.

Feb 17, 2011 at 12:16 AM

I saw this issue on a ctp. I think that code path was removed in the RTW release. It sounds like it was added back in.

sent from my mobile

On Feb 16, 2011 5:39 PM, "sodablue" <notifications@codeplex.com> wrote:
> From: sodablue
>
> We noticed with the 1.1 release that it has become painfully slow. Every action seems to take minutes to complete. Even just bringing up the UI or the package console takes minutes.Digging in, I noticed the CPU was flat but network traffic was spiking. As it turned out it was sending a lot of requests to the TFS server. These appeared to be checking to see if we had the latest version in the /packages folder. It appears that what it is doing is recursively navigating this packages tree and doing a get latest, although I'm not entirely certain. To generate that many TFS activities I'm wondering if it isn't doing it multiple times.I dug into the source to see if I could pinpoint it, but haven't really had time. However looking at the changesets for the 1.1 release it does appear that this TFS integration was added recently and that would explain then why it started behaving this way with 1.1 when we didn't have problems with 1.0. As I understand the workitem, it was to integrate the packages folder with TFS where I know before we had to manually do these checkins. Is anyone else seeing this behavior? It may be aggravated on our side because our TFS server is located in Kentucky while development is in Minnesota so latency is a bit higher then someone running locally might see.
>
>
Developer
Feb 17, 2011 at 1:02 AM

This is a known issue. The TFS perf is pretty bad (especially for big solutions), you can revert to the 1.0 behavior by deleting the NuGet.TeamFoundationServer.dll in:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\NuGet Package Manager

Restart VS and it won't detect tfs source control. Unfortunately we don't have a good way of turning it off. We can look at fixing the perf in the next version.

Hope this helps

Feb 17, 2011 at 3:53 PM

Thanks.  That worked!

Looking at the requests coming through fiddler, it seems like it's iterating through the folder structure when all it probably has to do is check for changes at the top level packages folder and let TFS do the recursion.  I looked briefly at the code, but it'll take me some time to understand how it's being called.

Coordinator
Feb 17, 2011 at 4:11 PM

@sodablue If you have a solid understanding of how TFS works, we'd *love* to have your help with such integration. I'm sure you're busy like the rest of us, but if you have time to look at the code and submit a patch, it would be very much appreciated. :)

Feb 17, 2011 at 5:39 PM

Thanks for the solution, I have just had a couple of hours of hell with this.

I found NuGet was install at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.1.229.160 in case this helps anyone else looking for it.

 

Feb 18, 2011 at 5:55 AM

@haacked: I'll see what I can do.

Feb 24, 2011 at 7:01 PM
Edited Feb 24, 2011 at 7:03 PM

I had this issue as well - it was very painful even on a TFS repo on the same LAN. Removing the NuGet.TeamFoundationServer.dll assembly worked for me, too.  But, it also (unsurprisingly) removed my TFS integration which was a pretty major feature for me. :(

Is there a work item for this issue?  If so, is it assigned to anyone?  I don't see one that's obvious.

If it's not created/assigned, I'm no TFS expert, but I might be able to take a shot at it...

Developer
Mar 4, 2011 at 4:32 PM

Hey guys, we think we have a fix for the bad TFS performance. Can you try out the below build and see if things work better?

http://ci.nuget.org:8080/guestAuth/repository/download/bt4/.lastSuccessful/VisualStudioAddIn/NuGet.Tools.vsix

Thanks

Mar 5, 2011 at 12:51 AM

YES!  It looks like it works.  It's now loading as fast as it should.

I'll play with it a few days and make sure it's solid.

Mar 5, 2011 at 3:18 AM

I suffered the same problem. And the hot fix worked perfectly for me.

Thanks.

Mar 10, 2011 at 10:02 PM

This fix did the trick for me too! The perf was killing me, literally taking 5 mins to finish an install from the console.

Mar 11, 2011 at 2:19 PM

This hotfix fixed it for me also.

Aug 13, 2013 at 10:18 PM
Edited Aug 13, 2013 at 10:19 PM
It seems like the performance issue is back using the 2.6 version. I have the following configuration

<add key="repositorypath" value="\\localhost\packages" />

So whenever a dll is referenced the hintpath would have the absolute path. This works for the tfs build agent also perfect. But if I try to install any package, the adding of the package to the project takes several minutes.