WordPress bietet ein einfaches und in hohem Maße erweiterbares Caching System an. Viele Funktionen arbeiten unter der Haube damit. In den eigenen Code lässt es sich sehr einfach einsetzen. Smashing Magazine hat dazu einen umfangreichen Beitrag geschrieben. Aufwändige Datenbankabfragen und viele andere performancelastige Berechnungen und Ausgaben müssen mit dem flexiblen WordPress Caching System so nicht jedes Mal aufs Neue durchgeführt werden. Stattdessen können sie dir in zukünftigen Abfragen rasend schnell beantwortet werden. Eine Einführung in das Caching System von WordPress gebe ich dir in diesem Blogpost. Außerdem möchte ich dir eine Inpsyde Lösung vorstellen, die den WordPress Caching Prozess noch weiter vereinfacht.
Einführung in das WordPress Caching System
Im Normalfall haben Elemente im WordPress-Cache keine Persistenz. Sie sind also nur für einen einzelnen Seitenaufruf im Cache und müssen für neue Requests neu erstellt werden.
Die einzige Ausnahme bilden die Transient-Funktionen von WordPress, die Elemente im Cache in die Datenbank schreibt. Für diese Transients kannst du eine Lebensdauer angeben, nach der sie wieder neu generiert werden muss. Bedauerlicherweise führen häufige Datenbankzugriffe oft zu Performanceproblemen. Verwaiste Transient-Datensätze sind ein wiederkehrendes Ärgernis, welches nach und nach die Datenbank aufbläht.
Die Kontrolle darüber, welche Art Cache wie lange wohin gespeichert wird, gibt WordPress aber zum Glück auf Wunsch komplett aus der Hand. Mithilfe einer “wp-content/object-cache.php”-Datei – beziehungsweise eines Caching-Plugins, das eine solche Datei anlegt – kann das Caching-System von WordPress komplett ausgetauscht und somit an zahlreiche externe Tools angeschlossen werden, zum Beispiel:
- Redis
- Memcached
- APCu
Je nachdem, was der Server zur Verfügung stellt, kann man also auf verschiedenste Weise an einen “persistenten Object Cache” gelangen. Damit kannst du deine WordPress-Performance gehörig verbessern. Denn jetzt können Cache-Elemente einen Seitenaufruf überdauern und beim Nächsten sofort wieder zur Verfügung stehen. Das ist einer der wichtigsten Mechanismen für Website-Performance überhaupt.
WordPress Caching im Alltag
Im Agenturalltag steht man nun aber gelegentlich vor der Situation, dass nicht alle Systeme vollkommen gleich sind, auf denen man ein- und dieselbe Seite lauffähig bekommen möchte. Das Live-System mag mit Redis laufen, für das interne Testsystem steht nur APCu zur Verfügung und ein Entwickler auf seiner lokalen Umgebung hat eventuell gar kein externes Caching. Für das Deployment von WordPress-Websites würde das bedeuten, pro Server eine eigene Caching-Lösung zu deployen. Das ist unübersichtlich und unelegant.
Nicht immer sind solche Szenarien vermeidbar und selbst wenn sie es sind, bleibt immer noch der Wunsch, standardisierte Tools für wiederkehrende Anforderungen zu finden. Es ist einfach nicht praktikabel, mit zwanzig verschiedenen object-cache.php Dateien zu jonglieren und überall etwas anderes installiert zu haben.
Der Caching Standard PSR-6
In der großen weiten PHP-Welt hat man diesen Wunsch ebenso verspürt. Darum hat man einen Standard namens PSR-6 http://www.php-fig.org/psr/psr-6/ geschaffen. Dieser definiert eine Schnittstelle, nach der verschiedene Caching-Backends und Clients vollkommen unabhängig voneinander arbeiten können. Auf deutsch: Wenn ich eine PSR-6-Lösung einsetze, muss mich überhaupt nicht mehr interessieren, ob hintendran nun Memcached oder Redis arbeitet. Mit “Stash” ( http://www.stashphp.com/ ) existiert eine Bibliothek, die alle erdenklichen Cache-Arten und -Systeme unterstützt und darüber hinaus noch einige weitere Features unterstützt. Zwei davon möchte ich näher beschreiben.
Regeneration Before Expiration / Stampede Protection
Cache-Items können neu generiert werden, noch bevor das Ende der Lebensdauer des Caches erreicht ist. Somit stehen sofort neue Daten zur Verfügung. Außerdem wird so vermieden, dass mehrere Nutzer ein- und denselben Cache neu generieren müssen. Bei sehr aufwändigen Prozessen unter extremen Lastszenarien kann dies schlimmstenfalls zu einem kompletten Crash führen, da jeder hinzukommende neue Seitenaufruf erneut den teuren Regenerationsprozess startet, und somit noch mehr Ressourcen auffrisst.
Hierarchal Cache / Group Invalidation
Stash macht es möglich, seine Caches ähnlich einer Ordnerstruktur zu gruppieren und dann durch Löschen eines Elternknotens sämtliche Unterelemente zu invalidieren. Diese Problematik taucht immer wieder auf, ist in WordPress nicht allzu gut lösbar und hat daher schon zu abenteuerlichen, wenn auch brillianten Lösungsansätzen geführt: https://www.tollmanz.com/invalidation-schemes/
WP Stash
Die genannten Alltagsanforderungen und die Möglichkeiten von Stash vor Augen führten zu der reizvollen Idee, WordPress an Stash anzubinden. Das Erzeugnis haben wir “WP Stash” getauft und ist ab sofort auf GitHub verfügbar. Es ist ein MU-Plugin, läuft also immer und ist nicht deaktivierbar.
Du konfigurierst WP Stash über die wp-config.php. Derzeit ist es möglich einen CacheDriver und dessen Parameter anzugeben. Beispielsweise kannst du definieren, dass Redis benutzt wird, und welche Datenbank angesprochen werden soll. Du kannst alle Treiber verwenden, die Stash bereitstellt. Mehr dazu unter http://www.stashphp.com/Drivers.html
Hier ein Beispiel, wie du WP Stash für APCu konfigurieren kannst:
define( 'WP_STASH_DRIVER', 'Stash\\Driver\\Apc' );
define( 'WP_STASH_DRIVER_ARGS', serialize( array('ttl' => 3600 ) ) );
Ist kein Treiber definiert, benutzt WP Stash einen In-Memory-Cache als Rückfalllösung, dessen Verhalten den gewöhnlichen WordPress-Cachingmethoden entspricht. Dieser hat demnach auch keine Persistenz.
Mithilfe von WP Stash können wir jetzt also dieselbe Website auf verschiedenste Systeme deployen und müssen sie nur noch per Konfiguration in der wp-config.php an das jeweilige Caching-Backend anschließen. Zusätzlich bekommen wir einige Features und Stabilitätsverbesserungen gratis dazu.
Ausblick
Durch das eingeschränkte Interface der wp_cache_* Funktionen können nicht alle zusätzlichen Features von Stash direkt angesprochen werden. Darum arbeiten wir an einer Client-Bibliothek, die sowohl das bekannte WordPress-Caching soweit wie möglich um diese Funktionen erweitert, als auch den Umweg über WordPress komplett umgeht und direkt mit WP Stash zusammenarbeiten kann.
Failed to submit:
one or more fields are invalid.