Du solltest einen persistenten Objekt-Cache verwenden

foto von mxart bei pixabay
foto von mxart auf pixabay

sagte mir WordPress nach dem Update auf v 6.1. Allerdings wird in den wenisten Hostingpaketen überhaupt zur Verfügung stehen, was mit persistentem Objektcache gemeint ist: Redis oder Memcached. Dafür braucht man einen eigenen Server (jedenfalls meistens). Was man auch auf Shard Hosts haben kann, ist ein normaler, resp. nicht persistenter Objektcache.

Während Seiten-Caching statische Kopien dynamisch generierter Seiten zwischenspeichert, speichert ein Objekt-Cache Datenbank-Abfragen zwischen. Damit wird die Datenbank nicht bei jedem Aufruf erneut belastet. Ist der Cache persistent, macht er das dauerhaft, ansonsten nur für die Dauer der Abfrage.

Um die Meldung loszuwerden, benötigt man ein Plugin, das eine Verwaltung für verfügbaren Objektcache (OPCache in den meisten Fällen oder APCu) innerhalb der WordPress-Installation aktiviert, und gecachte Anfragen für länger speichert. Bei webgo (SSD Power) verwendete ich den APCu Manager. Bei APCu handelt es sich eigentlich einfach nur um Objektcaching (nicht persistent). „Persisent“ wird es erst durch das Plugin (es gibt von PerfOps One auch ein OPCache-Managment-Plugin), welches die gecachten Objekte zwischenspeichert.

Mit oder ohne APCu-Manager sah das Ergebnis des Performancetests allerdings gleich aus. Wenn die Site vom APCu-Manager profititierte, dann in einem Ausmaß, das sich messtechnisch nicht signifikant von dem ohne APCu Manager abhob.

Desktop

screenshot 20221116 122538

Mobile

screenshot 20221116 122045

Nach Aktivierung einer Objektcache-Verwaltung empfiehlt es sich, genau zu beobachten, wie sich die Website verhält, und zu messen, ob sich der Einsatz eines Plugins dieser Art tatsächlich lohnt. Fallweise kann es Konflikte mit anderen Plugins geben. Falsch konfiguriert kann ein persistentes Objektcache-Plugin mehr Probleme verursachen als positiv wirksam sein.

Wie Seitencaching funktioniert, und wo es meist ausreichend ist

Bei einem Seiten-Cache sind keinerlei Datenabfragen mehr erforderlich, da die ganze Seite bereits als HTML-Version zwischengespeichert wurde. Wenn jemand die Seite das nächste Mal anfordert, stellt der Webserver die zwischengespeicherte Version der Seite bereit, ohne PHP und Datenbankabfragen auszuführen. Ein Objekt-Cache hat hierbei keine Aufgabe.

Wo ein Objektcache seine Wirksamkeit ausspielt ist beispielsweise in einem Woocommerce-Shop, in dem ein eingeloggter Benutzer Artikel zu seinem Warenkorb hinzufügt und auf Kontoinformationen zugreift. An der Stelle ist ein Seiten-Cache nicht hilfreich, da der Inhalt nur für einen einzigen Benutzer gilt. Ein Objekt-Cache kann Kontodaten- oder Warenkorb-Abfragen hingegen beschleunigen, wenn darauf mehr als einmal zugegriffen wird.

Echte Cronjobs von Vorteil

Echte Cronjobs zu verwenden statt auf Besuche angewiesen zu sein die WP-Cron auslösen, ist dem Gesamtergebnis zuträglich. Hat man zu wenig Besucher, werden auf Termin gelegte Aufgaben (wie Backups) dennoch zur rechten Zeit erledigt, hat man viele Besucher, wird die Performance durch WP Cron nicht beeinträchtigt.

Bestimmte Einstellungen (APCu Manger) erfordern es sogar:

grafik 7

Um einen echten Cronjob zu verwenden braucht es ein Hosting-Paket, welches das Einrichten von Cronjobs integriert (oder einen externen Anbieter, über den man Cronjobs einrichten kann).

Ans Ende des editierbaren Bereichs der wp-config.php folgende Zeile einfügen:

define('DISABLE_WP_CRON', true);
/* That's all, stop editing! Happy publishing. */

Dann den Cronjob beim Hoster einrichten. Mit ziemlicher Sicherheit liegt eine Anleitung für Kunden vor, wie man das (bei ihm) macht. Ggf. googeln, um die Anleitung zu finden (so fand ich sie bei meinem Hoster – FAQ sind ja selten dafür gemacht, dass man darin die Antworten auf die Fragen findet, die man tatsächlich hat ;)).

Wenn ich bei All-inkl. einen Cronjob eingebe, dann rufe ich die URL auf, z.B. https://blog.webentwicklerin.at/wp-cron.php?doing_wp_cron

Mehr zum Einrichten von Cronjobs über diesen Link.

Ein nützliches Plugin zur Überwachung der Cronjobs ist WP Crontrol.

Die Meldung einfach ausblenden

Kein Bedarf an einem persistenten Objektcache, und / oder Du möchtest die Meldung dennoch loswerden? Dieses kleine Snippet hilft:

add_filter( 'site_status_tests', function( $tests ) {
	unset( $tests['direct']['persistent_object_cache'] );
	return $tests;
});

Nachtrag 14.02.2023: Wie ich mittlerweile aus bisherigen Erfahrung lernte, erfordert der Betrieb eines Objekt-Cache-Plugins einige Aufmerksamkeit, um Probleme zu vermeiden oder bereits eingetretene Probleme zu lösen (es ist ja nicht so, dass man nicht gewarnt würde).

Glücklicherweise lasse ich mir von UpdraftPlus (premium) E-Mails nach jeder Sicherung schicken, sonst hätte ich nicht so schnell bemerkt, dass was nicht stimmt. Alle paar Minuten, zum Schluss sogar minütlich, entstand ein neues Datenbank-Backup (mit dem Nebeneffekt, dass es ältere Backups dahinraffte).

Hinzu kam, dass ich nach dem klick auf „deaktivieren“ von UpdraftPlus zwar die Bestätigung las, das Plugin sei deaktiviert worden, das war jedoch nicht der Fall. Gar kein Plugin ließ sich de- oder aktivieren.

Nachdem ich alle zwischengespeicherten Objekte im APCu-Manager gelöscht hatte, funktionierte – erstmal – alles wieder.

Nachtrag 20.02.2023: Da es regelmäßig passierte, dass bei aktivem APCu Manager die Durchführung der Cronjobs (unabhängig davon, ob WP Cron oder echte Cronjobs) zum Erliegen kam, beschloss ich erstmal, künftig darauf zu verzichten, und die Meldung auszublenden.

Nachtrag 31.10.2023: Wer einen Hoster mit Redis hat, kann das Redis Cache Plugin verwenden, um den persistenten Objekt Cache zu aktivieren. Das Plugin Installieren, aktivieren und es wird umgehend ersichtlich, ob der Object Cache verfügbar ist. Dann braucht man nur noch den Objekt-Cache aktivieren. Im Versuch bei webgo stellte sich heraus, dass Redis verfügbar ist.

grafik

Kurz nach der Aktivierung machte es den Anschein, als würde der Objekt Cache keinen Unterschied bewirken, und ich wollte das Thema (erneut) abhaken. Ein paar Stunden später testete ich nochmal, und die Ladezeiten hatten sich halbiert. Später waren sie dann wieder beinahe wie gehabt. Also lohnt es sich für (m)ein kleines Blog doch nicht, einen persistenten Objekt Cache zu verwenden…? – So lange kein Fehlverhalten auftritt, lasse ich ihn aktiv und schaue, was weiter passiert.

Nachtrag 01.11.2023: Eine Verbesserung gab es, als ich von Cache Enabler (wieder) zu WP Super Cache wechselte.

Es hängt von mehreren Faktoren ab, was ein persistenter Objekt-Cache bringt, und es bedarf ein paar Experimente und Tests, um die für das eigene Projekt besten Performance-Bedingungen herauszufinden. Die besten Ergebnisse erzielte ich mit der Kombination aus WP-Super-Cache, Autoptimize und Redis-Cache. Da kamen schon mal Werte wie dieser heraus:

screenshot 2023 11 01 133746

5 Antworten zu „Du solltest einen persistenten Objekt-Cache verwenden“

  1. Ernstl

    Moin.

    Interessanten Beitrag, ich weiss noch keinen klaren Weg. Interessant fand ich spontan, daß du mit mehreren Plungins arbeitest, nämlich WP-Super-Cache, Autoptimize und Redis-Cache.

    Danke

  2. Bernhard

    Hallo Gabriele!
    DANKE für deine Testungen!
    Habe mir dadurch viel Zeit erspart.
    lg

  3. Michél

    Huhu,

    habe ich das richtig verstanden, du aktivierst bei APCu-Manager Garbage collector und Analytics – den Objectcache lässt du aus?

    Grüße

    Michél

    1. webentwicklerinat

      sorry, war länger nicht da. Mittlerweile gab ich dem APCu Manager nochmal einen Versuch, und es läuft wieder reibungslos. Ich hatte zuerst den OPcache Manager an, dann den APCu Manager (den OPcache Manager aber aus), dann eine Weile gar nichts davon, mittlerweile wieder ausschließlich den APCu Manager. – Einen Unterschied in der Performance konnte ich damit nicht wirklich messen (10-20 MS – vielleicht…)

  4. Rabi

    Hallo,

    danke für diesen hilfreichen Beitrag!
    Ich habe die Meldung bisher immer ignoriert und werde das jetzt auch weiterhin tun. 😉
    Mein Blog ist klein und die Besuchsrate überschaubar, daher werde ich auf diesen persistenten Cache verzichten. 🙂
    Mal sehen, ob ich es hinbekomme, dass die Meldung ausgeblendet wird. ^.^‘

    Beste Grüße
    Rabi

Bitte Kommentarfunktion nicht für Supportanfragen nutzen. Dem kann hier nicht entsprochen werden. Die Angabe einer E-Mail-Adresse und eines Namens ist nicht erforderlich. Einen (Spitz)-Namen zu nennen wäre aber doch nett.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Sowohl angegebener Name als auch E-Mail-Adresse (beides ist optional, dafür werden alle Kommentare vor Veröffentlichung geprüft) werden dauerhaft gespeichert. Du kannst jeder Zeit die Löschung Deiner Daten oder / und Kommentare einfordern, direkt über dieses Formular (wird nicht veröffentlicht, und im Anschluss gelöscht), und ich werde das umgehend erledigen. – Mit hinterlassenen Kommentaren hinterlegte IP-Adressen werden nach zwei Monaten automatisch gelöscht

publicly queryable