Kunde möchte eine voraussichtlich stark frequentierte Seite mit Typo3 bei sich hosten.
Erwartet werden 5000 Benutzer gleichzeitig – die geschätzt alle 10 Sekunden klicken. Ergibt 500 Requests/s. Wir sollen die Architektur vorschlagen.
Mein Metier. Nach einer zweiwöchigen Evaluation kristallisierte sich Nginx mit FastCGI als Webserver heraus, weil der FastCGI Anfragen cachen kann und somit auf eine tolle Geschwindigkeit kommt.
Das Problem ist nicht der Cache an sich. Das Problem ist, wie Nginx damit umgeht, wenn der Cache verfällt.
Der Cache hat ein Ablaufdatum, eine Time-To-Live, TTL. Läuft diese ab, muss das HTML vom Backend neu geholt werden. Und wenn der Cache bei 500 gleichzeitigen Anfragen pro Sekunde abläuft, muss das HTML 500 mal gleichzeitig vom Backend geholt werden. Schönä!
Ich habe verschiedene Reverse-Proxies ausprobiert. Unter anderem den Varnish-Cache. Und der hat eine Besonderheit, die ich sonst bei keinem Cache finde:
When several clients are requesting the same page Varnish will send one request to the backend and place the others on hold while fetching one copy from the back end. (Source)
Ich beglücke den Webserver mit 5000 Benutzern. Gleichzeitig.
5000 Benutzer prasseln auf den Server. Nach einer Minute wird _eine_ Anfrage an den Webserver geschickt – die 5000 Benutzer werden weiterhin mit dem „alten” Inhalt bedient.
Die Antwort kommt, der Cache wird erneuert und von jetzt an wird der neue Inhalt an die 5000 Benutzer ausgeliefert.
So sieht die Aktivität auf dem Server aus:
Genau ein httpd ist am schwitzen, und nicht fünfzig. Und der varnishd tobt sich aus…
So sieht meine Netzwerkauslastung aus:
I can haz more bandwidth?
Zwei Proxysniffer im Verbund auf Vollgas. Schampar schade dass unser Netzwerk nicht mehr als 800MBit hergeben will:
Ça fait rock.
Und der Varnish lässt sich unendlich flexibel konfigurieren. Ich kann z.B. anhand der URL Anfragen auf unterschiedliche Backends leiten, mehrere Backends mit einer gewichteten Lastverteilung aufstellen und und und…
Ein Beispiel.
backend crappy_j2ee_enterprise_grüselapp {
.host = "server.example.com";
.first_byte_timeout = 5s;
.max_connections = 10;
.probe = {
.url = "/check.jsp";
.interval = 5s;
.timeout = 1s;
.window = 5;
.threshold = 3;
}
}
Das Backend wird alle 5 Sekunden vom Varnish angefragt (interval). Von 5 Anfragen (window) müssen 3 korrekt sein (threshold) und unter 1s antworten (timeout).
Ist dies nicht der Fall, bekommt das Backend den Status „unhealthy” verpasst. Jetzt liegt es an der Konfiguration, was jetzt passiert.
if (! req.backend.healthy) {
set req.grace = 30d;
} else {
set req.grace = 1m;
}
Ist das Backend nicht verfügbar, wird es für 30 Tage nicht mehr angefragt bei einem User-Request, auch wenn die TTL für die Seite abgelaufen ist. Der Health-Check läuft normal weiter.
#renew content every minute
set beresp.ttl = 1m;
#save content for 30 days - if backend fails
set beresp.grace = 30d;
Nach einer Minute wird der Webserver nach neuen Inhalten abgefragt. Die Antwort wird 30 Tage lang gespeichert – sollte der Webserver abliegen, kann die Website noch 30 Tage lang von dieser Notration überleben.
Und das ist toll – ich kann meine Apache’s stoppen. Ein paar Benutzer haben Pech – in den maximal 5 Sekunden, bis Varnish das merkt und das Backend als ungesund deklariert. Aber dann läuft alles wie gewohnt weiter. Sobald die Webserver wieder da sind, werden die Cache-Inhalte erneuert.
Voraussetzung für den ganzen Gspass ist natürlich eine statische Seite ohne personalisierte Inhalte.
Man könnte es noch auf die Spitze treiben mit dem Caching und für verschiedene Inhalte eigene TTLs definieren:
Did you know? Wikileaks setzt auch auf Varnish:
Ich weiss nicht wie viel Traffic Varnish wirklich verarbeiten kann. Aber ganz offensichtlich mehr als 10 Gigabit:
http://twitter.com/wikileaks/status/9609091915718656
http://www.varnish-cache.org/
