Magentoperformance

Performanceprobleme bei Magento erkennen, analysieren und beheben


von Daniel Ceballos
Keine Kommentare

Backend Performance Teil 1: Asynchrone Indizierung

Damit Magento im Frontend schnell arbeitet, wird ein Index mit den aggregierten Daten der Produkte und Kategorien erstellt. Der Index sorgt dafür, dass die Ladezeiten im Frontend beim Zusammensuchen der Informationen zu einem Produkt gering sind, da diese dann meistens schon im optimalen Zustand in der Datenbank vorliegen. Diese Art der Datenaufbereitung ist ein gängiger und oft genutzter Weg und findet sich ebenfalls in vielen weiteren großen Systemen wieder, die mit einer großen Datenmenge konfrontiert werden. Da man bei Performance Maßnahmen stets Kompromisse eingehen muss, müssen sich Shop-Betreiber im Magento-Backend auf verlängerte Ladezeiten einstellen.

Beim Speichern von Produktdaten und Kategorien wird eine Aktualisierung der im Index stehenden Daten durchgeführt. Bei einer einzigen StoreView ist das noch recht überschaubar und akzeptabel. Sollte der Shop allerdings drei oder mehr StoreViews besitzen, wird man bei steigender Produktanzahl und Varianz merken, dass sich die Ladezeiten verlängern. Wenn ein Magento Shop-Betreiber viel im Magento-Backend arbeitet, wird dieser in seiner Effizienz sehr stark eingeschränkt und jede Produktpflege wird zu einem Dilemma.

Unsere Kunden besitzen oftmals Magento-Shops, die weit mehr als einen StoreView besitzen. Dabei beläuft sich die Anzahl der Produktvarianten auf mehr als 60.000 Artikel. An einem Beispiel erläutere ich nun welchen Weg wir bei der Optimierung des Magento-Backends eingeschlagen haben:

Abspeichern benötigt 2 Minuten

Der Kunde informierte uns, dass ein Abspeichern von Produkten im Magento-Backend ca. 2 Minuten benötigt. Oftmals werden solche Ladezeiten schon bei einer Standard Serverkonfiguration nach 30 Sekunden abgebrochen und der Kunde sieht nur noch eine weiße Seite. Dies ist verständlicherweise nicht zufriedenstellend und schränkt unseren Kunden in der Produktivität sehr stark ein.

Um unseren Kunden bei seiner Produktivität und Effizienz im Magento-Backend zu unterstützen, haben wir uns Gedanken darüber gemacht wie wir den Prozess im Magento-Backend für ihn optimieren können, damit er mehr Produkte in weniger Zeit anlegen, bearbeiten und aktuell halten kann. Dabei sind wir zu dem Entschluss gekommen, dass wir diese Entscheidung nicht alleine treffen können, sondern den Kunden mit einbeziehen müssen. Grund dafür ist, dass sich die Produkt-Informationen im Magento-Frontend für kurze Zeit zu den im Backend gespeicherten Daten unterscheiden können. Diesen Umstand wollten wir nicht über den Kopf des Kunden hinweg entscheiden und haben ihn dazu geholt.

Auf ein 10-faches beschleunigt

Nach Absprache mit unserem Kunden haben wir eine Lösung entwickelt, die sich positiv auf den Workflow im Magento-Backend auswirkt. Nach der Umsetzung und Integration der Eigenentwicklung, konnten wir die Ladezeiten beim Speichern von Kategorien und Produkten im Magento-Backend auf ein 10-faches beschleunigen. Der Prozess, der in der Vergangenheit mehr als 120 Sekunden in Anspruch genommen hatte, wird nun in 10-15 Sekunden durchgeführt.

Im Hintergrund finden nun die Operationen statt, die normalerweise als zusätzliche Aufgabe nach dem eigentlichen Speichern durchgeführt werden sollten. Dieser Asynchrone Prozess hat also positive Auswirkungen auf das Nutzungserlebnis des Administrators im Magento-Backend. Somit stand unserem Kunden nichts mehr im Weg die Produkte im Backend schnell anzulegen und die Produktdaten schneller zu aktualisieren.

Fazit

Magento ist im Stande sowohl kleine als auch große Aufgaben zu bewältigen. Oftmals sind es Lösungen, die speziell für einen Magento-Shop entwickelt werden müssen und in enger Absprache mit dem Kunden erfolgen sollten. Nur so ist es möglich, die Fehler und Unstimmigkeiten bei der Verwendung des Magento-Shops aufzudecken und zu beheben. Durch einen geringen Nachteil sind weitestgehend große Vorteile erkennbar. Hier ist der zuvor angesprochene Kompromiss zum Tragen gekommen und hat unseren Kunden letztendlich sehr zufrieden gestellt.

 

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

Erfahrungen mit Aitoc Custom Options Template

Eine tolle Sache an Magento ist, dass es für fast jede Anforderung schon eine fertige Extension gibt. Als ein Kunde mit dem Wunsch an uns herantrat, viele konfigurierbare Produkte in seinem Shop anbieten zu wollen, die alle ähnliche oder teils sogar gleiche Konfigurationsoptionen besitzen sollten, bot sich die Extension Custom Options Template der Firma Aitoc an. Der Vorteil: Die Produkte müssen nicht alle mehrmals von Hand eingepflegt werden. 

An der Einrichtung und der Benutzung im Testsystem war nichts auszusetzen. Es war genau das, was sich der Kunde vorgestellt hatte. Auch bei der Einpflege seiner Produkte und dem Launch seines Shops verlief alles reibungslos. Mit der steigenden Anzahl an Produkten und Besuchern, stellten sich jedoch immer größer werdende Performance Probleme ein. Diese wurden so groß, dass der Shop im Backend und speziell bei der Produktbearbeitung mehr und mehr unbrauchbar wurde. 

Nach der Analyse des Problems stellten wir fest, dass fast der gesamte Teil der Wartezeiten im Backend in den Code der Custom Options Template Extension floss. Mal abgesehen vom eigenwilligen Rewriting-System –  von dem sich Aitoc mittlerweile selbst verabschiedet hat – ist die Erweiterung scheinbar nicht für eine größere Anzahl an Options-Templates mit vielen Konfigurations-Dimensionen und vielen Optionswerten ausgelegt.

Der Server, auf dem der Shop lief, war zwar stark genug, dennoch hatte allein das Laden der Konfigurationsmaske im Backend, speziell die Maske von Custom Options Template, über eine Minute gedauert. Nachdem wir die Extension testweise deaktiviert hatten, waren wir bei fünf Sekunden. Grund dafür war, dass die Extension alle möglichen Templates bereits vorab aus der Datenbank lädt, obwohl diese eventuell gar nicht benötigt werden. Auch das Speichern von Produkten hat sich sehr in die Länge gezogen. Ein Teil des langsamen, ausgeführten Codes war – auf Nachfrage bei Aitoc selbst – sogar überhaupt nicht notwendig bzw. in der vorliegenden Version der Extension nicht mehr aktiv und konnte problemfrei auskommentiert werden.

Um das Speichern, welches oftmals bis zu zwei Minuten dauern konnte, zumindest etwas zu beschleunigen, hatten wir im Shop eine Möglichkeit eingebracht die Indexer-Events, die das System an vielen Stellen erzeugt, abzufangen und asynchron per CronJob abarbeiten zu lassen. Ohne die Extension war auch der Speichervorgang deutlich schneller. Wir lagen hier bei ca. zehn Sekunden. Auf das asynchrone Indexing werde ich in einem späteren Blogeintrag noch einmal eingehen.

Unterstützt wurde der Eindruck, den diese Erweiterung hinterlassen hatte, dann noch von einer Aussage auf der MeetMagento 2014. Dort ist im Rahmen eines Entwicklervortrages zur Codequalität der Satz: “Do not use Aitoc Extensions” gefallen. Auch wenn so eine pauschale Aussage gegen eine ganze Firma nicht sehr nett ist, wurde sie doch von der nahezu ganzen Zuhörerschaft  mit Applaus belohnt.

Das Fazit: Fertige Extensions sind wahrscheinlich in den meisten Fällen erst einmal kostengünstiger als Eigenentwicklungen. Die Einsparungen können aber schnell von den eventuell notwendigen Nacharbeiten aufgehoben werden. Wenn man also wirklich komplexere Drittanbieter-Erweiterungen einsetzen möchte, sollten daher immer umfangreiche Tests und Codeanalysen vorab erfolgen.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

Kategorieverwaltung im Magento-Backend beschleunigen

Kategorieverwaltung mit Produktzähler

Bei einem Shop mit vielen Produkten welche in einem großen Kategoriebaum sortiert sind, merkt man schnell, dass die Kategorieverwaltung relativ träge ist. Die komplette Navigation innerhalb des Kategoriebaums fühlt sich langsam an. Davon betroffen sind hauptsächlich das Öffnen von Zweigen des Kategoriebaums, sowie das erstmalige Öffnen der Kategorieverwaltung. Nach ein wenig Recherche fanden wir die Haupt-Performance Bremse im Shop unseres Kunden:

Die Anzeige der Produktanzahl in der Klammer hinter dem Namen der Kategorie. Diese wurde teils live berechnet was zu erheblichen Performance-Einbußen führte. Nach einer kurzen Rückfrage bei unserem Kunden ob die Anzeige der Produktanzahl bei seinen administrativen Tätigkeiten im Shop wichtig ist, haben wir uns zusammen dafür entschieden diese Funktionalität zu entfernen. Eine Konfigurationseinstellung gab es dafür nicht, weswegen wir den zuständigen Core-Block mit Hilfe einer kleinen Extension überschrieben und das Aufsummieren der Produktzähler für den Kategoriebaum deaktivierten.

Die Kategorieverwaltung wurde sofort merklich schneller und unser Kunde konnte seine Aufgaben im Backend schneller und effizienter erledigen.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

Varnish Cache vorwärmen mit der Google Sitemap

Nach dem Start eines neuen Magento-Shops mit Varnish-Server brauchten wir eine einfache Möglichkeit um möglichst viele der Shop Seiten für einen schnellen Abruf im Varnish abzulegen. Sprich: cache warming! Nach kurzem Überlegen kam der Kollege aus der Technik-Abteilung darauf, einfach die ohnehin schon generierte Google Sitemap zu nutzen, da dort alle wichtigen Seiten bereits enthalten sind. Dafür schrieb er ein shell-Script welches per Cronjob in regelmäßigen Abständen automatisch ausgeführt wird. Während eines Durchlaufs geht das Script durch die sitemap.xml, filtert alle URLs heraus und triggert jede URL einmal per GET-Aufruf auf dem Server an. Liegt die Seite zu dem Zeitpunkt noch nicht im Varnish, ruft dieser sie zuerst vom Backend ab und speichert sie für zukünftige Aufrufe in seinem Cache. Für kleine und mittlere Shops ist das eine einfache und schnelle Möglichkeit den Cache „warm zu halten“, beziehungsweise ein Mal „auf zu wärmen“. Bei großen Shops mit mehreren Tausend Produkten sollte man vorher versuchen die Dauer eines Durchlaufs grob ab zu schätzen und eventuell nicht alle Einträge der sitemap.xml durchgehen. Schließlich bedeutet das Aufwärmen des Varnishs auch eine zusätzliche Last für den Server, die zu manchen Tageszeiten vielleicht nicht unbedingt förderlich ist.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

Sidebar-Warenkorb trotz Varnish

Im vorherigen Blog-Artikel hatte ich bereits schon darüber geschrieben, das es wichtig ist, das Magento über einen vorgelagerten Varnish-Server bescheid weiß. Zu diesem Zweck kann man z.b. die Extension PageCache installieren, welche bei bestimmten Routen automatisch entsprechende Header/Cookies setzt um Anfragen am Varnish vorbei zu leiten. Hat man auf der Seite aber einen Block der den aktuellen Warenkorb-Inhalt anzeigen soll (checkout/cart_sidebar) darf der Varnish nicht mehr jede Katalogseite pauschal anhand der URL cachen.

Wenn man Katalog- und Produktseiten aber trotzdem cachen möchte kann man die dynamischen bzw. benutzerspezifischen Teile der Seite per AJAX – am Varnish vorbei – nachladen. Als Beispiel stelle ich hier mal den sidebar-Warenkorb vor. Wenn man das ganze als eigenständiges kleines Modul entwickeln möchte gibt es folgendes zu tun:

  • Einen Controller erstellen der nur den HTML-Schnipsel zurückliefert der für den sidebar-Warenkorb zuständig ist.
  • Eine Layout-Datei erzeugen welche alle benötigten Blöcke für den sidebar-Warenkorb erstellt. Hier kann der Standard Block für den sidebar-Warenkorb aus dem checkout.xml Layout kopiert werden und ein einem übergeordneten Block zusammengefasst werden.
  • Das Template das den im Layout definierten Block rendert. Als Vorlage kann hier das Standard- bzw. das aktuell im Shop verwendete sidebar-Warenkorb-Template verwendet werden.
  • Die Anpassung des bisherigen sidebar-Warenkorb-Templates damit dieses nun nicht mehr den Warenkorb darstellt sondern ihn erst per AJAX vom Server – von unserem neuen Controller – abruft und dann im HTML platziert. Hier sollte man darauf achten das dieser AJAX-Aufruf nie vom Varnish gecached wird. Das kann anhand der URL, über bestimmte header (NO_CACHE) oder sonst wie erfolgen. Beispielsweise so:
    ...
    jQuery.ajaxSetup({
       headers: { 'Cache-Control': 'no-cache' }
    });
     
    jQuery("#ajaxcart-container").load('<!--?php echo $this--->getUrl("ajaxblocks/index/headcart"); ?&gt;;');            
    ...

    Hier wird der NO_CACHE-Header gesetzt der vom Varnish im Normallfall beachtet wird wird.

Funktioniert das alles können auch die Startseite, Katalogseiten, Produktseiten usw. für den Varnish frei gegeben werden, der dann für wesentlich schnellere Ladezeiten sorgt. Der sidebar-Warenkorb wird dann kurze Zeit nach dem die Seite (aus dem Varnish) im Browser angezeigt wird per AJAX (direkt aus Magento) nachgeladen. Das vorgehen kann natürlich auch auf andere dynamische Blöcke wie z.B. Produktvorschläge, Merkzettel oder ähnliches angewendet werden.

Über den Performance-Gewinn solcher einfachen Eingriffe erfreuen sich mittlerweile auch schon mehrere unserer Kunden.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
1 Kommentar

Wenn schon Varnish, dann bitte richtig!

Vor kurzem sollten wir in einem Shop eines neuen Kunden ein paar Anpassungen vornehmen. Die Änderungen waren auch schnell umgesetzt, getestet und sollten dann live gestellt werden. Doch im Browser sah man nichts von den Änderungen. An die üblichen Dinge wie Cache-Löschen, Indexer etc. hatten wir gedacht, doch nichts passierte. Irgendwie schien der alte Zustand immer noch aus irgend einem Cache zu kommen.

Bis wir beim stöbern festgestellt hatten, das auf dem Web-Server auf ein Varnish-Server läuft. Dieser war soweit korrekt konfiguriert, die Magento-Installation wusste aber nichts vom Varnish. Es war keine Steuerungs-Erweiterung wie z.B. PageCache installiert, weswegen Magento zwar sein eigenes Cache-Backend zu einem Flush zwingen konnte, aber nicht den Varnish-Server.

Eine langwierige Fehlersuche hätte man sich so sparen können, wenn das Magento richtig für den Server und vor allem für den Cache-Server Varnish eingerichtet worden wäre.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

Zu langsames Anlegen und Ändern von Produkten aufgrund des Indexers

Dass der bei Magento mitgelieferte Produkt-Importer weder schnell noch sehr flexibel ist, ist bekannt. Auf Grund dessen musste ich für ein aktuelles Kundenprojekt wieder ein speziell zugeschnittenen Importer entwicklen, welcher einen Satz definierter Produktattribute aus dem ERP-System des Kunden regelmäßig in den Magento-Shop importiert. Die Entwicklung ging gut voran, doch die ersten Tests zeigten, dass der Import sehr langsam lief: für die große Anzahl an Produkten zu langsam.

Was das Problem war, verrät der Titel dieses Blogeintrags bereits: Die Indexer von Magento waren dahingehend eingestellt, dass sie bei jedem “Produkt-Update” die Änderungen in den Index übernehmen. Diese Einstellung ist in Ordnung, solange nur einzelne, manuelle Produktupdates vom Backend aus erfolgen. Bei Massen-Änderungen führen diese allerdings zu erheblich verminderter Geschwindigkeit und zu erhöhter Last auf dem Datenbank-Server.

Die einfachste Lösung ist, vor Beginn der Produktupdates den Indexer zu deaktivieren und erst nach allen Updates den Indexer wieder zu aktivieren. Gegebenenfalls muss der Index-Prozess dann einmal von Hand angestoßen werden.

Um einen, oder wie im folgenden Beispiel gleich alle, Indexer temporär zu deaktivieren und im Nachhinein wieder zu aktivieren kann folgender Code-Schnipsel verwendet werden:

// Liste aller Indexer erhalten
$indexerCollection = Mage::getSingleton('index/indexer')->getProcessesCollection(); 
 
// durch Liste der Indexer iterieren..
foreach ($indexerCollection as $indexer) {
  // .. und diese in den manuellen Modus versetzen
  $indexer->setMode(Mage_Index_Model_Process::MODE_MANUAL)->save();
}
 
// hier Produktupdates ausführen
 
foreach ($indexerCollection as $indexer)
{
  // und nach den Produktupdates wieder aktivieren
  $indexer->setMode(Mage_Index_Model_Process::MODE_REAL_TIME)->save();
}

Je nach Art der vorgenommenen Produktupdates kann es auch ausreichen nur ein Teil der Indexer kurzfristig zu deaktivieren.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
Keine Kommentare

“Warum ist der jetzt so langsam?” – über die Wichtigkeit von XDebug

Wieder einmal ein Alltagsproblem: Eine Kunde möchte, neben ein paar Änderungen und einer ERP-Connector-Erweiterungen mit seinem Shop auf unser Shared-Hosting umziehen. Soweit kein Problem. Ich habe eine Kopie aus dem Liveshop auf unserem Server erstellt. Da vor dem Go-Live ohnehin ein aktueller Kunden- und Produktstamm eingespielt werden muss leerte ich die Kunden und Produktdatenbank im Shop fast vollständig. Lediglich ein paar Datensätze zum Testen habe ich übrig gelassen.

Nachdem alle vom Kunden gewünschten Änderungen umgesetzt wurden, habe ich test weise noch einmal den kompletten Produktstamm importiert… und da ist das Problem! Das Shop-Frontend ist wunderbar schnell, das Admin-Backend ist aber unbenutzbar. Entweder “unendlich” langsam, oder der Webserver-Prozess wird vor Ende durch Speicher- oder Ausführungszeit-Limits abgebrochen.

“Warum ist der jetzt so langsam? Liegt es am etwas schwächeren Server? Liegt es an den Codeänderungen? Aber wir haben doch gar nichts an den Backend-Modulen geändert?”

Wenn das Frontend auch ohne Cache schnell ist das Backend aber nicht, dann liegt es nicht an der Server-Hardware. Mit wenig manuellem Debuggen bin ich nur bis zum einem “CollectionLoad” gekommen, ab da wurde das Debugging aber fast unmöglich. Das Problem wurde dann aber schnell klar, nachdem die Technikabteilung das Modul XDebug auf dem Server aktiviert hatte und ich die langsamen Shop-Backend-Bereiche noch einmal aufgerufen habe.


In Zeile 36 sieht man, das die ProductCollection eigentlich fertig geladen wurde. Ab Zeile 37 wird der Standard-Event “Collection_Load_After” gefeuert UND von genau der einen Drittanbieter-Erweiterung gefangen welche ich im Zuge der Shopanpassungen installieren sollte. Bis zu dem Zeitpunkt sind, wie man in der zweiten Spalte erkennen kann, auch erst 0.7 Sekunden vergangen. Eine Zeile weiter – Nummer 41 – sind aber schon ca. 120 Sekunden vergangen und die MAX_EXECUTION_TIME von PHP ist erreicht.

Nachdem ich das Problem innerhalb der Erweiterung behoben hatte, war der Shop auch im Backend wieder so schnell wie zuvor. Bevor man ein Problem”mit Hardware tot schlägt” oder lange manuell versucht zu Debuggen sollte man besser einmal einen Debugversuch mit XDebug unternehmen. Entweder mit dem oben gezeigten Aufruf-Stack oder mit den von XDebug erzeugten Cachegrind-Dateien. Wie das genau geht habe ich bereits im Artikel “Magento Code-Profiling mit Xdebug” beschrieben.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
2 Kommentare

Produkte schneller speichern

Steht man vor der Aufgabe ein Produktobjekt in Magento zu speichern wird das oft einfach mit einem “save()” erledigt:

$product = Mage::getModel("catalog/product")->load(1);
$product->setName("Produkt mit neuem Namen");
$product->save();

Diese Variante des Speicherns ist aber nicht besonders performant, da das gesammte Produktobjekt in der Datenbank aktualisiert wird. Je nach Anzahl der EAV-Attribute kann das eine sehr aufwändige Operation werden.

Für den Fall das wirklich nur einzelne Attributwerte eines Produkts aktualisiert werden sollen, sollte man stattdessen den Weg über das Resource-Model gehen. Übertragen auf das Beispiel von oben würde der Code dann so aus:

$product = Mage::getModel("catalog/product")->load(1);
$product->setName("Produkt mit neuem Namen");
$product->getResource()->saveAttribute($product,"name");

Die genutzte Funktion “saveAttribute()” findet man im Magento-Core unter /app/code/core/Mage/Eav/Model/entity/Abstract.php. “Schlank” sieht diese Methode zwar auch nicht aus, sie beschränkt sich aber wirklich nur auf das Speichern von einem Attribut.

Im Gegensatz dazu lädt die Funktion “save()” aus dem ersten Codebeispiel ein eventuell nur teilweise geladenes Produkt zuerst komplett und stellt dann für alle Attribute die Aktualisierungs-Statements zusammen. Ohne Frage die letztendlich aufwändigere Funktion.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.


von Sebastian
2 Kommentare

Extra Boost durch Full Page Caching: Varnish Cache und Magento

Da wir bei basecom nicht nur für Magento Shops entwickeln, sondern auch für viele Kunden deren Magento Hosting betreuen, beschäftigt sich auch unsere Technikabteilung mit der Performanceoptimierung.
Vor ein paar Tagen haben wir daher eine weitere Möglichkeit zur Performance Steigerung getestet. Diese Möglichkeit kann sogar gleichzeitig mit memcache genutzt werden.

Unter dem Varnish Cache kann man sich eine Art Proxy-Server zwischen Shop und Webseitenbesucher vorstellen, der alle Anfragen an den Shop entgegennimmt und entscheidet, ob eine Version aus dem Cache ausgeliefert werden kann oder ob der Aufruf an den Shop durchgereicht werden muss. Unterstützend dazu wird in Magento die Erweiterung “PageCache powered by Varnish” installiert. Diese Erweiterung hängt sich an einen Routerevent (controller_front_init_routers) von Magento und passt dort die HTTP Header für ein besseres Zusammenspiel mit dem Varnish Server an. Einstellungsmöglichkeiten dafür gibt es im Magento-Verwaltungsbereich unter dem Punkt “Advanced“->”System“:

Varnish Konfigurationsmöglichkeiten im Magento Backend

Varnish Konfigurationsmöglichkeiten im Magento Backend

Bei Aufsetzen des Varnish Servers (Installation Ubuntu) bringt dieser eine allgemeine Konfigurationsdatei (/etc/default/varnish ) mit, welche unter anderem den verwendeten Arbeitsspeicher, das Steuerinterface oder die Threading-Einstellungen regelt. Hier der Abschnitt mit der allgemeinen Serverkonfiguration, welcher der leicht abgewandelten Beispielkonfiguration aus der der Konfigurationsdatei entspricht:

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -u varnish -g varnish \
             -S /etc/varnish/secret \
	     -p thread_pool_add_delay=2 \
             -p thread_pools=2 \
             -p thread_pool_min=400  \
             -p thread_pool_max=4000 \
             -p session_linger=50 \
             -p sess_workspace=262144 \
             -s malloc,512m"

Eine weitere Konfigurationsdatei die Varnish mitliefert befindet sich im Verzeichnis /etc/varnish (siehe Zeile 3 der Serverkonfiguration). Die default.vcl ist von Haus aus relativ leer und nicht auf Magento abgestimmt. Die PageCache Erweiterung bringt aber bereits eine optimierte Version der Datei mit welche händisch kopiert werden muss.

Diese wird von der oben erwähnten Magento-Erweiterung erstellt und lässt sich als eine Art Regelsatz verstehen, welcher dem Varnish Server genaue Instruktionen gibt, wann welche Seiten und Dateien im Cache abgelegt werden dürfen und wann nicht.

Interessant sind jetzt natürlich noch die Performanceunterschiede in der Praxis. Die “Werbetrommel” spricht von einem bis zu 100x schnellerem Shop. In der Praxis hatte ich beispielsweise bei einer Katalogseite eine deutlich kürzere Antwortzeit im Browser feststellen können:

Varnish deaktiviert, Magento Cache deaktiviert: 950ms

Varnish deaktiviert, Magento Cache aktiviert: 480ms

Varnish aktiviert, Magento Cache deaktiviert: 25ms

In unserem Fall war der Varnish Server nicht auf dem selben Server installiert wie der Shop selbst, da es sich um ein “Shared Hosting System” handelt. Die localhost Installation ist aber möglich und bietet sich besonders bei VM-Systemen an, bei denen jeder Shop eine eigene virtuelle Maschine hat.

In der localhost-Variante muss dann noch der eigentliche Webserver des Shops (Apache, etc.) auf einen anderen Port umgestellt werden, damit der Varnish Server auf dem Port 80 alle eingehenden Anfragen abfangen kann. Installiert man den Caching Server auf einer anderen Maschine, muss der DNS Eintrag des Shops dahingehend geändert werden, als dass dieser nicht mehr auf den Shop sondern auf den Varnish Server zeigt.

Benötigen Sie mehr Informationen oder Hilfe bei der Umsetzung in Ihrer Magento Installation? Wenden Sie sich einfach an den Ansprechpartner für Online-Shops bei meinem Arbeitgeber basecom.