Lasttests mit Grafana k6: Shop-Infrastruktur belastbar absichern

Wenn ein Online-Shop die Server-Infrastruktur wechselt, steht immer dieselbe Frage im Raum: Hält das Neue mindestens so viel aus wie das Alte? Bei einem unserer Kunden haben wir diese Frage nicht dem Bauchgefühl überlassen, sondern mit einem Lasttest belastbar beantwortet. Das Werkzeug der Wahl war Grafana k6. In diesem Beitrag zeige ich, wie wir reproduzierbare Last erzeugt, einen versteckten Ressourcenfresser aufgedeckt und nebenbei die Vorbereitungszeit von Tagen auf wenige Stunden reduziert haben.

Ausgangslage: Ein Infrastrukturwechsel ohne Blindflug

Unser Kunde hatte sich entschieden, seine Server-Infrastruktur auf eine neue Umgebung umzuziehen. Solche Wechsel sind ein klassischer Moment für unangenehme Überraschungen: Konfigurationen unterscheiden sich, Ressourcen sind anders zugeschnitten, und Engpässe zeigen sich oft erst dann, wenn es teuer wird – nämlich unter echter Last im Tagesgeschäft.

Unser Ziel war deshalb klar: Wir wollten vor dem endgültigen Umzug schwarz auf weiß wissen, dass die neue Infrastruktur mindestens das Gleiche aushält wie die bestehende. Keine Annahmen, keine Versprechen aus dem Datenblatt, sondern messbare Werte unter realistischen Bedingungen. Genau dafür ist ein Lasttest da.

Wie ein realistischer Lasttest aufgebaut ist

Ein Lasttest ist nur so gut wie das Verhalten, das er nachbildet. Schickt man tausend identische Anfragen auf die Startseite, misst man wenig Praxisrelevantes. Echte Besucher klicken sich durch Kategorien, rufen Produktseiten auf, legen etwas in den Warenkorb und legen Konten an. Diese Mischung haben wir abgebildet.

Konkret bestand unser Szenario aus zwei Anteilen. Rund 70 Prozent statische Inhalte – also das Durchblättern von Seiten, Kategorien und Produkten. Die passenden URLs mussten wir dafür nicht von Hand zusammensuchen: Wir haben die sitemap.xml des Shops als Quelle genutzt und daraus die real existierenden Seiten gezogen. Die übrigen 30 Prozent entfielen auf die geschäftskritischen, dynamischen Aktionen: Artikel in den Warenkorb legen und Kundenkonten anlegen. Das sind genau die Vorgänge, die Datenbank und Anwendung wirklich beanspruchen.

Diese 70/30-Verteilung ist kein Zufall. Sie spiegelt das tatsächliche Verhältnis aus Stöbern und Handeln in einem typischen Shop wider – und macht die Ergebnisse damit aussagekräftig statt akademisch.

KI als Beschleuniger: von Tagen zu Stunden

Der größte Unterschied zu früheren Projekten lag in der Vorbereitung. Lasttest-Skripte zu schreiben war traditionell aufwendig: URLs sammeln, Nutzerpfade modellieren, Authentifizierung und Formulare nachbauen, das Ganze sauber parametrisieren. Früher haben wir dafür mehrere Tage eingeplant.

Mit KI-Unterstützung haben wir diese Skripte für Grafana k6 in wenigen Stunden erstellt und ausgeführt. Die KI hilft dabei, aus der Sitemap-Struktur und den bekannten Shop-Abläufen schnell lauffähige Testszenarien zu generieren – inklusive der Logik für Warenkorb und Kontoanlage. Das verschiebt die Wirtschaftlichkeit eines Lasttests grundlegend: Was früher ein eigenes kleines Projekt war, wird zu einem Schritt, den man sich problemlos leisten kann – auch mehrfach im Projektverlauf.

Reproduzierbare Last in der Pipeline

Ein einzelner Testlauf sagt wenig aus. Entscheidend ist, dieselbe Last reproduzierbar immer wieder erzeugen zu können, um Umgebungen fair zu vergleichen. Deshalb haben wir die Lasttests in unsere Pipeline integriert und verschiedene Szenarien definiert, die jederzeit identisch wiederholbar sind.

Wir sind dabei stufenweise vorgegangen – etwa von 25 gleichzeitigen Nutzern über fünf Minuten, dann 50 Nutzer und weiter nach oben. So lässt sich nicht nur prüfen, ob ein System eine bestimmte Last verkraftet, sondern auch, wie es sich beim Hochfahren verhält: Wo steigen die Antwortzeiten, wo beginnen Fehler, wo liegt die Grenze. Weil alte und neue Infrastruktur exakt denselben Szenarien ausgesetzt wurden, war der Vergleich belastbar.

Diese Reproduzierbarkeit zahlt sich über das einzelne Projekt hinaus aus. Steht der Test einmal in der Pipeline, lässt er sich nach jeder größeren Änderung erneut auslösen – nach einem Update, einer Konfigurationsanpassung oder eben nach der Optimierung der statischen Auslieferung. So entsteht über die Zeit ein verlässliches Bild davon, wie sich die Performance entwickelt, statt punktueller Momentaufnahmen.

Welche Kennzahlen ein Lasttest liefert

Ein Lasttest produziert keine Bauchgefühle, sondern konkrete Zahlen. Drei Kennzahlen sind für die Bewertung entscheidend. Die Antwortzeiten zeigen, wie schnell der Shop unter Last reagiert – und ab welchem Punkt die Ladezeiten in einen Bereich rutschen, der Besucher abspringen lässt. Die Fehlerrate macht sichtbar, ab wann Anfragen nicht mehr sauber beantwortet werden, etwa weil Verbindungen oder Datenbank an ihre Grenze kommen. Und der Durchsatz – also wie viele Anfragen pro Sekunde das System verarbeitet – verrät die tatsächliche Kapazität.

Spannend ist nicht der einzelne Wert, sondern der Verlauf: Wo bleiben die Antwortzeiten stabil, und an welchem Punkt knicken sie ab? Genau dieser Knick markiert die reale Belastungsgrenze. Weil wir alte und neue Infrastruktur denselben Stufen ausgesetzt haben, ließen sich die Kurven direkt übereinanderlegen – und damit die Kernfrage des Projekts sauber beantworten.

Das Ergebnis: gleich belastbar – und ein blinder Fleck

Die gute Nachricht zuerst: Die neue Infrastruktur konnte die gleiche Last abfangen wie die alte. Der Umzug war damit aus Kapazitätssicht abgesichert – das eigentliche Projektziel war erreicht.

Spannend war aber die zweite Erkenntnis, die der Test ans Licht brachte: Alle statischen Dateien – Bilder, JavaScript, Stylesheets – werden derzeit über den PHP-Prozess ausgeliefert. Das ist technisch unnötig und verbraucht wertvolle Ressourcen, die eigentlich für die dynamischen, geschäftskritischen Anfragen gebraucht werden. Ein Webserver kann statische Dateien deutlich effizienter direkt ausliefern, ohne die Anwendung überhaupt zu beanspruchen.

Dieser Befund wäre im Normalbetrieb kaum aufgefallen – unter Last wird er zum echten Hebel. Gemeinsam mit dem Hoster haben wir deshalb eine bessere Lösung für die Auslieferung der statischen Inhalte abgestimmt. Sobald diese umgesetzt ist, wiederholen wir die Lasttests, um die Verbesserung zu messen. Das ist der eigentliche Wert reproduzierbarer Tests: Man optimiert nicht ins Blaue hinein, sondern belegt jede Maßnahme mit Zahlen.

Warum Lasttests gerade vor Marketing-Aktionen Pflicht sind

Der größte Vorteil von Lasttests ist, dass sie Fehler aufdecken, die nur bei Peak-Traffic auftreten. Im Alltag läuft ein Shop oft unauffällig – die kritischen Schwächen zeigen sich erst, wenn plötzlich viele Besucher gleichzeitig kommen.

Genau das passiert bei Marketing-Aktionen: ein Newsletter-Versand, ein TV-Spot, eine größere Kampagne. In diesen Momenten ist die Werbung erfolgreich – und genau dann will niemand erleben, dass die Werbung funktioniert, der Shop die Besucher aber nicht bedienen kann. Jeder Ausfall in der Spitze ist doppelt teuer: Man zahlt für die Reichweite und verliert trotzdem den Umsatz. Ein Lasttest verlagert diesen Stresstest vom Live-Betrieb in eine kontrollierte Umgebung, in der ein Engpass nichts kostet außer der Zeit, ihn zu beheben.

Praxis-Tipps für aussagekräftige Lasttests

• Realistische Mischung statt Einzel-URL: Bilden Sie das echte Nutzerverhalten ab – Stöbern und kritische Aktionen wie Warenkorb und Kontoanlage.
• Sitemap als Datenquelle: Die sitemap.xml liefert reale URLs und spart das mühsame Zusammensuchen von Testpfaden.
• Stufenweise hochfahren: Testen Sie mehrere Lastniveaus (z. B. 25, 50, 100 Nutzer), um die Grenze und das Verhalten beim Skalieren zu sehen – nicht nur ein Ja/Nein.
• Reproduzierbarkeit sichern: Integrieren Sie Tests in die Pipeline, damit jeder Lauf vergleichbar bleibt und Optimierungen messbar werden.
• Vor jedem großen Wechsel testen: Infrastrukturumzüge gehören grundsätzlich vorher abgesichert – mit Zahlen, nicht mit Datenblättern.
• Statische Auslieferung prüfen: Stellen Sie sicher, dass Bilder, JS und CSS nicht unnötig über den Anwendungsprozess laufen.
• Rechtzeitig vor Kampagnen: Planen Sie Lasttests vor Newsletter, TV-Spots und großen Aktionen ein – nicht danach.

Fazit

Ein Infrastrukturwechsel muss kein Blindflug sein. Mit einem realistisch aufgebauten Lasttest in Grafana k6 konnten wir belegen, dass die neue Umgebung mindestens so belastbar ist wie die alte – und gleichzeitig einen vermeidbaren Ressourcenfresser bei der Auslieferung statischer Dateien aufdecken. Dass sich solche Tests dank KI heute in Stunden statt Tagen aufsetzen lassen, macht sie zu einem Standardwerkzeug und nicht zur Ausnahme.

Der eigentliche Gewinn liegt im richtigen Timing: Lasttests decken genau die Schwächen auf, die sich sonst erst im teuersten Moment zeigen – bei Peak-Traffic durch eine erfolgreiche Marketing-Aktion. Wer hier vorher testet, sorgt dafür, dass nicht nur die Werbung funktioniert, sondern auch der Shop dahinter. Sobald die optimierte Auslieferung beim Hoster umgesetzt ist, wiederholen wir die Messung – und werden die Verbesserung mit Zahlen belegen können.