getting started with varnish
2 likes434 views
Varnish Cache is a web application accelerator that can speed up websites. It works by caching content and serving it to subsequent requests, reducing load on backend servers. The document outlines 9 steps to implement Varnish Cache, starting with easy steps like caching static assets and compression, then progressing to more complex techniques like caching semi-static content, graceful degradation, and advanced invalidation methods using custom headers. Implementing the initial steps provides minor speed improvements, while fully utilizing Varnish Cache through techniques like content composition and invalidation can yield high performance gains.
getting started with varnish
- 2. Varnish Cache Step by Step Federico G. Schwindt Technical Presales Engineer Varnish Software
- 4. AboutVarnish Software ● The company behindVarnish Cache ● Offers “Varnish Plus” - consisting of: ○ Additional software ○ 24/7 support ○ Professional services
- 5. Insert business logic here
- 6. AboutVarnish Cache • Web app accelerator • Fast • we measure TTBF in µs • Flexible • Some assembly required :-)
- 7. VCL • Varnish Configuration Language • Applies to transactions that flow through the cache • You can hook custom logic into the flow • Main hooks used: vcl_recv{} and vcl_backend_response{}
- 9. Goal Knowing what to do to speed up your website.
- 11. Designing a web app for Varnish ● Build apps from the ground up forVarnish ● Intelligent cache usage with cache headers ● Proper cache invalidation ● Monitoring
- 13. Incremental implementations ● DeployVarnish on existing apps ● Gradually increase caching ● “Low hanging fruits” first
- 14. Requirements ● Linux or FreeBSD ● Virtualization is OK, not awesome ● Tuning is mostly for high traffic
- 15. Step 1: Installing Varnish Difficulty level: Easy Payoff: Minor
- 16. Step 1: Pass through only ● PassiveVarnish ○ 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. Difficulty level: Medium Payoff: High Step 5:Autopurge
- 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. Difficulty level: Easy Payoff: High Step 6: Grace mode
- 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) • Period set via beresp.grace • Serving actually controlled in vcl_hit{} • Tip: Use 10s normally and 1 hour when backend is down
- 32. Difficulty level: Hard Payoff: High Step 7: Content composition with ESI
- 33. Article snippet 1 Article snippet 4 Article snippet 3 Article snippet 2 Welcome, Foobar (logout) Top 10 popular news items Horrible Designed News Site Blah Edge Side Includes (ESI)
- 34. TTL: 30min TTL: 30minTTL: 30min TTL: 30min TTL: 60min, user specific TTL: 1min TTL: 1800minutes Edge Side Includes (ESI)
- 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. Difficulty level: Hard Payoff: High Step 8:Advanced cache invalidation
- 38. Step 8:Advanced cache invalidation (1/2) ● 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 enhanced cache invalidation ● Possible database driven expiry (triggers)
- 40. Step 9 TCP/IP Tuning • The defaults in Linux are great • if you are Linus Torvalds and you’re browsing with Arena • somaxconn, rmem, wmem, fin timeout, ...
- 41. 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.
- 42. Q & A