Mit Lasttests zur performanten JEE-Anwendung

Lasttests gehören zu jedem größeren Entwicklungsprojekt dazu, wie der TÜV zum Auto. Die Tests sind nicht gerade beliebt, aber unerlässlich, um zu alltagstauglichen, robusten und performanten Software-Anwendungen zu kommen - genauso wie zu verkehrssicheren Autos. Lasttests überprüfen die Einhaltung von zwei wichtigen Anforderungen an ein Softwaresystem: Stabilität und Performanz. Dieser Artikel stellt anhand von Erfahrungen in einem Kundenprojekt grundlegende Aspekte und Untersuchungsmethoden zu dieser Thematik vor.

Das Kundenprojekt

In diesem Projekt wird eine JEE-Client-Server-Anwendung entwickelt, die aus einer Altanwendung entstanden ist und an vielen Stellen auf neuere Technologien aufsetzt, z. B.:

• JEE als Kerntechnologie mit allen Facetten (hieß zu Projektbeginn übrigens noch J2EE):
  • WEB Container mit JSP/Servlets
  • EJB Container mit EJB für die Business Logik
  • Apache Webserver für das Loadbalancing


• CORBA für die Anbindung von Legacy-Systemen


• Oracle als Datenbank


• .Net und JScript für den Client-Anteil

Das komplexe Gesamtsystem hat inzwischen erfolgreich die Einführung in den Produktivbetrieb geschafft. Der mehrmonatige Betrieb ohne gravierende Performanzprobleme ist nicht zuletzt den umfangreichen und produktivbetriebsnahen Lasttests zu verdanken.

Was sind eigentlich Lasttests?

Für eine treffende Definition von Lasttests liefert uns Wikipedia eine aussagekräftige Beschreibung [1]:

„Unter einem Lasttest versteht man einen Softwaretest, mit dem eine zu erwartende, auch extreme Last auf dem laufenden System erzeugt und das Verhalten desselbigen beobachtet und untersucht wird. Dazu kann eine Simulation eingesetzt werden. Ziel dabei ist es,

1. Fehler aufzudecken, die im funktional orientierten Systemtest/Integrationstest nicht gefunden wurden.
2. Erfüllung nichtfunktionaler Anforderungen, wie z. B. geforderte Antwortzeiten sowie Mengenverarbeitungen, für den Produktivbetrieb nachzuweisen.“

Zeitliche Einbettung in die Projektphase

Es gibt eine prinzipielle Schwierigkeit, die Durchführung von Lasttests formal sauber und korrekt in den Terminplan von Entwicklungsprojekten zu platzieren.

Denn eigentlich darf ein Lasttest erst dann durchgeführt werden, wenn die funktionale Korrektheit dokumentiert ist, d. h. die fachliche Abnahme der Anwendung vorliegt. Wenn dann Lasttests stattfinden, die ihrerseits Performanzschwachstellen aufdecken, geht es wieder zurück in die Entwicklung und das Prozedere „Fachliche Abnahme mit anschließenden Lasttests“ beginnt von vorn.

Abb. 1: Projektplan mit zeitlicher Einordnung der Lasttestphase. (vergrößern)

In der Praxis findet deshalb häufig eine verzahnte bzw. überlappende Zeitplanung statt. So können Fehler aus den beiden Phasen „Abnahme“ und „Lasttest“ gesammelt und in einem Topf zusammengefasst werden. Diese Vorgehensweise spart Zeit in der Entwicklung bzw. Fehlerbehebung, da sich die Anzahl der Termine für Bereitstellung und Lieferung minimiert. So wurde es auch in dem von ORDIX unterstützten Kundenprojekt praktiziert. Den schematischen Zeitplan des Projekts mit den wichtigsten Phasen zeigt Abbildung 1.

Performanz: Antwortzeiten und Durchsatz

Die Performanz einer Anwendung kann man unter verschiedenen Gesichtspunkten betrachten. Da geht es zum einen um das Kriterium des Antwortzeitverhaltens in der Benutzerinteraktion. Dahinter steckt die Frage: „Wie lange muss der Benutzer einer Anwendung auf die Antwort einer von ihm angestoßenen Transaktion warten?“ Zum anderen ist Performanz aber auch häufig aus einer übergeordneten Sichtweise mit der Fragestellung assoziiert: „Wie viele Transaktionen pro Zeiteinheiten bewältigt das System?“ Diese Größe wird auch als Durchsatz bezeichnet. Beide Fragestellungen, die der individuellen Antwortzeit und die des globalen Durchsatzes, hängen eng miteinander zusammen.

In unserem Kontext gelangte das Thema Performanz vorwiegend unter dem Aspekt Antwortzeitverhalten in die Untersuchung. Die zu testende Anwendung ist für die Servicemitarbeiter des Kunden konzipiert, die damit ihre Auftragsvorbereitung und -abarbeitung sowie den Tagesabschluss und weitere Verwaltungsaufgaben, erledigen. Diese Geschäftsfälle und ihre zügige Abarbeitung sind für den Kunden natürlich von großem Interesse und somit standen sie während der Lasttests unter spezieller Beobachtung.

Abb. 2: Punktwolke der Einzeldauern von konkreten Geschäftsfällen im Lasttest. (vergrößern)

Mittelwert (sec) Anteil <= X sec Gewichtung 1 Client: Anmelden m1 A1 (<= 5 sec) (1- A1) / 0,5 2 Edda: Liste laden m2 A2 (<= 10 sec) (1- A2) / 0,5 3 Client: Auftrag laden m3 A3 (<= 10 sec) (1- A3) / 0,5 4 Client: Auftrag abschließen m4 A4 (<= 10 sec) (1- A4) / 0,5 5 Client: Tagesabschluss m5 A5 (<= 5 sec) (1- A5) / 0,5

Abb. 3: Mittelwerte der Zeitdauern und Vorgaben, welche Antwortzeiten bei einzelnen Geschäftsfällen einzuhalten sind. Die Spalte Gewichtung ist für die Bewertung der Testläufe von Bedeutung.

Abb. 4: CPU-Auslastung für einen Server im Zeitraum eines Lasttestlaufs. (vergrößern)

CPU-Auslastung, Statistik Mittelwert Maxwert Anteil > 50 % 1 App Server AD 32,8 % 91,0 % 6,5 % 2 App Server CS 35,3 % 78,3 % 22,1 % 3 DB Server AD 7,3 % 71,0 % 0,4 % 4 DB Server CS 36,9 % 56,0 % 0,0 %

Abb. 5: Messergebnisse der CPU-Auslastung aller beteiligten Serversysteme.

Abb. 6: Netzplandiagramme für die Bewertung. (vergrößern)

Messung, Darstellung und Bewertung

Die Lasttests wurden mit dem Tool JMeter [2] erstellt, einem Framework zur Erstellung von Simulatoren, die Client-Aktivitäten in sehr großem Umfang und hochparallelem Ablauf erlauben. JMeter gestattet es darüber hinaus, einzelne Client-Aktionen genau zu protokollieren und zu messen, so dass einer gezielten Analyse nichts im Wege steht [3]. Die Durchführung von einzelnen Lasttestläufen fand zu bestimmten Tageszeiten statt und ging meistens über einen Zeitraum von vier Stunden.

Die Zeitdauer eines Geschäftsfalls, wie z. B. „Auftrag laden“, ist als einzelner Punkt in einem Diagramm eingetragen - an dem Zeitpunkt, als er ausgeführt wurde. Die Punktwolke setzt sich aus allen gemessenen Zeiten für diesen Geschäftsfall zusammen und die schwarze Linie stellt den gleitenden Durchschnitt dar. Die Zeitskala (8:00 - 12:00 h) gibt die Dauer dieses konkreten Lasttestlaufs an (siehe Abbildung 2).

In Abbildung 3 sind die wichtigen Geschäftsfälle oder Client-Aktionen aufgelistet, die in den Lasttestläufen simuliert wurden. Typische Durchläufe dauerten jeweils vier Stunden und die Gesamtanzahl aller simulierten Geschäftsfälle pro Testlauf erreichte ca. 200.000. Von jedem einzelnen Geschäftsfall wurden die Dauer und der Zeitpunkt der Rückkehr gemessen. Die interessanten statistischen Größen sind der Mittelwert der Antwortzeiten pro Geschäftsfall in Sekunden und der Anteil der Geschäftsfälle, die eine vorgegebene Zeitdauer unterschreiten.

Zusammen mit einem Netzplandiagramm werden daraus die Kriterien für „erfolgreiche“ Lasttests abgeleitet. Aber dazu später mehr.

Stabilität

Mit Stabilität oder Robustheit ist die Ausfallwahrscheinlichkeit einer Anwendung gemeint. Ausfälle können durch eine Vielzahl von Gründen auftreten, häufig durch schiere Überlastung der Prozessoren. Daher stand die Überwachung der CPU-Auslastung in den verschiedenen Serversystemen bei unseren Lasttests im Vordergrund, von denen eine Auslastungskurve beispielhaft in Abbildung 4 zu sehen ist.

Von Interesse in der hier zugrunde liegenden Gesamtanwendung sind vier unterschiedliche Serversysteme, die sich vom Typus her in jeweils zwei Application Server und zwei Datenbank Server aufteilen. Bei beiden Datenbank Servern und einem der Application Server handelt es sich um Mehr-CPU-Maschinen des Herstellers Fujitsu Siemens Computers mit dem Betriebssystem Sun Solaris 8. Hinter dem anderen Application Server verbirgt sich in Wirklichkeit eine Serverfarm, bestehend aus bis zu 40 Windows 2000 Servern. In der Lasttestumgebung kommt eine analoge Serverlandschaft zum Einsatz, die allerdings von der Ausstattung her „nur“ über ca. 20 Prozent der Hardware-Ressourcen des Produktivbetriebs verfügt.

Auch diese Messergebnisse der CPU-Auslastungen von allen Servern müssen wieder zusammengefasst und verdichtet werden, was beispielhaft die Abbildung 5 für einen konkreten Lasttestlauf zeigt. Für die CPU-Auslastung sind als statistische Größen besonders der Mittel- und der Maximalwert, aber auch der prozentuale Anteil der Gesamtzeit interessant, bei der die CPU-Auslastung mehr als 50 Prozent beträgt.

Ergebnisse ins rechte Licht rücken

Nachdem wir nun eine ganze Reihe von Messergebnissen und Zusammenfassungen ermittelt und statistische Aufbereitung betrieben haben, fehlt noch der letzte Schritt der Bewertung. Diese muss übersichtlich und vor allem aussagekräftig sein, da man in typischen Lasttestphasen mehrere Dutzend verschiedener Testläufe durchführt und diese eine rasche Einschätzung und Kategorisierung benötigen. Für diesen Schritt haben wir Netzplandiagramme aus MS Excel verwendet (siehe Abbildung 6).

In dem Netzplandiagramm „Laufzeiten“ sind die Werte aus der Spalte Gewichtung aus Abbildung 3 eingetragen, die zwischen 0 und 1 liegen können. Das globale Kriterium dafür, ob ein Lasttestlauf in dieser Kategorie erfolgreich war oder nicht, lautet: „Es darf keine Ausreißer im Netzplan geben“. d. h. im Fall der Laufzeiten: Kein Wert darf > 0,5 sein, was durch die rote Linie markiert ist. Bezogen auf den Geschäftsfall „1 Client: Anmelden“ aus Abbildung 3 bedeutet das z. B.: Nicht mehr als 25 Prozent aller Anmeldungen dürfen länger als 5 Sekunden dauern.

Analog dürfen keine Ausreißer bei den CPUAuslastungen auftreten, deren Netzplandiagramm mit den Werten der Spalte Anteil > 50 % aus Abbildung 5 gefüllt ist. Im vorliegenden Fall wurde der konkrete Lasttest als gerade noch bestanden bewertet, obwohl es eine kleine Überschreitung der erlaubten Laufzeit in einem Geschäftsfall 1 gibt.

So wurden etliche Runden gedreht - mit zum Teil auch schlechten Netzplandiagrammen und deutlichen Ausreißern in mehreren Dimensionen. Aber gerade diese Aufbereitung und Darstellung der Messdaten hat wertvolle Dienste in der Fehlersuche und der Aufdeckung von Performanzschwächen geleistet. Am Ende der Lasttestphase lautete das Ergebnis der Lasttests schlicht: „Die Anwendung ist performant und stabil“.

Fazit

Lasttests gehören zu jedem größeren Softwareprojekt essentiell dazu und können nicht früh genug in die Planung einbezogen werden. Antwortzeitverhalten, CPU- und Hauptspeicherauslastung sowie deren statistische Auswertung und Bewertung haben sich als geeignete Analysemethoden herausgestellt. ORDIX hat viel Erfahrung in diesem Themenkomplex gesammelt und bringt auch Ihre Anwendung gerne durch belastende Tests zu Stabilität und Performanz.

Dr. Hubert Austermeier (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen