Zurück

Shopware 5-Performance drastisch verbessern

[Shopware Praxis-Tipp]

Ok, das klingt jetzt ziemlich reißerisch und in den allermeisten Fällen ist es natürlich nicht so einfach. Shopware 5 ist eine komplexe Software und viele Komponenten müssen optimal aufeinander abgestimmt sein, damit die Geschwindigkeit stimmt (HostingCachemöglichst wenige PluginsOptimierung der Templates etc.). Shopware gibt selbst einige Tipps dazu: https://docs.shopware.com/de/shopware-5-de/tutorials-und-faq/performance-tipps und https://www.shopware.com/de/news/praxistipp-performance-optimierung-fuer-onlineshops/

Das Nachfolgende bezieht sich wohlgemerkt auf die Server-Performance (also den Shopware-Stack und PHP) und weniger auf die Frontend-Performance, wie schnell also die eigentliche Seite dann im Browser angezeigt wird. Hier spielen dann eher Faktoren wie der generelle Template-Aufbau, CSS-/Javascript-Optimierung und Bildkompression/CDN eine Rolle.

In einem Fall hatten wir also das Problem, dass die Performance eines High Traffic Shops wirklich jenseits von Gut und Böse war — auch ohne wirklich viele Nutzer im Shop waren Seitenladezeiten von mehreren Sekunden leider der Normalzustand. Über den PHP-Profiler tideways.io (sehr empfehlenswert zur Analyse!) konnte das Problem zwar deutlich PHP selbst zugeordnet werden, aber wirkliche Ansatzpunkte gab es nicht, auch der Hoster stocherte eher im Nebel.

Es wurde viel optimiert (grundsätzlich nie verkehrt!), Hosting Einstellungen wurden verändert und sogar ein schnellerer Server beauftragt. Nach einem Update auf Shopware 5.6 wurde es allerdings nur noch langsamer: 5–6 Sekunden Abrufzeit für eine Seite (ohne nennenswerten Traffic)?! An ein Arbeiten im Backend war nicht zu denken, der Aufruf der Caching-Einstellungen im Shopware Backend schlug regelmäßig fehl (hier werden Dateien gezählt…!)

PHP-Einstellung open_basedir

Fast immer haben nun derartige Probleme keine singuläre Ursache — es ist meist ein Zusammenspiel aus verschiedenen Faktoren. Hier allerdings lag der Fall anders: die simple PHP-Einstellung open_basedir = none brachte — wirklich schlagartig! — eine extreme Verbesserung von vormals über 5 Sekunden auf dann etwa 500 bis 700 Millisekunden für den Seitenaufbau.

Zugrunde liegt ein Verhalten von PHP, das bei aktiviertem open_basedir das so genannte realpath caching abschaltet (siehe https://bugs.php.net/bug.php?id=77406). Wenn nun eine PHP-Anwendung sehr viele Datei-Operationen durchführt, und dazu gehören neben filesize(), file_exists(), fopen() auch include()include_once(), require() usw., wird jedesmal eine bestimmte Betriebssystemfunktion mehrfach aufgerufen, um den tatsächlichen Dateipfad zu ermitteln. Da Shopware (bzw. Symfony) bei jedem Aufruf durchaus zahlreiche Dateien inkludiert, scheint das in diesem Fall PHP dramatisch ausgebremst zu haben.

Sehr gut nachvollziehbar war das übrigens in der tideways-Auswertung: nach dem Aufruf einer Seite passierte über 5 Sekunden erst einmal rein gar nichts, erst dann kam weiterer Code zur Ausführung.

 

Sicherheit

Ja, open_basedir ist sicherheitsrelevant und sollte nicht ohne gute Begründung verändert werden. Ist die Funktion deaktiviert, können PHP-Skripte potentiell auf Verzeichnisse anderer Hosting-Nutzer zugreifen (relevant im shared hosting). Allerdings sollte das zum einen über entsprechende Zugriffsrechte des Dateisystems geregelt und ausgeschlossen sein, und zum anderen läuft ein derartig stark frequentierter Shop ohnehin auf einem komplett eigenen Server.

Und natürlich gelten auch nach dem Lösen dieser Handbremse die üblichen Tipps zur Performance-Verbesserung für Shopware: möglichst wenige Plugins verwendenOptimierung von PHP-Code und Datenbankabfragen (legt mal ein paar Indizes an, liebe Plugin-Hersteller!) und die volle Ausnutzung der Shopware Caching-Mechanismen. Nicht zuletzt muss der Server zum Shop und zu den erwarteten Nutzerzahlen passen (zertifiziertes Shopware Hosting mit entsprechender Server-Dimensionierung).