search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Don't hit registration to gather deprecation/vulnerability metadata #10865

Open nkolev92 opened 3 years ago

nkolev92 commented 3 years ago

Blocked on https://github.com/NuGet/NuGetGallery/issues/7297.

A lot of the feedback centered around the PM UI has to do with how sluggish and heavy the UI looks. Some of the problems are technical decisions in the PM UI, some are UX driven, others are a little bit of both.

Say you create a new project and you open the PM UI. 0 remote calls happen because NuGet will default to the installed tab. Switch to the browse tab. You get 1 search call + N registration calls, where N is the number of loaded packages. The logic behind this registration call is fetching vulnerability and deprecation information.

Registration pages can be just as large and as heavy to parse as the search ones.

This "trick" is there due to https://github.com/NuGet/NuGetGallery/issues/7297.

Given the repeated feedback about the clunkiness of the PM UI, I think we should ask the server team to prioritize this ask, and we should follow up on the equivalent client side.

Alternatively, we can hack it and only fetch metadata whne nuget.org is the source. This idea is bad. Current perf is worse.

nkolev92 commented 3 years ago

cc @donnie-msft @jebriede @aortiz-msft

nkolev92 commented 3 years ago

Triage: This change is blocked on a server feature. @JonDouglas to make sure it's on the unified backlog.

nkolev92 commented 2 years ago

Prototype in https://github.com/NuGet/Home/issues/11483.

Already on the backlog, so need to keep it assigned to Jon.

loic-sharma commented 9 months ago

FYI, a simpler solution may be to reconsider the registration API's paging strategy. Currently, the registration API splits package's information into groups of 64 package versions. This page size appears to be much too low. Making registration pages include more package versions would reduce the number network requests the client needs to do without needing to update the protocol or clients.

See: https://github.com/NuGet/Home/issues/8058#issuecomment-626465454

I made a tool to help estimate response sizes if we removed paging from the registration API altogether. The resulting registration indexes had the following size on disk after gzip compression:

  • Average size: 1.15 KB
  • 90th percentile size: 1.82 KB
  • 99th percentile size: 8.60 KB
  • 99.9th percentile size: 25.1 KB
  • 99.99th percentile: 60.76 KB
  • Max size size: 223 KB

In other words, it appears that paging is unnecessary for 99.99% of packages on nuget.org. An alternative solution to this problem could be to shove more package versions in each registration page.