Redis Teil 1: Performance Optimierung für Shopware und Magento

Über diese Redis-Blogserie

maxcluster konnte in der täglichen Arbeit mit Onlineshops immer wieder feststellen, dass Redis die Performance der Shops deutlich verbesserte. Unseren Kunden haben wir die Nutzung des bei uns vorkonfigurierten Tools aus diesem Grund immer wieder empfohlen. Doch belegen konnten wir unsere Erfahrung nur mit den von Collin Mollenhour durchgeführten Benchmarks von 2012. Deshalb haben wir uns dazu entschlossen, eigene Benchmarks durchzuführen, um die Nützlichkeit von Redis neu zu bewerten. Diese Redis-Blogserie teilt sich in insgesamt 5 Beiträge auf. In diesem ersten Beitrag geben wir eine Einführung in das Thema Redis, schildern unsere Ergebnisse der Benchmarks, geben Tipps zur Konfiguration von Redis und sprechen am Ende eine Empfehlung aus.

Teil 2 und Teil 3 thematisieren die Benchmarks. Wir haben insgesamt zwei Benchmarks durchgeführt: für Sessions und für den Anwendungscache. Im vierten Teil dieser Serie beschreiben wir die Integration von Redis in Shopware. Im letzten und fünften Teil der Redis-Blogserie erklären wir die Integration von Redis in Magento.

Was ist Redis?

Redis ist eine in C implementierte In-Memory-Datenbank. Sie gehört zur Gruppe der NoSQL-Datenbanken und bietet einen einfachen Key Value Store.

Die Redis-Datenbank ist in einem Open Source-Projekt 2010 entstanden und wurde von Salvatore Sanfilippo entwickelt. Mit dieser In-Memory-Datenbank können Strings, Mengen, Listen und Hashes im Hauptspeicher gespeichert werden. Sie lässt sich durch Virtual Memory erweitern, wodurch bestimmte Datensätze ausgelagert werden können.

Sessions - Bringt Redis Performance Vorteile für Onlineshops?

Warum ist es ein Problem für Onlineshops, Sessions in der Datenbank oder im Dateisystem zu speichern?

Jeder Besucher erzeugt eine sogenannte Session, wenn er einen Onlineshop besucht. Darin werden benutzerdefinierte Daten gespeichert, wie zum Beispiel der Warenkorb eines Kunden. Shopware speichert diese Sessions standardmäßig in der Datenbank, Magento im Dateisystem.

Gewöhnlich wird jede Session in eine einzelne Datei abgelegt. Bei vielen Besuchern führt dies sehr schnell zu einer großen Menge an Dateien. Je höher diese Menge ist, umso mehr verlangsamt sich das Lesen dieser Dateien und die Ladezeiten erhöhen sich. Für den Kunden bedeutet dies, dass der Checkout sehr langsam wird – meistens unbemerkt!

Ein weiteres Problem liegt darin, dass der benötigte Speicherplatz nicht vorhersehbar ist, da die Anzahl der Besucher stark schwanken kann. Auch lassen sich die Sessions in einzelnen Dateien nicht effizient in einem Backup sichern. Hier bringt Redis wesentliche Vorteile mit. Die Sessions lassen sich in Redis ablegen und werden dabei im Arbeitsspeicher verwaltet.

Vorteile für Onlineshops mit einem Webserver

In regelmäßigen Abständen werden die Sessions in einer einzigen großen Datei auf der Festplatte gespeichert und mit einem Backup gesichert. Durch die Verwaltung im Arbeitsspeicher lassen sich die Sessions performant lesen und schreiben. Dies bietet Vorteile sowohl für mittelgroße Shops mit einem Webserver als auch für sehr große Onlineshops mit mehreren Servern.

Bei Shopware sind die Auswirkungen hierbei am deutlichsten zu sehen, da Shopware Sessions in der Standardeinstellung in der MySQL Datenbank speichert. Das führt zu einer deutlich verschlechterten Performance im Vergleich zu Redis. Zusätzlich kommt es unserer Erfahrung nach oft zu Lockings auf die MySQL Tabelle. Für Shopware können wir Redis daher uneingeschränkt für alle Shop-Größen empfehlen.

Vorteile für Onlineshops mit mehreren Webservern

Gewöhnlich wird vor die Webserver ein Loadbalancer platziert, welcher die Anfragen auf die Webserver verteilt. (Mehr zum Thema Loadbalancer erfahren Sie im Videovortrag von maxcluster auf YouTube.) Während es bei einzelnen Webservern noch einfach möglich ist, Sessions lokal abzulegen, führt dies, wenn mehrere Webnodes im Einsatz sind, zu Problemen. Die Webserver würden in dem Fall unterschiedliche Dateien bzw. Sessions sehen und schreiben. Dafür gibt es verschiedene Lösungen.

Entweder verwendet ein Onlineshop ein verteiltes Dateisystem, in welchem die Sessions abgelegt werden - was allerdings den Nachteil der schlechten Performance mit sich bringt. Die Ursache ist, dass die Sessions hier auf Dateisystemebene synchronisiert werden müssen, wodurch ein zusätzlicher Zeitverlust entsteht. Oder der Loadbalancer ordnet die Besucher fest auf einen bestimmten Webserver zu, wodurch die Konfiguration durch erhöhte Komplexität des Setups erschwert wird. Mit Redis kann der Loadbalancer die Anfragen beliebig auf die Webserver verteilen. Dies ist einfacher einzurichten, weniger fehleranfällig und leichter zu erweitern, da alle Webserver auf dieselbe Redis-Instanz zugreifen. Auch für die Anwendungscaches gilt dieser Vorteil.

Vorteile bei einer hohen Anzahl von Sessions

Wenn die Sessions nicht bereinigt werden, sammelt sich im Laufe der Zeit eine hohe Anzahl innerhalb eines Shops an. Problematisch ist eine hohe Anzahl an Sessions, da hierdurch der Backup-Vorgang gestört wird und die Performance verringert wird. Denn die Ladezeit einer Datei steigt mit der Anzahl der vorhandenen Dateien. So konnten wir messen, dass es selbst bei einem Shop ohne Traffic, 48 Millisekunden länger dauert, ein Produkt in den Warenkorb zu legen, wenn 5.000.000 Sessions vorhanden sind. Bei einem frequentiert besuchten Shop sind die Auswirkungen noch wesentlich stärker. Mit Redis hingegen besteht dieses Problem nicht. Zum einen bleibt die Ladezeit bei Redis aufgrund der internen Datenstruktur konstant, zum anderen löscht Redis selbstständig Sessions, sobald diese abgelaufen sind.

Redis im Vergleich zu NVMe SSDs und MySQL

Wir haben die Auswirkungen von Redis auf Sessions getestet. Die technischen Informationen zu unseren Benchmarks stellen wir in einem weiteren Blogbeitrag vor: Redis Teil 3 - Sessions Benchmark - NVMe SSDs, Redis und MySQL.

Was bedeutet der Test für Shopware und Magento?

Durch unseren Benchmark haben wir festgestellt, dass es für Shopware Onlineshops vorteilhaft ist, die Sessions in Redis zu legen.

Bei Magento (1 & 2) lohnt sich die Nutzung von Redis für das Ablegen der Sessions ebenfalls, sofern mehrere Besucher parallel auf den Shop zugreifen. Die Ergebnisse unseres Benchmarks im Bereich Multi Threaded zeigten, dass Redis für schreibende, lesende und ändernde Operationen höhere Leistung pro Sekunde bietet als NVMe SSDs und MySQL.

Lesen Sie alle technischen Details zu den Session Benchmarks: Redis Teil 3 - Sessions Benchmark - NVMe SSDs, Redis und MySQL.

Anwendungscache - Bringt Redis Performance Vorteile für Onlineshops?

Neben den Sessions lassen sich zudem Anwendungscaches in Redis ablegen und über mehrere Webnodes verteilen. Je nach Anwendung bringt dies eine Verbesserung der Performance im Vergleich zum Dateisystem. Der Vorteil zeigt sich allerdings nicht so deutlich wie bei den Sessions.

Neben dem Cachen von Konfigurationsdaten lassen sich auch komplette Webseiten über einen sogenannten Full Page Cache in Redis speichern. Dies hat allerdings den Nachteil, dass weiterhin eine PHP-Anwendung instanziiert werden muss, um diesen Pagecache auszulesen. Wir empfehlen daher, stattdessen Pagecaches in Varnish abzulegen.

Auch für Anwendungscaches haben wir unsere Erfahrungen mit einem Benchmark validiert: Redis Teil 2 - Anwendungscache Benchmark: Redis, NVMe SSDs und memcached.

Mit diesem Benchmark wollten wir herausstellen, welches Backend für den Anwendungscache performanter ist: Redis, Dateisystem mit NVMe SSDs (wie auf unseren Clustern im Einsatz) oder memcached. Dafür haben wir die Anzahl an Lösch-, Lese- und Schreib-Operationen pro Sekunde gemessen.

Das unten stehende Diagramm zeigt die Schreibrate der Cache Backends: Zend_Cache_Backend_File (Dateisystem), Cm_Cache_Backend_Redis, memcached (Zend_Cache_Backend_TwoLevels) + Zend_Cache_Backend_File und memcached (Zend_Cache_Backend_TwoLevels) + Cm_Cache_Backend_Redis.

Wir konnten das Ergebnis festhalten, dass auf unseren NVMe SSDs der Durchsatz der Lese-Operationen zwar höher war, die Anzahl an Schreib-Operationen pro Sekunde allerdings bei Redis besser war. Zudem war bei Redis die Anzahl an Lösch-Operationen pro Sekunde wesentlich höher. Dies ist besonders für stark besuchte Shops relevant, da auch Einkäufe gewöhnlich zu partiellen Cache-Invalidierungen führen, sodass wir auch hier für gut besuchte Shops die Verwendung von Redis empfehlen.

Was zeichnet Redis im Vergleich zu anderen Datenbanken aus?

Durch die einfache Datenspeicherung ist Redis ein extrem effizienter Key Value Store. Es bietet dadurch die notwendige Performance, Skalierbarkeit und Stabilität, die notwendig sind, um große Onlineshops zu betreiben. Ein weiterer Vorteil gegenüber anderen Datenbanken ist die native Unterstützung vieler Webanwendungen wie Shopware und Magento 2.

Redis konfigurieren

Um Redis optimal zu verwenden, empfehlen wir, für jede Anbindung (z.B. Cache oder Sessions) eine eigene Redis-Instanz zu verwenden. Dies erlaubt es, die einzelnen Instanzen individuell zu konfigurieren. Diese Aufteilung ermöglicht eine höhere Performance, da Redis die meisten Operationen in einem einzigen Thread ausführt.

Persistenz

Redis speichert die Daten standardmäßig im Arbeitsspeicher. Bei einem Neustart der Redis-Instanz wird dieser Arbeitsspeicher geleert. Um dies zu verhindern, bietet Redis zwei mögliche Optionen zur Persistenz an. Zum einen kann in gewissen Zeitabständen ein Snapshot (RDB) des aktuellen Zustandes erstellt werden, welcher beim Neustart eingelesen werden kann. Dadurch würden bei einem ungeplanten Neustart nur sehr wenige Daten verloren gehen. Zum anderen steht die AOF-Methode (append-only file) zur Verfügung, welche die Daten dauerhaft in ein Journal schreibt, um Datenverlust komplett zu vermeiden. Der Nachteil von AOF besteht in einer leicht erhöhten Latenz.

Für Magento- und Shopware-Caches empfehlen wir die Persistenz komplett zu deaktivieren, da sich die Caches leicht neu aufbauen können. Insofern ist die Datenspeicherung nicht so effizient, als dass Onlineshops dafür den Performance Nachteil auf sich nehmen sollten.

Für Sessions empfehlen wir die Snapshot-basierte Sicherungsmethode RDB. So kann im Fall eines Ausfalls der Instanz oder sogar des Servers ein Großteil der Sessions erhalten bleiben. Dies bietet unserer Erfahrung nach die beste Kombination aus Performance und Stabilität.

Master-Replica

Mit einem Master-Replica-Setup ist es möglich, die Lesezugriffe auf mehrere Nodes zu verteilen oder anderen Anwendungen zur Verfügung zu stellen. Unserer Erfahrung nach ist dies gewöhnlich für kleine und mittlere Magentoshops nicht notwendig.

Verdrängungsstrategie

Über die maxmemory-Einstellung ist es möglich den Speicher von Redis zu begrenzen. Dies ist eine Maßnahme, um zu verhindern, dass eine plötzlich stark ansteigende Redis Instanz die Ressoucen des Servers belegt und die Stabilität gefährdet. Dabei stehen verschiedene Strategien zur Verfügung, wie Redis damit umgehen soll, wenn der Speicherplatz voll belegt ist. Ziel dieser Strategien ist es, wieder freien Speicher zu schaffen. Die einzelnen Schlüssel stellen hier jeweils Datensätze dar, welche eine Session bzw. ein zu cachendes Element beinhalten. Die Strategie lässt sich über die maxmemory-policy einstellen:

noeviction: Sobald der Speicher voll ist, führt das Speichern von weiteren Daten zu einer Fehlermeldung.

allkeys-lru: Es werden mehrere Schlüssel zufällig ausgewählt. Von diesen wird der Schlüssel gelöscht, welcher am längsten nicht verwendet wurde.

volatile-lru: Es werden mehrere als flüchtig markierte Schlüssel zufällig ausgewählt. Von diesen wird der Schlüssel gelöscht, welcher am längsten nicht verwendet wurde.

allkeys-random: Ein zufälliger Schlüssel wird entfernt.

volatile-random: Ein zufälliger als flüchtig markierter Schlüssel wird entfernt

volatile-ttl: Es werden mehrere als flüchtig markierte Schlüssel zufällig ausgewählt. Von diesen wird der Schlüssel gelöscht, welcher die niedrigste TTL (Time to live) hat.

allkeys-lfu (ab Redis 4): Es werden mehrere Schlüssel zufällig ausgewählt. Von diesen wird der Schlüssel gelöscht, welcher am wenigsten verwendet wurde.

volatile-lfu (ab Redis 4): Es werden mehrere als flüchtig markiere Schlüssel zufällig ausgewählt. Von diesen wird der Schlüssel gelöscht, welcher am wenigsten verwendet wurde.

Für Sessions empfehlen wir die Strategie volatile-lru. Dadurch wird sichergestellt, dass nur die Schlüssel entfernt werden, welche sowieso zu einem späteren Zeitpunkt aufgrund des Ablaufens der TTL (Time to live) gelöscht werden würden.

Für die Anwendungscaches empfehlen wir außerdem die Belegung von Redis zu überwachen, um reagieren zu können, bevor der Speicher einer Cache-Instanz voll belegt ist. Wir überwachen die Belegung und greifen im Notfall ein oder informieren den Kunden.

Für die Cache Instanz empfehlen wir zwar ebenfalls die Strategie volatile-lru, dies ist allerdings nur eine Maßnahme, um schnelle Peaks abzufangen. Durch unser Monitoring stellen wir sicher, dass wir informiert werden bevor die Instanz das Maximum erreicht und so rechtzeitig eingreifen können.

Durch die volatile-lru Policy stellen wir sicher, dass in dem Fall, sollte die Instanz voll belegt sein, nur Schlüssel entfernt werden, welche auch entfernt werden dürfen, der Shop allerdings weiterhin erreichbar ist. Eine allkeys-lru Policy entfernt hingegen beliebige Schlüssel und kann damit die Stabilität und Datenkonsistenz des Shops potenziell beeinträchtigen. Wir raten ebenfalls stark davon ab, die Instanz dauerhaft am Limit zu belassen, da hierdurch die Performance Vorteile von Redis wieder aufgehoben werden.

Redis und Magento 1

Redis ist in Magento 1 nicht per default integriert. Mit dem Plugin von Colin Mollenhour gibt es eine einfache und kostenfreie Möglichkeit Sessions in Redis abzulegen. Die Magento-Versionen ab Open Source 1.8.0 bzw. Commerce 1.13.0 beinhalten dieses Plugin standardmäßig. Wir empfehlen hier allerdings, die neuste Version des Plugins von Github zu verwenden.

Für Caches kann auf GitHub das Plugin Cm_Cache_Backend_Redis, ebenfalls von Collin Mollenhour, heruntergeladen und installiert werden.

Redis und Magento 2

Im Gegensatz zu Magento 1 liefert Magento 2 bereits eine vollständige Integration in allen Editionen mit. Diese lässt sich einfach über die env.php konfigurieren.

Magento hat hier eine ausführliche Anleitung veröffentlicht, welche die genaue Konfiguration für Sessions erklärt.

Auch der Magento-Cache und ein Full Page Cache lassen sich in allen Magento-Editionen in Redis ablegen. Details hierzu erklären wir im weiteren Teil dieser Blogserie.

Unserer Erfahrung nach ist es sinnvoll, den Magento-Cache in Redis abzulegen, aber nicht den Full Page Cache. Als Full Page Cache empfehlen wir für Magento Varnish. Ausführliche Informationen, wie Sie Varnish für Magento 2 konfigurieren und nutzen können, erfahren Sie in den Magento-DevDocs: Configure and use Varnish.

Redis und Shopware

Ebenso wie bei Magento 2 wird Redis von Shopware unterstützt. Bei Shopware können der Anwendungscache, ein zusätzlicher Model-Cache und die Sessions in Redis abgelegt werden.

Im Gegensatz zu Magento speichert Shopware die Sessions standardmäßig in der MySQL-Datenbank anstatt im Dateisystem. Dies ist wesentlich in-performanter, sodass wir für eine Shopware-Installation den Einsatz von Redis dringend empfehlen.

Die Konfiguration erfolgt bei Shopware 5 bequem über die config.php im Shopware-Ordner oder für Composer-Installationen unter app/config/config.php. Details dazu werden im Teil 3 dieser Blogserie erklärt.

Redis und andere PHP-Anwendungen

Eine Vielzahl an Anwendungen unterstützt Redis bereits "out of the box".

Es ist über die php.ini weiterhin möglich, Sessions direkt auf PHP-Ebene in Redis umzuleiten. Hierzu lässt sich folgender Code in die php.ini eingetragen. Auf unseren Clustern setzen wir dies bei Bedarf gerne für Sie um.

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=password"

Auch eigene Daten können dank der einfachen Redis-API leicht in Redis abgelegt werden. Für PHP (und andere Programmiersprachen) stehen zahlreiche Bibliotheken zum Ansteuern von Redis zur Verfügung.

Redis bei maxcluster

Über unser Interface lassen sich bequem und ohne Zusatzkosten Redis-Instanzen anlegen und verwalten. Für Caches und Sessions bieten wir außerdem Templates an, um die Redis-Instanzen optimal zu konfigurieren. Bei Verwendung des Cache-Templates überwacht unser Team die Speicherplatzbelegung der Instanz und greift ein, wenn zu wenig Speicherplatz verfügbar ist.

Bei Bedarf unterstützen wir Sie auch bei der Integration von Redis in Ihren eigenen Onlineshop. Kontaktieren Sie hierzu bitte unser Support-Team.

Sollten Sie Fragen zu Redis haben, freuen wir uns auf Ihre Nachricht via E-Mail an support@maxcluster.de oder telefonisch unter 05251/414130.

Fazit

Redis ist ein nützliches Tool, um Sessions zu speichern. Für diesen Zweck empfehlen wir die NoSQL-Datenbank uneingeschränkt. Bei Shopware wird durch den Einsatz von Redis die Datenbank entlastet, was zu schnelleren Ladezeiten im Checkout führt und damit die Gefahr vor Kaufabbrüchen durch langsame Ladezeiten eingegrenzt wird. Auch für Magento bringt Redis eine Entlastung, da die Sessions und der Cache hier besser mit steigenden Benutzerzahlen skalieren.

In Bezug auf Caches hängt die Effizienz von Redis stark von der individuellen Shopanwendung und -konfiguration ab. Grundsätzlich lässt sich die Nutzung der In-Memory-Datenbank allerdings bei einem Einsatz von mehr als einem Webserver empfehlen. Gerne beraten wir Sie, ob für Ihren individuellen Shop der Einsatz von Redis effizient ist und Ihnen Performance-Vorteile bringt.

Weitere Beiträge dieser Blogserie

• Redis Teil 2 - Anwendungscache Benchmark: Redis, NVMe SSDs und memcached
• Redis Teil 3 - Sessions Benchmark - NVMe SSDs, Redis und MySQL
• Redis Teil 4 - Wie wird Redis in Shopware integriert?
• Redis Teil 5 - Wie wird Redis in Magento integriert?

Titelbild: marchmeena29/iStock.com

Zuletzt aktualisiert am 09.06.2021 | MM