Your official information source from the .NET Web Development and Tools group at Microsoft.
Since August 16th, and especially since August 21st, the NuGet Gallery has been exhbiting intermittent performance issues. Some users are reporting errors when attempting to browse or search for NuGet packages from Visual Studio or other clients. Many users are reporting that browsing and searching are slow. There have also been timeout errors when browsing the gallery’s packages page.
During this time, we have been communicating with many of you on twitter, under the #nuget tag, as well as in JabbR’s #nuget room. We truly appreciate your patience and understanding with us.
We have been working to address these performance issues over the last several days, and we hope to have a deployment in place this evening (August 22nd, Pacific Time). It looks like the deployment will cause a short outage though–we will post more information about that when the details are available.
The root cause of the performance issues boils down to some sub-optimal queries that are used when searching the gallery–especially when searching from Visual Studio. There are a couple reasons these queries are slow:
The deployment we’re preparing will address both of these issues by adding size constraints to many fields and then creating several new indexes. Unfortunately, the process of altering the Packages and PackageRegistrations tables and then creating these new indexes is going to take some time to apply – during that time, the database will be rather unresponsive. Again, when we know more about the timing of the outage, we’ll share the details.
Will migration scripts be made available for those with private repositories?
Also, totally unrelated: searching from Visual Studio s*cks! Only if you already know the exact name of the package can you find it.
I use NuGet often. It seems that I rarely (if ever) had a problem until this last update. Can we go back? That is, install a previous version?
I can't understand why you don't use an intelligent server-side caching, that would solve most of the issues. But I guess the whole query design (Odata, Queryprovider, hard to map to cache keys) makes it really hard to do so. Abstraction costs..
Really, there is absolutely no reason an extension from within Visual Studio should cost more than 100 ms.. it takes several seconds, still. It's just (right now) 7,577 package names to search over, that's.. sorry to say.. a bit lame.
Still having some issues today, was working slowly past week or so but now get 417 continuation error.
I added <servicePointManager expect100Continue="false" /> into devenv.exe.config to resolve.