Shopware-Audit

Ausgangslage

CULTIZM, ein etablierter Online-Händler, betrieb sein Geschäft auf Shopware 5.2.12 mit PHP 7.0 und MySQL 5.7 auf einem einzelnen leistungsstarken Server (32 Kerne, 93 GB RAM). Im Normalbetrieb mit aktivem HTTP-Cache waren die Ladezeiten hervorragend — die Startseite lud in 0,11 Sekunden. Doch sobald der Cache nicht griff, brach die Performance ein: Produktdetailseiten benötigten über 3 Sekunden, und bei parallelen Zugriffen stiegen die Antwortzeiten auf bis zu 17 Sekunden. Das zugrunde liegende Problem war nicht offensichtlich, und der Kunde benötigte eine unabhängige, datenbasierte Analyse.

Herausforderung

Die zentrale Herausforderung war die Diskrepanz zwischen Cache- und Nicht-Cache-Performance. Solange der HTTP-Cache die Last abfing, lief der Shop einwandfrei. Sobald ein Request jedoch PHP und MySQL durchlief — etwa beim Warenkorb, im Checkout oder bei Suchen — brach die Antwortzeit zusammen. Die Ursachen konnten auf mehreren Ebenen liegen: veraltete PHP-Version, ineffiziente MySQL-Konfiguration (insbesondere ein viel zu großer Query Cache von 128 MB), fehlende Skalierbarkeit durch die Single-Server-Architektur oder das obligatorische IonCube-Encoding, das moderne PHP-Features blockierte. Es galt, unter diesen möglichen Faktoren die wirklichen Engpässe zu identifizieren und einen priorisierten Maßnahmenkatalog zu liefern — ohne den laufenden Betrieb zu gefährden.

Vorgehen

Ich führte eine systematische, mehrschichtige Analyse durch. Zunächst erfasste ich die gesamte Infrastrukturkonfiguration: PHP-Einstellungen (OPCache, Execution Limits), MySQL-Parameter (Query Cache, InnoDB Buffer) und das Hosting-Modell. Dann maß ich die tatsächlichen Ladezeiten aller relevanten Seitentypen — sowohl mit als auch ohne HTTP-Cache. Apache-Benchmark-Tests simulierten parallele Zugriffe unter Last und legten das MySQL-Blocking-Verhalten offen. Jeder Befund wurde mit messbaren Vorher-Werten belegt, einer konkreten Ursache zugeordnet und mit Aufwand sowie erwartetem Nutzen bewertet. Der Abschlussbericht enthielt acht priorisierte Handlungsempfehlungen in einer übersichtlichen Matrix.

Ergebnis

Die Analyse identifizierte den MySQL Query Cache als einen der Hauptverursacher: mit 128 MB überdimensioniert, verursachte er bei Schreibzugriffen massive Blockierungen. Weitere Quick Wins umfassten die Auslagerung der Session-Speicherung auf Redis und optimierte PHP-OPCache-Einstellungen. Mittelfristig empfahl der Bericht das Upgrade auf PHP 7.4 sowie die Entfernung des IonCube-Loaders, der die Nutzung moderner PHP-Features und OPCode-Optimierungen verhinderte. Für skalierbares Wachstum wurde ein Umstieg auf Multi-Node-Hosting mit Load Balancer und MySQL-Cluster (Primary + Replicas) skizziert. Der Kunde erhielt einen klaren, evidenzbasierten Fahrplan, der schnelle Stabilitätsgewinne mit einer nachhaltigen Architektur-Perspektive verband.