Package Manager UI loads all registration pages

[loic-sharma]

Details about Problem

Visual Studio's 2019's Package Manager UI is very slow to load packages with many versions. This happens because Visual Studio loads the metadata for all versions of the package immediately.

Suggestion

Ideally, Visual Studio's UI should only do up to three requests:

1. Search for packages. The packages' list of versions should be generated using the search results' versions field.
2. Load the package's registration index. Example: https://api.nuget.org/v3/registration3-gz-semver2/fake/index.json
3. If necessary, load the latest version's registration page. Example: https://api.nuget.org/v3/registration3-gz-semver2/fake/page/4.64.13/5.8.4.json

The differences between this suggestion and the current implementation:

1. The version list is generated using the search response.
2. Only load ONE registration page instead of ALL registration pages.

/cc @dtivel @nkolev92

Detailed repro steps so we can see the same problem

1. Open Fiddler
2. Open "Manage Packages"
3. Open the "Browse" tab
4. Search for "FAKE"
5. Look at the requests on Fiddler
6. Try to select another "Version" on the right-hand side (this is very slow)

Blocked by NuGet/NuGetGallery#8067.

[nkolev92]

Basically this proposal moves the initial load from taking the perf hit to the having the switching of versions take the perf hit.

What we perceive an average user behavior on the search page, should impact the decision here.

[loic-sharma]

Basically this proposal moves the initial load from taking the perf hit to the having the switching of versions take the perf hit.

This is not necessarily true. Several popular packages have over a thousand versions, resulting in 16+ registration pages (each page contains 64 versions). The current implementation needs at least 17 HTTP requests (1 registration index + 16 registration pages). My suggestion would cut that down to 2 requests for the most common customer scenarios. Assuming reasonably fast response times of 200ms and no caching, this suggestion would save 3+ seconds to browse popular packages like FAKE or AWS SDK. The effect would be even more dramatic for customers that aren't in North America (especially India, Australia, Brazil).

[nkolev92]

Long time dup of #2495, I just didn't find it back then..

[donnie-msft]

Reopening this one in favor of its details over #2495 .

[nkolev92]

Another related issue #8492

[loic-sharma]

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.

[nkolev92]

Found yet another dup of this.
That one is older and has comparable amount of information.

I want to dup this to #4448?
Thoughts @donnie-msft ?

[nkolev92]

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.

@loic-sharma Is the paging strategy the number of versions right now?

I think the client should be a bit more resilient anyways.

[loic-sharma]

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.

@loic-sharma Is the paging strategy the number of versions right now?

Yup, today we page a package's registration once it has over 128 versions. We create a page for each chunk of 64 versions.

[nkolev92]

Currently the deprecation experience calls for a deprecated message in the drop down when looking at the version list.
We can't do that without NuGet/NuGetGallery#7297, so marking that issue as a blocker.

edit
Zenhub won't let me add blockers cross repo, so editing the body :)

[nkolev92]

We can technically do the work on the client side, and just only consider it implemented when the server side change goes in.
This would be beneficial for non-nuget.org servers anyways. I think there's plenty of potential work in S173 right now, so moving to S174 for the time being.

[nkolev92]

• Only applies to NuGet.org as other feeds don't paginate today.
• Most packages on NuGet.org are not affected by it.
• The implementation cost is significant.

Lowering to priority 3.