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.
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.

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.
Wow, das sind in der Tat sehr beeindruckende Zahlen – Glückwunsch!
Ivan Chepurnyi hat bei der Mage Titans Konferenz übrigens ein ähnliches Konzept mit Sphinx vorgestellt: https://prezi.com/f7wi-iqwllfh/going-beyond-magento-speed-limits-without-hhvm-and-varnish-mage-titans/
Fast den gleichen Vortrag haben wir von Ivan auf der Meet Magento NL dieses Jahr schon gesehen, sein Layered Navigation Framework Konzept ist auf jeden Fall spannend! Unabhängig davon gab es die Idee, Kategorieseiten aus Solr zu holen bei uns aber auch schon länger, die Performance der Standardnavigation in Magento ist einfach in vielen Fällen nicht zufriedenstellend.