Nov 23, 2010 at 8:14 PM

Right now on our test NuGet.Server we do pretty aggressive http caching and also memory in memory caching of package metadata. 

For the feed, we have 2 levels of caching:

  • We cache the metadata in memory from the file system (our database) based on the last modified date of each package file. 
  • We layer on regular http caching based on the last modified date of the packages directory.

This makes the server pretty fast, and even when a new package is added, only the added file needs to be unzipped for metadata (this wouldn't apply to your server).
The http caching allows our clients to cache data locally and send requests that check if it is ok to use the cached content (basic http caching):

  1. The client sends the first request for the feed and gets the data back along with a last modified header from the server (which is the last time the folder with packages was modified).
  2. On subsequent requests, the client sends an if-modified-since header to the server asking if the feed changed for a certain url. If it didn't change it'll return a 304 (not modified). If it did change we loop over all the files in the directory and update the in memory cache with metadata for new or change files.

We do the same kind of caching for file downloads that are on our server using the last modified date of the file.

We need to think about how we're going to do caching for the gallery server. Do you guys have any thoughts on this?

Nov 23, 2010 at 8:36 PM

This came up in the conf call this morning.  David, can you point them to our code where we do this?  Since it's pretty tricky to get it right, that could save some time.

Nov 23, 2010 at 11:29 PM

In the NuGet sources, the feed caching logic is here:


There are other helpers that play a part in the caching logic:


Hope that helps.