Caching ist eine der Königsdisziplinen, wenn es um das Optimieren einer Webseite geht, denn wenn es richtig gemacht ist, kann man mit sehr wenig Aufwand sehr viel erreichen. Umgekehrt kann man aber auch mit viel Aufwand die Applikation unwartbar bekommen. Es gilt also, den richtigen Cache an der richtigen Stelle einzusetzen, um somit höchste Effizienz zu erreichen. Ideen, wo und wann man handeln sollte, soll diese Einführung in das Thema Caching bringen. Prinzipiell geht es beim Caching darum, dass man häufig verwendete oder relativ teuer zu berechnende Daten im System vorhält, damit sie auf Wunsch abrufbar sind. Der Einsatz von solchen Zwischenspeichern sollte aber gut überlegt werden. Nicht alles, was zu cachen ist, sollte auch seinen Weg in den Speicher finden, denn oft verliert man durch komplexere Strukturen das Stück Wartbarkeit, das genauso über den Erfolg eines Projekts entscheiden kann. Stolpersteine, die einem beim Caching hier gerne in den Weg gelegt werden, haben meistens ihren Ursprung in der Invalidierung, also dem Anstoßen der Neuberechnung, oder dem Aufwärmen des Zwischenspeichers. Wie reagiert mein System, wenn es das erste Mal neu gestartet wurde und somit keine Caches gefüllt sind? Beide Punkte sollte man unbedingt im Hinterkopf behalten, wenn man sich an die Optimierung einer Anwendung macht.
Drei Wege zum Glück
Es gibt viele Strategien, wie man Websysteme performant hält – wir werden drei Ansätze vorstellen. Ziel dabei ist es, einen Überblick über die Möglichkeiten zu geben und Interesse zu wecken. Auch wenn wir PHP-Entwickler von Herzen sind, sind all die vorgestellten Methoden auch für andere Sprachen, die im Web Anwendung finden, gültig. Wie bereits erwähnt, ist es eine der großen Herausforderung beim Cachen, die Stelle zu finden, an der eine Vorberechnung am effektivsten wirken kann, wobei wir Effektivität im Sinne der Entlastung der Infrastruktur verstehen. Die Last von den Servern zu nehmen und die Auslieferung der Daten zu beschleunigen, ist hier maßgeblich.
Durch den Aufbau des Internets bietet sich an, an diversen Schichten eine Caching-Strategie zu wählen. Die Pyramidenform wurde gewählt, da sie am einfachsten den Wirkungsgrad des Caches zeigt. Je früher meine Vorberechnungen greifen, desto höher ist die Entlastung des Systems. Denn im besten Fall hilft einem der Client bereits Daten vorzuhalten, man denke nur an das Vorhalten von CSS- oder JavaScript-Dateien. Diesen Cache bezeichnen wir im Webumfeld als Browser-Cache. Bei nichtpersonalisierten Inhalten hilft uns eine weitere Schicht, die Effizienz zu erhöhen, indem sie stabilen Inhalt vorhält und ihn ohne Berechnungen ausliefern kann. Diese Strategie hört auf den Namen Webcache. Erst nachdem diese zwei Schichten erfolglos durchquert wurden, schlagen die Anfragen bei der Applikation ein. Hier werden punktuell Berechnungen zwischengespeichert und der Anwendung zur Verfügung gestellt. Applikation-Cache heißt hier das Zauberwort. Browser-Cache und ein einfacher Webcache können fast unabhängig von der Anwendung eingesetzt werden, was den großen Vorteil mit sich bringt, dass man in den Produktivcode nicht eingreifen muss und somit eine nachträgliche Verwendung in den meisten Fällen problemlos geschehen kann.
Caching im Client (Browser-Cache)
Der Freund jeder Applikation ist das Caching im Client. Hier wird die erste und effektivste Caching-Stufe eingebaut. Für den Einsatz des Browsers als Cache für eine Applikation muss der Entwickler nur einigen wenigen Regeln folgen und im Vorfeld bestimmen, welche Teile der Applikation wann und wie lange im Browser gecacht werden sollen. Das Caching-Verhalten eines Browsers wird über das Setzen von HTTP-Headern gesteuert.Dabei gibt es grundsätzlich zwei Methoden. Die erste arbeitet mit If-Modified-Since oder entity tag (ETag). Dem Browser wird über den Last-Modified-Header beim Aufruf einer Webseite mitgeteilt, wann sie das letzte Mal aktualisiert wurde. Er sendet dann bei jeder nachfolgenden Anfrage nach genau diesem Inhalt den Header: If-Modified-Since mit dem Änderungsdatum des Inhalts zur Überprüfung an den Server, der das gesendete Datum mit dem aktuellen Änderungsdatum vergleicht. Anschließend wird entweder die aktuelle Version des Inhalts gesendet oder ein "günstiger" 304 (Not-Modified) Statuscode.
