TellerHttpCaching

HTTP Caching In Teller

Introduction

Glance consists of two services, Parallax, the image registry, which stores image metadata describing the image and where to fetch it, and Teller which acts as a proxy for the object store containing the actual image data. Both Parallax and Teller are HTTP servers and therefore can benefit from the performance improvements offered by HTTP caching. The following is a proposal for how to add HTTP caching to the Glance project, and in particular the Teller sub-project (for Parallax see ParallaxHttpCaching).

It should be noted that HTTP caching is not the only type of caching that could improve the speed of OpenStack builds. Down the road, we leave open an option for adding memcached to Parallax, a Bit-Torrent distribution system within the cluster and any number of other options. We are starting with HTTP caching first since it will offer a dramatic savings in bandwidth and performance without a lot of work and at the same time as a clear implementation path dictated by RFC 2616.

Background on HTTP Caching

HTTP caching is built on two fundamental concepts, freshness (aka cache-expiration) and validation. The expiration policy is governed by the max-age Cache-Control header (we are not using the Expires header since it requires clock synchronization between the client and the origin server). Validation, a process of verifying that cached data is still accurate, occurs by using a validator header, either Last-Modified or the Etag header added by HTTP/1.1. For this spec, we will only use Etag (Last-Modified suffers the same clock synchronization issues as Expires).

These two headers, Cache-Control: max-age and Etag will provide the information that client caches or transparent caching proxies (Squid or Varnish) need to make informed cache descions regarding eviction and validation.