Note that if you’re streaming large audio or video files, this list may not be a good one for you.  The questions are biased towards StyleFeeder’s needs, namely the fact that we have tens of millions of small product images floating around.

CDN Evaluation Criteria:

1. Do you support HTTP compression?  Does content have to exceed a minimum size in order to be compressed?  (i.e. content less than 2Kb is not compressed)
2. Do you allow us to override the Expires headers being sent by the origin?
3. Will you obey long Expires headers (5 years) and cache content accordingly?
4. Once a piece of content has been cached on your network, under what conditions would your CDN re-request that content from the origin?
5. Do you allow full and partial (based on regexes) cache flushes?
6. Can you demonstrate that you’re better than one of the “value” CDNs?
7. How many nodes do you have?
8. Do you have a lazy-loading caching proxy scheme (like Akamai, Panther, Voxel) to allow for easy deployment?
9. Is there an API we can use to add or flush content?

Let me know if you have other questions that should be on the list!

One unique feature of Nginx is the notion of mirror-on-demand, which I recently explained to a friend as caching but without a removal policy. What we wanted was our static asset server to do was exactly this. We’re using this as a way to get content from our backend app server and then to cache it forever in the filesystem that our nginx servers can read from. It turns out that both Apache and Squid simply cannot do this 100% of the time. Various combinations of Cache-control headers and non-conditional GET requests will cause requests going to the backend, which, in our case, was exactly what we were trying to avoid. Plus, I was also looking for HTTP compression for text/* mime-types. Squid doesn’t do compression, period. It does, however, do de-compression, so you can get gzipped content from a backend server and then serve it up uncompressed, which may be useful in some arcane cases.

I should mention here that our first choice was actually to use Lighttpd with mod_cache, which is capable of doing this kind of “only retrieve this content from the backend exactly once” caching. However, within literally minutes of deploying, we ran into corruption issues with some Javascript and CSS content that we didn’t detect during our testing. I saw many instances of corrupted cache content during the time that we used Lighttpd and mod_cache and quickly decided that I needed to explore other options.

Our experience with nginx was great from the start. Most of the docs are in Russian, but the English docs are very well done and quite adequate all around. Configuration is a cinch and deployment was easy as pie. The only hiccup was that I noticed that nginx does not set a Content-length header on content that has undergone HTTP compression (gzip). This is minor for our purposes.

In short, nginx rocks hard.