Teil unserer Performance & Scalability-Serie
Den vollständigen Leitfaden lesenBelastungstest Ihrer E-Commerce-Plattform: Vorbereitung auf den Black Friday-Verkehr
Shopify berichtete, dass Händler am Black Friday/Cyber Monday 2024 insgesamt einen Umsatz von 9,3 Milliarden US-Dollar erzielten – und jede Minute Ausfallzeit während dieser 96 Stunden kostete Tausende an Umsatzeinbußen. Lasttests machen den Unterschied zwischen einer Plattform, die sich bei Spitzenlasten reibungslos skaliert, und einer Plattform, die im schlimmsten Moment abstürzt. Doch die meisten Unternehmen entdecken den Bruchpunkt ihrer Plattform erst während des tatsächlichen Ereignisses und nicht während des Testens.
Wichtige Erkenntnisse
- Belastungstest mit realistischen Verkehrsmustern, nicht nur mit rohen Anfragezahlen – modellieren Sie tatsächliche Benutzerreisen vom Surfen bis zum Bezahlen
- Beginnen Sie 8–12 Wochen vor Spitzenereignissen mit dem Lasttest, um Zeit für Infrastrukturänderungen und Codeoptimierung zu haben
- Identifizieren Sie Engpässe schrittweise: Steigen Sie von der Grundlinie auf das Zweifache des erwarteten Spitzenwerts und testen Sie jede Schicht einzeln
- Die Analyse nach dem Test ist genauso wichtig wie der Test selbst – korrelieren Sie Antwortzeiten mit Infrastrukturmetriken, um die wahre Einschränkung zu finden
Vergleich der Auslastungstest-Tools
Die Wahl des richtigen Lasttest-Tools hängt von den technischen Fähigkeiten, der Infrastruktur und den Testanforderungen Ihres Teams ab.
| Werkzeug | Sprache | Protokollunterstützung | Skripterstellung | Cloud-Ausführung | Am besten für |
|---|---|---|---|---|---|
| k6 (Grafana) | JavaScript | HTTP, WebSocket, gRPC | JavaScript ES6 | Grafana-Wolke, k6-Wolke | Entwicklerfreundlich, CI/CD-Integration |
| Artillerie | JavaScript | HTTP, WebSocket, Socket.io | YAML + JavaScript | Artilleriewolke | Schnelle Einrichtung, YAML-basierte Szenarien |
| Heuschrecke | Python | HTTP (erweiterbar) | Python | Verteilter Modus | Python-Teams, komplexe Szenarien |
| JMeter | Java | HTTP, JDBC, FTP, LDAP | GUI + XML | BlazeMeter, OctoPerf | Legacy-Systeme, Protokollvielfalt |
| Gatling | Scala | HTTP, WebSocket | Scala DSL | Gatling Enterprise | Leistungsstarke, detaillierte Berichte |
| Dramatiker (laden) | JavaScript | Vollständiger Browser | JavaScript | CI-Läufer | Testen von JavaScript-lastigen SPAs |
k6: Empfohlen für die meisten Teams
k6 ist unser empfohlenes Tool für die meisten E-Commerce-Lasttests. Es verwendet JavaScript für Testskripte, lässt sich in CI/CD-Pipelines integrieren und erstellt detaillierte Metriken, einschließlich Antwortzeitperzentilen, Durchsatz und Fehlerraten. Es läuft lokal oder in der Cloud und seine Ausgabe lässt sich zur Echtzeitüberwachung in Grafana-Dashboards integrieren.
k6-Tests definieren virtuelle Benutzer (VUs), die Szenarien ausführen – Sequenzen von HTTP-Anfragen, die Benutzerverhalten simulieren. Jede VU behält ihren eigenen Sitzungsstatus (Cookies, Header) bei und ermöglicht so realistische authentifizierte Arbeitsabläufe.
Artillerie: Am besten für eine schnelle Einrichtung geeignet
Artillery verwendet eine YAML-basierte Konfiguration für gängige Szenarien und unterstützt JavaScript für komplexe Logik. Es eignet sich hervorragend für Schnellstart-Lasttests, bei denen Sie Ergebnisse innerhalb von Minuten statt stundenlanger Skripterstellung benötigen. Es bietet außerdem native Unterstützung für Socket.io- und WebSocket-Tests.
Modellierung realistischer Verkehrsmuster
Der größte Fehler beim Lasttest besteht darin, einheitlichen Datenverkehr zu senden, der nicht dem tatsächlichen Benutzerverhalten entspricht. Echter Datenverkehr weist spezifische Muster auf, die unterschiedliche Engpässe aufdecken.
User Journey-Modellierung
Ein E-Commerce-Auslastungstest sollte vollständige Benutzerreisen modellieren, nicht nur einzelne Endpunkttreffer. Ein realistischer Test umfasst folgende Benutzertypen mit entsprechenden Verhältnissen:
| Benutzertyp | Verkehrsanteil | Reise |
|---|---|---|
| Browser | 60-70 % | Startseite, Kategorieseiten, Produktseiten, Suche |
| Vergleichskäufer | 15-20 % | Produktseiten, zum Warenkorb hinzufügen, Warenkorb anzeigen, verlassen |
| Käufer | 8-12 % | Durchsuchen, in den Warenkorb legen, zur Kasse gehen, bezahlen |
| Wiederkehrende Kunden | 5-10 % | Login, Bestellhistorie, Nachbestellung, Kasse |
| API-Integrationen | 2-5 % | Inventarsynchronisierung, Bestellexport, Webhook-Verarbeitung |
Verkehrsrampenmuster
Springen Sie nicht direkt zur Spitzenlast. Steigen Sie schrittweise an, um Bruchstellen zu identifizieren.
Anlaufmuster für Black-Friday-Tests:
- Grundlinie (0–10 Minuten) – Beginnen Sie mit dem normalen täglichen Datenverkehr, um die Leistungsgrundlinie festzulegen
- Anstieg auf den erwarteten Spitzenwert (10–30 Minuten) – allmählicher Anstieg auf den erwarteten Black-Friday-Verkehr
- Spitzenlast aufrechterhalten (30–60 Minuten) – Spitzenlast aufrechterhalten, um anhaltende Leistung und Ressourcenlecks zu testen
- Spike-Test (60–70 Minuten) – Simulieren Sie den Start des Flash-Sales mit einer 3-5-fachen Traffic-Spitze über 30 Sekunden
- Wiederherstellung (70–80 Minuten) – kehren Sie zur normalen Last zurück und überprüfen Sie, ob sich das System ohne manuelles Eingreifen erholt
- Soak-Test (separater Lauf, 4–8 Stunden) – anhaltende moderate Belastung, um Speicherlecks und Erschöpfung des Verbindungspools zu erkennen
Denken Sie an Zeit und Tempo
Echte Benutzer senden Anfragen nicht so schnell wie möglich. Sie lesen Inhalte, vergleichen Produkte und füllen Formulare aus. Planen Sie realistische Bedenkzeiten zwischen den Anfragen ein:
- Zwischen Seitenaufrufen: 5–30 Sekunden
- Ausfüllen des Checkout-Formulars: 30–120 Sekunden
- Produktbeschreibungen lesen: 10-60 Sekunden
- Suchen und Filtern: 3-10 Sekunden zwischen den Aktionen
Ohne Bedenkzeit erzeugt Ihr Test eine unrealistisch konzentrierte Last, die nicht den Produktionsverkehrsmustern entspricht.
Identifizierung von Engpässen
Auslastungstests offenbaren Engpässe, aber Sie müssen wissen, wo Sie suchen müssen. Überwachen Sie Infrastrukturmetriken zusammen mit Testergebnissen, um die Verschlechterung der Reaktionszeit mit der Erschöpfung der Ressourcen zu korrelieren.
Datenbankengpässe
Symptome: Die Antwortzeiten steigen linear mit der Auslastung, die Datenbank-CPU liegt bei über 90 % und das langsame Abfrageprotokoll füllt sich schnell
Häufige Ursachen:
- Fehlende Indizes für häufig abgefragte Spalten – N+1 Abfragen, die sich mit gleichzeitigen Benutzern vervielfachen
- Blockieren Sie Konflikte bei Bestandsaktualisierungen während des Bezahlvorgangs
- Erschöpfung des Verbindungspools (alle Verbindungen werden verwendet, Warteschlange für neue Anfragen)
Diagnose: Überwachen Sie pg_stat_activity auf aktive Abfragen, pg_stat_user_tables auf die Anzahl sequenzieller Scans und Verbindungspoolmetriken. Sehen Sie sich unseren ausführlichen Leitfaden zur Datenbankabfrageoptimierung an.
Anwendungsserver-Engpässe
Symptome: Die CPU-Auslastung steigt auf 100 %, die Verzögerung der Ereignisschleife nimmt zu (Node.js), Garbage-Collection-Pausen verursachen Latenzspitzen
Häufige Ursachen:
- Synchrone Operationen, die die Ereignisschleife blockieren (Bildverarbeitung, PDF-Generierung)
- Speicherlecks führen zu einer immer häufigeren Speicherbereinigung – Unzureichende Arbeitsprozesse für CPU-gebundene Vorgänge
- Fehlendes Caching für teure Berechnungen
Diagnose: Überwachen Sie CPU-, Speicher-, Ereignisschleifenverzögerungs- und Garbage-Collection-Metriken pro Anwendungsinstanz.
Netzwerk- und Infrastrukturengpässe
Symptome: Bandbreitensättigung, Verbindungszeitüberschreitungen, SSL-Handshake-Verzögerungen unter Last
Häufige Ursachen: – Unkomprimierte Antworten verbrauchen Bandbreite – Statische Assets werden vom Anwendungsserver statt vom CDN bereitgestellt – SSL/TLS-Terminierung auf dem Anwendungsserver anstelle des Load Balancers – Unzureichende Netzwerkbandbreite für den Serverinstanztyp
Kapazitätsplanung
Lasttests fließen in die Kapazitätsplanung ein und bestimmen, wie viel Infrastruktur Sie für Spitzenereignisse benötigen.
Die Kapazitätsplanungsformel
- Bestimmen Sie die Spitzenverkehrserwartung – verwenden Sie die Daten des letzten Jahres plus Wachstumsprognosen. Wenn dies Ihr erster großer Verkauf ist, schätzen Sie dies anhand der Marketingreichweite und Branchen-Benchmarks
- Sicherheitsspielraum hinzufügen – Planen Sie das Zwei- bis Dreifache des erwarteten Spitzenwerts ein, um unerwarteten viralen Datenverkehr zu bewältigen
- Führen Sie einen Lasttest mit der Zielkapazität durch – überprüfen Sie, ob Ihre Infrastruktur 2-3-fache Spitzenlasten mit akzeptablen Reaktionszeiten bewältigt
- Kosten berechnen – Ermitteln Sie die Infrastrukturkosten für Spitzenkapazitäten und entscheiden Sie, ob automatische Skalierung oder Vorabbereitstellung kosteneffizienter ist
Checkliste vor der Skalierung
Beginnen Sie 8–12 Wochen vor der Veranstaltung mit der Vorbereitung:
| Zeitleiste | Aktion |
|---|---|
| 8-12 Wochen vorher | Führen Sie einen Basislasttest durch und identifizieren Sie die fünf größten Engpässe |
| 6-8 Wochen vorher | Optimierungen implementieren (Caching, Abfragekorrekturen, Codeänderungen) |
| 4-6 Wochen vorher | Lasttest bei erwarteter Spitze durchführen, Verbesserungen überprüfen |
| 2-4 Wochen vorher | Führen Sie einen Lasttest mit 2–3-fachem Spitzenwert durch und planen Sie die Skalierung der Infrastruktur |
| 1 Woche vorher | Infrastruktur vorskalieren, abschließenden Validierungstest durchführen |
| Veranstaltungstag | Dashboards überwachen, Rollback-Pläne bereithalten |
Automatische Skalierung vs. Vorbereitstellung
Die automatische Skalierung passt die Kapazität basierend auf Bedarfsmetriken an, das Hinzufügen neuer Instanzen dauert jedoch 3–10 Minuten. Bei plötzlichen Traffic-Spitzen (Beginn eines Flash-Sales, viraler Social-Media-Beitrag) vermeidet die Vorabbereitstellung Verzögerungen.
Empfohlener Ansatz: Stellen Sie vorab bereit, um erwartete Spitzen zu bewältigen, und konfigurieren Sie die automatische Skalierung für unerwartete Spitzen über die vorab bereitgestellte Kapazität hinaus.
Post-Test-Analyse
Der Belastungstest selbst ist nur halb so wertvoll. Die Analyse nach dem Test verwandelt Rohdaten in umsetzbare Optimierungsprioritäten.
Zu analysierende Schlüsselmetriken
| Metrisch | Worauf Sie achten sollten |
|---|---|
| P95 Reaktionszeit | Sollte bei Spitzenlast unter 500 ms bleiben |
| P99 Reaktionszeit | Sollte unter 2 Sekunden bleiben – die Endlatenz wirkt sich auf Ihre aktivsten Benutzer aus |
| Fehlerquote | Sollte unter 0,1 % bleiben – jeder höhere Wert deutet auf Kapazitätsprobleme hin |
| Durchsatzobergrenze | Die Anfragen/Sekunde, bei denen sich die Antwortzeit zu verschlechtern beginnt |
| Erholungszeit | Wie schnell normalisieren sich die Antwortzeiten nach einem Anstieg |
| Ressourcennutzung | CPU, Speicher, Verbindungen auf Hochtouren – was erreicht zuerst die Obergrenze? |
Erstellen eines Aktionsplans
Priorisieren Sie die Ergebnisse nach geschäftlicher Auswirkung:
- Fehler in Spitzenzeiten – jede Anfrage, die unter Last 5xx zurückgibt, muss behoben werden. Das sind entgangene Umsätze.
- Checkout-Leistung – wenn die Reaktionszeit beim Checkout 2 Sekunden überschreitet, optimieren Sie zuerst diesen Pfad. Langsamer Checkout wirkt sich direkt auf die Conversion aus.
- Such- und Browsing-Leistung – eine langsame Produkterkennung reduziert die angezeigten Artikel und die Warenkorbgröße.
- Verwaltung und Backoffice – diese können sich in Spitzenzeiten verschlechtern, ohne dass sich dies auf den Umsatz auswirkt. Priorisieren Sie ggf. die Prioritäten.
Häufig gestellte Fragen
Wie teste ich einen Shopify-Shop unter Last, wenn ich die Infrastruktur nicht kontrolliere?
Konzentrieren Sie sich auf das, was Sie kontrollieren: Ihren benutzerdefinierten Theme-Code, Apps von Drittanbietern und externe Integrationen. Verwenden Sie Tools wie Lighthouse CI für Frontend-Leistungstests. Testen Sie Ihre Webhook-Verarbeitungsendpunkte und Inventarsynchronisierungs-APIs unter Last. Für Shopify Plus-Händler: Arbeiten Sie mit dem Händlererfolgsteam von Shopify zusammen, um die Kapazität für Ihren spezifischen Shop zu überprüfen.
Was ist der Unterschied zwischen Lasttests und Stresstests?
Durch Auslastungstests wird überprüft, ob Ihr System den erwarteten Spitzenverkehr mit akzeptabler Leistung bewältigt. Stresstests gehen über die erwarteten Grenzen hinaus, um den Bruchpunkt zu finden und eine ordnungsgemäße Verschlechterung zu überprüfen. Belastungstest zur Vorbereitung auf bekannte Ereignisse; Stresstest, um unbekannte Grenzen zu entdecken und sicherzustellen, dass das System sicher und nicht katastrophal ausfällt.
Sollte ich den Test in der Produktion oder im Staging ausführen?
Testen Sie in einer Umgebung, die der Produktion möglichst nahe kommt. Staging-Umgebungen verfügen oft über kleinere Datenbanken, weniger Server und unterschiedliche Netzwerkkonfigurationen. Führen Sie nach Möglichkeit Auslastungstests für die Produktionsinfrastruktur zu Zeiten mit geringem Datenverkehr durch. Verwenden Sie in Ihrer Staging-Datenbank mindestens Daten in Produktionsgröße.
Wie simuliere ich eine realistische Zahlungsabwicklung in Lasttests?
Verwenden Sie Sandbox-/Testmodi des Zahlungsanbieters, die Testkartennummern akzeptieren. Stripe, PayPal und andere Anbieter bieten Testumgebungen an, die Transaktionen abwickeln, ohne echte Karten zu belasten. Testen Sie den gesamten Checkout-Ablauf einschließlich Zahlungs-API-Aufrufen, um Integrationsengpässe zu identifizieren. Überwachen Sie die Ratenlimits der Zahlungsanbieter – einige Anbieter drosseln Sandbox-Anfragen anders als in der Produktion.
Wie oft sollte ich Lasttests durchführen?
Führen Sie vor jedem größeren Verkehrsereignis (Black Friday, Produkteinführungen, Marketingkampagnen) umfassende Belastungstests durch. Führen Sie wöchentlich oder nach wesentlichen Codeänderungen im Rahmen von CI/CD automatisierte kleinere Lasttests durch. Beziehen Sie Lasttests in Ihre Bereitstellungscheckliste ein, um Änderungen zu erkennen, die sich auf Endpunkte mit hohem Datenverkehr auswirken.
Was kommt als nächstes?
Beginnen Sie mit einem Basislasttest anhand Ihrer aktuellen Produktionsverkehrsmuster. Identifizieren Sie Ihre drei größten Engpässe und optimieren Sie sie, bevor Sie den nächsten Test durchführen. Wiederholen Sie diesen Zyklus, bis Ihre Plattform das Zwei- bis Dreifache des erwarteten Spitzenverkehrs mit Reaktionszeiten unter 500 ms problemlos bewältigen kann.
Informationen zum breiteren Performance-Engineering-Kontext finden Sie in unserem Säulenleitfaden zum Thema „Skalierung Ihrer Geschäftsplattform“ (/blog/scaling-business-platform-performance). Um die von Ihren Lasttests beanspruchte Infrastruktur zu optimieren, lesen Sie unseren Leitfaden zu Infrastrukturskalierung und Lastausgleich.
ECOSIRE bietet Lasttests und Leistungsoptimierung für E-Commerce-Plattformen auf Shopify und Odoo. Kontaktieren Sie unser Team für die Vorbereitung Ihres Auftritts vor der Veranstaltung.
Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.
Geschrieben von
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
Skalieren Sie Ihren Shopify-Shop
Maßgeschneiderte Entwicklungs-, Optimierungs- und Migrationsdienste für wachstumsstarken E-Commerce.
Verwandte Artikel
KI-Content-Generierung für E-Commerce: Produktbeschreibungen, SEO und mehr
Skalieren Sie E-Commerce-Inhalte mit KI: Produktbeschreibungen, SEO-Meta-Tags, E-Mail-Texte und soziale Medien. Qualitätskontrollrahmen und Leitfaden zur Konsistenz der Markenstimme.
KI-gestützte dynamische Preisgestaltung: Optimieren Sie den Umsatz in Echtzeit
Implementieren Sie die dynamische KI-Preisgestaltung, um den Umsatz durch Nachfrageelastizitätsmodellierung, Wettbewerbsüberwachung und ethische Preisstrategien zu optimieren. Leitfaden zu Architektur und ROI.
KI-Betrugserkennung für E-Commerce: Schützen Sie Ihren Umsatz, ohne den Verkauf zu blockieren
Implementieren Sie eine KI-Betrugserkennung, die mehr als 95 % der betrügerischen Transaktionen erkennt und gleichzeitig die Falsch-Positiv-Rate unter 2 % hält. ML-Bewertung, Verhaltensanalyse und ROI-Leitfaden.
Mehr aus Performance & Scalability
Webhook-Debugging und -Überwachung: Der vollständige Leitfaden zur Fehlerbehebung
Beherrschen Sie das Webhook-Debugging mit diesem vollständigen Leitfaden, der Fehlermuster, Debugging-Tools, Wiederholungsstrategien, Überwachungs-Dashboards und Best Practices für die Sicherheit abdeckt.
k6-Lasttest: Führen Sie vor dem Start einen Stresstest für Ihre APIs durch
Master-K6-Lasttests für Node.js-APIs. Behandelt das Hochfahren virtueller Benutzer, Schwellenwerte, Szenarien, HTTP/2, WebSocket-Tests, Grafana-Dashboards und CI-Integrationsmuster.
Nginx-Produktionskonfiguration: SSL, Caching und Sicherheit
Nginx-Produktionskonfigurationsleitfaden: SSL-Terminierung, HTTP/2, Caching-Header, Sicherheits-Header, Ratenbegrenzung, Reverse-Proxy-Einrichtung und Cloudflare-Integrationsmuster.
Odoo Performance Tuning: PostgreSQL und Serveroptimierung
Expertenleitfaden zur Leistungsoptimierung von Odoo 19. Behandelt PostgreSQL-Konfiguration, Indizierung, Abfrageoptimierung, Nginx-Caching und Serverdimensionierung für Unternehmensbereitstellungen.
Odoo vs Acumatica: Cloud ERP für wachsende Unternehmen
Odoo vs. Acumatica im Vergleich für 2026: einzigartige Preismodelle, Skalierbarkeit, Fertigungstiefe und welches Cloud-ERP zu Ihrem Wachstumskurs passt.
Testen und Überwachen von KI-Agenten in der Produktion
Eine vollständige Anleitung zum Testen und Überwachen von KI-Agenten in Produktionsumgebungen. Behandelt Bewertungsrahmen, Beobachtbarkeit, Abweichungserkennung und Reaktion auf Vorfälle für OpenClaw-Bereitstellungen.