HTTP Caching mit Varnish

IPC München, 24. Oktober 2016

© David Buchmann

Was ist schon wieder ein reverse proxy?

What could possibly go wrong?

Nichts wird gecached (HTTP Headers)
Zuviel wird gecached (also HTTP Headers)
Redaktoren siehen Änderungen nicht (Cache Invalidierung)
Caches werden vermischt (personalisierter Inhalt)

httpstatusdogs.com

Überblick

HTTP refresher
HTTP cache control
Varnish
Fortgeschrittene Themen
Ausblick

HTTP Refresher

Das HTTP Protokoll

Request

`1`	`GET /path`

`2`	`Accept-Encoding: text/html`

Response

1HTTP/1.1 200 OK
2Content-Type: text/html
3 
4<html>...</html>

HTTP Verben

GET
HEAD
POST
PUT
DELETE
...

HTTP Antwort-Codes

1xx hold on
2xx here you go
3xx go away
4xx you fucked up
5xx I fucked up

twitter.com/stevelosh/status/372740571749572610

HTTP Cache Control

Cache Control Header

Cache Expiration Model
Cache Validation Model

HTTP 1.1, RFC 2616, Kapitel 13.2 und 13.3

Cache Expiration

`1`	`Cache-Control: s-maxage=3600, max-age=900`

`2`	`Expires: Thu, 15 May 2014 08:00:00 GMT`

s-maxage
max-age
Expires (HTTP 1.0 - avoid!)
Wenn nichts angegeben: default_ttl

Cache Validation

Hash auf der Response
Client sendet Hash beim nächsten Request
Server kann prüfen ob Hash geändert hat

ETag: 82901821233 If-None-Match: 82901821233 304 Not Modified

Nicht cachen

`1`	`Cache-Control: s-maxage=0, private, no-cache`

Varnish 3 achtet nur auf s-maxage=0.
Varnish 4 berücksichtigt s-maxage=0, private und no-cache.

www.varnish-cache.org/trac/browser/bin/varnishd/default.vcl?rev=3.0 (Varnish 3)
www.varnish-cache.org/trac/browser/bin/varnishd/builtin.vcl?rev=4.0 (Varnish 4)

Voreingestellte Varnish Konfiguration

Nur GET und HEAD Request werden gecached
Requests mit cookies / authorization header werden nie gecached
Responses mit set-cookie werden nie gecached
Cached nur safe Responses (status 200, 203, 300, 301, 302, 307, 404, 410)

Varianten auseinander halten

Inhalt hängt von Request Header ab

`1`	`GET /resource`

`2`	`Accept: application/json`

`1`	`GET /resource`

`2`	`Accept: text/xml`

`1`	`Vary: Accept`

Varnish macht genau das,
was du ihm sagst

Bitte genau aufpassen und gut testen

Varnish Configuration Language

Lesen und schreiben von Headern
If Konditionen, aber keine Schleifen
Funktionen: Reguläre Ausdrücke, Invalidierung
Keine Rückgabewerte, nur Status Änderungen
Keine Variablen, Information persistieren nur in Headern
Inline C code
//, # und /* foo */ für Kommentare

VCL: Debuggen time to live

1sub vcl_backend_response {
2    set beresp.http.TTL = beresp.ttl;
3}

VCL: Debuggen cache hit / miss

01sub vcl_deliver {
02    # If X-Varnish contains only 1 id, we have
03    # a miss, if it contains more (and
04    # therefore a space), we have a hit.
05 
06    if (resp.http.X-Varnish ~ " ") {
07        set resp.http.Debug-Cache = "HIT";
08    } else {
09        set resp.http.Debug-Cache = "MISS";
10    }
11}

VCL: Zwei Applikationen

01backend default {
02    .host = "127.0.0.1"; .port = "8080";}
03backend legacy {
04    .host = "127.0.0.1"; .port = "8000";}
05 
06sub vcl_recv {
07    if (req.url ~ "^/archive/") {
08        set req.backend_hint = legacy;
09    } else {
10        set req.backend_hint = default;
11    }
12}

VCL kann vieles

Hinzufügen, ändern und löschen von Headern in Request und Response
Entscheiden ob und wie gecached wird
Request URLs umschreiben

Aber bitte nicht zuerst schauen, dass die Webanwendung HTTP korrekt verwendet!

Fortgeschrittene Themen

Cache Invalidierung
Cache Tagging
Edge Side Includes
Caching und Sessions

Cache Invalidierung

Die zwei harten Probleme in der Computerwissenschaft:

Naming things
Cache Invalidierung
Off by one Fehler

Cache busting

Sehr lange cache lifetime für Assets
?version an Asset Links anhängen
Der Query String führt zum Cache miss

1<link rel="stylesheet" href="/css/style.css?v1" type="text/css"/>
2...
3<script src="/js/scripts.js?v1"></script>

Explizite Cache Invalidierung

Lange cache lifetime in Varnish
Nachrichten an Varnish um gezielt gecachte URLs zu Invalidieren
Änderungen die sich nicht sauber erkennen lassen: Kurze lifetime

Arten der Invalidierung

Purge: URL und alle Varianten
Refresh: Genau diesen Request erneuern, wärmt Cache wieder auf
Ban: breite Invalidierung mit Regulären Ausdrücken

Invalidierung senden

varnishdm Kommandozeilen Programm
Eigene VCL und Web Requests
Messaging: Wenn die Varnish Server nicht bekannt sind (cloud)

Eigene VCL für purge

01acl invalidators {
02    "localhost";
03}
04 
05if (req.method == "PURGE") {
06    if (!client.ip ~ invalidators) {
07        return (synth(405, "Not allowed"));
08    }
09    return (purge);
10}
11 
12...

Banning

Reguläre Ausdrücke
Geht für beliebige Header, nicht nur Pfad

01vcl_backend_response {
02    set beresp.http.X-Url = bereq.url;
03    set beresp.http.X-Host = bereq.http.host;
04}
05 
06vcl_recv {
07  if (req.method == "BAN") {
08    if (!client.ip ~ invalidators) {
09      return (synth(405, "Not allowed"));
10    }
11    ban("obj.http.X-Host ~ " + req.http.X-Host
12      + " && obj.http.X-Url ~ " + req.http.X-Url
13    );
14  }
15}

Cache Tagging

Eigener Header mit id von jedem Inhalts-Element
BAN Request für den Header wenn Element geändert hat

`1`	`$response->withHeader('X-Cache-Tags',` `'id-42');`

1ban("obj.http.x-cache-tags ~ "
2      + req.http.x-cache-tags
3);

FOSHttpCacheBundle

1/** @var $cm CacheManageer */
2$cm->tagResponse($response, array('id-42'));
3...
4$cm->invalidateTags(array('id-42'));

1use FOS\HttpCacheBundle\Configuration\Tag;
2class CommentController extends Controller {
3    /**
4     * @Tag({"comments", "'comment-'~id"})
5     */
6    public function commentAction($id)
7    // ...

Edge Side Includes

Edge Side Includes verwenden

Wie server side include, aber in Varnish:

URLs im Inhalt auf Inhaltsteile
Varnish hohlt und cached die Teile separat
Individuelle Caching Regeln pro Teil
z.B. nur gewisse Teile hängen von Cookie ab, unterschiedliche TTL, ...

Caching und Sessions

Strategien für Caching mit Sessions

Session vermeiden, beenden wenn nicht mehr benötigt
Cache lookup trotz Cookies
- Response Header um caching von Cookie spezifischen Seiten zu verhindern
- Vary auf dem Cookies Header
User Context: Caching pro Berechtigungsgruppe

Wrap-Up

Take-Aways

Varnish kann viel
Varnish ist gefährlich
KISS VCL!
Zuerst das HTTP Verhalten der Webanwendung korrigieren
Verstehe was du machst, teste was du machst

Ausblick: Code Bibliotheken

Varnish plugins (vmods) für Dinge wie basic authentication
Frameworks für bessere Modellierung von HTTP request/response, z.B. PSR-7
FOSHttpCache: Invalidierung, integration tests mit Varnish
Symfony Anwender sollten sich das FOSHttpCacheBundle anschauen

Outlook: Wie weiter?

Monitoring was Varnish macht
Verbessern der cache hit Ratio
Varnish Tutorials: varnish-cache.org

Outlook: Caching ist nicht alles

Frontend Performanz: z.B. Deep Dive into Browser Performance by Ilia Alshanetsky
Applikations Performanz

HTTP Caching mit Varnish

© David Buchmann

Was ist schon wieder ein reverse proxy?

What could possibly go wrong?

Überblick

HTTP Refresher

Das HTTP Protokoll

Request

Response

HTTP Verben

HTTP Antwort-Codes

HTTP Cache Control

Cache Control Header

Cache Expiration

Cache Validation

Nicht cachen

Voreingestellte Varnish Konfiguration

Varianten auseinander halten

Inhalt hängt von Request Header ab

Varnish Configuration Language

VCL: Debuggen time to live

VCL: Debuggen cache hit / miss

VCL: Zwei Applikationen

VCL kann vieles

Fortgeschrittene Themen

Cache Invalidierung

Die zwei harten Probleme in der Computerwissenschaft:

Cache busting

Explizite Cache Invalidierung

Arten der Invalidierung

Invalidierung senden

Eigene VCL für purge

Banning

Cache Tagging

Cache Tagging

FOSHttpCacheBundle

Edge Side Includes

Edge Side Includes verwenden

Wie server side include, aber in Varnish:

Caching und Sessions

Strategien für Caching mit Sessions

Wrap-Up

Take-Aways

Ausblick: Code Bibliotheken

Outlook: Wie weiter?

Outlook: Caching ist nicht alles

Danke!

@dbu