In der Anfang November veröffentlichten Version 1.3. unseres Solr-Suchmoduls „IntegerNet_Solr“ haben wir die Möglichkeit integriert, Magento-Kategorieseiten ebenfalls mit Daten aus Solr darzustellen. Warum und in welchen Fällen das sinnvoll ist, erklären wir hier. Auch eine kleine Performance-Untersuchungsreihe haben wir durchgeführt.

„Was ist falsch an der Magento-eigenen Kategoriedarstellung?“

Im Allgemeinen nichts. Unter speziellen Bedingungen kann sich die Kategoriedarstellung allerdings als Performance-Flaschenhals erweisen und das ganze System ausbremsen:

  • Viele Produkte (spätestens ab dem oberen fünfstelligen Bereich)
  • Generische Kategorien mit vielen Produkten
  • Intensiver Einsatz von Filtern

Vor allem wenn mehrere dieser Punkte zusammen kommen, gerät Magento schnell an seine Grenzen.

„Aber ich habe Varnish, damit werden alle Kategorieseiten gecacht“

Varnish, andere Reverse-Proxies oder Full Page Caches sind eine sinnvolle Maßnahme zur Performance-Optimierung. Diese können allerdings immer nur eine begrenzte Anzahl Seiten, und immer nur für einen begrenzten Zeitraum, cachen. Die Kategorieseiten selbst sind darin üblicherweise enthalten. Sobald man aber einen oder mehrere Filter wählt, sind die Ergebnisse üblicherweise nicht mehr gecacht, da es eine extrem große Anzahl an möglichen Filterkombination (und damit auch Seiten-URLs) gibt. Es ist quasi unmöglich, bei einer größeren Anzahl Produkten, Kategorien und/oder Filtern alle möglichen Varianten im Cache zu halten. Daher werden auch bei grundsätzlich vorhandenem Cache entsprechender Seiten immer einige Kategorieseiten direkt von Magento ausgegeben werden müssen. Dabei können bei Standard-Setups schnell Laufzeiten von mehreren Sekunden entstehen, die bei vielen Besuchern teilweise auch den Server auslasten können.

Performance-Tests

Im von uns getesteten Beispiel hatten wir folgendes Setup:

  • Magento Community Edition 1.9
  • rwd/default-Theme
  • 100.000 einfache Produkte in einer Kategorie
  • 10 Filter-Attribute mit je 10 Optionen, die den Produkten gleichverteilt zugewiesen wurden
  • 4 Filter davon zufällig ausgewählt, sodass noch ca. 10 Produkte als gefiltertes Ergebnis übrig bleiben
  • Testreihe von 100 Kategorieaufrufen, mit jeweils neu ausgewählten Filtern bzw. neuen Suchbegriffen (ohne Wiederholungen)
  • „Flat Catalog“ aktiviert
  • Alle Caches aktiviert
  • Lokaler Test-Server ohne sonstige Last
  • „Produktanzahl im Filter anzeigen“ deaktiviert

Die Produkte haben wir über ein einfaches AvS_FastSimpleImport-Skript in Magento importiert (Download des Import-Skripts). Vorher mussten natürlich die passenden Attribute („attribute 1..10“) mit den korrekten Optionen („Option 1..10“) angelegt werden. Anschließend haben wir die Kategorie-URL mit jeweils vier gesetzten Filtern generiert und automatisiert aufgerufen. Dabei wurde die Zeit gestoppt und automatisch gespeichert. Folgende Werte haben wir jeweils für die Magento-Installation ohne Anpassungen und Magento mit der IntegerNet_Solr Erweiterung gemessen:

Kategoriedarstellung mit 4 zufällig aktivierten Filtern

Durchschnitt Minimum Maximum
Magento-Standard 15,13s 13,61s 21,19s
IntegerNet_Solr 0,68s 0,59s 0,80s

Zusätzlich haben wir die Gelegenheit genutzt und den gleichen Test auch für die Suchergebnisseite durchgeführt – mit und ohne Filter. Die Ergebnisse:

Suchergebnisseite mit 4 zufällig aktivierten Filtern

Durchschnitt Minimum Maximum
Magento-Standard 17,16s 15,63s 17,13s
IntegerNet_Solr 0,77s 0,58s 0,89s

Suchergebnisseite ohne aktivierte Filter

Durchschnitt Minimum Maximum
Magento-Standard 1,81s 0,77s 2,79s
IntegerNet_Solr 0,70s 0,61s 0,83s

Fazit

Wie man anhand der Performance-Tests sieht, können sich unter bestimmten Bedingungen die Laufzeiten schnell hochschaukeln, wenn man nur die Standard-Möglichkeiten von Magento nutzt. Um dieses Problem anzugehen, haben wir die Kategoriedarstellung in unser Solr-Modul integriert. Die gemessenen Laufzeit-Unterschiede sind eklatant. Gegenüber Magento konnte Solr die Ladezeiten um bis zu 95% reduzieren.

Vergleich der Seitenladezeit von Magento und IntegerNet_Solr

Dieses Beispiel ist sicherlich in mancherlei Hinsicht extrem, aber nicht völlig unrealistisch. Und auch wenn man die hier verwendeten Werte abschwächt, bleiben noch starke Performance-Unterschiede erkennbar. Die Reduzierung der Ladezeit einer gefilterten Kategorieseite auf die Hälfte oder ein Drittel ist auch bereits ein Ergebnis, das eine deutliche Verbesserung darstellt. Da bereits eine Sekunde Ladezeit zu einem Rückgang der Conversion Rate um 7% führen kann, lohnt sich eine Investition in die Performance-Optimierung nach kürzester Zeit.

Mehr über IntegerNet_Solr

Andreas von Studnitz

Autor: Andreas von Studnitz

Andreas von Studnitz ist Diplom-Informatiker, Magento-Entwickler und Geschäftsführer von integer_net. Seine Schwerpunkte sind Entwicklung, Beratung und die Durchführung von Schulungen. Er ist Magento 2 Certified Professional Developer Plus und hat darüber hinaus weitere Magento Zertifizierungen für Magento 1 und Magento 2. Sowohl im Jahr 2019 als auch 2020 wurde Andreas als Magento Master in der Kategorie „Mentor“ ausgezeichnet.

Mehr Informationen