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
Mobile
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.
Warum Seitencaching meistens 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 würde Kontodaten- oder Warenkorb-Abfragen beschleunigen, wenn darauf mehr als einmal zugegriffen wird.
Da viele WordPress-Sitebetreiber zudem keine Techniker sind, halte ich es für keine so gute Idee, das Fehlen desselben in die Verbesserungsvorschläge zu integrieren. Gewissenhafte Gemüter werden dies als Handlungsbedarf verstehen, weil sie zu gerne alle Beanstungen zum Website-Zustand gelöst sehen wollen.
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:
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 deaktivieren 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, künftig darauf zu verzichten, und die Meldung auszublenden. Mein Fazit: eine aktivierte Verwaltung für persistenten Objektcache erhöht den Pflegeaufwand einer Website. Darauf würde ich mich auf Dauer nur dann einlassen wollen, wenn ein spürbarer Impact dies auch rechtfertigt.
Schreibe einen Kommentar