Lasttest Workload und Last Profile

Welches Last-Profil / Workload sollte gewählt werden?

Die Frage, der hierzu vorher nachgegangen werden muss, lautet: “Was ist mein Ziel”?

Jede der folgenden Beispiele für Last-Profile und „Workloads“ würde im konkreten Fall mindestens aus einer Anzahl virtueller User und eine Bedenkzeit (Think-time, Reaction-time) pro Seitenaufruf bestehen. Dies wird komplexer bei AJAX Web Application, dazu in späteren Artikeln mehr. Durch die Anzahl virtueller User und der Thinktime (+ Antwortzeit der Seite) ergeben sich die Hits pro Zeiteinheit bzw. Seiten pro Zeiteinheit. Das Last-Profil ist dazu noch in …

  • Aufwärmphase (oft Ramp-up oder Warm-up genannt),
  • Last-Phase,
  • Cooldown-Phase zu unterteilen.

Der Komplexität sind hier keine Grenzen gesetzt, auch kurze Hochlastspitzen oder Darstellung einer Mittagspause durch Einbinden einer mittigen Phase mit weniger Last macht je nach gewünschtem Szenario und Realitätsanspruch Sinn. Man spricht dann von einer realistischen All-Day Workload. Zusätzlich kommen Eigenheiten für Desktop-Applikationen, Mobile Apps oder Web-Applikationen dazu.

Die richtigen Anforderungen und Ziele sind sehr individuell und müssen analysiert und bestimmt werden, hierfür bieten sich neben Erfahrung der gute “Gesunde Menschenverstand” und ein analytisches Vorgehen an. Die Ziele und Planung sollten in einem Last und Performance Konzept verfasst werden. Diese Last-Profile (Workloads) sollte sich in jedem Lasttest Tool mit mehr oder weniger Aufwand einrichten lassen.

Um hierzu konkreter zu werden, folgen Antworten anhand von Beispielen.

Lasttest Workload: Test mit Last-Durchschnitt

Zunächst ist oft eine “obere Durchschnittslast” als Lastprofil sinnvoll, dies bietet sich in den meisten Fällen an und springt den meisten Testern als selbstverständlicher Punkt direkt ins Auge. Auf die Durchschnittslast sollte man 20-30% drauf rechnen, denn in der Realität kann sein, dass sich die Last nicht so “praktisch” und gut verteilt ist als im Test. Außerdem muss diese Reserve im Normalfall vorhanden sein. In anderen Fällen, in dem eine realistische Hochlast vorgegeben ist, die in Produktion sehr wahrscheinlich aufkommt, sollte diese in dem Lasttestablauf zumindest zeitweise drin sein.

Lasttest Workload: Maximal-Lasttest / Stresstest

Verständlicher Weise ist es auch wichtig die Grenzen bzw. die Reserven des Systems zu kennen. Hierzu bietet sich der nach ISTQB betitelte “Stresstest” an. Ich selbst nenne es meistens “Maximale Last Test”, was noch etwas weiter gehen soll als der Stresstest. Bei einem Stresstest ist interessant, wie sich ein System bei temporärer Überlast verhält, es ist aber nicht zwangsläufig das Ziel das System in die Knie zu zwingen. Bei dem Stresstest oder „Maximale Last Test” steh der Test für eine potentielle Zukunft mit mehr als die bisher geplante Last im Vordergrund. Dies kann ganz simpel der Fall sein, falls man sich mit der “geforderten Last” als Vorhersage für die Produktion verschätzt oder verrechnet hat, wie auch wenn zwischenzeitlich Peaks aufkommen mit denen man nicht gerechnet hat.

Beim Maximal-Lasttest versucht man im Gegensatz zum Stresstest auf jeden Fall bis zu dem Punkt zu kommen, ab dem die Antwortzeiten der Applikation exponentiell schlechter werden. Hierbei ist ein Monitoring besonders essentiell, da man nur damit ein Aufschluss darauf bekommt, wo das Bottleneck liegt. Das Monitoring reicht von Hardware Monitoring, zu Applikation Monitoring, zu Software und Datenbank Profiling. Die gewollte Überlast im Stresstest kann durch Erhöhung der Last oder durch Ausfall von Ressourcen (Ausfall einzelner Web oder Application-Server) simuliert werden. Nach diesem Test weiß man auf jeden Fall wo sich die nächste Last-Grenze befindet, wo das nächste Bottleneck ist und wodurch dies verursacht wird. Und man weiß wie viel Reserve vorhanden ist.

Lasttest Workload: Sonderszenarien / Sonder-Produtkivsetzungs-Szenarien

Für Produktivsetzungen kann ein besonderer Lasttest mit überdurchschnittlicher Spitzenlast an Erstnutzern wichtigen sein. Wie man durch “Abstürze” von größeren öffentlichen Seiten schon mitbekam, kann eine Produtkivsetzung gerade zu Anfang eine extreme Spitzenlast verursachen. Außerdem werden bei ersten Seitenbesuch im Durchschnitt immer mehr Daten übertragen, da zum Beispiel weniger im Browser-Cache ist. Ggf. könnten noch individuelle Punkte für Peak an Account-Registrierungen (zB. bei Release Intranet-App mit nötiger Registrierung im Unternehmen) oder ähnliches hinzukommen.

Hierzu können aber auch organisatorische Punkte und ein optimierter Ablauf der Produktivsetzung helfen, diese Situation möglichst zu vermeiden bzw. zumindest entgegenwirken.

Lasttest Workload: Langzeit / Robustheits -Lasttest / Dauerlasttest

Leider zeigt die Realität oft, dass eine Applikation die mehrere Stunden oder gar einen Arbeitstag aushält, dies leider nicht eine ganze Woche schafft.  Der Normalfall ist aber genau, dass das System durchgehend laufen und erreichbar sein soll, ohne Neustarts. Eine Client-Server Applikation ist meist 24h erreichbar, auch wenn manche interne Unternehmens-Applikationen eher während den Businesszeiten genutzt werden. Und diese Applikationen sollten nicht zwangsweise in festen kurzen Intervallen neu gestartet werden.

Um dies zu testen, bieten sich Langzeit-Lasttests an. Hierfür sind einige größere Herausforderungen zu beachten, da die Masse an Daten, die über mehrere Tage gesammelt wird, extrem hoch sein kann. Und ausgewertet werden muss der Test samt allen Logs und Monitoring ja auch. Bei diesem Test lassen sich auch kleinere Memory-Leaks entdecken, welche in kurzen Last-Testphasen sonst gar nicht auffallen.

 

Besonderheit: Einsparen virtueller User

Aus Lizenzkosten wie auch aus Gründen nicht vorhandener nötiger Hardware (oder Software) zum Emulieren aller nötigen virtuellen Usern, könnte man zu dem Entschluss kommen, eine Last auch mit weniger konkurrierenden Usern als nach Anforderungen gewünscht laufen zu lassen. In diesem Fall dreht man die realistische “Bedenkzeit / Pausezeit” eines virtuellen Users runter und kann damit mit der Hälfte an virtuellen Usern die gleiche Anzahl an “Klicks/Sekunde” erzeugen. Dies ist grundsätzlich weder richtig noch falsch. Man muss im Hinterkopf behalten, dass die Last hierbei in der Realitätsnähe beeinträchtigt wird.

Ein einfaches Beispiel für die Beeinträchtigung der Last-Realität: es werden schlicht weniger Sessions offen gehalten, auch wenn der gleiche Durchsatz geklickt wird. Weniger User bleiben eingeloggt. Weiterhin kann die Peaklast gleichzeitiger Aufrufe, nur der maximalen Anzahl virtueller User entsprechen. Bildlich gesprochen, mit 30 virtuellen Usern selbst ohne Thinktime, können maximal 30 Klicks pro Sekunde parallel erfolgen. Durchaus kann man mit diesen 30 virtuellen Usern auch den Durchsatz von 300 virtuellen Usern erreichen, wenn diese 300 User eine ca. 10-fach höhere Thinktime besitzen, jedoch bleibt die Grenze der maximalen konkurrierenden Userinteraktionen.

Diese maximale Grenze der konkurrierenden Connections / Userinteraktionen ziehen sich natürlich durch das ganze System. Beispielweise werden auch nie mehr DB-Connections konkurrierend aufgebaut als für die maximale Anzahl User benötigt. Wird pro eingeloggtem User etwas zwischengespeichert, was oft so ist und Memory verbraucht, geht dies nur bis zur maximalen Anzahl der konkurrierenden virtuellen User. Auch eingestellte Webserver-Connection-Limits die in der Realität zu Problemen führen, werden nur bis zu dieser Anzahl maximal konkurrierender User getestet. Auch Hardware wie Loadbalancer und Router werden anders belastet, durch weites herabsenken der virtuellen User könnte sich auch das Load Balancing verschlechtern.

 Wie immer, muss letztendlich muss eine individuelle Entscheidung getroffen werden.

 

Besonderheit: Mobile Devices und Mobile Apps

Mobile Apps haben neben in den letzten Jahren neue Anforderungen an den Lasttest mit sich gebracht. Zwar ist die Nutzung von Anwendungen unter mobilen Voraussetzungen nicht neu, jedoch ist diese mit Smartphone und Tablet stark gestiegen. Hierbei kommen zum Lasttest Anforderungen wie Emulation verschiedener Bandbreiten und Latenzen (Verbdingen von GSM über UMTS/LTE bis WLAN möglich), verschiedene Verbindungsqualitäten (Oft mehr Packetloss im mobilen Netz) inkl. Verbindungsabbrüche und schnell wechselnden Funkmasten beispielsweise bei der Fahrt im ICE. Wobei nichts davon zwangsweise in den Last- und Performancetest einfließen muss. Dazu kommen die stark unterschiedlichen Ausprägungen einer App auf verschiedene Betriebssysteme für mobile Endgeräte.

 

Besonderheit: Performancetest ohne Last?

Auch das ist möglich, dient an dieser Stelle nur der Vollständigkeit halber. Dieser Punkt wird in anderen Beiträgen ausführlicher besprochen. Bei Performancetests ohne Last, geht es eben um die Single-Instance-Performance. Auch diese ist durchaus interessant. Der ganze Anteil an Informationen, welche erst durch die Last und Belastung aus dem Test gezogen werden, bleiben hierbei natürlich auf der Strecke.

Fanden Sie den Artikel hilfreich?
[Gesamt: 0 Durchschnitt: 0] -

Leave a Reply