Varnish Cache - step by step

Varnish CacheStep by step

Insert business logic here

About Varnish Cache

● Web app accelerator

● Fast

● Flexible

VCL

• Varnish Configuration Language

• Applies to transactions that flow through the cache

• Hook custom logic into the flow

• Main hooks used: vcl_recv and vcl_fetch

About Varnish Software● The company behind Varnish Cache

● Offers “Varnish Plus” - consisting of:

○ Additional software

○ 24/7 support

○ Professional services

GoalKnowing what to do to speed up your website.

Designing a web app for Varnish

● Build apps from the ground up for Varnish

● Intelligent cache usage

● Proper cache invalidation

● Monitoring

Incremental implementations

● Deploy Varnish on existing apps

● Gradually increase caching

● “Low hanging fruits” first

Requirements

● Linux or FreeBSD

● Virtualization is OK, not awesome

● Tuning is only for high traffic

Step 1: Installing VarnishDifficulty level: Easy

Payoff: Minor

Step 1: Pass through only● Passive Varnish

○ return(pass) in vcl_recv

● Powerful load balancing

● Health checks built in

● Excellent for debugging webapps

Step 2: Cache static assets

Difficulty level: Trivial

Payoff: Minor

Step 2: Cache static assets

● Cache images, CSS, Javascript

● Backend concurrency decrease

● Backend bandwidth decrease

● Minor CPU usage decrease

Step 3: CompressionDifficulty level: Trivial

Payoff: Medium

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

Step 4: Semi-static caching

Difficulty level: Medium

Payoff: High

Step 4: Semi-static content caching

● Dynamically rendered content

● Expensive to render

● Almost never changes

● Set short TTL (10-120 seconds)

● Mitigates traffic peaks

Step 4: Semi static (2/2)

● Manual cache expiry

● Magic URLs

● Shift-refresh from special IP-range

● Web interface for ban or purge

Difficulty level: Medium Payoff: High

Step 5: Autopurge

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

Difficulty level: Easy

Payoff: High

Step 6: Grace mode

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

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

Difficulty level: Hard

Payoff: High

Step 7: Content composition with ESI

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)

TTL: 30min

TTL: 30minTTL: 30min

TTL: 30min

TTL: 60min, user specific

TTL: 1min

TTL: 1800minutes

Edge Side Includes (ESI)

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

Difficulty level: HardPayoff: High

Step 8: Advanced cache invalidation

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

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)

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.

Varnish Cache - step by step

Technology

Transcript of Varnish Cache - step by step