nuget api calls blocking proget

parthu.reddy

Hi Team

We've a question on nuget api calls blocking proget.

We've been facing issue while connecting to proget recently, after some investigation with our IS team they have provided below info.

Looking at one of the failures from this morning, we can see that ProGet served no requests while it was busy establishing >200 outgoing connections

For the above time (09:15 AEST), it was 23.46.10.74 and 23.46.10.19, which according to the DNS audit logs is api.nuget.org.

SQL server seems healthy. But perhaps ProGet holds a table lock for longer than we want it to. A client successfully holding a lock isn't a "problem" from the perspective of MSSQL itself.

Is there any possibility that api calls to nuget is blocking proget servers?

Proget version we're using: Version 2025.15 (Build 9)

If possible we would like to know what calls are being send to nuget to analyze the requests being made.

Thanks
Parthu

dean-houston

Hi @parthu-reddy,

Thanks for the detailed investigation notes. From what you've described, the behavior doesn't appear to be related to SQL Server locking. It's most certainly related to blocking/waiting on the 200+ outgoing connections to receive a response from api.nuget.org.

If api.nuget.org is running slow, then ProGet will run slow. There's really no way around this when you use connectors, as ProGet is effectively forwarding client requests.

Most likely, someone or some build server is making legacy/V2 NuGet API requests (they look like ODATA/SQL queries on the url), and those are being forwarded. The V3 requests are just JSON files.

-- Dean

parthu.reddy

Thanks for confirmation, but we've a limit of 5000 concurrent requests on proget server

We only enabled v3 at feed level actully

And we didn't enable metadata caching, should we enable this to avoid these issues?

dean-houston

Hi @parthu-reddy ,

Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what.

As for your configuration...

5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead.

I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard.

It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage.

-- Dean