Applikations-Caching
Bis jetzt haben wir nur Caches besprochen, die unabhängig von der Applikation wirken. Browser- und Webcache treten beide in Aktion, bevor die Anfrage den Webserver erreicht. Es wäre wunderbar, wenn wir mit diesen beiden Strategien unsere Anwendung schon so stabil bekommen, dass wir gar nicht weiter über Optimierungen nachdenken müssen. Leider klappt dies in den meisten Fällen nicht so einfach, denn irgendwann muss jede Seite einmal aufgebaut werden, bevor sie überhaupt gecacht werden kann. Wenn ein Cache noch kalt ist, er also keinerlei Daten zwischengespeichert hat, ist die Chance groß, dass die Applikation viele Berechnungen auf einmal machen muss. Damit nicht jeder Request, der es bis zum Webserver schafft, alle Berechnungen machen muss, gilt es auch hier zu cachen. Die Gesamtzahl der registrierten Benutzer muss zum Beispiel nur einmal aus der Datenbank geholt werden und nicht für jede Seite, die diese Information anzeigt. Das Prinzip ist also im Kern das gleiche wie bei den anderen Ansätzen. Daten, die von mehreren Anfragenden benötigt werden, sollten im Speicher vorliegen. Was zu speichern ist, ist klar: Berechnungen, die häufig gebraucht werden und welche, die sehr kostspielig sind. Die Herausforderung beim Applikations-Cache ist es vielmehr, den Ort des Zwischenspeichers zu bestimmen. Mögliche Orte sind hier der Hauptspeicher eines Servers oder die lokale Festplatte. Beide Ansätze haben Vor- und Nachteile.
Die Hauptspeicherlösung, die meistens über memcached geschieht, hat den großen Vorteil, dass dank des verwendeten Protokolls auch Hauptspeicher von entfernten Maschinen verwendet werden können. Leider ist dieser Cache sehr beschränkt in seiner Größe und kann somit nicht sicherstellen, dass benötigte Daten auch zur Verfügung stehen, solange sie benötigt werden. Anwendungsgebiete wären hier zum Beispiel Daten, die für eine relativ kurze Zeit gültig sind und das Ergebnis nicht allzu großen Speicherbedarf benötigt. Entscheidet man sich für die lokale Festplatte, so kann man auf einen fast uneingeschränkt großen Zwischenspeicher zurückgreifen. Komplett gerenderte Seitenteile wären zum Beispiel ein Fall für die lokale Ablage. Großer Vorteil dieser Strategie ist Unabhängigkeit zu irgendwelchen PHP-Paketen. Jede noch so beschnittene moderne PHP-Version sollte in der Lage sein, lokal Dateien abzulegen. Auf den Hauptspeicher hingegen zuzugreifen benötigt Rechte, die vielleicht nicht jedem gegeben sind. Bei beiden Lösungen sollte man aber das Rad nicht neu erfinden und auf eine bereits existierende Lösung, z. B. Zend_Cache oder der memcached-Erweiterung, zurückgreifen.
Wie bringt man Caching in existierende Projekte?
Wir haben eingangs bereits erwähnt, dass man Caching bei der Entwicklung gut dosiert anwenden sollte. Aus diesem Grund wird es häufig vorkommen, dass Engpässe in der Software, die erst relativ spät auftreten, nachträglich mit einem Cache versehen werden müssen. Pauschal ist es schwer, eine konkrete Vorgehensweise zu definieren, wie man mit so einem Bottleneck umgehen muss. In einigen Fällen muss man hier tief in die Architektur eingreifen. Um die Last auf dem Webserver aber trotzdem zu reduzieren, empfiehlt es sich, die Techniken zu verwenden, die keine Änderungen im Sourcecode nach sich ziehen. Eine solche Technik wäre der Webcache, der einfach vor die Applikation gestellt wird. Stellt man das System so ein, dass jede Seite fünf Minuten gültig ist, so sollte schon ein großer Teil der Last vom Server genommen sein. Nachteil ist die langsamere Aktualisierung des Inhalts. Ein Kommentar, der einem Artikel angehängt wird, erscheint so zum Beispiel erst nach bis zu fünf Minuten. In den meisten Fällen sollte dies aber kein Problem sein. Hierzu muss man natürlich seine Webseite gut kennen. Habe ich viele Inhalte, die stabil sind? Dann habe ich eine gute Chance, mit Webcache meine komplette Applikation abzudecken. Blogs, News-Seiten und Seiten mit vielen redaktionellen Inhalten würden hierzu gehören. Foren zum Beispiel, die von ihrer Aktualität leben, müssen leider andere Wege gehen, da ist der nachträgliche Einbau eines Caches mit tieferen Eingriffen verbunden.
Fazit
Caching gehört sicherlich zu einem der interessantesten Techniken in der Webentwicklung. Seine Webseite unter hoher Last noch schnell reagieren zu sehen, ist wohl der Wunsch eines jeden Softwareentwicklers. Caches sind aber häufig mit Vorsicht zu genießen, denn schnell erhöhen sie die Komplexität einer Webseite immens. Einen Cache dort einzubauen, wo sich ein Engpass auftut, ist sicherlich immer der richtige Weg. Vorher Engpässe zu erraten und somit Teile ihrer Wartbarkeit zu berauben, ist in den meisten Fällen ein Schritt in die falsche Richtung. Es gibt viele Sorten von Caches, und wenn möglich, sollte man die vorziehen, die die meiste Last vom gesamten System nehmen. Unter Betracht der Caching-Pyramide wäre der erste Ansatzpunkt, alles Mögliche im Client zu hinterlegen, dann einen Webcache einzuschalten und als Letztes die Applikation selbst ihre Dienste tun zu lassen. Diese Reihenfolge kann natürlich je nach Webseite anders sein, bei Standardangeboten im Internet sollte diese jedoch meistens greifen. Caching kann komplex sein, muss es aber nicht. Viele der angesprochenen Lösungen können schon out-of-the-box ihre Effizienz beweisen. Trotzdem sollte man immer auch im Hinterkopf behalten, dass neue Hardware auch eine legitime Lösung sein kann, falls man die Entwicklungsgeschwindigkeit und Wartbarkeit über die Kosten der Infrastruktur stellt.
Nils, der an der Universität Freiburg Informatik studierte, treibt sich nun mehr seit fast 10 Jahren in der Webentwicklung herum und arbeitet derzeit für eines der größten Verlagshäuser Europas im Qualitätsmanagement der Onlinesysteme. In seiner Freizeit betreibt er einen sehr erfolgreichen deutschsprachigen PHP-Blog, in dem er seine Erfahrungen zum Thema "PHP" kundtut. Hier werden aktuelle Geschehnisse aus der PHP-Gemeinde genauso besprochen wie Best Practices aus der Softwaretechnik. Ein Blatt wird dabei nie vor den Mund genommen.
Mike begann nach seiner Ausbildung zum Fachinformatiker ein Informatikstudium an der Uni Bielefeld. Seit 11 Jahren entwickelt er Webanwendungen und arbeitet derzeit für Gruner + Jahr in der Softwarearchitektur der Onlinesysteme. Mike ist seit 2000 Mitglied des kompetenzverbund.werk01.
