Auslieferung
Webserver und PHP liefern Storefront-Requests aus. Diese Schicht soll skalieren können, ohne selbst Kunden- oder Warenkorbzustand zu besitzen.
Ursache statt Schnellfix
„Shopware zu langsam“ beschreibt ein Symptom, keine Ursache.
Eine Produktseite, ein eingeloggter Kunde und ein Checkout laufen nicht unter denselben Bedingungen. Wer alles mit mehr PHP-Worker oder einem HTML-Cache beantworten will, verschiebt das Risiko oft nur in den Warenkorb.
Gemeinsamer Zustand
Redis kann Cache, Sessions und Locks zentral halten. Mehrere Webnodes sehen damit denselben flüchtigen Zustand statt jeweils ihre eigene Wahrheit.
Führende Daten
Bestellungen, Preise und Bestände gehören in die Datenbank. Suche, Jobs und Medien brauchen klare Zuständigkeiten statt Konkurrenz um denselben Webserver.
Der Weg aus dem Monolithen
Ein zweiter Server hilft erst, wenn kein einzelner Server den Zustand allein hält.
Für einen belastbaren Shopware-Betrieb werden Zuständigkeiten entkoppelt: Datenbank, Redis, Suche und Worker laufen nicht als zufällige Nebenwirkung neben der Storefront. So lassen sich Lastspitzen abfedern und Deploys kontrollierter durchführen.
CDN / Load Balancer
Webnode AWebnode B
SQL Bestellungen & BestandRedis Sessions & LocksSearch SucheWorker asynchron
Was wir prüfen
Erst messen, dann umbauen.
- Request-Pfade trennen. Startseite, Kategorie, Produkt, Suche, eingeloggter Kunde, Cart und Checkout separat messen.
- Zustand kartieren. Wo liegen Session, Cart-Kontext, Cache und Locks heute? Was passiert bei einem Node-Wechsel?
- Hintergrundarbeit isolieren. Indexierung, Queue-Worker, Import und Cron dürfen nicht unbemerkt den Checkout verdrängen.
- Lastfähigkeit beweisen. Erst danach Caching, Managed Services oder weitere Webnodes kontrolliert einführen.
Aus der Praxis
Ein schneller Cache kann trotzdem der falsche Fix sein.
In einem großen Shopware-Betrieb war anonyme Storefront-Auslieferung nach einem Cache-Tweak extrem schnell. Der Tweak wurde dennoch zurückgenommen, als die Warenkorb-Semantik nicht mehr belastbar war. Der richtige Maßstab ist nicht TTFB allein, sondern ein korrekter Commerce-Zustand unter Last.
Praxisfall lesenFAQ
Häufige Fragen zur Shopware-Performance.
Wie lässt sich Shopware-Performance sinnvoll optimieren?
Nicht mit einem einzelnen Schalter. Zuerst werden Storefront, eingeloggter Zustand, Warenkorb, Checkout und Hintergrundarbeit getrennt gemessen. Dann wird geklärt, ob PHP, Datenbank, Redis, Suche, Plugins oder Jobs den jeweiligen Pfad bremsen.
Warum wird ein Shopware-Shop langsam?
Häufig ist nicht ein einzelner Fehler schuld. PHP-Worker, Plugins, Datenbankabfragen, Suche, Medien, Hintergrundjobs und Cache-Verhalten treffen gleichzeitig aufeinander. Der erste Schritt ist eine Messung, die Storefront, Warenkorb, Checkout und Hintergrundarbeit getrennt betrachtet.
Braucht Shopware Redis?
Redis kann gemeinsam genutzten, flüchtigen Zustand übernehmen: Cache, Sessions und Locks. Entscheidend ist nicht das Schlagwort Redis, sondern eine klare Zuständigkeit. Was dauerhaft zu einer Bestellung oder einem Bestand gehört, bleibt in der führenden Datenbank.
Warum reichen mehr PHP-Worker nicht?
Mehr Worker helfen nur, solange Datenbank, Cache, Sessions und externe Dienste mithalten. Wenn mehrere Webserver dazukommen, müssen Sessions, Cart-Kontext und Locks bewusst geteilt werden. Sonst entstehen verlorene Warenkörbe, doppelte Arbeit oder schwer erklärbare Fehler.
Wann ist ein zweiter Shopware-Webserver sinnvoll?
Wenn die Lastmessung zeigt, dass die Storefront an PHP-Kapazität oder einzelnen Maschinen scheitert – und der Zustand bereits sauber ausgelagert ist. Ein Load Balancer vor zwei identischen Servern ist kein Fix für lokale Sessions oder konkurrierende Hintergrundjobs.
Ihr Shop wird bei Last langsam oder unberechenbar?