NuGet Feed Performance Update

NuGet Feed Performance Update

Rate This
  • Comments 6

As you might know, NuGet has been having some performance (and timeout) related issues recently. Earlier this week, we completed a deployment that helped, but it didn't address everything.

Many users are still seeing slow responses or even timeouts when trying to use the ‘Manage NuGet Packages’ dialog in Visual Studio.

Ongoing Investigation

The deployment earlier this week greatly improved the packages page on the gallery, but it didn't address the Visual Studio dialog performance as much as we had hoped. Since that deployment, we’ve been focusing on the queries behind the Visual Studio dialog.

We have found that the SQL queries that get executed from the ‘Manage NuGet Package’ dialog are not great. While the execution plans look okay, the memory grants for the queries are HUGE–MUCH bigger than they need to be. Because of the huge memory grants, the queries are stacking up behind each other waiting for memory to be granted. This is leading to poor performance and also timeouts.

We are working to get a different approach for these queries in place. We will let you know when a fix is ready. If you’re curious about what the queries look like, you can see the current and tentative rewritten queries here. The rewritten queries are using about 1/100th of the memory of the current queries.

To stay in touch with us, follow @nuget, or the #nuget tag on twitter for live updates. You can also check in on JabbR's #nuget room.


Leave a Comment
  • Please add 3 and 4 and type the answer here:
  • Post
  • Thanks for including a link to the SQL queries, folks! Really nice to be able to compare the changes.

  • Does "EF vs. Rewritten" indicate that EF writes SQL that causes memory problems with large-scale sites? IF so, then NuGet Manager seems to be a case study of why NOT to use EF on a large-scale site.  Am I misunderstanding?

  • @Jeremy I don't believe EF is at fault here. It's the way we have authored the EF queries and then wrapped OData around them. It's our own bad implementation, not a problem with the technology itself.

  • The good think about the performance issues is that I'm learning to use the Package Manager Console ¬¬'

  • Could you elaborate on "It's the way we have authored the EF queries and then wrapped OData around them"?  Do you mean that, had you written the EF queries differently, you would not have had the memory problem?  What would you have changed?

  • @Olly A

    The problem boils down to lack of control of the SQL statement that gets executed for OData requests, and we are using an OData service method for our own very hot-path scenarios.  When you open "Manage NuGet Packages" in VS, that results in an OData query.  We should have a specialized service method for that scenario, where we can control the SQL that gets executed behind it.

    Furthermore, our current service method for search returns full details for the matching packages - and the SQL statement that gets generated based on our very simple implementation yields 3-level nested selects where those full details are part of the results at each stage.  That's where the large memory grants come in.

    I can get EF to generate a query very similar to that I wrote by hand in T-SQL.  However, it's not straight-forward to get that working when the method must return an IQueryable for Data Services to apply OData requests to.

    At the end of the day, we have a very hot path where we're running non-performant queries against the database.

Page 1 of 1 (6 items)