Spreadshirt Techcamp 2018 - Hold until Told
Download as PPTX, PDF•0 likes•104 views
The document discusses using content tagging and purging to improve caching strategies for dynamic content at the edge network. It describes how caching everything can lead to serving stale content. Instead, tagging content with surrogate keys allows caching both dynamic and static content, while purging specific resources by tag when they change. This provides better performance than low expiry caching while maintaining freshness. Purging is fast through the Fastly API. Tag-based purging allows invalidating multiple related resources at once from the edge cache.
Spreadshirt Techcamp 2018 - Hold until Told
- 1. Hold until Told Spreadshirt TechCamp 10/2018 Martin Breest
- 2. Using content tagging and purging to get back control over freshness of cached content at the edge thereby improving performance and resilience of your services 2
- 3. Why do we cache content with Fastly at the edge anyway?
- 4. Comparison of uncached vs cached page load of www.spreadshirt.com on desktop from London 4 Source: https://www.webpagetest.org/
- 5. Cached page starts ~1.5 seconds earlier to render because of faster HTML delivery 5 Cached 1 second Uncached 2.5 seconds Source: https://www.webpagetest.org/
- 6. Without Fastly browser communicates with data center in Dallas and retrieves uncached HTML 6 Data Center Dallas Browser London 7644 km/ RTT ~105 ms for desktop influences load time >1000 ms page creation influences wait time Source: https://wondernetwork.com/pings/Dallas
- 7. With Fastly browser communicates with edge node in London and retrieves cached HTML 7 Data Center Dallas + Fastly Shield POP Browser London + Fastly Edge POP RTT ~10 ms -> >10 times faster ~20 ms cache page retrieval -> >50 times faster Source: https://wondernetwork.com/pings/Dallas
- 8. Distances in US are in general higher than in Europe 8 Dallas Los Angeles Seattle New York Miami 2703 km RTT 52 ms 2235 km RTT 43 ms 1991km RTT 34 ms 1787km RTT 29 ms Frankfurt Paris 477 km RTT 17 ms Source: https://wondernetwork.com/pings/Dallas https://wondernetwork.com/pings/Frankfurt
- 9. Load and wait times are much lower with Fastly for cached pages compared to uncached ones 9 Uncached Cached Source: Catchpoint CDN vs Origin www.spreadshirt.com
- 10. Great! So why don‘t we cache everything? 10
- 11. Area of tension between static and dynamic content 11 Dynamic Content Static Content Type HTML, API data (JSON, XML) User related content CSS, JS, Images Change Frequency Medium to High No or Low Caching No Yes Expiry Time Edge Node None High Expiry Time Browser No or Low Medium to High Control over Freshness High Low Performance Low to Medium High Resilience on Spikes Low High
- 12. Sometimes we sacrifice freshness to get better performance and resilience 12 Low Expiry StrategyDynamic Content Static Content Type HTML, API data (JSON, XML) User related content HTML, API data (JSON, XML) CSS, JS, Images Change Frequency Medium to High Medium No or Low Caching No Yes Yes Expiry Time Edge Node None Low to Medium High Expiry Time Browser No or Low No or Low Medium to High Control over Freshness High Low Low Performance Low to Medium High High Resilience on Spikes Low High High
- 13. Low expiry strategy is an exercise in your tolerance for mistakes 13 „Using the low-expiry approach has never been an optimal caching strategy since you sacrifice good caching to hopefully minimize how long you may serve stale content. (Also, your fingers probably really hurt from always keeping them crossed, since choosing these low expiry times is essentially an exercise in your tolerance for mistakes.)“ Hooman Beheshti, VP of Technology @ Fastly Source: https://www.fastly.com/blog/leveraging-your-cdn-cache-uncacheable-content
- 14. Can‘t we just notify the cache if content changes, like an inversion of control?
- 15. Good idea! Because most content is actually event- driven! 15 Event-Driven ContentDynamic Content Static Content Type HTML, API data (JSON, XML) User related content HTML, API data CSS, JS, Images User related content CSS, JS, Images Change Frequency Medium to High Low to Medium No or Low Caching No Yes Yes Expiry Time Edge Node None Medium High Expiry Time Browser No or Low No or Low Medium to High Purge on State Change No Yes No Control over Freshness High High Low Performance Low to Medium High High Resilience on Spikes Low High High
- 16. How does it work? On first browser request content gets cached with Fastly and subsequent requests get delivered from cache. 16 Browser Step 1 – Load homepage to cache: R R 1. Request homepage 1.1. Request homepage 1.2. Cache homepage with TTL of 24 houres 1.3. Cache homepage with TTL of 60 seconds Fastly Origin Browser Step 2 – A couple of seconds later ... deliver homepage from cache: R 2. Request homepage 2.2. Get homepage from cache2.3. Cache homepage with TTL of 60 seconds Fastly
- 17. On state change origin uses Purge API to notify Fastly of changes and subsequent request fetches new content from origin. 17 Step 3 – A couple of hours later ... notify Fastly on homepage change: R 3. Purge homepage 3.1. Mark homepage as stale or delete homepage from cache Step 4 – A few seconds later ... fetch latest homepage version from origin: Fastly Origin Browser R R 4. Request homepage 4.1. Request homepage 4.2. Cache homepage with TTL of 24 houres 4.3. Cache homepage with TTL of 60 seconds Fastly Origin
- 18. How does a purge request look like in Fastly? 18 Purge single entry • PURGE https://www.spreadshirt.com Purge all entries of a Fastly service (which handles www.spreadshirt.com for example) • POST https://api.fastly.com/service/SJ4xrdqVxxxxCFpF2FQ6i/purge_all Request Header: Fastly-Key: 05ce6d7d7293ebc35bb15135426d0000 Purges can easily be triggered from your application! Thousands of purges can be triggered per minute! Purges are really fast and run in ~150 ms! Documentation: https://docs.fastly.com/api/purge
- 19. Got it! But what do I do in more a realistic scenario with multiple resources involved? 19
- 20. Content tagging and tag-based purging to the rescue! Content can be tagged with surrogate keys • GET https://www.spreadshirt.com/hallowen+kids+premium+t-shirt-D1100053716?sellable=106995955 (article detail page) • GET https://image.spreadshirtmedia.com/image- server/v1/mp/designs/1100053716,width=178,height=178/hallowen.png (design image) • GET https://image.spreadshirtmedia.com/image- server/v1/mp/products/T815A2MPA1659PT17X23Y24D1100053716S38/views/1,width=800,height=800,appeara nceId=2,backgroundColor=E8E8E8,version=1516099426/hallowen-kids-premium-t-shirt.jpg (product image) Response Header: Surrogate-Key: d1100053716 Content can be purged using surrogate keys (tags) • POST https://api.fastly.com/service/SU1Z0xxxxPaozGVKXdv0eY/purge Request Header: Surrogate-Key: d1100053716 Fastly-Key: 05ce6d4d7793ebc35bb15135426d0000 Documentation: https://docs.fastly.com/api/purge
- 21. And that is it! 21
- 22. Conclusion 22 • Fastly‘s Purge API with instant purge capabilities allows to avoid the low expiry strategy and implement truly event-driven content, which allows to Cache dynamic content at edge nodes with medium expiry times Improve performance and resilience (and therefore user experience) Keep high control on content freshness (avoid stale data)
- 23. Is that all I need to know? 23
- 24. Actually, No! 24 • Implementing event-driven content, we also need to talk about State change triggers and how to implement them Revalidation between browser and edge node to keep traffic costs low Decomposition strategies to handle parts of a page with different change policies Vary headers to deliver different cached content on the same URL ... but that is enough content for the next presentation ...