Was ist eigentlich Website-Caching?

Was ist eigentlich Website-Caching?

|

Waren Sie in letzter Zeit mal auf Amazon, Spiegel Online oder auch dem Online-Angebot der FAZ? Dann ist Ihnen bestimmt gar nicht mehr aufgefallen, wie schnell diese Webseiten sind. Eine einigermaßen gute Internet-Verbindung und einen schnellen Web-Browser vorausgesetzt, laden alle drei Angebote in unter einer Sekunde, also praktisch ohne Wartezeit. Und das trotz teilweise sehr komplexer Angebote und Millionen von Besuchern pro Monat!

Der wesentliche Bestandteil dieser schnellen Auslieferung von Websites ist eine Technologie namens Caching, die im Folgenden erklärt werden soll. Caching ist immer dann besonders effizient, wenn (größtenteils) identische Inhalte an eine große Zahl von Besuchern ausgeliefert werden sollen.

 

Was ist ein Cache?

Wikipedia definiert den Begriff wie folgt:

Cache bezeichnet in der EDV einen schnellen Puffer-Speicher, der (erneute) Zugriffe auf ein langsames Hintergrundmedium oder aufwändige Neuberechnungen zu vermeiden hilft. Inhalte/Daten, die bereits einmal beschafft/berechnet wurden, verbleiben im Cache, sodass sie bei späterem Bedarf schneller zur Verfügung stehen. Auch können Daten, die vermutlich bald benötigt werden, vorab vom Hintergrundmedium abgerufen und vorerst im Cache bereitgestellt werden.

Ein Cache macht also zwei Dinge:

  • Er speichert einmal beschaffte und aufbereitete Inhalte zwischen
  • Er verlagert Inhalte in einen (viel) schnelleren Puffer-Speicher, aus dem sie performant abgerufen werden können

Aber welche Rolle spielt dies bei der Auslieferung einer Website? Schauen wir uns zunächst an, aus welchen Schritten dieser Prozess überhaupt besteht.

 

Was passiert bei der Auslieferung einer Website?

  1. Der Nutzer ruft eine URL auf, in dem er sie in seinen Browser eingibt oder auf einen Link klickt.
  2. Die Anfrage wird von seinem Browser an den Webserver der entsprechenden Seite geschickt.
  3. Der Webserver nimmt die Anfrage entgegen und führt die entsprechende Applikation aus. Webseiten sind heute fast immer dynamisch, so dass ein Programm (z.B. ein CMS oder ein Online-Shop) ausgeführt wird, das die Seite zusammenbaut und die Inhalte aus einer Datenbank abfragt.
  4. Wenn dieses Programm vollständig durchgelaufen ist, sendet der Webserver den Quelltext der Website zurück an den Browser des Users. Der Seitenaufbau im Browser (das sogenannte Rendering) beginnt erst jetzt.

 

Warum kann das langsam sein?

Zunächst kann die Ausführung der verwendeten Software einfach einige Zeit dauern. Viele der zur Zeit beliebten CMS sind sehr komplexe Systeme, die eine Vielzahl von für den Nutzer nicht direkt sichtbaren Aufgaben ausführen, modular aufgebaut sind und über Plugins erweitert werden können. Dies ist für die Betreiber von Webseiten sehr bequem, da sehr viel Funktionalität sehr einfach und ohne großen Aufwand für Eigenprogrammierung eingebaut werden kann.

Oft wird jedoch ein möglichst großer Funktionsumfang in den Vordergrund gestellt und eine performance-optimierte Architektur vernachlässigt. Gerade bei modular aufgebauten Systemen, in denen der Betreiber viele verschiedene Elemente individuell zusammenstellen kann, gibt es häufig Nachteile gegenüber einer monolithischen Architektur. So kann es passieren, dass bei einem gängigen CMS ein einziger Seitenaufruf (d.h. jeder Klick eines Benutzers) zur Ausführung einer komplexem Software-Umgebung und mehreren Hundert Datenbankabrufen führt.

Dies kann selbst auf modernen Server-Systemen dann einige Sekunden dauern. Wenn es nun noch ein hohes Besucheraufkommen gibt, d.h. viele Anfragen parallel bearbeitet werden müssen, kommen die Server schnell an ihre Grenzen und die Ausführungsgeschwindigkeit sinkt weiter. Im schlimmsten Fall kann es sogar passieren, dass auf diese Weise ein Server ganz „abgeschossen“ wird, d.h. nicht mehr erreichbar ist. Dieser Effekt ist oft zu beobachten, wenn kleinere Seiten z.B. durch einen TV-Bericht oder eine Verlinkung auf einer großen Nachrichtenseite unerwartet viele Besuche in kurzer Zeit bekommen.

 

Wo kommt nun ein Cache ins Spiel?

Caching-Syteme für Web-Applikationen können prinzipiell an zwei Stellen vorkommen: Innerhalb der Applikation selbst oder ausserhalb als quasi „vorgeschalteter“ Dienst.

Innerhalb der Applikation speichert ein Cache einen einmal generierten Inhalt zwischen, um ihn dann schnell(er) ausliefern zu können. Im Beispiel eines CMS würde beim ersten Aufruf einer Seite durch einen User der erzeugte HTML-Quelltext einfach zwischengespeichert, so dass er bei allen weiteren Aufrufen direkt ausgeliefert werden kann, ohne dass die Software noch einmal vollständig ausgeführt und die Datenbankabfragen durchlaufen müssen.

Dies bringt bereits einen enormen Performance-Vorteil (d.h. mehr Aufrufe können in kürzerer Zeit bedient werden), funktioniert aber nicht immer, da gerade bei modularen Systemen der Cache auch mit allen Modulen harmonieren muss. Außerdem muss weiterhin der bestehende Webserver alle Anfragen bearbeiten und zudem die Software-Umgebung bei jeder Abfrage (zumindest teilweise) geladen werden.

Um dieses Problem zu umgehen, wurden externe Caching-Server entwickelt, die als eigenständiger Dienst zwischen dem Benutzer und den Webserver platziert werden, und nichts anderes tun, als Inhalte zwischenzuspeichern:

varnish_big_picture

 

Varnish als Caching-System

Eine sehr populäre Caching-Software ist das frei verfügbare und quelloffene Varnish, das auch bei den ITstrategen immer dann eingesetzt wird, wenn es um das Hosting von Websites mit hohen Ressourcenanforderungen und Besucherzahlen geht. Varnish ist auch das System, das von fast allen großen Nachrichten-Portalen in Deutschland (wie bspw. den anfangs genannten) eingesetzt wird.

Varnish ist in der Lage, Websites und Dokumente direkt im Arbeitsspeicher (RAM) abzulegen und sie von dort aus wieder auszuliefern. Da Arbeitsspeicher sehr schnelle Zugriffszeiten bietet (ca. 100.000 mal schneller als die moderner Festplatten) und zudem auch einen viel höheren Datendurchsatz ermöglicht, können Inhalte in sehr kurzer Zeit (wenige Millisekunden) ausgeliefert und fast unbegrenzt viele Anfragen parallel bearbeitet werden.

Wie sich das auswirkt, sieht man am Beispiel einer Nachrichten-Website mit einigen Tausend Besuchern pro Tag, die wir auf Varnish-Caching umgestellt haben:

blog-caching-navigator-graph

In der Grafik sieht man, wie die durchschnittliche Ladezeit von 2 bis 2,5 Sekunden auf praktisch keine mehr (um genau zu sein: 70 Millisekunden) reduziert werden konnte. Gleichzeitig haben wir auf unseren Server-Systemen auch eine deutliche Reduktion der Prozessor-Auslastung feststellen können:

blog-caching-cpu-usage

Varnish hat zudem den Vorteil, dass es über eine sehr umfangreiche Konfigurations-Sprache an die jeweilige Anwendung anpassbar ist, um z.B. Ausnahmen vom Caching für bestimmte Elemente zu definieren. Außerdem existieren für viele der gängigen CMS Plugins, die mit dem Caching-Server kommunizieren und ihm mitteilen, wann Inhalte auf der Website upgedated wurden und somit im Cache zu invalidieren sind.

Mit Hilfe dieser Integration können Inhalte sehr lange gespeichert werden (z.B. 30 Tage), da der Cache mitbekommt, wann sich etwas auf der Website ändert. Dies ermöglicht wiederum eine viel höhere Caching-Durchdringung oder „Hitrate“ (Anzahl der Elemente, die aus dem Cache ausgeliefert werden können) als bei Systemen, bei denen diese Kommunikation nicht besteht und bei der die Caching-Dauer z.B. nur auf 5 Minuten gesetzt werden kann, damit den Besuchern keine veralteten Seiten ausgeliefert werden.

 

Was ist noch zu beachten, damit Websites schnell sind?

Caching ist der wesentliche, aber nicht der einzige Faktor, um schnelle Websites zu produzieren. Auch eine Optimierung der eigentlichen Applikation ist vorteilhaft, da es fast immer auch Bereiche in der Seite gibt, die nutzerspezifisch sind (z.B. eine individuelle Ansicht nach einem Login oder ein Warenkorb in einem Online-Shop), und die somit nicht gecached werden können.

Auch die Größe der Website und ihrer Elemente ist von Belang: Wenn eine Seite z.B. durch nicht optimierte Bilder oder CSS-Files sehr groß ist, dauert der Seitenaufbau auch mit einem schnellen Caching-System länger. Gleiches gilt, wenn das browserseitig ausgeführte JavaScript schlecht programmiert ist und nicht performant ausgeführt werden kann.