Rely on explicit deleted-entry documents to indicate that cached data is invalid, rather than matching counts. We now check for an active entry with a modification time later than the cached data and for a deleted entry with a modification time later than the cached data. This eliminates the slow count query entirely, which helps both the cache hit and cache miss latency.
Stream data from S3 to the client rather than issuing a redirect. The latency overhead for a HEAD request to S3 can be significant, and we ended up forcing the client to incur the same latency when it followed the redirect. Instead, we request the whole object. If the cached data is stale, we don't use the actual object contents, only the header info. If the cached data is good, we either issue a 304 Not Modified or stream the data to the client. This method also lets us apply gzip encoding more easily.
hampelm
commented
9 years ago
Rely on explicit deleted-entry documents to indicate that cached data is invalid, rather than matching counts. We now check for an active entry with a modification time later than the cached data and for a deleted entry with a modification time later than the cached data. This eliminates the slow count query entirely, which helps both the cache hit and cache miss latency.
Stream data from S3 to the client rather than issuing a redirect. The latency overhead for a HEAD request to S3 can be significant, and we ended up forcing the client to incur the same latency when it followed the redirect. Instead, we request the whole object. If the cached data is stale, we don't use the actual object contents, only the header info. If the cached data is good, we either issue a 304 Not Modified or stream the data to the client. This method also lets us apply gzip encoding more easily.
/cc @hampelm