Lastspitzen im Shop: Vorbereitung und Lasttest

Ein Aktionstag verändert den Lastverlauf, nicht nur die Menge. Die Bestellungen kommen in einer Spitze, dieselben Produktseiten werden gleichzeitig aufgerufen, und jede Bestellung löst Aufrufe aus, die den Shop selbst erreichen. Ein Test mit eigenen Zahlen zeigt vorher, wie sich der Shop unter der erwarteten Last verhält.

Was Sie vorab brauchen

• Bestell- und Zugriffszahlen des letzten vergleichbaren Aktionstags, aufgeschlüsselt nach Stunden
• eine Nachbildung des Shops mit derselben Softwareversion, denselben Erweiterungen und einem ähnlich großen Datenbestand
• Testdaten ohne echte Kundendaten
• zwei Zielwerte: die Last, die der Shop halten soll, und die Antwortzeit, die Sie zulassen
• die Vertragsunterlagen von Hoster, Zahlungsdienst und Versand mit zugesagter Reaktionszeit, Mengengrenzen und Wartungsfenstern
• ein benanntes Zeitfenster außerhalb des Verkaufs und eine Person, die den Test abbricht

Schritt für Schritt: Vom Lastprofil zum getesteten Aktionstag

Schritt 1: Lastprofil aus Ihren Zahlen berechnen

Das Lastprofil ist das erwartete Nutzungsmuster Ihres Shops; das ISTQB-Glossar nennt es operational profile. Rechnen Sie es aus eigenen Werten, nicht aus einer allgemeinen Annahme: Bestellungen der stärksten Stunde und die Aufrufe, die je Bestellung auf Ihren Systemen ankommen.

Beispielrechnung: In der stärksten Stunde des letzten Aktionstags zählten Sie 1.200 Bestellungen. Je Bestellung erreichen 14 Aufrufe von Kategorie- und Produktseiten und 3 Aufrufe in Warenkorb und Bezahlvorgang den Shop selbst; Bilder und Skripte beantwortet der Zwischenspeicher.

Größe	Rechnung	Wert
Bestellungen in der stärksten Stunde	Beispielwert	1.200
Aufrufe je Bestellung im Shop	14 + 3	17
Aufrufe in der Stunde	1.200 × 17	20.400
Aufrufe je Sekunde im Mittel	20.400 ÷ 3.600	5,7
Ziellast mit Spitzenfaktor 3	5,7 × 3	17,1
Planwert für den Test (redaktionelle Reserve)	17,1 auf 20 aufgerundet	20
Bestellungen je Sekunde an der Spitze	1.200 ÷ 3.600 × 3	1,0

Zwei Werte tragen den weiteren Plan: 20 Aufrufe je Sekunde als Ziellast und 1 Bestellung je Sekunde für die Kaufstrecke. Die Aufrundung von 17,1 auf 20 ist eine Reserveentscheidung der Redaktion und kein Rechenergebnis: Rechnerisch trägt der Spitzenfaktor 3 genau 17,1 Aufrufe je Sekunde. Prüfen Sie das Profil gegen die Protokolle: Wie verteilten sich die Aufrufe über die Stunde, und welcher Anteil traf den Shop statt des Zwischenspeichers? Dieser Anteil entscheidet, welche Last Ihr System wirklich sieht.

Schritt 2: Szenarien und Abbruchkriterien festlegen

Die Szenarien folgen den Testarten des ISTQB-Glossars: Der Lasttest (load testing) prüft das Verhalten unter schwankender Last zwischen niedrigem, typischem und stärkstem Aufkommen, der Stresstest (stress testing) geht über die geplante Last hinaus oder verknappt Ressourcen wie Arbeitsspeicher, der Dauerlasttest (endurance testing) prüft die Stabilität unter erheblicher Last über einen längeren Zeitraum, und der Lastsprung-Test (spike testing) prüft die Erholung nach plötzlichen Spitzen.

Szenario	Lastverlauf	Was Sie damit prüfen	Abbruch, wenn
Referenzlauf	25 Prozent der Ziellast, 10 Minuten	Messpunkte, Fehlerbilder, Grundrauschen	ein Fehler ohne Last auftritt
Peak-Stunde	Ziellast, 60 Minuten halten	Verhalten über die längste erwartete Spitze	eine Schwelle aus Schritt 3 reißt
Aktionsstart – Spitzenphase	von 0 auf dreifache Ziellast in 60 Sekunden, 10 Minuten halten	Verhalten unter einem plötzlichen Sprung	die Antwortzeit länger als eine Minute über 5 Sekunden liegt
Aktionsstart – Erholung	Last auf die Prüflast des Referenzlaufs zurücknehmen (25 Prozent der Ziellast) und halten, bis der Rückstand abgebaut ist	Rückkehr in den stabilen Zustand bei weiter laufender Messung	p95 oder p99 bleibt über der Schwelle, oder der Rückstand wächst weiter
Kaufstrecke	Last nur auf Warenkorb und Bezahlvorgang, 1 Bestellung je Sekunde	Nebenläufigkeit, Sperren, doppelte Vorgänge	eine Bestellung verloren geht oder doppelt entsteht
Dauerlast	Ziellast, 4 Stunden	Speicher, Sitzungen, Verbindungen, Protokolldateien	die Antwortzeit über den Lauf hinweg ansteigt
Stresstest	Last in Stufen steigern	die Grenze und das Verhalten an der Grenze	die Testumgebung selbst abbricht

Die Laufzeiten, Laststufen und Faktoren sind redaktionelle Beispielwerte, ebenso die Zuordnung der Schwellen zu den Szenarien. Übernehmen Sie die Zahlen Ihres Aktionstags: Eine Aktion über zwei Stunden braucht ein anderes Dauerlast-Szenario als eine Woche mit Rabatt.

Schritt 3: Schwellen für bestanden und nicht bestanden setzen

Schreiben Sie vor dem ersten Lauf auf, welche Zahl an welchem Messpunkt als bestanden gilt. Welche Kennzahlen Sie wählen, ist eine redaktionelle Entscheidung dieses Artikels: Der BSI-Baustein OPS.1.1.6 (Edition 2023) nennt keine Kennzahlen, sondern verlangt in A3, dass die Ergebnisse ausgewertet, mit definierten Vorgaben verglichen (Soll-Ist-Vergleich) und dokumentiert werden; A10 sieht einen Abnahmeplan mit den erwarteten Ergebnissen und den Freigabekriterien vor. Ein Lauf ohne messbare Vorgabe lässt sich nur subjektiv beurteilen; der ISTQB-Lehrplan Performance Testing nennt genau das als Projektrisiko (Abschnitt 2.1.1). Beide BSI-Anforderungen sind Empfehlungen und binden nur, wenn Gesetz oder Vertrag auf sie verweisen.

Kennzahl	Bezug	Beispielschwelle	Bewertung
Erfolgreicher Durchsatz	erfolgreich beantwortete Aufrufe je Sekunde, ohne 429 und 503	die im Szenario gefahrene Last durchgehend gehalten (Zielwert je Szenario, siehe Zuordnung unten)	bestanden
Abgeschlossene Abläufe	jeder Ablauf aus dem Lastprofil (Kategorie, Produkt, Warenkorb, Bezahlvorgang)	alle Abläufe abgeschlossen	bestanden
Fehlerquote ohne 429 und 503	alle Aufrufe in der Messzeit	unter 0,5 Prozent	bestanden
Anteil 429 und 503	Anteil an allen Aufrufen in der Messzeit, in den Szenarien mit erwarteter Last	höchstens 0,1 Prozent	bestanden
Antwortzeit p95	Produktseite und Warenkorb, von außen gemessen, nur erfolgreiche Antworten	höchstens 1,5 Sekunden	bestanden
Antwortzeit p99	Bezahlvorgang, nur erfolgreiche Antworten	höchstens 3,0 Sekunden	bestanden
Bestellungen	Kaufstrecke	keine verlorene, keine doppelte	bestanden
Retry-After	jede 429- und jede 503-Antwort	Kopf nennt eine Wartezeit	Beobachtung, kein Bestehenskriterium
Rückstand bei Testende	Warteschlangen und Auftragsübergabe	in 15 Minuten abgebaut	bestanden

Erfüllt der Lauf eine Zeile, ist sie bestanden; reißt er sie, ist sie nicht bestanden, und die Ursache wird vor dem Aktionstag behoben oder mit einer bewussten Entscheidung festgehalten.

Welche Zeilen für welches Szenario gelten und welche Last der erfolgreiche Durchsatz treffen muss, hängt davon ab, wie viel Last das Szenario fährt. Der Referenzlauf läuft mit 25 Prozent der Ziellast, die Kaufstrecke mit 1 Bestellung je Sekunde auf Warenkorb und Bezahlvorgang: Für sie gilt der Durchsatz gegen die im Szenario gefahrene Last, nicht gegen den Planwert von 20 Aufrufen je Sekunde. Diese Zuordnung ist eine redaktionelle Entscheidung des Artikels:

Szenario	Durchsatzziel	Anzuwendende Zeilen
Referenzlauf	5 Aufrufe je Sekunde (25 Prozent der Ziellast von 20)	Fehlerquote ohne 429 und 503, Anteil 429 und 503, p95, p99, abgeschlossene Abläufe
Peak-Stunde	20 Aufrufe je Sekunde (Ziellast)	alle Bewertungszeilen
Aktionsstart – Spitzenphase	60 Aufrufe je Sekunde (dreifache Ziellast)	abgeschlossene Abläufe, Fehlerquote ohne 429 und 503 und Bestellungen; p95 und p99 werden beobachtet, abgebrochen wird bei einer Antwortzeit über 5 Sekunden für mehr als eine Minute; 429 und 503 sind zulässig und werden gezählt (Anteil, Retry-After)
Aktionsstart – Erholung	5 Aufrufe je Sekunde (Prüflast, 25 Prozent der Ziellast) bis zum Ende der Messung	p95 und p99 gegen die Prüflast gemessen wieder innerhalb der Schwellen, Rückstand bei Testende in 15 Minuten abgebaut, Bestellungen ohne Verlust und Dopplung
Kaufstrecke	1 Bestellung je Sekunde auf Warenkorb und Bezahlvorgang	Bestellungen, p99 Bezahlvorgang, Fehlerquote; der Aufruf-Durchsatz wird hier nicht gegen 20 Aufrufe je Sekunde geprüft
Dauerlast	20 Aufrufe je Sekunde über 4 Stunden	Fehlerquote ohne 429 und 503, Anteil 429 und 503, p95, p99, abgeschlossene Abläufe
Stresstest	Last in Stufen über die Ziellast hinaus	keine Bestehensregel; festhalten, ab welcher Last Abweisungen einsetzen, ob die Antwort einen Retry-After-Kopf trägt und ob sich der Shop danach erholt

Als bestanden gilt ein Lauf mit erwarteter Last (Referenzlauf, Peak-Stunde, Kaufstrecke, Dauerlast) nur, wenn jede für dieses Szenario anzuwendende Zeile bestanden ist. Entscheidend ist der erfolgreiche Durchsatz: Ein Lauf, der die im Szenario gefahrene Last allein mit 429- oder 503-Antworten erreicht, ist nicht bestanden, denn die Anfragen kamen an, wurden aber abgewiesen.

Der Lastsprung (Aktionsstart) wird in zwei Phasen bewertet. In der Spitzenphase fahren Sie bewusst das Dreifache der Ziellast. 429 und 503 sind dort zulässig; sie zeigen die Lastabgabe an und werden gezählt, nicht als Verstoß gegen die Bestehensregel gewertet. Ein Absturz ohne Antwort, eine verlorene oder doppelte Bestellung und eine Antwortzeit, die länger als eine Minute über 5 Sekunden liegt, brechen ab. In der Erholungsphase nehmen Sie die Last auf die Prüflast des Referenzlaufs zurück (25 Prozent der Ziellast, 5 Aufrufe je Sekunde) und lassen sie bis zum Ende der Messung an. Ohne Anfragen entstehen keine Antwortzeitmesswerte, und verbleibende Antworten aus der Spitzenphase belegen keine Erholung. Gemessen gegen die Prüflast müssen p95 und p99 wieder innerhalb der Schwellen liegen, der Rückstand in 15 Minuten abgebaut sein und keine Bestellung verloren gehen oder doppelt entstehen. Das entspricht der Definition des Lastsprungs im ISTQB-Glossar (spike testing): die Fähigkeit, sich nach plötzlichen Spitzen zu erholen und in einen stabilen Zustand zurückzukehren. Bleiben p95 oder p99 über der Schwelle oder wächst der Rückstand weiter, gilt der Lastsprung als nicht bestanden.

Der Stresstest wird getrennt bewertet. Dort steigern Sie die Last absichtlich über die Grenze; 429 und 503 sind dort das erwartete Ergebnis und keine Verletzung der Bestehensregel. Halten Sie für ihn fest, bei welcher Last die Abweisungen einsetzen, ob die Antwort einen Retry-After-Kopf trägt und ob sich der Shop nach dem Ende der Last wieder erholt. Die Zeile zu Retry-After ist in allen Läufen eine Beobachtung, keine Bestehensregel.

Der p95-Wert ist die Antwortzeit, die 95 von 100 Messungen nicht überschreiten; die langsamsten 5 Prozent liegen darüber. Ein Mittelwert verdeckt genau diese Aufrufe, und ein abgebrochener Kauf steht dort; der ISTQB-Lehrplan Performance Testing hält fest, dass der Durchschnitt durch Ausreißer verzerrt wird und dass ein Perzentil für die Bewertung aussagekräftiger ist (Abschnitt 4.4). Führen Sie deshalb mindestens p95 und p99.

Die beiden Statuscodes gehören getrennt gezählt und mit einem eigenen Grenzwert bewertet. 429 zeigt nach RFC 6585 Abschnitt 4 an, dass zu viele Anfragen in einem Zeitraum eingegangen sind (Rate Limiting); 503 zeigt nach RFC 9110 Abschnitt 15.6.4 an, dass der Server wegen vorübergehender Überlast oder geplanter Wartung gerade nicht antworten kann. Beide dürfen einen Retry-After-Kopf tragen, der die Wartezeit nennt (RFC 9110 Abschnitt 10.2.3). Beide Antworten zeigen damit eine Grenze an; ein Lauf mit erwarteter Last, in dem die im Szenario gefahrene Last nur so erreicht wird, ist nicht bestanden. Trägt eine solche Antwort keinen Retry-After-Kopf, fehlt der Hinweis, wie lange der Client warten soll.

Schritt 4: Lasttest auf einer Nachbildung fahren

Testen Sie nicht im Verkaufsbetrieb. Der BSI-Baustein OPS.1.1.6 (Edition 2023) verlangt eigene Tests für nichtfunktionale Anforderungen (A5), sieht vor, Software nur in einer dafür vorgesehenen, von der Produktivumgebung getrennten Testumgebung zu testen (A13), und verlangt für funktionale Tests, dass sie den Produktivbetrieb nicht beeinflussen (A2); A11 verlangt für Produktivdaten mit schützenswerten Informationen einen angemessenen Schutz und mindestens pseudonymisierte Daten, wenn diese personenbezogene Informationen enthalten. Auch das sind BSI-Empfehlungen und keine Gesetzespflichten. Praktisch heißt das: eigener Testshop, Kopie des Katalogs, keine echten Adressen, keine echten Bestellungen.

Fahren Sie den Test außerdem nicht aus dem eigenen Netz. Sonst messen Sie Ihre Internetanbindung und die Strecke zum Server. Erzeugen Sie die Last aus mehreren entfernten Orten und messen Sie jeden Aufruf von dort.

Halten Sie den Lauf ruhig: Rampe über einige Minuten, dann die Ziellast über die volle Zeit, dann eine Auslaufphase. Wiederholen Sie jeden Lauf mindestens einmal mit denselben Einstellungen und ändern Sie zwischen zwei Läufen nur eine Sache. Prüfen Sie vorher, dass der Test keine produktiven Nebenwirkungen erzeugt: Testbestellungen dürfen keine Rechnung, keinen Versandauftrag und keine Echtzahlung auslösen. Hängen Warenwirtschaft, Versand und Zahlung am Testshop, ersetzen Sie sie durch Attrappen oder schalten Sie sie in den Testmodus.

Vorsicht bei automatischen Wiederholungen. Nach RFC 9110 Abschnitt 9.2.2 soll ein Client eine Anfrage mit einer nicht-idempotenten Methode nicht ohne Weiteres wiederholen; zulässig ist die Wiederholung nur, wenn die mehrfache Ausführung denselben Effekt hat oder der Client erkennen kann, dass die erste Anfrage nie angewendet wurde, etwa über eine eindeutige Bestellnummer. Ohne diese Vorkehrung erzeugt ein Wiederholungsversuch mitten in der Spitze doppelte Bestellungen.

Schritt 5: Engpässe vor dem Aktionstag beheben

Arbeiten Sie die Messwerte von der Grenze her ab, nicht nach Gefühl.

In einen gemeinsamen Zwischenspeicher dürfen nur Antworten, die dafür geeignet und freigegeben sind – typischerweise statische und selten geänderte Inhalte wie Bilder, Skripte und Stylesheets. RFC 9111 Abschnitt 3 nennt die Bedingungen: Ein geteilter Zwischenspeicher darf eine Antwort mit dem Direktiv private nicht speichern, eine Antwort mit no-store gar nicht, und eine Antwort auf eine Anfrage mit Authorization-Kopf nur, wenn ein Direktiv die gemeinsame Speicherung ausdrücklich erlaubt; das sind s-maxage, must-revalidate und public (Abschnitt 3.5). Seiten mit Kundendaten und angemeldete Anfragen bleiben deshalb außen vor.

Für geeignete Antworten regelt RFC 9111 die Fristen: s-maxage setzt die Höchstzeit für einen geteilten Zwischenspeicher und überstimmt max-age (Abschnitt 5.2.2.10), must-revalidate und proxy-revalidate verbieten ihm, eine veraltete Antwort ohne Rücksprache mit dem Ursprung weiterzugeben (Abschnitte 5.2.2.2 und 5.2.2.8). Die beiden Erweiterungen aus RFC 5861 erlauben mehr, aber nur innerhalb des angegebenen Zeitfensters: stale-while-revalidate lässt den Zwischenspeicher die veraltete Antwort sofort ausliefern und im Hintergrund erneuern, stale-if-error lässt ihn die veraltete Antwort ausliefern, wenn der Ursprung einen Fehler meldet. Läuft das Zeitfenster ab, ohne dass eine Erneuerung gelingt, darf die veraltete Antwort nicht weiter ausgeliefert werden (Abschnitte 3 und 4).

Verbindungen sparen Aufwand. HTTP/1.1 nutzt standardmäßig dauerhafte Verbindungen, über die mehrere Anfragen laufen (RFC 9112 Abschnitt 9.3); HTTP/2 bildet jede Anfrage auf einen eigenen Strom ab, und diese Ströme sind weitgehend unabhängig, sodass eine blockierte Anfrage den Fortschritt der übrigen Ströme nicht aufhält (RFC 9113 Abschnitt 2). Das TCP-Head-of-Line-Blocking beseitigt HTTP/2 damit nicht (RFC 9113 Abschnitt 1). Für die Zahl gleichzeitiger Ströme besteht anfangs keine Grenze; jede Seite kann mit SETTINGS_MAX_CONCURRENT_STREAMS begrenzen, wie viele Ströme die Gegenseite gleichzeitig eröffnen darf, und diese Grenze gilt richtungsabhängig (RFC 9113 Abschnitt 6.5.2). Fragen Sie beim Anbieter nach diesem Wert und nach den Mengengrenzen Ihres Vertrags; der BSI-Baustein APP.3.2 (Edition 2023) verlangt in A10 für Webhosting ein schriftliches Service Level Agreement.

Teuer sind Seiten, die bei jedem Aufruf rechnen: Produktseiten mit Empfehlungen, Suche und Filter. Rechnen Sie für den Aktionstag aus, welche davon entbehrlich sind, und bereiten Sie die restlichen vor: Zwischenspeichern, Vorausberechnen oder hinter eine Warteschlange legen. Arbeiten, die nicht zur Antwort gehören müssen, gehören nicht in die Anfrage.

Schritt 6: Den Aktionstag begleiten

Vor dem Start: Überwachung scharf schalten und die Werte aus dem Test als Vergleichsgröße bereithalten, wie im Monitoring und Notfallplan beschrieben. Legen Sie schriftlich fest, in welcher Reihenfolge Sie Funktionen abschalten, wenn die Last über die getestete Grenze geht, und wer das entscheidet. Ein Beispiel aus der Redaktion: erst Live-Bestandsanzeige, dann Empfehlungen, dann Suche.

Während des Aktionstags vergleichen Sie die eingehenden Bestellungen je Stunde mit dem Plan. Fällt die Zahl der Bestellungen, während die Besucherzahl gleich bleibt, prüfen Sie zuerst die Kaufstrecke, bevor Sie an der Werbung drehen. Eine solche Auffälligkeit beweist die Ursache nicht: Der ISTQB-Lehrplan Performance Testing verlangt vor einer Korrektur die Ursachenanalyse (Abschnitt 4.4).

Schritt 7: Ergebnisse nachziehen

Notieren Sie je Lauf: Datum, Szenario, Ziellast, Schwellen, Messwerte und jede Abweichung mit Ursache. Diese Auswertung sieht der BSI-Baustein OPS.1.1.6 in A3 vor, die Freigabe der geänderten Umgebung für den Verkaufsbetrieb in A4. Nach jeder Änderung an Shopsoftware, Erweiterungen, Design, Zahlungsarten oder Datenbanksystem gehört ein neuer Lauf dazu; A12 sieht für geänderte Software Regressionstests vor und verlangt, ausgelassene Testfälle zu begründen und zu dokumentieren. Vergleichen Sie die Werte mit dem letzten Lauf: Ein Wert ohne Vorgänger sagt wenig, die Reihe zeigt den Trend.

So prüfen Sie das Ergebnis

• Das Lastprofil rechnet mit Ihren Zahlen und nennt den Anteil der Aufrufe, die den Shop statt des Zwischenspeichers treffen.
• Jedes Szenario hat Lastverlauf, Dauer, Abbruchkriterium, die anzuwendenden Schwellen und eine verantwortliche Person.
• Die Schwellen standen vor dem Lauf schriftlich fest, mit Messpunkt, Bezugszeitraum und Bewertung; die Auswahl der Kennzahlen ist als eigene Entscheidung gekennzeichnet, und jedem Szenario sind Durchsatzziel und anzuwendende Zeilen zugeordnet.
• Der Durchsatz zählt nur erfolgreich beantwortete Aufrufe; in den Szenarien mit erwarteter Last haben 429 und 503 einen eigenen Grenzwert, im Lastsprung und im Stresstest sind sie erwartet und werden gezählt.
• Der Test lief auf einer Nachbildung; im Verkaufsbetrieb wurde nichts erzeugt.
• Die Testdaten enthalten keine echten Kundendaten; werden Produktivdaten mit Personenbezug verwendet, verlangt BSI OPS.1.1.6.A11 mindestens Pseudonymisierung.
• Die Erholung nach dem Lastsprung wurde gegen eine weiterlaufende Prüflast gemessen, nicht bei abgeschalteter Last.
• Erfasst wurden p95 und p99, die Fehlerquote ohne 429 und 503, der Anteil der 429- und 503-Antworten an allen Aufrufen und der Rückstand bei Testende.
• Für den Aktionstag sind Abbruchkriterium, Abschaltreihenfolge und eine entscheidungsberechtigte Person benannt.

Wenn etwas nicht klappt

Fehlerbild	Mögliche Ursache	Behebung
Der Test läuft in 429, die Antwortzeiten sind aber niedrig	Ein Rate-Limit greift vor der Anwendung	Grenze aus dem Vertrag holen, Testlast darunter ansetzen, 429 getrennt zählen (RFC 6585 Abschnitt 4)
Testwerte besser als am Aktionstag	Anderer Datenbestand, leerer Zwischenspeicher oder Last aus dem eigenen Netz	Datenbestand angleichen, von außen messen, Anteil der Aufrufe am Shop nachrechnen
Der Test erzeugt Bestellungen in der Warenwirtschaft	Der Testshop hängt am Produktivsystem	Attrappen oder Testmodus einsetzen und Testbestellungen vorher kennzeichnen
Doppelte Bestellungen nach einer Störung	Ein Client wiederholt eine nicht-idempotente Anfrage	Wiederholungen auf idempotente Methoden begrenzen (RFC 9110 Abschnitt 9.2.2), eindeutige Bestellnummer verlangen
Antwortzeiten steigen über den Lauf an	Speicher, Sitzungen oder Verbindungen wachsen	Dauerlast-Szenario wiederholen und diese Werte mitschreiben
Nach dem Lastsprung kommt der Shop nicht zurück	Warteschlange läuft voll, Wiederholungen addieren sich	Warteschlange begrenzen, 503 mit Retry-After senden (RFC 9110 Abschnitt 15.6.4)
Ergebnis nicht wiederholbar	Zwischen den Läufen wurde mehr als eine Sache geändert	nur eine Änderung je Lauf, Einstellungen festhalten

Wann Sie Hilfe holen sollten

Klären Sie vorab beim Hoster und bei den angeschlossenen Diensten, ob und in welchem Zeitfenster Lasttests zulässig sind; das ist eine Frage an Ihren Vertrag. Holen Sie Unterstützung, wenn mehrere Systeme an der Kaufstrecke hängen, wenn die Messwerte ohne erkennbare Ursache streuen oder wenn der Shop bei einem Anbieter läuft, dessen Grenzen Sie nicht selbst einsehen können.

Für die Zeit im Browser führt Ladezeit und Core Web Vitals weiter, für die Wahl des Betriebsmodells und die zugesagten Werte Hosting für den Onlineshop, und für den Weg zurück aus einem Fehler Backup und Wiederherstellung für Shops.