Most likely, Visual Studio is trying to talk to nuget.org and other services. You can use Fiddler to see what connections are being made.

Thanks, that helped a lot. I removed some connectors to myget.org and it's getting faster.

Hello; Your best metric is going to be your users; if they're complaining it's slow, then it's probably too slow. My guess is that it's intermittant (during peak times). But in any case, it's not about the number of packages (a micro server can easily serve millions of packages nearly instantly), it's about the number of simultaneous connections (requests) to the server, and the features you've enabled (like license checking, etc). It sounds like you've got a single "2 core instance with 8gb of ram" server; while you can try to increase the hardware, the bottleneck is most likely network related; a single server might not just be enough to keep up with the traffic from your developers. Keep in mind that "plain old NPM" (i.e. registry.npmjs.org) runs on a massive, dedicated data center and is heavily cached (basically read-only). The ProGet Free to ProGet Enterprise article contains some general guidance that might help answer your questions: High Performance: 1 Server per 50 Developers. The network never slows down, never crashes. Average Performance: 1 Server per 100 Developers. The network slows down and drops productivity 10% on average during peak times daily. Acceptable Performance: 1 Server per 200 Developers. The network slows down and drops productivity 10-30% during peak times daily. Unacceptable Performance: 1 Server per 250+ Developers. The network is unstable and crashes. You can try disabling connectors, disabling license checking, disabling vulnerability scanning -- but those are really important features, so your best bet will be to plan for a load-balanced scenario.

Hi, please see: https://inedo.com/support/kb/1072/proget-vs-nugetserver

It seems like the problem is caused outside of ProGet. So, i would investigate Windows integrated Authentication (if you have it enabled, disable it as a test). Also look for other "random" IIS settings that may have inadvertently been changed. It's also possible to be networking equipment (bad router, switch, etc).

If the files contained in a zip being transferred as a whole, shouldn't they be appearing almost all at once? It's like downloading a file from your browser... the files are sent are written to disk as they are being streamed. Unfortunately, sometimes the .exe files is relatively large that their size increases gradually, therefore probably locked by the anti-virus tools while the deployment is still going. That could happen; it's possible the AV tool is acquiring a lock between chunks. In this case, your best bet would be to disable the AV tool or, if not possible, then use the zip method you described.

Sure, here are the main ones as of v4.0.6 which we released ealier today: OData output caching may be optionally configured in Advanced Settings that should improve package installation performance since the NuGet client (both .exe and VS extension as of v3.3.0) always issues 2 identical requests when querying for package data or downloading packages ProGet now respects the NuGet client's Accept-Encoding header which has recently added gzip; this may reduce package download times considerably Currently, the biggest bottlenecks on performance are related to connectors reaching out to NuGet.org, especially when combined with connector filters. Connector filters especially may cause slowdowns if the connected NuGet feed does not optimize the OData "startsWith" filter. In a future version, we are planning to have scheduled tasks index NuGet.org so that connectors can be filtered in ProGet's database, which will be instant in comparison to a basic 3-filter connector query.

We've finally tracked down what was causing this issue. We had two feeds configured that both had two connectors that connected back to the same ProGet server on different feeds. Turns out that this causes a very high request queue on the ProGet server, which in turn caused timeouts and eventually errors during package restore. I've now created a separate web application in IIS hosting the same ProGet folder but running on a different port and configured those two feeds to connect to the other port. This seems to alleviate the problem for now. Would be nice though if this was supported by ProGet itself. I've seen many artifact repositories that support such a feature where sort of virtualized feeds can be created by combining other feeds.

I've read that NuGet's architecture is being redesigned for version 3.0, which should also improve the performance. http://blog.nuget.org/20150608/nuget-server-status.html http://blog.nuget.org/20150601/nuget-3.0-rc2.html

Excellent, version 3.4.2 installed and download is now pretty much instant! Many thanks for the incredibly quick turnaround.

No, this is not a known bug... it may be related to your IIS settings, or something else. Regardless, that's a really really really big package!! You should reevaluate how you have packages > 100mb, let alone 1gb! Best practices dictate to keep these as small as possible.

Hi Simeon, Windows XP is definitely not going to be a reliable server :) The TCP stack is deliberately throttled/crippled to prevent server usage.

Indexing is currently done in-memory (as opposed to a separate indexing service/database), which can obviously lead to issues like this on very large datasets. I've shot you an email, and we're investigating some options.