Cache response types

Understanding cache response types can help you gain insight into the effectiveness (or ineffectiveness) of your CDN and your origin server, as well as the relationship between the two.

nodeboost.io uses 6 cache response types which are viewable in both our real-time logs (we’re working on our real-time logging feature right now, using Elasticsearch) and the Activity screen for each of your nodeboost.io configurations:

  • CACHE_HIT – The file was served from cached copy. No hit was made against the origin server. Size recorded will be the size of the file on disk.
  • CACHE_MISS_CACHE – The file was not found in the cache, therefore a request to origin was made and the content was pass-thru streamed to the end user while at the same time cached on nodeboost.io. Size recorded will be the size in Content-Length header sent by the origin server for the file.
  • CACHE_MISS_EXPIRED – The cache record indicates that the file has gone over the TTL (time-to-live) and has therefore expired. The file will be re-downloaded from origin and pass-thru streamed to the end user. Size recorded will be the size in Content-Length header sent by the origin server for the file.
  • CACHE_MISS_STREAM – The cache record states the file is in “DOWNLOADING” state, probably from a previous “CACHE_MISS_CACHE”. Since the file is already being cached, there is no need to create another cached copy on nodeboost.io. Since it is still downloading it is not useful to read the incomplete cached copy and send it back to the client. So we hit the origin server for this. Size recorded will be the size in Content-Length header sent by the origin server for the file.
  • CACHE_MISS_SOURCE_FAILED – The cache engine received an error while trying to retrieve the content from origin. This indicates non-HTTP errors while connecting to your origin server. For example, DNS name resolution errors or network connectivity errors.
  • CACHE_MISS_OTHER – The cache engine received an error while trying to retrieve content from origin. This indicates HTTP-related errors while connecting and trying to GET content from your origin server. For example, HTTP 4xx or HTTP 5xx errors.

If your CDN and origin server are configured correctly then the ratio of CACHE_HIT responses to other responses will be as high as possible, thereby translating into a ‘hit ratio’ of (hopefully) 99%+ for static content.

What about dynamic content (or “event driven content” as Fastly more aptly names it) you ask? That’s another story, and we’ll leave that one for the another blog post 😉