Vorheriger Artikel Nächster Artikel

Magento: Aus dem Shopsystem mehr Performance rausholen

Aus dem
t3n Magazin Nr. 24

06/2011 - 08/2011

Wer einen plant, kommt an kaum vorbei. Das Open-Source-System punktet vor allem mit Flexibilität. Doch die geht zu Lasten der Leistung. Vermeintlich, denn auch aus Magento lässt sich jede Menge Performance herausholen.

Bequem vom eigenen Sofa aus zu bestellen, scheint Volkssport geworden zu sein. Doch ob Besucher eines Onlineshops verweilen und schließlich einkaufen oder direkt wieder in den Weiten des Webs verschwinden, hängt von vielen Faktoren ab: Finden sie auf Anhieb, was sie gesucht haben? Erscheint der Shop vertrauenswürdig? Passen Preise für Produkte und Versand?

Hinzu kommt die Reaktionszeit der Seite, die einen großen Anteil am „Wohlfühlfaktor“ des Besuchers hat. Wenn der Nutzer den Eindruck hat, dass die Seite nur behäbig auf die Eingaben reagiert, macht das Surfen durch die Produkte des Shops nur wenig Spaß und der Einkauf wird bei Mitbewerbern fortgesetzt. Google wird deshalb in Zukunft die Ladegeschwindigkeit einer Seite stärker in seine Beurteilung innerhalb der Suche einbeziehen – ein weiterer Grund, ein Auge auf die Performance zu werfen.

Flexibilität als Fluch und Segen

Flexibilität galt bei Magento von Beginn an als Maxime. Über Module und Templates lässt sich das System sowohl funktional als auch optisch an fast alle Anforderungen und Ansprüche der Shopbetreiber anpassen. Nicht zuletzt dieser Flexibilität ist die hohe Beliebtheit Magentos zu verdanken.

Gleichzeitig erweist sich diese Flexibilität aber als größter Feind der Performance. Statt Prozesse, Daten und Layouts strikt festzulegen, bleibt dem Betreiber immer die Möglichkeit, Dinge anzupassen und zu erweitern. Dass das System hierdurch komplexere Routinen durchlaufen muss, ist die logische Konsequenz.

Bestes Beispiel hierfür ist das Entity-Attribute-Value-Pattern (EAV), das Magentos Datenmodelle hochgradig flexibel macht. Über das Backend können Betreiber Produkte frei mit beliebigen Attributen verschiedener Typen ausstatten. Die Besucher können dann Produkte anhand dieser Attribute vergleichen, filtern oder suchen.

Andererseits ist EAV sehr performancelastig. Im Gegensatz zu herkömmlichen Datenbankmodellen, bei denen die Eigenschaften eines Objekts in einzelnen Spalten einer flachen Tabelle gespeichert werden, teilt EAV die Daten in mehrere Tabellen auf: Entitätstypen wie Produkte, Kategorien oder Kunden werden zentral in der Tabelle eav_entity_type definiert. Attribute zu Produkten werden in eav_attribute spezifiziert und den jeweiligen Entitätstypen zugeordnet. Optionen für Auswahl-Attribute werden in eav_attribute_option, deren Labels in eav_attribute_option_value gespeichert. Die eigentlichen Daten der Produkte, Kategorien und sonstigen EAV-Objekte liegen aber in den Wertetabellen. Hierbei handelt es sich um eine Kopftabelle (beispielsweise catalog_product_entity) und bis zu neun datentypspezifische Tabellen für Integer, Texte, Datumswerte und andere.

dms f1fb7c0bef45383cd00ab2914cc210fb
Ganze fünf Tabellen sind nötig, um das Entity-Attribute-Pattern abzubilden; die Werte selbst, die das EAV komplettieren, fehlen in der Abbildung aus Platzgründen.

Um nun ein Produkt vollständig aus der Datenbank zu lesen, muss zunächst bestimmt werden, welche Attribute diesem Produkt zugeordnet sind, um anschließend die jeweiligen Werte auslesen zu können. Hierfür sind mehrere Datenbankzugriffe über mehrere Tabellen notwendig, was mehr Zeit und Ressourcen in Anspruch nimmt als der Zugriff auf eine einzelne Tabelle.

Ein weiteres Beispiel sind die Module: Über XML-Konfigurationen lässt sich das Verhalten anderer Module anpassen, indem beispielsweise Klassen dynamisch ausgetauscht werden. Hierdurch wird der Instanzierungsprozess von Klassen jedoch deutlich gebremst. Noch verstärkt wird dieser Effekt durch die vier Codepools „lib“, „core“, „community“ und „local“, durch die die Ordnung und Update-Fähigkeit des Systems gewahrt bleiben soll. Wird eine bestimmte Klasse gesucht, probiert das System die vier Ordner rückwärts durch. Dadurch wird das Laden der Klassen in Magento paradoxerweise schneller, je mehr Klassen in „local“ oder „community“ überschrieben werden.

Caching, Caching, Caching

Um Flexibilität und Performance unter einen Hut zu bringen, beinhaltet Magento diverse Caching-Mechanismen. Hierbei wird ausgenutzt, dass die meisten Konfigurationseinstellungen zu Beginn eines Projekts stark variieren, zur eigentlichen Produktivphase jedoch überwiegend gleich bleiben.

Eine Übersicht über die Zustände der Caches findet man im Backend bei System, Cache Management. Während es für die Entwicklungsumgebung durchaus sinnvoll sein kann, die Caches zu deaktivieren, ist dies in der Produktivumgebung keine Option. Innerhalb des Caching-Moduls finden sich folgende Optionen:

  • Konfiguration: Beinhaltet die Grundkonfiguration des Systems sowie die Konfiguration aller aktiven Module.
  • Layouts: Definition der Ausgabeblöcke sowie deren Positionen.
  • Block HTML-Ausgabe: Speichert die HTML-Ausgaben von Blöcken, wenn diese für Caching konfiguriert wurden.
  • Übersetzungen: Dieser Cache speichert die verschiedenen Übersetzungen zentral ab.
  • Kollektionsdaten: Bestimmte Listen werden in Magento immer wieder aufgerufen. Werden diese zwischengespeichert, kann wertvolle Zeit gespart werden.
  • EAV-Typen und -Attribute: Konfiguration der verschiedenen EAV-Elemente, sodass diese nicht permanent aus der Datenbank gelesen werden müssen.
  • Konfiguration der Webdienste: Vorrangig für die SOAP-API interessant; speichert öffentliche Methoden und Zugriffsrechte.

Obschon überall zu Caching geraten wird, finden sich in der Praxis noch zu viele Magento-Shops mit (partiell) deaktiviertem Cache. Das ist zum Teil einer fehlenden Unterstützung durch Templates oder Erweiterungen von Drittanbietern geschuldet: Haben die Entwickler Caching bei der Programmierung nicht vorgesehen, beeinträchtigt dies unter Umständen die komplette Installation.

Cache-Keys

Ob Magento einen Block live generieren muss oder eine valide Version aus dem Cache beziehen kann, wird anhand so genannter Cache-Keys entschieden. Diese geben den aktuellen Zustand der Ausgabe wieder und werden vor der Ausgabe eines Blocks generiert.

Wird der aktuelle Zustand in einem gültigen Eintrag im Speicher gefunden, kann der dort hinterlegte Inhalt direkt ausgegeben werden, ohne weitere Programmlogik ausführen zu müssen. Wird der Block nicht im Speicher gefunden, erzeugt Magento die Blockausgabe und legt diese für die definierte Cache-Lebenszeit statisch ab. Ohne Cache-Informationen im Block kann das System die Blockausgaben nicht zwischenspeichern und erzeugt die Ausgaben bei jedem Zugriff dynamisch.

Die Definition der Cache-Angaben erfolgt in der Regel im Magento-eigenen Platzhalterkonstruktor des Blocks (Template Method Pattern).

Definition der Cache-Header im Block

class T3n_Example_Block_Example extends Mage_Core_Block_Template
{
	protected function _construct()
	{
		$this->addData(array(
			'cache_lifetime'	=> 86400,
			'cache_tags'	=> array(Mage_Catalog_Model_Product::CACHE_TAG)
		));
	}

	public function getCacheKeyInfo() {
		return array(
			'T3N_EXAMPLE',
			(int)Mage::app()->getStore()->isCurrentlySecure(),
			Mage::getDesign()->getPackageName(),
			Mage::getDesign()->getTheme('template')
		);
	}

}

Listing 1

Der angegebene Wert in der Cache-Lifetime definiert den Zeitraum in Sekunden, für den der Cache gültig sein soll. Der Wert sollte mit Bedacht gewählt werden. Fällt er zu niedrig aus, wird der Block zu häufig dynamisch generiert. Ist er zu hoch, kommt es zu keiner Aktualisierung und die Informationen bleiben länger im Speicher als gewünscht. Im Beispiel wird eine Cache-Lebenszeit von einem Tag (in Sekunden; 60 x 60 x 24 = 86400) definiert.

Die Cache-Tags unterteilen die Informationen im Cache in verschiedene Kategorien. Diese Kategorien werden etwa verwendet, um bestimmte Bestandteile gezielt zu aktivieren, zu deaktivieren oder zu verwerfen. Genau das passiert auch beim Löschen eines Caches über das Magento-Backend.

dms 160b12233d5779cf908fbd5f44bf36d8
Im Backend lassen sich die einzelnen Caches überwachen und steuern.

Dritter Bestandteil des Listings ist die Definition des Keys in der Methode getCacheKeyInfo. Der Cache-Key ist der eindeutige Bezeichner für eine im Cache hinterlegte Information. Die Werte des Cache-Keys sollten alle verschiedenen Zustände eines Blocks wiedergeben, die einzeln gespeichert werden. Erlaubt ein Block verschiedene Zustände, so darf es genauso viele unterschiedliche Cache-Keys für den aktuellen Block geben. Um Cache-Kollisionen mit anderen Blöcken zu vermeiden, wird als erster Teil meist der Identifikator des aktuellen Blocks verwendet. Weitere Komponenten sind häufig das Package und Theme sowie die Sprache.

Cache-Backends

Wie die Caching-Daten gespeichert werden, entscheidet die Wahl der Cache-Backends, welche in der Konfigurationsdatei app/etc/local.xml eingestellt werden.

Beispiel einer Cache-Backend-Konfiguration

<config>
	<cache>
		<backend>memcached</backend>
		<slow_backend>database</slow_backend>
		<fast_backend>memcached</fast_backend>
		<memcached>
			<servers>
				<server>
					<host>192.168.0.1</host>
					<port>11211</port>
					<persistent>0</persistent>
				</server>
			</servers>
		</memcached>
	</cache>
	[...]
</config>

Listing 2

In <backend> wird das Cache-Backend eingetragen, welches mit der Zwischenspeicherung beauftragt werden soll. Mögliche Werte sind memcached, apc, xcache, eaccelerator, sqlite, database und file. Wird kein Wert übergeben, nutzt Magento standardmäßig den dateibasierten Cache.

Die vier erstgenannten Cache-Backends sind arbeits­speicher­basiert und dementsprechend schnell; allerdings sind sie nicht persistent und unterstützen keine Cache-Tags. Sie werden deshalb im Rahmen des Two-Level-Cache-Backends mit einem langsameren, aber persistenten Speicher kombiniert. Dies geschieht über die Konfigurations-Tags <slow_backend> und <fast_backend>. Darüber hinaus werden dem memcached-Backend im Beispiel noch notwendige Serverinformationen übergeben.

Zur Verbesserung der Two-Level-Cache-Performance existiert ein Cache-Modul [1], welches verhindert, dass Magento bei jedem Lesezugriff den schnellen Cache neu schreibt. Über das Modul kann zusätzlich das Cache-Backend Libmemcached aktiviert werden, welches in den Benchmarks deutlich besser abschneidet als Memcached [2].

Empfohlen wird für einzelne Webserver übrigens APC mit File-Cache. Werden mehrere Webserver verwendet, sollte das Libmemcached- mit dem Datenbank-Backend kombiniert werden.

NEU: Lass dir diesen Artikel vorlesen
Ein Service von t3n, in Kooperation mit Narando.

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
Eine Antwort
  1. von Philipp W. am 05.01.2012 (00:07 Uhr)

    Erwähnenswert ist noch das Magento Modul Full Page Cache von mgt-commerce..sehr einfach einzurichten und den Performanceunterschied ist enorm. In Kombination mit dem Hetzner EX 4 Server gehört es zu meinem Standardsetup. Statt dem normalen MySQL Server setze ich Percona 5.5 ein (verwendet eine andere Storage Engine aber sonst bleibt alles beim alten)..kein großer Aufwand und gibt auch einen guten Boost.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Aktuelles aus dem Bereich Magento
Amazon Prime greift nach „Weltherrschaft“: Prime-Vorteile jetzt auch in anderen Onlineshops
Amazon Prime greift nach „Weltherrschaft“: Prime-Vorteile jetzt auch in anderen Onlineshops

Amazon versucht sein Prime-Programm auf andere Onlineshops auszuweiten und als übergreifendes Kundenbindungsprogramm zu etablieren. Jetzt ist der erste große Retailer eingestiegen. » weiterlesen

SocialCurrency: New Yorker Pop-up-Store lässt dich mit Social-Media-Kontakten zahlen
SocialCurrency: New Yorker Pop-up-Store lässt dich mit Social-Media-Kontakten zahlen

Im New Yorker Pop-up-Store des norwegischen Herstellers OnePiece können Kunden in den nächsten Tagen mit Social-Media-Kontakten zahlen - SocialCurrency nennt das Unternehmen das. 500 Follower sind … » weiterlesen

8 Gründe, warum E-Commerce-Startups einen Pop-up-Store eröffnen sollten [Infografik]
8 Gründe, warum E-Commerce-Startups einen Pop-up-Store eröffnen sollten [Infografik]

Es scheint fast so, als sei es gerade schick, als E-Commerce-Startup einen Pop-up-Store zu eröffnen. Die folgende Infografik zeigt, warum sich ein physischer Shop durchaus lohnen könnte. » weiterlesen

Kennst Du schon unser t3n Magazin?

t3n-Newsletter t3n-Newsletter
Top-Themen der Woche für Web-Pioniere
Jetzt kostenlos
anmelden
Diesen Hinweis verbergen