HTTP Caching For The Win - REST Fest 2013
2 likes1,638 views
This document summarizes the development of a mobile app and supporting architecture for a media platform hosting Dave Ramsey's radio show. Key points: - An iOS native app and web app were developed to stream video of the radio show online. This required a media service API and content delivery network. - The media service abstracted away the vendor's feed API and used HTTP caching headers like "stale-while-revalidate" to improve performance when content became stale. - Techniques like ETag generation and HTTP/2 support were added to make the media service more robust and efficient as traffic increased.
HTTP Caching For The Win - REST Fest 2013
- 1. HTTP Caching FTW A Brief Project Retrospective
- 2. Phil Harvey Web Developer/Architect The Lampo Group, Inc. (Dave Ramsey) http://developwithpurpose.com
- 3. Background
- 4. Hosted by Dave Ramsey Focuses on real life & money Nationally syndicated radio program On the radio for over 20 years 4.5 million weekly listeners The Dave Ramsey Show
- 5. What Could Be Next?
- 6. Online Video Channel Take the Dave Ramsey Show to a new format (online video) HD video Accessible via mobile and web
- 7. User Experience: Native iOS App
- 10. HyperBek HAL+JSON Hypermedia-aware HAL+JSON client Open Source Apple NSURLConnection APIs Accepts gzipped encoded response bodies Only base API URL is hard coded iOS App
- 12. Media Platform (Channel Programming, MetaData) Media Service/API (Content Metadata) Content Delivery Network (Streaming, On Demand Video) iOS Native Client, Web App Client Apache Memcached
- 14. Media Service Read-only (GET requests) REST API Hypermedia-Driven HAL+JSON media type Abstracts away media vendor-specific feed API Strategically bundles/unbundles responses Responds faster than media vendor API Java/Spring MVC/Tomcat
- 15. Launch Week Stats Approx. 20k app downloads within first 24h Approx. 73TB video served per day by CDN
- 16. Average RPM to Media Service... (RPM = Requests Per Minute)
- 17. 6-8 RPMs Wait thats not quite right or is it?
- 19. Challenge: Stale cache causes requests to block until fresh content is served
- 21. HTTP Cache-Control Extensions for Stale Content RFC5861 Authored by Mark Nottingham Extends HTTP/1.1 Cache-Control header Cache-Control: stale-while-revalidate={max-stale-seconds}, stale-if-error={max-stale-seconds}
- 22. HTTP Caching GET /feed Cache-Control: stale-while-revalidate=300, stale-if-error=300 GET /media/channel/tdrs/ Cache-Control: max-age=300 ETag: "5247caf6a9a327864ee1- 3ac0af56e4267cc39593"
- 23. Media Platform (Channel Programming, MetaData) Media Service/API (Content Metadata) Content Delivery Network (Streaming, On Demand Video) iOS Native Client, Web App Client Apache Memcached
- 24. (from the Vendors feed API) Challenge: Flaky Last-Modified response headers
- 25. Solution: Generate ETag based on vendor response (using MurmurHash3)
- 26. Why MurmurHash3 Super fast (vs MD5, SHA1) Generally low collisions/highly distributive Java implementation readily available (Google Guava library)
- 27. One more thing... Media Service Today Implementation fully bundles all resources in root resource by default, via HAL+JSONs _embedded feature Media Service Tomorrow Once HTTP/2.0 is available, all resources can be unbundled, and clients will transparently fallback to link relations and GET requests
- 29. Cache is King
- 30. Resources MNots Caching Tutorial: http://www.mnot.net/cache_docs/ MNots stale-while-revalidate/stale-if-error: http://tools.ietf. org/html/rfc5861 RedBot: http://redbot.org (explains caching headers in English) MurmurHash3: http://en.wikipedia.org/wiki/MurmurHash HyperBek Objective-C Library: https://bitbucket. org/dcutting/hyperbek HTTP/2.0 WG: http://datatracker.ietf.org/wg/httpbis/charter/