Wir haben reale Lasttests für sieben verschiedene Infrastrukturpläne durchgeführt, von Grid bis Dedicated Split, und dabei realistische Konversionsraten, Bot-Traffic-Mischungen und ERP-gesteuerte API-Importe verwendet. Die Ergebnisse waren eindeutig: Die Leistung skaliert vorhersehbar mit den Ressourcen, aber nur, wenn Ihr Code, Ihr Cache und Ihre Konfiguration mithalten können. Dieser Blogbeitrag erläutert die wichtigsten Ergebnisse, warum die API-Last unverhältnismäßig teuer ist und welche Metriken am wichtigsten sind.
Wie gut funktioniert Shopware tatsächlich unter Last? Diese Frage wird häufig gestellt, insbesondere wenn Teams eine neue Infrastruktur evaluieren oder sich auf Traffic-Spitzen vorbereiten. Deshalb haben wir beschlossen, dies selbst zu testen.
Wir haben strukturierte Lasttests im Produktionsstil für sieben verschiedene Shopware-PaaS-Infrastrukturpläne durchgeführt, von Grid-Konfigurationen der Einstiegsklasse bis hin zu dedizierten Split-Clustern mit hoher Kapazität. Das Ziel war nicht, das System zum Absturz zu bringen, sondern die reale E-Commerce-Nutzung unter Druck zu simulieren: Browsen, Kaufen und Backend-Automatisierung, alles mit realistischen Konversionsraten und Caching-Verhalten. Hier sind unsere Ergebnisse.
Der reale Datenverkehr ist komplexer als gedacht
Viele Leistungstests basieren auf synthetischen Szenarien, d. h. einzelnen Endpunkten, die mit festen Raten bombardiert werden. So verhalten sich echte Storefronts jedoch nicht. Unser Testplan umfasste:
- Anonymes Browsen (Homepage, Kategorien, Suche)
- Neue Customer Journeys (Browsen, Registrieren, Zur Kasse gehen)
- Wiederholte Kundenkäufe (Anmeldung und Schnellkauf)
- API-gesteuerte Produktimporte (ERP-Simulation)
Außerdem haben wir realistische Konversionsraten (~3 %), Bot-zu-Benutzer-Verhältnisse und Caching-Verhalten eingeführt. Die Caches wurden mit automatisierten Crawlern vorgewärmt, um reale Bereitstellungen widerzuspiegeln.
Wichtige Erkenntnisse aus den Lasttests
1. Shopware skaliert vorhersehbar mit Ressourcen
Mit zunehmender CPU- und Speicherleistung der Infrastrukturpläne konnte Shopware mehr gleichzeitigen Datenverkehr bewältigen und gleichzeitig die Antwortzeiten niedrig halten. Selbst bescheidene Pläne zeigten unter optimierten Bedingungen eine gute Leistung. So bewältigte beispielsweise ein Dedicated Grid Host (DGH32) über 7.000 Bestellungen pro Tag mit einer TTFB von unter einer Sekunde (p95).
2. Die API ist ein versteckter Kostentreiber
Der API-Traffic (z. B. Produktaktualisierungen oder ERP-Synchronisierungen) verursachte einen unverhältnismäßig hohen Anteil der Backend-Last. Obwohl er nur 5–10 % des gesamten Traffics ausmachte, waren API-Anfragen für Cache-Invalidierungen und Spitzen in der CPU-Auslastung verantwortlich.
3. Die Caching-Strategie entscheidet über die Leistung
Pläne mit vorgewärmten Fastly-Caches sorgten für konsistente Antwortzeiten. Diejenigen, die ohne ordnungsgemäße Cache-Vorbereitung getestet wurden, wiesen eine erhebliche Latenz auf. Cache-Fragmentierung und schlecht strukturierte Endpunkte führten zu MISS-Antworten, die den Durchsatz sofort verschlechterten.
4. Die Infrastruktur ist nicht der Engpass
In fast allen Szenarien, in denen die Leistung abnahm, lag das Problem im Code, in der Konfiguration oder in der Cache-Invalidierung – nicht in der zugrunde liegenden Plattform. Beispielsweise führte ein Plugin, das im Debug-Modus belassen wurde, zu einer Disk-I/O-Konflikt, der die Seiten extrem verlangsamte.
Ein Hinweis zur Methodik
Wir verwendeten Grafana K6, um den Datenverkehr zu simulieren, und verfolgten Metriken wie:
- p95 TTFB (Time to First Byte)
- Spitzenanfragen pro Sekunde (RPS)
- CPU-Auslastung
- Fehlerrate
- Bestellungen/Stunde und Bestellungen/Tag
Jeder Test lief 5 Minuten lang in isolierten, sauberen Umgebungen. Um das Verhalten eines echten Shops so genau wie möglich nachzubilden, wurden Konvertierungslogik und Traffic Shaping angewendet.
