Gallery assumes it receives all requests for package downloads, causes wrong statistics if proxies cache packages

[akoeplinger]

As discussed in pull request #505, the gallery assumes it receives all requests for downloading packages, so package statistics are created inside the GetPackage ApiController action when a client requests a package. If packages are cached at the client or proxy server, the download statistics will be wrong as the gallery never receives the request.

Note that this currently only applies to local installations of the gallery, as the main nuget.org site runs on Azure and redirects download requests to Blob storage without a caching header. If caching is enabled on the Blob storage however, this issue will apply there as well.

Generally, I think the concept behind counting downloads should be changed. As of now, every single action that requests the package bytes will increment the download counter. With features such as package restore it's far more common that packages are fetched many times, while this doesn't mean they are necessarily "new" in a project. Imagine a company that uses package restore and does a high number of clean builds a day on a CI server. The downloads for packages they used will sky-rocket very soon, leading other users into thinking these packages are popular.

In my opinion, the statistics would be much more meaningful if the counter ist only incremented when a user installs a package via the package manager console or the VS dialog. This way, we could also cache the package bytes at a proxy server forever while still allowing the gallery to show a useful download count. This could also be called "installation count" instead, if you want to keep the existing meaning.

[matthewskelton]

+1 for suggestion by @akoeplinger regarding "installation count" vs. "download count".

[half-ogre]

We have previously discussed the idea of better tracking what it means to install versus download, throttling count based in a time window, etc. All good things, potentially, but not very high on the list of priorities, currently.

[analogrelay]

We're now tracking three different operations for each request: Install, Update or Restore. The NuGet client reports which of these three operations is in progress when a package is requested and we track that. We're working on building reports as this data comes in, but the underlying data collection is in production now.