Sieben vermeidbare Fehler bei Lasttests

Einleitung

Der Lasttest ist einer der letzten Schritte der Vorproduktion in der Entwicklungskette. Das verleitet dazu, Abkürzungen zu nehmen, Ergebnisse zu übereilen und so die Tests einfach nur so schnell wie möglich hinter sich zu bringen, damit die Software eingeführt werden kann.

Niemand kann jedoch bestreiten, dass Lasttests eine hochkomplexe Angelegenheit sind. Inkorrekte Planung, Szenarien, die der echten Produktumgebung nicht genau entsprechen oder überlastete Lastgeneratoren – im besten Fall verlieren Sie deshalb nur Zeit, Geld und Ressourcen, die Sie für erneute Tests einsetzen müssen.

Im schlimmsten Fall haben Sie Ihr System nicht richtig getestet – und da kann die lang erwartete Einführung schnell zur Katastrophe werden. Mit der Erfahrung aus tausenden Stunden Lasttests, die wir bei Unternehmen auf der ganzen Welt durchgeführt haben, können wir Ihnen nun die folgende Liste mit sieben häufig auftretenden Fehlern bei Lasttests vorstellen.

Jedem können diese Fehler passieren, doch wenn Sie diesen Artikel gelesen haben, werden sie Ihnen nicht mehr passieren.

Fehler Nr. 1: Unklare Zieldefinition

Ohne klar definierte, quantifizierbare Testziele sind Lasttests im besten Fall nur ein Ratespiel.

Lasttestziele müssen vor dem Starten und Auswerten der Testszenarien klar definiert sein und zu den Bedürfnissen des Unternehmens passen. Hier sind einige gängige Testziele, die Sie in Betracht ziehen sollten.

KAPAZITÄT PRO SZENARIO

Wie viele Nutzer soll das System pro Szenario bedienen?

ANTWORTZEIT PRO AKTIVITÄT

Welche Antwortzeiten sind für jede einzelne Transaktion akzeptabel? Wie hoch sollen die maximale Antwortzeit, Durchschnittswerte und akzeptable Zahl von Ausreißern sein?

DATENDURCHLAUF

Mit welchem Datenvolumen soll Ihr System arbeiten können? Wenn Ihre Nutzer beispielsweise Dateien mit 1 GB herunterladen müssen, mit wie viel Datenvolumen soll Ihr System dann unter Spitzenlast arbeiten?

AKZEPTABLER FEHLER-PROZENTSATZ

Ist zum Beispiel eine Fehlerrate von 0,1 % akzeptabel für Logins in einer Bankapplikation?

ZIELE FÜR NUTZERTYPEN, STANDORTE, BROWSER UND WEITERES

Haben Sie verschiedene Kundentypen (Gold, VIP), denen Sie verschiedene Servicegrade anbieten? Sollten verschiedene Ziele für einen geographischen Standort Ihrer Nutzer definiert werden?

ZIELE FÜR STANDARD- UND SPITZENZEITEN

Haben Sie verschiedene Ziele bezüglich Antwortzeiten abhängig von der Tageszeit oder Aktivitäten zu Spitzenzeiten definiert?

VERFÜGBARKEITSZEITEN

Die meisten Systeme sind länger verfügbar als nur die 2-4 Stunden Laufzeit eines Lasttests. Wie ist Ihre Verfügbarkeit gelagert und wie wirkt sich das auf Ihre Zieldefinition für einen Laufzeit-Lasttest aus?

* * *

Finden Sie für sich heraus, welche Ziele für Ihr System und Ihre Umgebung relevant sind. Nur dann, wenn Sie spezifische Lasttest-Ziele wie die oben genannten festlegen, werden Sie auch die Ergebnisse Ihrer Leistungstests gut auswerten und weitergeben können.

Fehler Nr. 2: Keine realistische Testumgebung

Eine echte Produktumgebung besteht aus fast unendlich vielen Komponenten – Server, Datenbanken, Hardware, Tools von Drittanbietern, Integrationen, periodisch ablaufende Hintergrundprozesse und noch vieles mehr. Deshalb besteht eine große Herausforderung bei Lasttests darin, eine Testumgebung zu erstellen, die der tatsächlichen Produktionsumgebung entspricht.

Wenn Sie nicht bereit sind, Zeit und Mühe zu investieren, um eine realistische Umgebung zu erstellen, dann könnte es gut sein, dass Sie viel Zeit damit verschwenden, etwas zu testen, was es gar nicht gibt. Stellen Sie sicher, dass Ihre Testumgebung folgende Punkte erfüllt:

PRODUKT-ÄHNLICH

Ihre Testumgebung sollte der echten Produktumgebung so ähnlich wie möglich sein und zwar in allen Punkten von Hardware über Konfiguration und Speicher bis hin zu Datenbanken, Lastverteilern usw. Sie können klein anfangen und zunächst eine reduzierte Umgebung testen. Denken Sie dabei jedoch daran, dass Sie ein großes Produktsystem simulieren müssen.

ISOLIERT

Ihre Testumgebung sollte vollkommen isoliert von allen anderen Aktivitäten sein. Wenn weitere Nutzer Daten auf Ihrem Testsystem speichern oder dort Prozesse ablaufen, derer Sie nicht bewusst sind, dann können Ihre Testergebnisse verfälscht werden.

MIT EINGEPFLEGTEN DATEN

Ein System mit nur 100 Einträgen zu testen ist nicht das selbe, wie ein Lasttest mit einem echten Produktionssystem mit 20 Millionen Einträgen. Sie müssen die Zeit für die Erstellung von Datenmengen investieren, die dem echten Produktionssystem entsprechen.

INTEGRATION VON DRITTANBIETER-SOFTWARE

Bei Ihrem Test sollte jede Software von Drittanbietern (Kreditkarten, Bestellmanagement etc.) einbezogen werden, die in der Produktumgebung genutzt wird. Der Engpass nach dem Sie suchen, könnte sich genau hier verstecken! Dabei sollten Sie jedoch darauf achten, dass keine echten ‚Geschäftsaktivitäten‘ im Test erstellt werden, wie zum Beispiel Zahlungen, Käufe usw.

PERIODISCHE ABLAUFENDE ODER HINTERGRUND-PROZESSE

‚Versteckte‘ Prozesse wie Reinigung, Backup, Berichtswesen, Gruppierung oder Datenexporte sind oftmals Teil der Produktumgebung, werden jedoch oft bei Leistungstests vergessen. Diese Prozesse können erhebliche Ressourcen der Maschinen binden und das Systemverhalten extrem beeinflussen.

Fehler Nr. 3: Abkürzungen nehmen

Kompromisse einzugehen, kann verführerisch sein, wenn man Lasttest-Szenarien erstellt. Auch wenn Sie auf Budget-, Ressourcen- oder Zeitbeschränkungen achten müssen – seien Sie vorsichtig, ob und wo Sie Abkürzungen nehmen, damit die Ergebnisse Ihres Lasttests nicht darunter leiden.
Das sind zwei häufig auftretende Gefahren, die Sie vermeiden sollten.

ANZAHL VON NUTZERN

Für Lasttests von Systemen mit 100.000 Nutzern benötigt man mehrere Maschinen, die vielleicht nicht zur Verfügung stehen. Warum also nicht einfach 10.000 Nutzer nehmen und diese eine Transaktion pro Sekunde durchführen lassen, statt eine Transaktion alle 10 Sekunden wie in dem ‚echten‘ 100.000-Nutzer-Test?

Das Problem dabei ist, dass sich diese zwei Szenarien erheblich unterscheiden. Der Server muss für 10.000 Nutzer nicht die gleiche Zahl von Verbindungen aufrecht erhalten; der Speicherbedarf für 100.000 Nutzer unterscheidet sich stark von dem für 10.000. Genauso verhält es sich mit Datenbank-Anfragen. Sie können bei der Nutzerzahl nicht sparen und gleichzeitig realistische Testleistungen erwarten.

DATEN-RANDOMISIERUNG

Es ist viel einfacher, 100 Nutzerprofile zu erstellen als 10.000 Profile. Wenn allerdings die selben 100 Nutzer wiederholt auf Ihr System zugreifen und deren Nutzerdaten gespeichert werden, sehen Sie niemals die Auswirkungen, die Zugriffe von 10.000 verschiedenen Nutzern auf Ihr System haben.

Fehler Nr. 4: Zu viel zu früh

Das Ziel von Lasttests ist die Simulation einer großen Nutzerzahl in einer realistischen Umgebung.

Allerdings wissen erfahrene Lasttester, dass der Test zwangsläufig fehlschlägt, wenn man direkt mit der finalen Nutzerlast beginnt.

Warum? Nehmen wir an, dass Ihr finales Testszenario aus 10.000 Nutzern von 5 verschiedenen Standorten mit drei verschiedenen Gerätetypen und 10 verschiedenen Nutzerszenarien besteht. Wenn Sie das gleich zu Anfang testen wollen, ist es fast unmöglich, auftretende Fehler zu isolieren.

Stattdessen sollten Sie mit einem Nutzer an einem Standort mit einem Gerät beginnen. Erstellen Sie ein Testszenario, das graduell wächst und halten Sie auf jeder Stufe nach Fehler Ausschau. Hier sind noch einige weitere Tipps, wie Sie „klein anfangen“ können.

GANZ OHNE LAST

Testen Sie Webseiten zunächst ohne Lasttest-Tools. Es gibt mehrere Tools wie zum Beispiel WebPageTest.org, die Sie nutzen können. So können Sie feststellen, ob es Probleme auf Ihrer Seite gibt. Wenn es beispielsweise 20 Sekunden dauert, um eine Seite zu laden, dann macht es erst Sinn, einen Lasttest durchzuführen, wenn dieses Problem gelöst wurde.

EINZELSZENARIO + EINZELNUTZER

Bevor Sie Szenarien kombinieren oder Last erzeugen, lassen Sie jedes Szenario zunächst einmal eine ganze Stunde für sich alleine laufen. Das hilft Ihnen dabei, Probleme mit Speicherlecks, Fehlern, Testdaten und Ihrem eigentlichen Testskript zu identifizieren.

EINZELSZENARIO, MINIMALE LAST

Testen Sie jedes Szenario mit einer kleinen Zahl von Nutzern (z. B. 5 virtuelle Nutzer), bevor Sie anfangen Last zu generieren. So merken Sie gleich, ob es irgendwo schon bei einfachen Situationen hängt oder ob es andere Probleme gibt, die Ihre Anwendung beeinflussen, auch wenn nur wenige Nutzer gleichzeitig arbeiten.

LAST ERHÖHEN UND/ODER SZENARIEN MISCHEN

Wenn Sie bestätigen konnten, dass die grundlegenden Aspekte Ihres Szenarios richtig funktionieren, können Sie die Last erhöhen und auch eine Vermischung von Szenarien in Betracht ziehen. Sie können entweder die Last für jedes Szenario so lange erhöhen, bis Sie Ihre maximalen Anforderungen erreicht haben oder zuerst die Szenarien kombinieren und erst dann die Last erhöhen.

Fehler Nr. 5: Überlastete Lastgeneratoren

Lastgeneratoren helfen zwar dabei, Ihre Testziele zu erreichen, jedoch können sie auch die Testergebnisse verfälschen. Ein überlasteter Lastgenerator kann eine Situation erzeugen, in der gar keine Last bzw. Last mit falschen Ergebnissen erzeugt wird. Um festzustellen, ob Lastgeneratoren überlastet sind, überprüfen Sie Folgendes:

LASTERZEUGER-RESSOURCEN

• CPU- und Speicherbedarf
• Kontextwechsel pro Sekunde – eine hohe Zahl an Kontextwechseln zeigt, dass der Prozessor nicht effizient arbeitet und mehr Zeit mit eigenen Prozessen als mit den eigentlichen Aufgaben verschwendet.
• Seitenfehler – wenn diese Zahl hoch ist, verschwendet das System Ressourcen für das Schreiben auf Festplatte. Das zeigt Ineffizienz und potentiell schädliche Performance auf.
• Warteschleife der Festplatte – es gibt immer eine Warteschleife für das Schreiben auf Festplatte, doch wenn dieser Wert konstant steigt, kann das ein Zeichen für einen überlasteten Lastgenerator sein. Wenn sich die Warteschleife bei gleichbleibender Last verlängert, ist das ein noch deutlicheres Zeichen.

TRANSAKTIONEN PRO SEKUNDE

Vergleichen Sie den Lasterzeuger mit einem ‚Probing Client‘. Dabei handelt es sich um eine separate Maschine, die einen einzelnen virtuellen Nutzer darstellt. Angenommen, Sie erhöhen dann die Lastgröße und sehen, dass der Wert TX/s nicht linear ansteigt. Indem Sie den Wert TX/s des Probing Client mit dem des Lastgenerators vergleichen, können Sie feststellen, ob Ihr Lastgenerator Probleme hat.

Fehler Nr. 6: Systemfehler ignorieren

Leistungsmetriken und Antwortzeiten sind verständlicherweise Schlüsselpunkte von Lasttests. Doch einige Systemfehler zeigen sich erst durch Systemfehlermeldungen, die nicht so offensichtlich sind – anders, als zum Beispiel ein Absturz oder eine Verschlechterung der Antwortzeit.

Stellen Sie sich beispielsweise vor, dass eine Integration mit einem externen Tool oder einem Hintergrundprozess nicht mehr funktioniert. Da sich dies jedoch nicht auf die Nutzer auswirkt, zeigt sich das auch nicht in der Antwortzeit.

Ein weiteres Beispiel wäre ein HTTP 500 Fehler, der mit einem nur geringen Prozentsatz auftritt und sich so auch nur auf eine kleine Zahl von Nutzern auswirkt.

Um alle mit Last zusammenhängenden Schwachstellen im System zu finden, achten Sie auf Fehler und verdächtiges Verhalten, auch wenn die Antwortzeiten perfekt zu sein scheinen. Zum Beispiel:

BENUTZERFEHLER

Fehler, die der Server ausgibt und für den Nutzern sichtbar sind (wie HTTP 500), sollten auch in Ihrem Lasttest-Tool sichtbar sein.

SERVER-SEITIGE FEHLER

Überprüfen Sie Ihre Server-Log-Dateien, um serverseitige Fehler zu finden, wie zum Beispiel Ausnahmen oder Ausfälle von serverseitigen Komponenten oder Diensten.

FALSCHE DATEN

In einigen Fällen kann der Request/Response-Ablauf und die Antwortzeit in Ordnung sein, doch die Daten, die vom Server kommen, sind falsch. Stellen Sie sicher, dass Ihre Skripte eine Datenvalidierung enthält, um genau diese Fälle identifizieren zu können.

Fehler Nr. 7: Undokumentierte Test-/Lastszenarien

Das mehrmalige Ausführen von Szenarien und der Vergleich der Ergebnisse sind wesentliche Bestandteile von Lasttests. Doch bei den verschiedenen Durchgängen und mit Änderungen und Anpassungen verschiedener Parameter, Anwendungsversionen und Testeinstellungen kann die Nachverfolgung der Änderungen in jeder Testausführung schnell zum Alptraum werden.

Man kommt so leicht durcheinander nach mehreren Durchgängen und vergisst einfach, welche Änderungen und Einstellungen zu welchem Testlauf gehören und ob Ihre Interpretation der Ergebnisse korrekt ist. Hier sind einige Schlüsselpunkte, die in jedem ausgeführten Szenario dokumentiert werden sollten, um den Überblick über Ihren Testfortschritt zu behalten.

RATIONAL/ZIEL DES SZENARIOS

Dokumentieren Sie den Zweck dieses spezifischen Durchlaufs – was soll damit überprüft oder validiert werden im Vergleich zu anderen Durchläufen? Was sind die erwarteten Ergebnisse? Wie groß ist die Last und welche anderen Schlüsselparameter wurden im Vergleich zu anderen Durchläufen geändert?

SYSTEM UNTER TEST-EINSTELLUNGEN

Welche Software-Version wurde getestet? Welche spezifischen Fehlerkorrekturen enthält diese? Zusätzlich dazu sollten Sie die wichtigen Änderungen der Konfiguration und Einstellungen festhalten, die in der Umgebungsstruktur oder -konfiguration gemacht wurden.

EINSTELLUNGEN DER TESTUMGEBUNG

Notieren Sie wichtige oder geänderte Einstellungen der Lastgeneratoren und des Lasttest-Tools (z. B. Änderungen zum Zwischenspeichern oder gzip).

ERGEBNISSE/SCHLUSSFOLGERUNGEN

Zeichnen Sie Ihre eigenen Schlussfolgerungen zu jedem Durchlauf auf zusammen mit den Annahmen zu Problemursachen und Änderungen, die gemacht werden müssen, um das Problem isolieren zu können.

FAZIT

Professionelle Lasttest-Tools sind enorm wichtig für den Erfolg der Webseiten- oder Anwendungs-Lasttests – und dieser wiederum kann sich erheblich auf das gesamte Unternehmen auswirken.

Doch vergessen Sie nicht: Auch wenn Sie sich für ein Tool entschieden haben, ist ein Lasttest doch nur so verlässlich und genau, wie die Testumgebung und das Szenario es zulassen. Ergebnisse aus schlecht geplanten und schlecht ausgeführten Tests sind per Definition schlecht.

Nehmen Sie sich die Zeit, um einen genauen Plan auszuarbeiten und stellen Sie schwierige Fragen – und Sie sind schon auf dem richtigen Weg, um die Fehler in Lasttests von Anwendungen zu vermeiden.