Your SlideShare is downloading. ×
Accelerate your web app with a layer of Varnish
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Accelerate your web app with a layer of Varnish


Published on

Slides from a talk given at Confoo in 2014 on the Varnish caching reverse proxy server.

Slides from a talk given at Confoo in 2014 on the Varnish caching reverse proxy server.

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Mention jaw dropping nature of it...
    Talk is an intro to what varnish is, what it can do and when it is (as well as is not) the right tool for the job.
  • Explain what a caching reverse proxy is.
    Varnish users: BBC, Synacor, Slideshare, Facebook(?), Twitter(search), and NY Times.
    Mention that I have stories about how these organisations are using Varnish but no time...
  • Varnish's definition of a backend: any http server that can produce content that can potentially be cached.
    Safe http methods.
  • Mention html, json, xml, css, javascript, images, media files, etc.
    Developers claim speed improvement of 300-1000x
    Dev's also claim seeing Varnish deliver 20GBPS on off the shelf hardware...
    Claim that you will typically max out your internet connection before exhausting Varnish's ability to serve content from cache.
  • Mention some people have had problems under OSX.
  • Varnish looks for value in s-maxage or maxage in cache-control. If neither set looks for Expires header. Then looks in VCL. If nothing set then uses the default_ttl runtime option.
    Can be overridden in VCL.
    Varnish ignores request cache headers.
    Will only cache:
    200: OK
    203: Non-Authoritative Information
    300: Multiple Choices
    301: Moved Permanently
    302: Moved Temporarily
    307: Temporary Redirect
    410: Gone
    404: Not Found
  • Mention that 32 bit installs of supported versions are possible but limited memory.
    If your app runs on another OS there's nothing to stop you putting Varnish in front of it on a supported OS...
  • Lego analogy.
    -a port Varnish listens on.
    -f VCL file
    -s type and size of storage
    Mention that runtime options are passed to varnishd whent started, normally set in defaults file.
  • Mention that VCL allows you to decide which backend to use when a request is received.
    Also mention Varnish supports several types of load balancing.
  • Mention that issuing Varnish reload simply reloads the config.
    Server not stopped so cache not purged.
    Existing items in cache will keep the existing cache time!
    Reload does nothing if VCL invalid, which is good...
    Mention no support for user variables or loops.
  • Note that you can't pass arguments to subroutines in VCL.
  • Only give an overview!!
  • Also mention pipe along with pass.
  • hash_data: adds a string to the hash input.
    regsub: replaces first regex match with the sub
    regsuball: replaces all regex matches with sub
    ban: bans all objects in cache that match the expression.
    ban_url: bans all objects in cache that match the regex. DEPRECATED.
    Ban is a filter on objects in the cache. Ban things from being served from cache but doesn't stop new items entering the cache.
  • Mention that Varnish will set a ttl before this subroutine is called.
  • Note that this example is overly simplistic!
  • Varnish queues multiple requests for the same content.
    Allows Varnish to stop requests for content piling up while fetching content from a backend.
    To use graced content for unhealthy backends health checks must be set.
  • Configure req.grace in vcl_recv and beresp.grace in vcl_fetch.
    req.grace can be set dynamically depending on the health of a backend.
    Typically store an object for several hours past ttl.
    Only use it for a few seconds past the ttl unless the backend is sick.
  • Configured with url, interval, window, threshold.
    Interval is how often to probe.
    Threshold and window set limits, eg. Threshold probes must pass in window probes.
  • Used to mark a single object on a single backend as sick for a period of time.
    If n (default 10) objects are marked as sick whole backend will be marked as sick.
    Can trigger grace mode.
  • Note that Varnish does not implement the complete ESI specification.
  • Mention SF2 native support for ESI.
  • Transcript

    • 1. Accelerate your app with a  layer of Varnish
    • 2. Who? ● ● ● Ex-pat Englishman, now living in Southern Ontario. Web developer for 5 years, mostly PHP. (Almost) Senior Software Engineer at TribeHR. ● Co-organiser of Guelph PHP User Group. ● Ex-professional musician.
    • 3. Varnish can do incredible  things for your app...
    • 4. What is Varnish? ● ● Open source caching reverse proxy or HTTP accelerator. Mature software: – – ● Current version: 3.0.5 Varnish 4 currently in tech preview. Used by 5% (500) of the top 10,000 sites on the internet.
    • 5. Varnish basics ● Listens on a port (normally 80). ● When a request arrives: – – ● If content is already in cache it is served directly. If not Varnish forwards the request to a 'backend' server, delivering the content when it is received. Only caches GET and HEAD requests.
    • 6. Varnish features ● ● ● Can cache any kind of content delivered via HTTP. Blazingly fast with incredible performance. Support for multiple backends and basic load balancing.
    • 7. Varnish features (cont) ● ● ● ● Configuration through Varnish Configuration Language (VCL). Support for Edge Side Includes (ESI). Behaviour can be extended through Varnish Mods (VMODs). Includes tools to monitor and tune (varnishtop, varnishlog, varnishhist, varnishstat, etc).
    • 8. Show us the demo!
    • 9. Apache results
    • 10. Varnish Results
    • 11. Is Varnish always the right  tool? ● What kind of content are you serving? ● Cookies. ● SSL. ● Varnish is like a layer of... varnish. ● Do you really need Varnish?
    • 12. Getting started with Varnish
    • 13. Setting cache times ● Two possible methods – – ● HTTP cache headers Directly in VCL Prefer HTTP cache headers wherever possible.
    • 14. Supported OS's ● Fully supported: – – ● Linux FreeBSD 'Try not to break': – – OpenBSD – ● NetBSD OS X Needs a 64 bit OS ideally.
    • 15. Installing Varnish ● Use system package manager. – ● ● For Debian, Ubuntu and RedHat/CentOS Varnish software maintains repositories with up to date versions. To obtain up to date version to install on non-core supported platforms compile from source. More info at the Varnish website.
    • 16. Basic configuration ● ● Ships with an excellent, 'sane' default VCL configuration. To begin using Varnish: – Configure runtime options (/etc/default/varnish). – Add one or more backends to VCL file (/etc/varnish/default.vcl).
    • 17. Adding VCL backends ● ● ● Must add at least one backend in VCL. If more than one, first will be the default. Backends can be grouped into 'directors' to apply load balancing.
    • 18. Sample backend definition backend default { .host = ""; .port = "8080"; }
    • 19. Advanced configuration
    • 20. Introduction to VCL ● Provides a window into Varnish's state during the request/response cycle. ● Not a full programming language. ● C/Perl-like syntax. ● Compiled into a C shared object at runtime and loaded into Varnish.
    • 21. VCL Subroutines ● ● Dispatched at different times in the request/response cycle. Each routine has default code: – Varnish appends this to the end of any code you add. – Can be short-circuited by using the return keyword. Be careful! ● Allowed return values documentation. ● You can also define your own.
    • 22. VCL Subroutines (cont) ● vcl_init ● vcl_miss ● vcl_recv ● vcl_fetch ● vcl_pipe ● vcl_deliver ● vcl_pass ● vcl_error ● vcl_hash ● vcl_fini ● vcl_hit
    • 23. VCL Processing Cycle
    • 24. VCL Functions ● Functions Varnish makes available to you: – – regsub(str, regex, sub) – regsuball(str, regex, sub) – ban(ban expression) – ban_url(regex) (Deprecated) – purge() – ● hash_data(str) return() Also have set and unset keywords to manipulate variables and call to dispatch your own subroutines.
    • 25. vcl_recv ● ● Called once the OS kernel has given the complete request to Varnish. Typical uses: – Set the backend to use. – Amend the request. – Add extra information to the request. – Force a bypass of cache lookups (pass or pipe).
    • 26. vcl_fetch ● ● Called when a response is received from a backend, before it is considered for inclusion in the cache. Typical uses: – Amend or set a TTL. – Add or remove HTTP headers. – Detect errors (more later). – Turn on ESI processing.
    • 27. Select a backend backend default { .host = ""; .port = "8080"; } backend bar { .host = ""; .port = "8080": } sub vcl_recv { if ( ~ "") { set req.backend = bar; } // etc }
    • 28. Remove cookies sub vcl_recv { if (req.url !~ "^/admin/.*") { unset req.http.cookie; } } sub vcl_fetch { if (req.url !~ "^/admin/.*") { unset beresp.http.set-cookie; } }
    • 29. Set default TTL sub vcl_fetch { if (! beresp.http.cache-control && beresp.http.content-type ~ "text/html| text/xml|application/json") { set beresp.ttl = 5m; } }
    • 30. VMOD's ● Allow you to extend Varnish's features. ● Written in C. ● ● Community VMOD's at Examples: – Geo-IP lookup (BBC) – Query string normalisation – Memcache
    • 31. Grace mode ● ● ● Graced content is an object that has expired but is kept in cache. Grace mode is when a graced object is used. When this can happen: – No healthy backends are available. – Deliver old content while fetching new content is pending.
    • 32. Configuring grace sub vcl_recv { if (req.backend.healthy) { set req.grace = 30s; } else { set req.grace = 1h; } } sub vcl_fetch { set beresp.grace = 1h; }
    • 33. Health checks backend foo { .host = ""; .port = "8080"; .max_connections = 10; .probe = { .url = "/test"; .interval = 5s; .timeout = 1s; .window = 5; .threshold = 3; } }
    • 34. Saint mode ● ● ● Allows you to say that a backend is 'sick' for one url. Varnish will not make further requests to that backend for the url for the time specified. Gives you a chance to detect errors in responses.
    • 35. Saint mode example sub vcl_fetch { if (beresp.status ~ “^5d{2}$”) { set beresp.saintmode = 10s; return(restart); } }
    • 36. Edge Side Includes ● ● Allows different content on the same page to be cached for different times. Request flow: – – ● External request returns a page with special ESI tags in it. For each ESI tag Varnish issues a sub request which generates the content. Both 'master' and sub requests can be cached.
    • 37. Configuring ESI's ● Done in vcl_fetch: – ● ● set beresp.do_esi = true; Need to configure app to support 'layouts' and 'components'. Various frameworks have support for ESI's.
    • 38. ESI Example <!DOCTYPE html> <html> <head> <title>ESI example</title> </head> <body> <esi:include src="/route/to/content"/> </body> </html>
    • 39. Thanks for listening! ● Varnish docs: ● Any questions? ● Feel free to contact me: – @JCook21 –