Hinweis: Neben den Anleitungen im Rahmen dieser Serie habe ich mittlerweile fertige Shell Scripte erstellt, die quasi voll automatisch die Installation eines Servers für euch übernehmen. Ihr findet das Ganze auf github.de, wobei ihr entweder den ganzen Server per Script aufsetzen und konfigurieren lassen könnt, oder eben jeden einzelnen Schritt, wie  z.B. das Absichern des Servers, oder das Installieren eines LEMP Stacks, mit Hilfe der jeweiligen Scripte erledigen könnt. Die Scripte entsprechen quasi 1:1 zu den Tutorials.

Redis und Co. Cache me if you can!

Es gibt wohl heutzutage nichts nervigeres im Internet, also langsam ladende Websites. Okay, zugegeben, mit Werbung überladende Seiten sind auch kein Hit! Beides führt mitunter dazu, dass die Leute direkt abspringen und stattdessen eine andere Seite aufrufen. Die Ladezeiten eurer Website hängen von einer Vielzahl an Faktoren ab, wovon wir uns heute einen dieser Faktoren mal genauer angucken wollen. Das Caching.

Cache bedeutet nichts anderes, als einen schnellen Zwischenspeicher. Satt also immer und immer wieder neu irgendwelche Dinge zu berechnen, aus einer Datenbank auszulesen, etc. werden die Ergebnisse aller früheren Abfragen local zwischengespeichert, entweder irgendwo auf der Festplatte des Servers, vorzugsweise einer SSD, oder am besten direkt im RAM, je nachdem, welche Methode zum Einsatz kommt.

WordPress z.B. setzt auf PHP. Im Normalfall werden bei jedem Seitenaufruf die Seiten anhand des PHP Codes für den Besucher neu generiert. Wenn es sich dabei jetzt aber nicht um dynamischen Content handelt, wie z.B. ein Video oder dergleichen, reicht es im Prinzip aus, wenn diese Seite ein einziges Mal von eurem Webserver generiert wird. Die fertig generierte Seite wird also zwischengespeichert und steht jedem erneuten Besucher direkt zur Verfügung. Das Spart nicht nur Zeit, sondern auch Ressourcen. Eine dieser Möglichkeiten, dynamische Seiten in Form von statischen Seiten zwischenzuspeichern ist z.B. der fastcgi_cache von nginx. Wie genau dieser für WordPress und Co konfiguriert wird, werden wir uns zu einem späteren Zeitpunkt, im Rahmen der WordPress Installation angucken.

Was wir aber heute machen werden, sind die gängigen, oder zumindest in meinen Augen sinnvollen Caching Methoden, welche auch später in weiteren Tutorials zum Einsatz kommen werden, zu installieren, bzw. zu konfigurieren.

Redis – In-Memory-Datenbank

Bei Redis handelt es sich im eine sog. NoSQL-Datenbank, welche zwar keine komplexen Strukturen wie eben SQL Datenbanken speichern kann, aber dafür wesentlich schneller arbeitet. Ein weiterer Vorteil ist, dass der Redis Server komplett aus dem RAM heraus agiert. Das hat zwar den Nachteil, dass der Cache im Zweifel bei einem ungewollten Neustart des Systems leer ist, sorgt aber auch dafür, dass Anfragen viel schneller beantwortet werden, als beispielsweise von einer SSD oder gar einer HDD.

Auf Grund der Komplexität eignet sich Redis also nicht unbedingt für das Zwischenspeichern kompletter Websites, sondern eher als Object Cache, für einzelne Anfragen. Wir werden Redis aus diesem Grund hauptsächlich nutzen, um Datenbankabfragen zu cachen. Statt also immer und immer wieder Werte aus der SQL Datenbank abzurufen, werden diese mit Hilfe von Redis zwischengespeichert, wobei Redis über keine frei definierbaren Datenbanken wie z.b. MySQL verfügt, sondern lediglich numerische Datenbanken, d.h. mit den Namen 0, 1, 2 … etc. besitzt. Für den Fall, dass man mehrer Datenbanken simultan auf einem Server verwendet, sollte man sich also evtl. irgendwo Notizen dazu machen, welche Datenbank welche Werte zwischenspeichert.

Installation

Wie so oft gibt es auch bei der Installation des Redis Servers verschieden Möglichkeiten. Wir werden im Rahmen des Tutorials allerdings nur die manuelle Installation mit Hilfe der Source Files durchgehen da diese im Gegensatz zu allen anderen Optionen immer die aktuellste Version beinhalten.

Zunächst laden wir hierfür die passenden files herunter, entpacken sie und compilieren, bzw. installieren anschließend den Redis-Server.

Auf den „PREFIX=/usr“ kann theoretisch auch verzichtet werden, die Redis files werden dann statt im Ordner /usr/bin, unter /usr/local/bin abgelegt. Achtet nur am Ende bei der Konfiguration darauf, welchen Pfad ihr gewählt habt.

Die „Installation“ in diesem Sinne ist nun eigentlich fertig, allerdings benötigen wir für die anschließende Konfiguration noch einige Ordner, bzw. Rechte. Da es unklug wäre, den Redis-Server unter dem root user laufen zu lassen, da sonst kein anderer Systembenutzer, wie z.B. www-data später Zugriff darauf hätte, legen wir zusätzlich einen neuen Benutzer, bzw. eine neue Gruppe an, zu der wir auch direkt www-data als Nutzer hinzufügen.

Für die spätere Kommunikation mit php, installieren wir an dieser Stelle gleich schon mal die Erweiterung php-redis.

Konfiguration

Kommen wir nun zur Konfiguration unseres Redis Servers. Hier haben wir zwei Möglichkeiten, Redis kann entweder per TCP Port erreichbar sein, oder aber per UNIX Socket. Beides Zusammen ist eher weniger Sinnvoll.

Da die Kommunikation via UNIX Socket in der Regel etwas schneller läuft, also übe den  TCP Port, ist dieser in meinen Augen immer die bessere Wahl, auch weil der Socket nicht von Außen erreichbar ist und das ganze System somit in sich geschlossen ist. Für den Fall, dass ihr aber lieber den TCP Port verwenden möchtet, weil ihr z.B. Redis auf einem extra Server laufen lassen wollt, werde ich beide Konfigurationen kurz erklären.

Option 1: UNIX Socket

Wir könnten zwar auch das automatische Konfigurations-Script benutzen, erstellen die Config aber lieber von Hand. Hierzu kopieren wir die Beispiel-Config in unser zuvor erstelles redis Verzeichnis.

Diese Config können wir nun manuell editieren, oder aber eben wie bereits in zurückliegenden Tutorials, mit Hilfe von sed.

Option 2: TCP Port

Die Konfiguration läuft ähnlich ab. Wir kopieren zunächst die config und editieren sie.

Da unser Redis Server nun aber via TCP Port online erreichbar ist, also ein potentielles Angriffsziel, benötigen wir noch ein sicheres Passwort. Dieses generiere ich automatisch und füge es der Config hinzu.

Die Ausgabe „Dein Redis Passwort: ….“ solltest du dir am besten irgendwo notieren, da du das Passwort später immer wieder benötigst, um mit deinem Redis Server zu kommunizieren.

Hinweis: Solltest du vergessen haben das Passwort zu notieren, kannst du es auch einfach jeder zeit in der /etc/redis/redis.conf unter „requirepass“ nachlesen können.

Systemstart

Damit Redis auch nach einem Reboot wieder startet, bzw. um den Redis Server komfortabler zu administrieren, benötigen wir noch ein passendes Service script.

Anschließend sorgen wir dafür, dass der Server das Script auch findet und aktivieren Redis beim Systemstart.

So, das wars auch schon. Nun sollte Redis eigentlich ohne Probleme auf eurem Server laufen.

Aufräumen nicht vergessen.

Testen

Falls ihr überprüfen wollt, ob alles funktioniert habt, könnt ihr das mit Hilfe des „redis-cli“ scripts.

In jedem Fall sollte die Antwort „PONG“ lauten.

APCu – APC User Cache

APCu ist quasi der Nachfolger von APC – Alternative PHP Cache. APC fungierte zum einen als PHP-Beschleuniger, indem Bytecode im RAM ausgelagert wurde und zum anderen bot es einzelnen PHP Apps die Möglichkeit selbst Daten zu cachen. Die Aufgaben des PHP-Beschleunigers übernimmt mittlerweile OPcache, welches von Haus aus mit PHP zusammen ausgeliefert wird und das Cachen übernimmt nun eben APCu. Aufwendige Datenbankabfragen lassen sich z.B. mit APCu in den Zwischenspeicher legen, was wertvolle Zeit einspart.

Installation

APCu wird leider aktuell nicht als Modul für php7.2 per apt angeboten, weswegen wir es ebenfalls, wie Redis, aus dem Source compilieren.

Aufräumen nicht vergessen.

Eine weitere Möglichkeit wäre die Installation via PECL.

Bitte aber nur auf einem Weg installieren!

Konfiguration

Die Konfiguration erledigen wir wieder schnell mit Hilfe von sed via Console. Nicht vergessen php-fpm anschliend neuzustarten.

Um zu überprüfen, ob alles funktioniert habt, könnt ihr den Befehl php -m benutzen. Der Output sollte in etwas so aussehen, wobei der Eintrag APCu relevant ist.

OPcache – On Board Bescheleunier

Wie bereits im vorherigen Schritt erklärt, ist OPcache fester Bestandteil von PHP und fungiert als Beschleuniger. Klingt erst mal ganz gut, ne? Leider aber wird OPcache weder von Haus aus aktiviert, noch konfiguriert.  Beides lässt sich aber mit wenigen Handgriffen, bzw. einem copy&paste Befehl beheben.

 

So, damit wären wir auch schon durch. Ihr habt nun 3, bzw. wenn man fastcgi_cache aus dem LEMP Tutorial hinzuzählt, 4 Cache Möglichkeiten, welche sich für unterschiedliche Einsatzzwecke eignen.

Kommentieren Sie den Artikel

Please enter your comment!
Please enter your name here