Drupal Caching Teil 1

Was ist überhaupt Caching?

Caching ist nichts Drupal-Spezifisches, es ist noch nicht mal computer-spezifisch. Wir setzen es im Alltag in unterschiedlichsten Formen ein. Nehmen wir mal Telefonnummern: eine mittlere Großstadt hat vielleicht 50.000 Festnetzanschlüsse. Die wichtigsten 3 Nummern (Freundin, Papa, Oma) haben wir sicher im Kopf. Die wichtigsten 10 Nummern stehen auf einem Zettel am Kühlschrank. Für den Rest gibt es das Telefonbuch. Warum? Wenn wir fünfmal täglich mit der Freundin telefonieren, wollen wir ihre Nummer nicht jedes Mal nachschlagen. Bei aller Liebe, der Aufwand wäre zu groß. Also merken wir uns die Nummer einfach, in einem Cache.

Warum verwenden wir also einen Cache?

Ganz allgemein: wir möchten schneller an Informationen kommen, um z.B. eine Telefonnummer schneller zu finden oder mehr Zeit für andere Dinge zu haben. Einem Webserver geht es da nicht anders: er kann durch einen Cache z.B. Seiten schneller an seine Benutzer ausliefern, aber auch mehr Anfragen in einer bestimmten Zeit beantworten.

Super, dann cachen wir doch einfach Alles!

Viel Spaß beim Auswendiglernen und bestell schon mal nen großen Kühlschrank! Nein, jede Art von Cache hat Limitierungen in Form von Kapazität, Dauerhaftigkeit, Zuverlässigkeit oder Kosten. Auf einer Festplatte kosten 500 GB "Cache" vielleicht 50 €, als RAM-Speicher einige Tausend €. Und die 50.000 auswendig gelernten Rufnummern vergessen wir schneller wieder, als wir sie gelernt haben.

Woher wissen wir denn, ob der Cache aktuell ist?

Gute Frage. Ein Cache ist natürlich umso aktueller, je seltener sich die darin enthaltenen Informationen ändern. Wenn sie es aber doch tun, gibt es grob gesagt zwei Möglichkeiten:

• Der Cache hat eine zeitlich begrenzte Gültigkeit. Wir vermuten z.B. das unser 'Telefonbuch 2014' aktuell ist, im Gegensatz zu dem von 1998.
• Der Cache wird aktualisiert, wenn sich eine Information darin ändern soll. Die Freundin verrät uns also hoffentlich ihre neue Handy-Nummer.

Wie wählen wir also die geeignete Caching-Methode?

Allgemein lässt sich das nicht beantworten (wie integriert man einen Kühlschrank in Drupal?) aber man sollte sich vielleicht dazu an folgenden Fragen orientieren:

• wie wichtig ist die benötigte Information, also wie oft wird sie z.B. benötigt?
• was kostet uns der verwendete Cache, im Sinne von Kapazität oder Preis?
• wie oft ändert sich die benötigte Information?

Ein Cache ist umso leistungsfähiger, je häufiger die enthaltene Information benötigt wird, je seltener sie sich ändert, und je weniger Aufwand das gewählte Verfahren erfordert. So einfach ist das - in der Theorie.

Caching in Drupal

Caching-Ebenen in Drupal

Drupal profitiert von unterschiedlichsten Caching-Verfahren, zum Teil sind diese in Drupal schon vorhanden, zum Teil werden sie durch externe Systeme bereitgestellt. Schon mal über Begriffe wie Varnish, MemCache, Redis oder APC gestolpert? Genau darum geht es hier.

• PHP Static Cache dient dazu, eine Information während der Dauer eines Requests zwischenzuspeichern. Denken wir mal an eine Liste mit 50 Benutzernamen, in der 30 mal der gleiche Name auftaucht. Es wäre jetzt aufwändig, diesen jedes Mal neu aus der Datenbank zu holen, also merkt sich die Funktion oder Methode den Namen in einem eigenen Cache, einer statischen Variablen. Dieses Verfahren wird in Drupal und anderen PHP-Anwendungen regelmäßig eingesetzt.

• PHP OpCode Caching: PHP ist eine Skriptsprache, muss also vor Ausführung erst einmal interpretiert (genauer gesagt transpiliert) werden. Das ist relativ aufwändig, und ein OpCode Cache merkt sich einfach das Ergebnis dieses Verarbeitungsschritts. Bekannteste Vertreter sind APC, sowie der Zend Optimizer, ab PHP 5.5 im PHP-Core enthalten. Die Leistung unserer Drupal-Anwendung wird sich durch solch einen Cache deutlich erhöhen.

• In-Memory Cache dient ganz allgemein dazu, Informationen (z.B. Datenbanktabellen) im RAM des Servers bereitzuhalten, um schneller auf sie zugreifen zu können. Bekannte Vertreter sind APC (über seinen User Cache), Memcached oder auch Redis. Drupal stellt etliche Contributed Module zur Nutzung solcher Speicherformen bereit.

• Datenbank-basierter Cache: das ist das Standardverfahren in Drupal: eine aufwändig erstellte Information, z.B. eine gerenderte Seite, wird in einer Datenbanktabelle abgelegt, um sie beim nächsten Request schneller zur Verfügung zu haben. Wie bedeutsam diese Caching-Variante in Drupal ist ersieht man daran, dass z.B. der Drupal 7 Core alleine schon über 10 Cache-Tabellen in der Datenbank mitbringt. Wir kommen im zweiten Teil dieses Artikels ausführlich darauf zurück.

• File-basierter Cache: das klingt erst mal kontraproduktiv: eine Datei auf der Festplatte wird als Cache benutzt, und das soll schneller sein als ein Datenbank-Zugriff? Aber es kommt darauf an: die Auslieferung einer komplexen Drupal Webseite kann u.U. Hunderte von Datenbank-Zugriffen erfordern. Wenn diese fertige Seite jetzt in einer Datei zwischengespeichert wird, ist sie wahrscheinlich schneller verfügbar. Typische Vertreter dieses Verfahren sind z.B. die Drupal-Module Boost und FileCache

• Reverse Proxies entlasten einen Webserver von Anforderungen, indem sie vor diesen geschaltet werden. Der Geschwindigkeitsgewinn resultiert zum einen aus der Lastverteilung (der Proxy kann z.B. einen eigenen Server verwenden), zum anderen aus der Spezialisierung auf eine bestimmte Aufgabe, z.B. das Ausliefern von Dateien. Hier sind bekannte Vertreter wie beispielsweise Varnish oder Squid in der Performance einem Universalserver wie Apache oder IIS deutlich überlegen. Varnish ist hier der bevorzugte Partner für Drupal.

• Content Delivery Networks sind eigentlich keine Cache-Systeme im engeren Sinne, haben aber einen ähnlichen Zweck wie Reverse Proxies: sie fangen einen Teil der Anfragen für Dateien an den Webserver ab und entlasten diesen dadurch. Daneben sind sie spezialisiert, z.B. auf das Bereithalten von Bildern oder Videos, und ermöglichen durch verteilte Standorte u.U. eine schnellere Auslieferung der Inhalte an den Benutzer.

Außerdem gibt es natürlich auch die internen Caches der verschiedenen Server-Komponenten, vom Datenbankserver (MySQL) bis zum Webserver (Apache), ggf. auch auf Hardwareebene - damit hat aber Drupal nicht viel zu tun.

Und was verwenden wir jetzt für unser Drupal-Projekt?

Viel hilft viel? Nein, definitiv nicht. Wir haben zum einen eine beschränkte Menge an verfügbaren Methoden, insbesondere auf Shared Hosting Servern stehen viele der erwähnten Verfahren nicht zur Verfügung. Zum anderen müssen Drupal und die benutzten Cache-Verfahren sauber zusammenspielen, und hier gibt es eine ganze Reihe von Fehlerquellen zu beachten:

• Cache-Methoden können für die Art der zu cachenden Information ungeeignet sein, z.B. sollte man große Dateien nicht in einem Datenbank-Cache ablegen.

• Ein Cache kann relativ wirkungslos sein, wenn sich die darin enthaltene Information zu oft ändert, oder zu selten benötigt wird. Beispiel: niemand würde die aktuelle Uhrzeit in einem Datenbank-Cache ablegen, oder? Und muss man eine 'AGB'-Seite unbedingt cachen?

• Ein Cache kann die Performance unserer Anwendung durchaus auch negativ beeinflussen, wenn er z.B. unterdimensioniert ist und dadurch einen Server oder eine Datenbank laufend zum Ein- und Auslagern von Daten zwingt.

• Schlimmstenfalls liefert uns ein falsch konfigurierter Cache ständig veraltete Informationen, zwingt unseren Server in die Knie oder beeinträchtigt die Funktion unserer Anwendung auf andere Weise. Letzteres ist z.B. der Grund, warum auf Drupal-Seiten leider so häufig der Block-Cache deaktiviert ist.

Die Kunst besteht darin, eine sinnvolle Kombination von Cache-Verfahren zu finden, welche wirklich einen Leistungsschub für unsere schnelle Drupal Webseite bewirkt, und zwar zu vernünftigen Kosten. Dies erfordert eine gute Kenntnis der Drupal-Anwendung und ihrer Daten, sowie der Konfiguration, Stärken und Schwächen und des Zusammenspiels der verschiedenen Cache-Methoden.

Und, bei aller Sachkenntnis: es kann nichts schaden, geeignete Benchmarks und Profiling-Verfahren einzusetzen, vom einfachen Apache Benchmark bis hin zu umfangreichen Monitoring-Systemen wie New Relic

In "Drupal Caching Teil 2" werfen wir einen ausführlichen Blick auf das interne Caching von Drupal: wie funktioniert es, wie kann es konfiguriert oder angepasst werden, und wie nutzt man es in eigenen Modulen? Und wir räumen vielleicht mit einigen verbreiteten Vorurteilen auf, z.B. dass der Drupal Cache komplett abschaltbar sei. Bis dann!