Drupal 8 BigPipe - Rendern auf Warpspeed
Performance ist ein sehr wichtiger Faktor für Websites, entscheidet sie doch nicht selten über die Conversion-Rate in Shops oder die Besuchsdauer von Nutzern. Drupal 7 ist durchaus ein performantes System - sofern man in der Entwicklung die richtigen Stellschrauben anzieht und mit Hilfe eines Reverse-Proxys für eine schnelle Auslieferung der Seiten sorgt. Schwierig wird es hier allerdings bei dynamischen Inhalten, wenn beispielsweise angemeldete Nutzer einer Website personalisierten Inhalt präsentiert bekommen. Hier stößt Drupal 7 aufgrund der unflexiblen Cache-Struktur an seine Grenzen. Nur mit Hilfe von Contrib-Modulen wie Boost, Entity Cache, Render Cache oder Advanced Cache konnte man hier bisher Abhilfe schaffen. Wie das Problem jetzt endlich in Drupal 8 angepackt und gelöst wird, möchte ich in diesem Blogpost vorstellen.
Caching in Drupal 8
Ein großes Problem in Drupal 7 bezüglich des Caching ist, dass es nicht möglich ist, einzelne Elemente Cache-übergreifend zu invalidieren. Möchte man beispielsweise auf einer Website einen Block hinzufügen oder herausnehmen und diese in der neuen Version ausgeben, muss zunächst der komplette Page-Cache gelöscht werden damit die Site in neuer Version gerendert, gecacht und ausgegeben wird. Dies ist kein großes Problem auf einer Website mit wenig Content und Traffic, sorgt dafür aber für Performance-Einbußen, denn der Page-Cache muss für alle Seiten komplett neu aufgebaut werden. In Drupal 8 können nun gecachte Elemente leichter mit den im Folgenden beschriebenen Methoden gecacht, identifiziert, invalidiert und ausgegeben werden. Hierfür ist es notwendig, die verschiedenen Abhängigkeiten eines gecachten Elements zu bestimmen und zu entscheiden, welche Methodik anschließend angewandt werden soll. In Drupal 8 gibt es dazu ein neues „CacheableDependencyInterface“ welches für diese Meta-Daten von Elementen zur Verfügung steht. Von Haus aus werden diese Daten u.a. von Config- und Content-Entities, Blöcken und vielen weiteren Objekten unterstützt.
Cache-Contexts
Ein Cache-Context bietet Meta-Informationen über ein gecachtes Element auf Basis seines Kontextes. In Drupal 8 wird es möglich sein, Elemente nach Varianten ihrer Kontexte zu cachen. Dies ging zum Teil schon in Drupal 7 (bspw. über Rollen oder URL), kann nun in Drupal 8 jedoch noch viel genauer gesteuert werden, beispielsweise anhand der Sprache oder den Berechtigungen. Über die Cache-Context API ist es nun möglich, solche Kontexte zu definieren.
Cache-Tags
Mit Hilfe von Cache-Tags können gecachte Elemente markiert werden, die abhängig von Daten in Drupal sind. Ein gutes Beispiel für den Einsatz von Cache-Tags wären personalisierte Blöcke für Nutzer - also Blöcke, die nutzerspezifische Daten enthalten. Jedes gecachte Element bekommt nun einen Tag mit der User-ID des Nutzers und kann anschließend exakt mit Hilfe dieser identifiziert werden. Es ist nun möglich, nur Elemente aus dem Cache zu entfernen, die mit der ID des Nutzers getaggt sind. Somit ist es nicht mehr notwendig, den kompletten Cache zu leeren.
Cache Max-Age
Die dritte Methodik kümmert sich um die Problemstellung, dass einzelne Elemente eine begrenzte Lebensdauer besitzen und durch eine „max-age“-Zeit invalidiert werden - diese Elemente müssen zu einem bestimmten Zeitpunkt aus dem Cache entfernt werden. Es ist ebenfalls möglich, Elemente als dauerhaft zu markieren, sodass diese permanent im Cache verbleiben.
BigPipe to the Rescue - Rendern in Drupal 8
Das Caching von Seitenelementen ist ein Teil der Miete. Einen nicht unerheblich größeren Teil macht allerdings das Rendering der Inhalte aus. Inspiriert von Facebook wird das Rendern nun über „BigPipe“ geregelt. BigPipe schickt zunächst das Gerüst der Website an den Browser und liefert nach und nach die Elemente der Seite an den Browser. Der Vorteil ist hier, dass die einzelnen Elemente nun nicht mehr den Aufbauvorgang einer komplette Seite blockieren, falls Sie aufwändiger im Rendering sind. In der Praxis ist dieses Prinzip sehr schön in Facebooks Timeline zu beobachten.
Mit Hilfe von Platzhaltern wird eine Seite in ihre einzelnen statischen und dynamischen Elemente unterteilt. Die dynamischen und gecachten Elemente kennt Drupal über die oberhalb vorgestellten Cache-Methoden bereits und kann hierfür automatisch Platzhalter setzen. Die zu erzeugende Seite kann nun auch mit diesen Elementen gecacht werden, da nur noch die Platzhalter sowie der statische Inhalt zwischengespeichert werden. BigPipe ersetzt dann selbstständig die Platzhalter während des Rendering. Hier kommen die sogenannten „Independent Lazy Builder“ zum Einsatz, die unabhängig voneinander die einzelnen Elemente erzeugen. Die Platzhalter, die am Anfang im Gerüst mitgesendet werden, können dann mit Hilfe dieser Technik auf Client-Seite ersetzt werden.
Mehr zu Platzhaltern: http://wimleers.com/talk-making-drupal-fly-fastest-drupal-ever-here/#/4/13
Vorsprung durch Technik - Drupal 8 wird großartig
Die doch sehr lange Entwicklungszeit von Drupal 8 scheint Früchte zu tragen: Mit der Implementierung von BigPipe und den dazugehörigen Komponenten setzt sich Drupal als CMS technisch wieder an die Spitze der großen Systeme. Modulentwickler können das System durch das Hinzufügen von Cache-Tags und Cache-Contexts für ihre eigenen Elemente zu ihrem Vorteil erweitern und hierdurch für einen ordentlichen Geschwindigkeitsbonus sorgen.
Weitere Nachlese
- https://events.drupal.org/barcelona2015/sessions/making-drupal-fly-fastest-drupal-ever-here
- http://buytaert.net/the-future-of-decoupled-drupal
Bildnachweise:
?file=USS_Enterprise-D.jpeg){kind=link}