Redis, NoSQL und Caching | Euroxid: Oxid Freelancer

Redis, NoSQL und Caching

Oxid Performancesteigerung durch Redis

Kurze Seitenladezeiten verbessern Conversion, User Experience und Suchmaschinenranking Ihers Shops, das führen wir an anderer Stelle aus. Doch um die Ladezeiten zu verkürzen, gilt es Performance-Flaschenhälse zu beseitigen. Oft ist dabei die Datenbank ein limitierender Faktor, muss sie doch für jeden Seitenaufruf dutzende bis hunderte Abfragen bearbeiten<./p>

Eine nahe liegende Lösung ist, Ergebnisse der Datenbanken zwischenzuspeichern - sogenanntes cachen oder Caching, damit Sie beim nächsten Mal nicht abgefragt werden müssen. Redis ist unsere erste Wahl dafür. So funktioniert's...

Das bring Datenbank-Caching

In vielen Systemen - und zu vielen Onlineshops und Oxid-Systemen - gibt es nur eine Datenbank und einen Datenbankserver. Datenbank-Replikation Fehlanzeige. Während die Bilder aus content delivery networks kommen, jQuery über das Google CDN eingebunden wird und PHP sich auf alle Prozessorkerne verteilt, müssen alle Datenbankanfragen durch denselben Flaschenhals. Und der ist eng: Gigabytegroße Dateien auf der Festplatte werden nach Dateneinträgen durchsucht, um tausende von Operationen später einzelne Werte zurückzuliefern.

Wird das Ergebnis hingegen gecached, liegt es im Arbeitsspeicher vor. Die ist tausende mal schneller als die Festplatte und erfordert zum Abfragen nur einen Millionstel der Prozessorkapazität. Und das Beste: Es muss nicht mal auf dem gleichen Server sein. Damit können Sie beliebig skalieren und Peaks, also Lastspitzen abfangen.

Konkrete Zahlen zu nennen ist schwierig: sie variieren je nachdem, welche Daten Sie wie lange zwischenspeichern. Allgemein gesagt können Sie Ladezeitersparnisse zwischen 20 und 80% erreichen. Die Beispiele unten können das etwas beleuchten. Da man naturgemäß mit den größten Brocken anfängt, werden Sie am Anfang schnell Ergebnisse sehen. Die letzten Prozentpunkte herauszupressen wird hingegen aufwändig.

Redis, Memcached, NoSQL?

Die Möglichkeiten, Daten auszulagern, sind vielfältig. Bringen wir Klarheit in die Buzzwords:

  • NoSQL ist ein Sammelbegriff für Datenbanksysteme, die nicht den klassischen SQL-Strukturen folgen. Während einige große Dokumente speichern und andere Netzwerke darstellen, gibt es die extrem schnellen Schlüssel-Wert-Paare, siehe unten. Wichtig also: Es gibt schnelle NoSQL-Systeme, das Schlagwort NoSQL an sich ist aber noch kein Garant für Geschwindigkeitsvorteile.
  • Memcached ist ein reiner RAM-Speicher, der alle Daten im Arbeitsspeicher vorhält. Es ist ein Schlüssel-Wert-Paar-System (key value storage). 'MwSt':'19'. könnte ein solches Paar sein. Die Geschwindigkeit wird in 100.000 Antworten pro Sekunde gemessen und liegt in Benchmarks etwa Faktor 1.000 über der "durchschnittlichen" Oxid-SQL-Anfrage. Allerdings ist der Funktionsumfang stark eingeschränkt, zudem werden Daten stets nur im Arbeitsspeicher vorgehalten. Bei einem Neustart oder Absturz sind alle Daten weg. Das ist für einen Zwischenspeicher nicht tragisch, verhindert aber Synergien mit anderen Nutzungsszenarien.
  • Redis hat Ähnlichkeiten mit Memcached, teilt aber nicht dessen Nachteile. Sie können entscheiden, welche Informationen flüchtig sein sollen und welche nonvolatil auf die Festplatte gesichert werden. Zudem unterstützt es Transaktion und ist damit vollständig ACID. Die Abkürzung - Atomic, consistent, isolated, durable - beschreibt jene Kriterien, nach denen eine vollwertige Datenbank beurteilt wird. Mit Redis haben sie also einen Arbeitsspeicher-Cache, dass auf Wunsch zur vollwertigen Database wird. Somit können Sie mit einer Implementierung alle künftigen Entlastungen ihrer MySQL-Datenbank abdecken. PhpRedis und pRedis sind zwei kostenfreie Anbindungen. PhpRedis ist etwas schneller, muss aber im Server installiert werden. pRedis hingegen setzt rein auf php und ist damit fast überall lauffähig.

Konkrete Beispiele?

Cachen können Sie ohne Probleme alles, was veralten darf. Ein Beispiel sind Blogbeiträge oder Startseiten - Begrüßungstexte. Hier könne Sie die Daten einige Stunden vorhalten. Anders bei Artikelverfügbarkeiten. Ein ausverkaufter Artikel muss sofort auf Rot stehen.

Lohnende Beispiele sind also alle Inhalte, die aus der Datenbank kommen (d.h. im Backend gepflegt werden können), die sich selten ändern aber häufig abgerufen werden und die nicht allzu zeitkritisch sind:

  • Artikelbeschreibungen
  • Währungskurse (sofern nur täglich aktualisiert)
  • Hauptnavigation

"Große Shops gehören auf dedizierte Rootserver mit Redis und ausreichend RAM. "

Ok. Wie funktioniert nun das mit oxcontent?

Ein konkretes Beispiel wollen wir Ihnen noch zeigen: oxcontent. Es ist jene Smarty-Funktion, welche die im Backend unter "Kundeninformationen / CMS" gepflegten Textbausteine einblendet. Sie finden die Datei function.oxcontent.php im Smarty-Verzeichnis. Denken Sie aber daran, dass im /tmp - Verzeichnis ein Dateisystemgestützter Cache ist. Hier entlasten Sie also bei richtiger Einstellung zwar weniger die Datenbank, dafür aber die recht langsame Festplatte.

[{oxcontent ident=welcome}] etwa zeigt den Willkommenstext an. Oxcontent erstellt bei jedem Aufruf einen Content-Objekt, stellt eine Anfrage an die Datenbank, wartet auf die Antwort, und gibt den Text zurück. Auf unserer Startseite war das über 20-mal.

Die Lösung ist nun, direkt am Beginn der Funktion einzusteigen: Wir fragen mit HGET('oxcontent', 'welcome') bei Redis an, ob ein Text zu "welcome" bereitsteht. Wenn ja, geben wir es direkt zurück. Dabei sparen wir uns nicht nur die interne Erzeugung eines Objektes, sondern auch eine Menge Datenbank-Verkehr.

Falls welcome nicht bekannt ist, holen wir es wie gewohnt aus der Datenbank ab. Doch bevor wir es anzeigen, schicken wir es noch kurz mit HSET() an Redis. Beim nächsten mal steht es dann bereit. Praktisch: Wir können die Gültigkeitsdauer (expire oder ttl) eines solchen Wertes angeben. Stellen wir es z.b. auf 24h, wird garantiert einmal täglich aktualisiert, so dass immer Tagesaktuelle Willkommenstexte angezeigt werden.

Dabei sind 24h ein Extremfall. Selbst Einstellungen um die 5 Minuten bewirken Wunder: Schließlich wird ein Wert nur noch alle 300s abgefragt, statt mehrmals pro Sekunde. Damit haben Sie enorme Datenbank-Entlastungen bei minimaler Latenz.

Ein Ausblick auf die Möglichkeiten

Sie wollen es perfekt machen? Hier einige unserer Ansätze:

  • Stellen Sie die Speicherdauer auf mehrere Tage und passen Sie ihr System so an, dass es beim Speichern/Verändern eines Eintrages selbstständig den Cache aktualisiert. Stichwort dazu ist "cache poison".
  • Verwenden Sie mehrere Server, so dass jeder Zugriff auf den aktuell am wenigsten ausgelasteten "Node" geleitet wird. Stichwort dazu ist load balancing.
  • Passen Sie direkt die oxDb - Klasse an. Damit können Sie alle Änderungen erst einmal in Redis schreiben und in einer "ruhigen Minute" in die Datenbank übertragen. Die Pflege der Artikelbeschreibungen bietet sich dazu perfekt an.

Und wie fangen Sie an?

Code haben Sie auf der Seite wenig gesehen. Der Grund ist einfach: Mit copy&paste kommen Sie nicht weiter, dafür ist die Materie zu Komplex. Wenn Sie die Ideen nicht selber umsetzen können oder möchten: Fragen Sie uns.

Konkretes Beispiel ist Oxid, das Know-How passt aber auf alle ihre PHP-Projekte.

[Kontakt]
[Impressum]
[Tel 07641 962 8171]
Weiter zur IT-Haftpflicht Betriebshaftpflicht von Euroxid Systemberatung Zsolt Szilagyi, Emmendingen 

Den nächsten Schritt besprechen wir gemeinsam: +49 7641 962 8171, info@euroxid.de oder Kontakt