Hi Dean,

we noticed that when performing an "npm install" against ProGet it will successively open ~1000 sessions.

We tried a couple of values for Web.ConcurrentRequestLimit under "Administration --> Advanced Setting" (20, 50, 100, 200) and found out, that when using 100 we get the same (or even better) performance for an "npm install" compared to registry.npmjs.org. We're not exactly sure how Web.ConcurrentRequestLimit works but we assume that it has some relation to the default pool size for the SQL Server connection used by ProGet, which also seems to be 100.

I just wanted to let you know, that by setting Web.ConcurrentRequestLimit to 100 the performance of "npm install" is back to normal.

Best,
Andreas

Hi Dean,

we noticed that when performing an "npm install" against ProGet it will successively open ~1000 sessions and shortly after that a number of the aforementioned timeout errors will be logged.

We tried a couple of values for Web.ConcurrentRequestLimit under "Administration --> Advanced Setting" (20, 50, 100, 200) and found out, that when using 100 we get the same (or even better) performance for an "npm install" compared to registry.npmjs.org. We're not exactly sure how Web.ConcurrentRequestLimit works but we assume that it has some relation to the default pool size for the SQL Server connection used by ProGet, which also seems to be 100.

I just wanted to let you know, that by setting Web.ConcurrentRequestLimit to 100 we're no longer seeing these kind of errors being logged and also the performance of "npm install" is back to normal.

Best,
Andreas

@dean-houston Thank you for your insights.

The logged exceptions all occurred when I was doing an "npm install" with a small sample project while being the sole user of the ProGet instance in question. The "npm install" resulted in 727 packages being installed. As far as I can tell, that's a pretty normal scenario and one should not expect this to be overly demanding for a package server.

That being said, I'm fully aware of the fact that ProGet has a lot of things to do in this scenario. We've stopped using the NuGet v2 API some time ago but we won't be able to reduce connector usage as this feature is one of the primary reasons for us to use ProGet in the first place. ProGet being able to act as a "filtering proxy" for public package registries that allows us to block access to packages based on license type or vulnerabilies is the reason why all of our developers must install the packages from our ProGet instance instead of public registries.

So for now I think we need to have a look at setting up a server cluster.

Thanks again!

Hi,

when running package restores (npm and NuGet packages) we're seeing many timouts being logged on ProGet Version 2023.27 (Build 5):

What's possibly going wrong here? Is there anything we can do to avoid these?

Thanks in advance!
Andreas

Hi,

we're currently running ProGet Version 2023.27 (Build 5). We have a npm feed configured as a proxy feed for https://registry.npmjs.org.

We've noticed that npm install is significantly slower when using our proxy feed (compared to directly installing from npmjs.org) even when all requested packages are cached on the ProGet server.

Our test scenario ist this:

• empty npm cache

• delete node_modues directory

• delete package-lock.json file

• run npm install

Results:
ProGet: 02m35s
npmjs.org: 00m38s

= ~4x slower with ProGet

Is anyone else experiencing the same behavior? Any tips how to speed things up with ProGet?`

Thanks in advance!
Andreas