Performance Optimierung für Shopware 5

Zurück zur Übersicht
analyse

Bei einem von uns betreuten Shopware-Shop trat das Problem auf, dass unter hoher Last (Live-Sendungen bei einem bekannten Shopping-Sender) die Server-Performance drastisch einbrach.

Im normalen Tagesbetrieb mit ca. 6.000 Besuchern am Tag ist der Server absolut in der Lage, alle Anfragen zu bearbeiten und es gibt ausreichend Reserven nach oben. Während eines typischen TV-Events kann es jedoch leicht zu einer 3-4mal so hohen Last kommen, 15.000 bis 20.000 Besucher am Tag sind dann keine Seltenheit und es wird mit noch weiteren Steigerungen gerechnet.
Dies führte bei der letzten TV-Show zu Ladezeiten von bis zu 3 Sekunden und mehr (gegenüber einer normalen Ladezeit deutlich unter 800ms) - ein definitiv nicht akzeptabler Wert.

Auffällig zudem: Der betreffende Shop läuft bereits seit Mitte 2015 auf Shopware und es wurden bereits einige Shopping-Events durchgeführt, ohne dass es zu derartigen Verschlimmerungen gekommen wäre.

Wie kann dieses Problem also angegangen und behoben werden? Der erste Impuls war: „Wir brauchen einen stärkeren Server“. Möglicherweise führt das zum Erfolg, ist aber natürlich mit höheren Grundkosten verbunden, die zudem an 98% der Tage ohne den TV-Traffic schlichtweg unnötig sind. (Hier soll es nicht um eine flexible Skalierung von Shopware in der Cloud gehen - das wäre sicherlich noch einmal ein anderes Thema).

Hohe PHP-Last

Natürlich wurden bereits sämtliche von Shopware empfohlenen Maßnahmen zur Performance-Optimierung ausgenutzt (nginx-Server mit SSDs, PHP-Cache, HTTP-Cache etc.). Eine erste Anfrage beim Provider TimmeHosting ergab dann nach Auswertung der Logfiles schnell, dass der Flaschenhals bei PHP zu suchen ist: die PHP-Prozesse haben einen ganz erheblichen Teil der Systemlast erzeugt, so blieb naturgemäß deutlich zu wenig Anteil für Datenbank und Webserver übrig.

Eigentlich sollten dank des Webcaches bei Shopware 5 im Produktivbetrieb fast keine PHP-Script mehr aufgerufen werden, da die Seiten eben komplett aus dem Cache kommen. Natürlich gilt dies nicht für dynamisch nachgeladene Informationen (z.B. der Ajax-Warenkorb), das Kundenkonto und den gesamten Checkout-Prozess. Auch die Suche ist natürlich dynamisch und greift zwangsläufig über PHP auf die Datenbank zu.

Und genau hier gab es bereits einen ersten konkreten Ansatzpunkt: die Live-Suche fängt bei Shopware 5 bereits beim 3. eingegebenen Buchstaben an zu suchen. Das ist einerseits sehr responsiv und „fühlt“ sich somit für den Nutzer angenehm an, da er schnelle Ergebnisse erhält. Andererseits ist wohl kaum ein Suchbegriff nach bereits 3 Buchstaben sinnvoll beendet - es kommen also noch weitere Buchstaben. Die Suche - und damit ein PHP-Aufruf - wird jedoch für jede einzelne Eingabe wieder neu ausgelöst. An dem betroffenen Tag waren dies allein über 100.000 PHP-Aufruf nur für die Livesuche (ajax_search?sSearch=)!

Leider kann die Zeichenzahl, nach der die Suche ausgelöst wird, nicht in den Shopware-Einstellungen verändert werden. Dies muss direkt im Quellcode erfolgen (themes/Frontend/Responsive/frontend/_public/src/js/jquery.search.js, ca. in Zeile 109 die Variable minLength). Wir haben diese nun einmal auf 6 gesetzt, zudem gibt es noch die Einstellung searchDelay, die mit 250ms im Standard ebenfalls sehr niedrig gesetzt ist und angibt, mit welcher Verzögerung nach der letzten Zeicheneingabe die Livesuche ausgelöst werden soll. Ein guter Wert dafür erscheint uns aus Usability-Sicht 750ms zu sein.
Achtung: derartige Änderungen im Shopware Source-Code sind nicht updatesicher und müssen ggf. nach jeder Aktualisierung erneut durchgeführt werden!

Flaschenhälse identifizieren mit Profiling

Ein weiterer Tipp von TimmeHosting brachte dann jedoch letztlich den Durchbruch: Seit einiger Zeit kann direkt in der Webserver-Verwaltung ein sogenannter Profiler eingebunden werden. Direkt unterstützt wird dabei der Dienst tideways.io (es gibt eine 30 Tage-Testversion). Nach der Konfiguration werden sämtliche PHP-Aufrufe überwacht und nach vielfältigen Kriterien sehr übersichtlich aufbereitet. Auf einen Blick lassen sich so erkennen, welche Probleme auftreten und die Performance am meisten negativ beeinflussen!

Wir haben Tideways zunächst ein paar Tage laufen lassen, um die „Baseline“, also den aktuellen Stand erkennen zu können. Hier ergab sich schnell ein klares Bild: Mit 24% Anteil war der Shopware Controller ShopwareControllersFrontendMediaProxy::fallBackAction der Hauptverursacher an der Misere! Gefolgt von refreshStatisticsAction (12%) und der bereits identifizierten Livesuche (AjaxSearchProxy::indexAction, 6.1%).

tideways1

Besonders interessiert hat uns natürlich die fallBackAction.
In Shopware 5 hat sich die Speicherung der Medien (z.B. Bilder für Produkte, Einkaufswelten etc.) geändert. Diese werden in einem abstrahierten Dateisystem gespeichert und sollten nicht mehr über das alte Schema in der Form /media/image/bild.jpg abgerufen werden, sondern etwa über /media/image/7f/7f/06/bild.jpg. Damit eine Abwärtskompatibilität gewährleistet bleibt, ist der Abruf jedoch technisch noch in der alten Form möglich, dies wird genau durch die erwähnte fallBackAction realisiert.

Und siehe da: der Shop wurde vor einigen Monaten von Shopware 4 auf die Version 5 umgestellt und migriert, dabei wurden natürlich alle Inhalte übernommen. Bei der Einbindung einiger Bilder der Medienverwaltung wurden dabei jedoch nicht die neuen Bildaufrufe eingefügt (z.B. in einem verwendeten Mega-Menü oder in einigen statischen Templates). Unglücklicherweise führte der Aufruf jeder Seite so zu zusätzlichen unnötigen PHP-Anforderungen!

Nun war die Behebung trivial: die betroffenen Bilder konnten mit Hilfe von Tideways sehr schnell identifiziert werden und die Pfade wurden gegen das neue Medien-Schema ausgetauscht. Nach einigen Tagen erfolgte wiederum eine neue Auswertung - das Problem war behoben, die in Tideways angezeigte Fehlerrate ist von 32% auf 2.4% gesunken. Es bleibt natürlich abzuwarten, wie sich der Server nun unter hoher Last verhält, aber wir sind zuversichtlich. Es könnten auch gezielte Last-Tests durchgeführt werden, etwa mit LoadImpact oder ähnlichen Tools.

tideways2

Es besteht noch weiteres Potential zur Performance-Optimierung, so könnten etwa die Shopware-internen Statistiken (refreshStatisticsAction) abgeschaltet werden, ggf. auch nur temporär bei absehbar hohen Serverbelastungen. Und die noch verbliebenen Fehler-Ursachen könnten noch vertieft analysiert werden.

Fazit

Insgesamt hat uns Tideways hier sehr gute Dienste geleistet und dazu beigetragen, dass die Serverperformance mit wenigen und kleinen Maßnahmen innerhalb von kurzer Zeit erheblich verbessert werden konnte!


Zurück zur Übersicht