Performance-Tipp: Microcache in NGinx nutzen + WordPress-Config

Geschrieben am 03.09.2014 um 22:48 von

Bildschirmfoto-1Vor allem Websites, die viele Besucher haben, kommen in der Regel nicht drum herum eine ordentliche Cachinglösung zu verwenden. Beispielsweise gibt es für WordPress-Nutzer diverse Caching-Plugins, die die Seiten auf verschiedene Art und Weise zwischenspeichern. Unabhängig vom verwendeten CMS, gibt es für Nutzer von Nginx den Microcache, der aber eingestellt und aktiviert werden muss. Hierzu wird SSH-Zugang benötigt, die Einstellungen sollten nur vorgenommen werden, wenn man weiß was man macht! Je nach CMS müssen zusätzliche Einstellungen vorgenommen werden.

Der Microcache von Nginx macht nichts anderes als die Ausgabe einer Seite auf der Festplatte zwischenzuspeichern und statt der dynamischen Version auszugeben. Ich nutze den Microcache von Nginx auf meiner Seite tech-preis.de als einzige Cachinglösung. Zwar ist der Microcache dafür gedacht, die Daten kurz zwischenzuspeichern, aber man kann einstellen, wie viele Stunden zwischengespeichert werden soll.
Kommen wir nun zur Sache!

Nginx Microcache aktivieren und einstellen

Ordner anlegen, wo der Server die Daten anlegen soll

Bevor man an die Konfigurationsdateien geht, sollte man dafür sorgen, dass der Ordner existiert, in dem Nginx Daten ablegen darf. Im Prinzip könnt ihr jeden Ordner, den ihr wollt festlegen. Was sich aber empfiehlt ist das Ausnutzen des Arbeitsspeichers. Hierzu gibt es z.B. auf Ubuntu-Servern den Ordner /dev/shm. Dabei handelt es sich um eine von Ubuntu erstellte RAM-Disk. Für die beste Performance lohnt es sich die zwischengespeicherten Daten hier anlegen zu lassen.

1. Caching-Ordner innerhalb des Shared Memory anlegen:

mkdir /dev/shm/cache
mkdir /dev/shm/cache/nginx
mkdir /dev/shm/cache/nginx/tmp

Tipp: Nach dem Neustart des Servers müssen diese Ordner manchmal neu erstellt werden, da ansonsten Nginx nicht neustarten kann. Ich habe daher die oben gezeigten drei Zeilen in meiner /etc/rc.local eingetragen. Die Befehle werden dann bei jedem Neustart des Servers ausgeführt. Außerdem kann es nötig sein mit einem vierten Befehl die Ordner für den Nutzer „www-data“ (oder dem Nutzer, mit dem Nginx ausgeführt wird) beschreibbar zu machen.

/etc/nginx/nginx.conf bearbeiten

Im nächsten Schritt muss die /etc/nginx/nginx.conf bearbeitet werden. Innerhalb des http-Blocks (http {…}) fügt ihr das folgende ein:

fastcgi_cache_path /dev/shm/cache/nginx levels=1:2 keys_zone=mycache:300m inactive=60m;
fastcgi_temp_path /dev/shm/cache/nginx/tmp;

Die Dokumentation hierzu findet sich hier.

VHOST-Datei bearbeiten

Der letzte Schritt ist das Bearbeiten der vhost-Datei, die zu eurer Domain gehört. Diese findet ihr in /etc/nginx/sites-enabled/. Je nach Konfiguration des gesamten Systems habt ihr so eine Datei nicht, sondern alles steht in der /etc/nginx/sites-enabled/default oder gar in der /etc/nginx/nginx.conf.

Bei mir findet man alles unter: /etc/nginx/sites-enabled/100-tech-preis.de.vhost

Diese Datei müsst ihr öffnen und innerhalb des location-Blocks „@php“ das folgende oben Eintragen:

fastcgi_cache_valid any 20m;
fastcgi_ignore_headers Cache-Control Expires;
fastcgi_no_cache $nocache;
fastcgi_cache_bypass $nocache;
fastcgi_cache_use_stale error timeout invalid_header updating http_500;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache mycache;

fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_read_timeout 2m;

Einstellen, was und wann gecached werden soll

Vor dem „@php“-Location-Block könnt ihr Anweisungen schreiben, wann Nginx die Variable $nocache auf TRUE setzen soll. Wird das gemacht, wird der Request nicht gecached.
Im Fall von tech-preis.de, will ich beispielsweise nicht, dass die captcha.php gecached wird. Außerdem will ich nicht, dass alle Nutzer, bei denen der Cookie ’nice_one‘ gesetzt ist, gecached werden. Auch beim Aufruf des Ordners „admincp“ sollen die Daten immer Server generiert werden und nicht aus dem Cache kommen:
set $nocache "";
if ($http_cookie ~ (nice_one)) {
set $nocache "true";
}
if ($request_method ~ ^(HEAD|POST)$) {
set $nocache "true";
}

if ($uri ~ (captcha.php)) {
set $nocache "true";
}
if ($uri ~ (admincp)) {
set $nocache "true";
}

Die hervorgehobenen Zeilen sollten in jedem Fall gesetzt werden. Die erste Zeile setzt die Variable standardmäßig auf leer. Und die andere Anweisung verhindert das Zwischenspeichern von POST- und HEAD-Anfragen.

Nginx neu starten

Der letzte Schritt ist wohl der einfachste – Nginx muss neugestartet werden:
service nginx restart

Wenn alles in Ordnung ist, dann bekommt ihr keinen Fehler und der Cache ist erfolgreich aktiviert worden. Ab sofort werden die Seiten 20 Minuten zwischengespeichert. Wenn euch 20 Minuten zu wenig sind, dann solltet ihr den Wert bei fastcgi_cache_valid anpassen, beispielsweise:
fastcgi_cache_valid any 60m;
Damit wird jeder Request für eine Stunde gecached.

Einstellungen speziell für WordPress

Vor allem beim Einsatz von WordPress lohnt sich der MicroCache. WordPress hat hierzu eine schöne Dokumentation veröffentlicht: Nginx fastcgi_cache

Zum Ende wird erwähnt, dass man Nginx mit dem fastcgi_cache_purge-Modul kompiliert haben muss, damit das Plutin Nginx Helper funktioniert. Wenn das nicht der Fall sein sollte, ist das zwar schade, aber nicht weiter schlimm. Das einzige, was ihr dadurch nicht machen könnt:
Beim Veröffentlichen eines neuen Artikels wird dieser für Gäste erst sichtbar, wenn der Cache für die Startseite neu generiert werden muss. Gängige WordPress-Plugins, die sich ums Caching kümmern, löschen den eigenen Cache beispielsweise wenn neue Kommentare, Artikel oder Seiten veröffentlicht werden.
Wenn ihr das Modul nicht habt, dann dürft ihr den Codeblock, der unter „Finally add a location for conditional purge“ zu finden ist, NICHT bei euch übertragen. Wenn ihr das doch macht, startet der Server nicht!

Was ich insgesamt an der Caching-Lösung mit Nginx schön finde ist, dass man z.B. im Fall WordPress damit keine weiteren Caching-Plugins braucht. Schneller als Nginx wird keines dieser Plugins eure Seite machen – vor allem, wenn ihr eine SSD nutzt oder den Cache im Shared Memory/RAM speichert.

Das ist mir zu schwer, ich hab Angst das selbst zu machen

Ich empfehle mich für so etwas sehr gerne. Schaut einfach mal auf damianschwyrz.de vorbei. Es gibt die ein oder andere bekannte Referenz (allaboutsamsung.de, tabtech.de, appdated.de, …), für die ich solche Dinge bereits erledigt habe. Die Belohnung: eine schnelle Seite und zufriede Nutzer!

"Performance-Tipp: Microcache in NGinx nutzen + WordPress-Config" bewerten

Der Artikel ist schlecht!Der Artikel ist verbesserungswürdig!Der Artikel ist ganz gut.Der Artikel ist richtig gut!Der Artikel ist perfekt! Danke! (1 Bewertungen mit durchschnittlich 5,00 von 5 Sternen)
Loading...

2 Antworten zu Performance-Tipp: Microcache in NGinx nutzen + WordPress-Config

  1. Hallo Damian,

    danke für die Infos! Das habe ich bereits genau so schon so laufen, doch finde ich problematisch dass wenn der Cache abläuft, der erste user die Seite neu in den Cache generieren muss, was zu einem Performanceeinbruch in dem Problem beim user führt. Hast du eine Lösung wie man den Cache zwingen könnte sich zu erneuern bevor er abläuft? Z.B. könnte man einen Crawler losschicken den mit einem Parameter mitteilt, dass der Cache erneuert werden muss?

    Danke und viele Grüße
    Micha

    • Hi,
      naja der Sinn ist ja, dass der Cache ja irgendwann von irgendeinem User, der eben grad die Liveversion bekommt, erneuert wird. Wenn der EINE Performance Probleme hat, dann ist ja grundlegend was falsch und man sollte schauen, warum das WP trotz NGinx Caching so unheimlich langsam ist 😉 Ich für meinen Teil nehme das in Kauf, bei mir muss dieser eine Besucher allerdings trotzdem keine 10 Sekunden warten, ehe die Seite da ist.

      Sich einen Crawler zuzulegen, der regelmäßig die Seite crawled und damit den Cache erneuert wäre eine Idee. Aber da würde ich dafür sorgen, dass dieser Crawler das klug anstellt und kurz bevor er kommt der Cache für diese Seite geleert wird. Bei großem Besucheraufkommen ist das aber auch unsinnig, weil man nie im Leben genau einen Zeitpunkt abpassen wird, wo a) keiner die Seite requestet b) der crawler die Seite aus dem Cache löscht und direkt danach neu schreibt. Wenn man das in Summe schlecht umsetzt kann es aber auch passieren, dass einige User einen schönen 50xer haben, weil sie was aus dem Cache wollen, der aber parallel gelöscht wurde. Das eben vor allem bei vielen Besuchern.

      Ich persönlich nehme Abstand von sowas und sehe zu, dass meine Seite auch ohne Caching erstmal solide und schnell ist.

      Grüße

Schreibe einen Kommentar

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

*

© 2016 » Die Seite rennt auf PHP 7 und HTTP 2.0 ♥

Konnten wir Ihnen mit dieser Seite behilflich sein?

Danke für die Bewertung!

Könnten wir noch etwas verbessern, damit Sie zufriedener sind?