Slow file-protocol nuget feeds

Our build server generates lots of packages into a local file based nuget feed, and we’ve been finding that sometimes the “octo.exe create-release” command can take over 5 minutes to complete. It always completes successfully but this wait time is pretty painful.

Does anyone know if Octopus would be more efficient at refreshing feed status if we switched to using a nuget web feed? It seems like most of the time is wasted diddling files in the UNC share. I’m thinking if the web feed keeps an index of packages, it would help a lot. On the other hand I don’t want to waste time setting up a web feed if it won’t help.

Additionally, I’ve noticed that if the same package is deployed in different steps, the feed will be refreshed once for each step. This is a spot that could be optimized in the server, but could also be optimized in octo.exe.

Hi Chris,

I’ve seen good performance improvements when switching to a NuGet.Server-based server instead of the file share, for the reasons you stated - NuGet.Server will build the index once and serve from cache. You could also test it out by using - a hosted NuGet service.

Hope that helps,