-
Type:
Improvement
-
Status: Open
-
Resolution: Unresolved
-
Affects Version/s: 7.21.0, 7.27.10
-
Fix Version/s: None
-
Component/s: NuGet
-
Labels:None
-
Environment:
7.21.13 Pro in Kubernetes deployed with Helm
Checked against latest 7.27 as well
-
Location:External
The NuGet v3 API exposed by Artifactory does not provide an endpoint for the 'Package content' resource.
NuGet clients expect this resource to be available so that when a project asks for a specific version, they can efficiently tell whether a given source has that version available. You can see an example of this working on NuGet.org here:
https://api.nuget.org/v3-flatcontainer/xunit/index.json
The client then can directly request for the package at the same resource, like this:
https://api.nuget.org/v3-flatcontainer/xunit/2.4.1/xunit.2.4.1.nupkg
NuGet clients will fall back to a v2-ish behaviour if they can find the RegistrationsBaseUrl resource (which Artifactory provides) - however this means the client then paginates through all of the pages provided in that response (NuGet.org example below
https://api.nuget.org/v3/registration5-gz-semver2/xunit/index.json
This pagination causes enormous memory consumption for Artifactory, and will crash the application if a moderate number of clients attempt restores against packages with high version counts (>15,000 in our case for one package). This was previously reported as RTFACT-25080 - in our case we are seeing Artifactory 7.21.13 consume 90GB of memory to respond to all of the requests. I'm not asking you to fix that, necessarily, I think that this can be addressed by providing the Package Content resource instead.
You can also see a customer raising this as an issue against NuGet itself here
I've attached a client-side log of the behaviour; you'll see by the end the client is waiting 30+seconds for responses as the server is overwhelmed.