Die Zeiten sind doppelplusungut, um kein Blatt vor den Mund zu nehmen, möchte ich sagen, sie sind beschissen. Die aktuellen Energiekosten sind eine Katastrophe und dazu zählt letztlich auch der Strompreis. Ein Grund mehr im Webserver- und IT-Bereich auf Sparsamkeit zu achten, denn letztlich kommt ihr zwar nicht unmittelbar für VPS-, Dedicated- oder Webhosting auf, aber euer ISP schon – und der wird bei entsprechenden Ausgaben dann auch die Einnahmen steigern müssen (früher oder später).

Zudem erlaubt effizientes Caching trotz bequemer Webinterfaces bei Webanwendungen wie WordPress eine gute Seitenperformance, wenn man nicht einen von 1000 mittelprächtig entwickelten und gewarteten statischen Seitengeneratoren nutzen möchte.

Schauen zu uns zunächst mal an, was unser Ziel ist:

1. Ausbaustufe:
Statische Dateien (Text, Bilder, Videos) werden bereits direkt von Nginx ausgeliefert

2. Ausbaustufe:
Wir fügen Caching hinzu, die fertigen Cache-Dateien muss jedoch PHP noch ausliefern

3. Ausbaustufe:
Wir konfigurieren, dass Nginx die Cache-Dateien, sofern vorhanden, direkt ausliefert

Im Webserver (Nginx) konfigurieren wir das so:

# WP Super Cache rules.
set $cache_uri $request_uri;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
        set $cache_uri 'null cache';
}

if ($query_string != "") {
        set $cache_uri 'null cache';
}

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
}
  
location / {
    try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args ;
}

Im Beispiel werden alle Requests, die nicht der Methode „POST“ entsprechen (Methode zur Übermittlung von Daten) gecached. Der Cache wird noch für weitere Sonderfälle deaktiviert, beispielsweise die WordPress-API oder auch eingeloggte Nutzer oder Kommentatoren.

Achtung! Das Beispiel ist hierbei konkret für Seiten gedacht, die SSL/TLS nutzen (siehe Zeile „try_files“ -> „index-https.html“).

Vor und nach der Änderung können wir beispielsweise mittels h2load oder dem guten alten ApacheBench testen:

h2load -c 120 -D 30 https://eureseite.org/

Am Beispiel einer meiner WordPress-basierten Seiten konnte ich bei gleicher Performance eine Verbesserung von ca. 10% CPU-Auslastung durch die Nginx- und PHP-Container auf nun 2% nur durch den Nginx-Container beobachten. Eine Verringerung der CPU-Last um etwa 8% bei gleicher Performance also.

Limitierender Faktor ist bei meinen Tests weiterhin die Netzwerkverbindung von ca. 200 Mbit, sodass ich beim Aufruf meiner gecachten Startseite auf etwa 440 Requests pro Sekunde komme (Serverdaten: 6 Kerne eines Ryzen 9 3900, 6GB RAM, NVMe-basierter Storage). Mangels Bandbreite wäre eine Performanceverbesserung derzeit nur über schnellere Netzwerkanbindung möglich.

Besonders nützlich kann das Caching werden, möchte man auf einem ARM-basierten System, z. B. einem RaspberryPi, Webseiten einigermaßen performant betreiben. Besonders wo CPU-Zeit der limitierende Faktor ist, lässt sich hier mit dem statischen Caching einiges bewegen.

Wünsche maximalen Erfolg!