Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Varnish Cache - step by step
Semelhante a Varnish Cache - step by step (20)
Mais de Per Buer
Último
Último (20)
Varnish Cache - step by step
- 2. Varnish Cache Step by step
- 5. About Varnish Cache ● Web app accelerator ● Fast ● Flexible
- 6. VCL • • Varnish Configuration Language • • Hook custom logic into the flow Applies to transactions that flow through the cache Main hooks used: vcl_recv and vcl_fetch
- 8. About Varnish Software ● The company behind Varnish Cache ● Offers “Varnish Plus” - consisting of: ○ Additional software ○ 24/7 support ○ Professional services
- 9. Goal Knowing what to do to speed up your website.
- 11. Designing a web app for Varnish ● Build apps from the ground up for Varnish ● Intelligent cache usage ● Proper cache invalidation ● Monitoring
- 13. Incremental implementations ● Deploy Varnish on existing apps ● Gradually increase caching ● “Low hanging fruits” first
- 14. Requirements ● Linux or FreeBSD ● Virtualization is OK, not awesome ● Tuning is only for high traffic
- 15. Step 1: Installing Varnish Difficulty level: Easy Payoff: Minor
- 16. Step 1: Pass through only ● Passive Varnish ○ return(pass) in vcl_recv ● Powerful load balancing ● Health checks built in ● Excellent for debugging webapps
- 18. Step 2: Cache static assets Difficulty level: Trivial Payoff: Minor
- 19. Step 2: Cache static assets ● Cache images, CSS, Javascript ● Backend concurrency decrease ● Backend bandwidth decrease ● Minor CPU usage decrease
- 20. Step 3: Compression Difficulty level: Trivial Payoff: Medium
- 22. Step 3: Compression ● GZip compress CSS/Javascript ○ JQuery standard: 263KB ○ JQuery minified: 91KB ○ JQuery gzipped: 32KB ● Compress in one place only ● Reuse compression ● Move CPU load from backend
- 23. Step 4: Semi-static caching Difficulty level: Medium Payoff: High
- 24. Step 4: Semi-static content caching ● Dynamically rendered content ● Expensive to render ● Almost never changes ● Set short TTL (10-120 seconds) ● Mitigates traffic peaks
- 25. Step 4: Semi static (2/2) ● Manual cache expiry ● Magic URLs ● Shift-refresh from special IP-range ● Web interface for ban or purge
- 26. Step 5: Autopurge Difficulty level: Medium Payoff: High
- 27. Step 5: Autopurge ● Backend generates purge requests ● Set TTL to ~forever ● Invalidate on change ● Can be difficult for composite pages ○ Map relationships between data and pages
- 28. Step 6: Grace mode Difficulty level: Easy Payoff: High
- 30. Step 6: Grace mode • Originally developed to mitigate pile-ups • Can serve “graced” content when fresh content is unavailable • Unavailable means • • backend down object busy
- 31. Grace mode (2) • Both req.grace and beresp.grace must accept the old object • Tip: Set req.grace to 10s normally and 1 hour when backend is down
- 32. Step 7: Content composition with ESI Difficulty level: Hard Payoff: High
- 33. Edge Side Includes (ESI) Horrible Designed News Site Blah Article snippet 1 Welcome, Foobar (logout) Article snippet 2 Top 10 popular news items Article snippet 3 Article snippet 4
- 34. Edge Side Includes (ESI) TTL: 1800minutes TTL: 30min TTL: 60min, user specific TTL: 30min TTL: 1min TTL: 30min TTL: 30min
- 35. Step 7: Content composition ● Edge Side Includes (ESI) ● Split web pages into pieces ○ Individual caching policies ○ One piece = one URL ● Live stitching of content ● Works with compressed content as well
- 36. <html><body> ... <esi:include src="/frontpage/ breaking" /> ... <esi:include src="/frontpage/latest" /> ... <!-- Do we like the cache to meddle with content? --> </body><html>
- 37. Step 8: Advanced cache invalidation Difficulty level: Hard Payoff: High
- 38. Step 8: Advanced cache invalidation ● Sometimes a page relies on multiple “objects” for invalidation ● Finding out what object need to expire what pages can be hard ● Typically a problem in e-commerce and media
- 39. Advanced cache invalidation (2/2) ● Tag pages with custom headers ○ X-Skus: 49834, 34321, 4343 ● Execute with bans or hashninja ● Possible database driven expiry (triggers)
- 40. Conclusions ● High rewards with little work ● 3 - 15 days to reach “high” payoff ● Requires backend knowledge to do significant changes ● We talked about what to do - if you want to learn more about how please read the book or sign up for training.
- 41. Q &A