High Performance Magento in der Cloud
Kommentare

Magento-Caching

Auch Magento-seitig sind einige Optimierungen und Erweiterungen notwendig. Zunächst einmal muss ein geeignetes Cache-Konzept gefunden werden. Während jede Serverinstanz einen eigenen

Magento-Caching

Auch Magento-seitig sind einige Optimierungen und Erweiterungen notwendig. Zunächst einmal muss ein geeignetes Cache-Konzept gefunden werden. Während jede Serverinstanz einen eigenen lokalen Cache verwenden könnte, ist es einerseits sehr viel effizienter und andererseits für einige Features auch notwendig, dass alle beteiligen Knoten auf den gleichen Cache-Inhalt lesend und schreibend zugreifen können. Damit ist man in der Auswahl der Cache-Backends eingeschränkt. Ein Two-Level-Setup kann die Cache-Performance erhöhen, bringt aber auch einige Probleme und erhöhte Komplexität mit sich [4]. Eine sehr gute Übersicht über die verschiedenen Alternativen ist unter den Präsentationen der Magento Imagine 2012 zu finden [5].

Beim Angry-Birds-Shop haben wir uns für das Datenbank-Cache-Backend entschieden. Auch hier sind einige Bugfixes notwendig [6] und durch die Auslagerung der Datenbank-Handles auf eine eigene weitere RDS-Instanz werden die Datenbankzugriffe nicht zum Bottleneck.

Eine interessante Alternative ist das Redis Cache-Backend [7], das direkten Tag-Support hat und daher als einziger Cache eingesetzt werden kann. Während diese Lösung sehr schnell und elegant ist, erfordert sie jedoch in unserem redundanten Cloud-Setup ein weiteres Server-Array und erhöht damit die Komplexität des Setups.

Magento-Optimierungen

Magento kommt mit einer Vielzahl an Features. In den meisten Shops kommt allerdings nur ein kleiner Bruchteil davon tatsächlich zum Einsatz. Trotzdem fressen diese Features meistens einen erheblichen Teil der Performance. Daher ist es empfehlenswert den Shop genau unter die Lupe zu nehmen und nicht benötigte Features zu entfernen. Dabei sollten alle Seiten nach Blöcken und Event-Observern untersucht werden, die eventuell keinen sichtbaren Effekt haben, aber trotzdem vorhanden sind.

Einige Features sind fest im Magento-Core integriert und können nur durch Observer und Rewrites entfernt werden. Ein gutes Beispiel hierbei ist das Logging. Ein erheblicher Teil der Rendering-Zeit wird üblicherweise für das Loggen unterschiedlichster Informationen verwendet. Das belastet nicht nur die Performance, sondern führt auch dazu, dass diverse Datenbanktabellen und Log-Dateien sehr schnell riesig werden können. Gerade wenn diese Informationen nicht für Reports oder andere Auswertungen benötigt werden, sollte darauf verzichtet werden.

Durch die sorgfältige Analyse und wiederholtes Profiling mit unterschiedlichen Tools (xdebug, New Relic, Aoe_Profiler [8]) kann Magento sehr viel leichtgewichtiger und auf die funktionalen Anforderungen des Shops zugeschnitten werden.

Betreibt man Magento unter Hochlast wird man schnell feststellen, dass sich große Datenmengen ansammeln. Einige Daten werden gar nicht benötigt (wie zuvor am Beispiel der Logs erwähnt), andere müssen regelmäßig aufgeräumt werden. So müssen beispielsweise abgelaufene Cache-Einträge [9] sowie nicht mehr benötigte Quotes [10] gelöscht werden. Auf Bewegungsdaten (wie zum Beispiel die „recently viewed products“) kann auch komplett verzichtet werden, wenn die entsprechenden Features nicht verwendet werden.

Bei vielen Backend-Operationen und anderen Requests wird der Cache automatisch aktualisiert. Je nach Füllgrad des Caches und verwendetem Cache-Backend können diese Operationen durchaus mehrere Sekunden dauern, was das Arbeiten im Backend nicht besonders angenehm gestaltet. Ist man nicht auf sekundengenaue Cache-Invalidierung angewiesen, kann das Modul Aoe_AsyncCache [11] eingesetzt werden, das alle Cache-Operation abfängt und asynchron im Hintergrund als Crontask verarbeitet. Das Arbeiten im Backend wird dadurch spürbar schneller. Einen visuellen Überblick und volle Kontrolle über alle Crontasks gibt das Modul Aoe_Scheduler [12].

Qualitätskontrolle

Will man den Anforderungen gerecht werden, muss schon in der Entwicklungsphase darauf geachtet werden, dass jede Zeile Code für das angestrebte Szenario geeignet ist. Dies gilt ganz besonders beim Einsatz von Third-Party-Modulen. Diese sind oft nicht mit den hohen Anforderungen an Geschwindigkeit, Masse und Parallelität im Hinterkopf entwickelt worden. Während diese Module auf einem einzelnen Server mit überschaubarem Traffic ohne Probleme laufen, besteht ein hohes Risiko, dass unter einem Hochlastszenario auf verteilten Servern nicht mehr alles glatt läuft. Fremde Module müssen daher sorgfältig ausgewählt und unter die Lupe genommen werden. Auf verschlüsselte Module sollte grundsätzlich verzichtet werden. Aber auch der Einsatz externer Systeme muss gut durchdacht werden. Sind diese nicht auf die gleiche Geschwindigkeit und Verfügbarkeit ausgerichtet, können sie den eigenen Shop ausbremsen oder wesentlich Bestandteile wie zum Beispiel den Checkout-Prozess außer Kraft setzen. Idealerweise werden externe System asynchron im Hintergrund angesprochen, sodass die Kommunikation mit diesen Systemen keinen negativen Einfluss auf die Besucher hat.

Jede Komponente muss kontinuierlich auf Last geprüft werden. Aussagekräftige Lasttests, die reales Besucherverhalten simulieren, sind hier nicht optional und müssen den Entwicklungsprozess von Anfang an begleiten. Idealerweise sind Lasttests mit vergleichbaren Ergebnissen Bestandteil einer Deployment Pipeline.

Continuous Integration und die Deployment Pipeline

Eine Deployment Pipeline ist von Anfang an wichtig. Im laufenden Betrieb kann es zu unvorhergesehenen, kritischen Regressionen kommen. Umso wichtiger ist es, dass man schnell ein Paket bereitstellen kann, dass den allgemeinen Qualitätsanforderungen gerecht wird.

Jenkins ist ein großartiges Tool, um eine Deployment Pipeline zu implementieren. Zunächst erfolgt der eigentliche Build-Prozess, der neben dem Code selbst alle anderen notwendigen Komponenten, wie zum Beispiel umgebungsspezifische Settings, Datenbankinhalte und Media-Dateien, die notwendig sind, um eine komplette Serverinstanz vollautomatisch zu bauen, in einem Paket vereint. Danach finden mehrere Build-Schritte statt, die helfen zu beurteilen, ob das aktuelle Paket den nötigen Anforderungen entspricht, um auf die Produktivumgebung deployt zu werden (Abb. 5). Dazu gehören automatisierte Unit Tests mit PHPUnit, Frontend-Tests mit Selenium2 und Lasttests mit JMeter. Ist das Paket durch all diese Schritte erfolgreich durchgekommen, wird es zunächst auf einem internen Abnahmesystem installiert. Das Paket wird dann in einen S3-Bucket kopiert und kann von dort aus im Rahmen eines neuen Deployments automatisch auf neue Serverinstanzen installiert werden. Das Staging-System ist identisch mit der Produktivumgebung. Dort kann dann noch eine manuelle Abnahme des neuen Pakets durch die interne QA und die des Shop-Betreibers stattfinden. Hat das Paket alle Qualitätsansprüche erfüllt, kann es auf das Produktivsystem deployt werden.

Abb. 5: Qualifizierung für ein Production Deployment
Lessons learned

In jedem Projekt kann es zu unvorhergesehenen Problemen kommen. Besonders wenn mit einem komplexen Hosting-Setup und zahlreichen Services die Gesamtkomplexität steigt, ist es wichtig, immer den Überblick behalten und schnell reagieren zu können. Erprobte Deployment-Prozesse und eine umfangreiche Qualitätsprüfung sind daher nicht optional. Und dennoch kommt es zu Situation, die vorher nie da gewesen sind. Gelernt haben wir unter anderem, wie teuer 404-Seiten wirklich sein können. Wird zum Beispiel ein beliebtes Produkt, dessen Produktseite bisher immer von Varnish ausgeliefert worden ist, kurzfristig deaktiviert, treffen alle Requests auf Magento ein. Das automatische Hochskalieren führt dazu, dass in wenigen Minuten zahlreiche Server gebootet werden, um die neue Last abzufangen. 404-Seiten müssen also unbedingt auch gecacht werden – wenn auch nur für wenige Minuten.

Aber auch ganz reguläre Magento-Standard-Features können große Probleme bereiten. Versucht man einen Magento-Report im Backend aufzurufen, wird man die Datenbank extrem beanspruchen, was deutlich im Frontend zu spüren ist. Im Extremfall können in dem Zeitraum keine dynamische Requests bedient werden. Amazons RDS bietet die Möglichkeit, Read-Replica der Datenbank zu erstellen. Auf diesen Read-only-Kopien können dann die Reporting-Skripte ausgeführt werden.

Andere Magento-Features sind nicht auf riesige Produktkataloge oder eine große Anzahl an Orders oder Quotes ausgerichtet und verhindern zum Beispiel das Speichern von Produkten.

Und schließlich gibt es dann noch vermeintliche Selbstverständlichkeiten, wie zum Beispiel die Gzip-Komprimierung von JavaScript- und CSS-Dateien bei Cloudfront-Domains, die ihre Dateien von S3-Buckets beziehen. Spontan müssen hier andere Konzepte gefunden werden, um diese Dateien dennoch komprimiert ausliefern zu können [13].

In jedem Fall muss etwas mehr Zeit eingeplant werden, um Probleme dieser Art zu umgehen. Ein tiefgründiges Verständnis der Funktionsweisen von Magento, Varnish und den Amazon-Services ist hier zwingend erforderlich, um einen Shop erfolgreich implementieren und betreiben zu können.

Fazit

Magento ist ein sehr mächtiges und umfangreiches E-Commerce-Framework. Wenn es um Hochlastsysteme geht, kocht es aber auch nur mit Wasser, und es bedarf entsprechender, durchdachter Architekturkonzepte und Best Practices, um das Maximum an Leistung herauszuholen. Viele Bausteine der oben genannten Lösung stehen kostenfrei auf GitHub [13] zur Verfügung. Unter http://www.fabrizio-branca.de sind außerdem noch zahlreiche Blogposts zu finden, die einzelne verwandte Themen (darunter Varnish mit Magento) genauer betrachten. Und wer professionelle Hilfe braucht, um seinen Shop für den nächsten großen Ansturm oder das natürliche Wachstum fit zu machen oder von Grund auf plant eine große Shoplösung zu bauen, sollte mit unseren Magento- und Deployment-Experten [14a][14b] sprechen.

Fabrizio Branca (Twitter: @fbrnc) ist Lead System Developer bei AOE media. Vor Kurzem ist er mit seiner Familie nach San Francisco gezogen, um dort das amerikanische AOE-Team zu unterstützen. Fabrizio bloggt unter http://www.fabrizio-branca.de über Themen rund um Magento, TYPO3, Varnish und Performance.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -