Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nkolev92 opened this issue May 13, 2021 · 4 comments
Open

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

nkolev92 opened this issue May 13, 2021 · 4 comments
Labels

Comments

@nkolev92
Copy link
Member

nkolev92 commented May 13, 2021

Blocked on NuGet/NuGetGallery#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 NuGet/NuGetGallery#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
Copy link
Member Author

@nkolev92
Copy link
Member Author

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

@nkolev92
Copy link
Member Author

nkolev92 commented Feb 9, 2022

Prototype in #11483.

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

@donnie-msft donnie-msft self-assigned this Jul 5, 2022
@JonDouglas JonDouglas added this to the .NET 8.0 milestone Mar 22, 2023
@nkolev92 nkolev92 modified the milestones: .NET 8.0, 6.8 Jun 29, 2023
@nkolev92 nkolev92 modified the milestones: 6.8, 6.9 Oct 19, 2023
@jgonz120 jgonz120 modified the milestone: 6.9 Jan 31, 2024
@loic-sharma
Copy link
Contributor

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: #8058 (comment)

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.

@donnie-msft donnie-msft removed their assignment Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants