Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.02.2005

Performance - die Stunde der Wahrheit

Von Achim
Gute Performance ist ein wichtiges Kriterium für die Qualität einer IT-Lösung. Entsprechende Tests, kombiniert mit System-Tuning, können die Leistung um bis zu 100 Prozent steigern.

Unternehmensintern wirken sich gestörte IT- und Geschäftsprozesse gravierend auf die Benutzerakzeptanz, die Motivation und Produktivität der Mitarbeiter sowie die Datenqualität aus. Auch gegenüber Kunden sind Performance-Probleme immer mit Kosten verbunden, sei es durch Umsatzeinbußen, Reparaturaufwand oder Verschwendung von technischen Ressourcen und menschlicher Arbeitskraft.

Abhilfe schaffen kann hier der Performance-Test. Dabei handelt es sich um ein Verfahren, das eine definierte Anzahl paralleler Nutzer beziehungsweise Funktionsaufrufe simuliert und gleichzeitig die einzelnen Komponenten des IT-Systems misst (Monitoring). Für solche Tests benötigt man Informationen über Netzwerk, Betriebssystem, Applikations-Server, Datenbank und die Anwendung selbst. Auf Basis der im Test ermittelten Daten können die Konfigurationen von Komponenten (Tuning), der Softwarecode der Anwendung (Redesign) oder die Hardware (Sizing) verändert werden, um eine höhere Performance des Systems zu erreichen. Durch Tuning und Sizing lässt sich der Produktivbetrieb einer Anwendung erheblich verbilligen.

Systemanforderungen oft vernachlässigt

Niemand würde die Entwicklung einer Software in Auftrag ge- ben, ohne die benötigten Funktionen in Form funktionaler Anforderungen (Pflichtenheft) zu definieren. Die nichtfunktionalen Anforderungen werden jedoch häufig vergessen oder nur unzureichend beschrieben. Im Interesse der gewünschten Performance sollte aber die Zahl der parallel arbeitenden Benutzer genannt werden. Dazu kommen Angaben zu Transaktionszeiten für die Ausführung von Funktionen, über das zu verarbeitende Datenvolumen in einer Zeiteinheit (Durchsatz), zur Verfügbarkeit des Anwendungssystems (7x24) und zur Ausfallsicherheit beziehungsweise Stabilität. Diese Anforderungen müssen so definiert sein, dass sie auch getestet werden können. Eine verbreitete Formulierung wie "Das System muss stabil sein" ist nicht testbar und somit keine Anforderung.

Die nichtfunktionalen An- forderungen sollten zum Projektbeginn (bei Individualentwicklung) oder zur Systemeinführung (bei Standardprodukt) bekannt sein, damit entsprechende Tests eingeplant werden können. Entwicklungsbegleitende Performance-Tests helfen, mögliche Fehlentwicklungen oder -entscheidungen frühzeitig zu erkennen und so eine teurere späte Fehlerbehebung zu vermeiden.

Ein Schlüssel für den reibungslosen Projektverlauf ist die Be- teiligung von Testingenieuren. Dies beginnt bei der Projekt- planung und -initialisierung mit der Ermittlung und Definition der nichtfunktionalen Anfor- derungen für das Pflichten- heft. Aus diesen leiten sich Testmaßnahmen und -ziele ab, welche in einem Qualitätssicherungsplan festzuschreiben und in den Projektplan zu integrieren sind.

Ein Performance-Test kann entwicklungsbegleitend oder abschließend erfolgen. Der entwicklungsbegleitende Test empfiehlt sich bei Neuentwicklungen, um frühzeitig die Ursachen für Leistungsengpässe ermitteln und beheben zu können. Abschließende Tests erbringen in der Regel den Nachweis, ob ei- ne nichtfunktionale Anforderung erfüllt ist. Kommt es zu einem negativen Ergebnis, dauert das Projekt länger und wird teurer.

Für den Performance-Test sind geeignete Mitarbeiter, die Hardware für die Testumgebung, das Testwerkzeug und die Beschaffung oder Erstellung der Testdaten zu berücksichtigen. In der Vorbereitung müssen aus den nichtfunktionalen Anforderungen die Testziele und ein entsprechendes Vorgehen abgeleitet werden. Typische Tests sind:

- Lasttest: Messung der Transaktionszeiten bei parallelem Zugriff der vorgegebenen Benutzerhöchstzahl;

- Durchsatztest: Messung des Datenvolumens in einer Zeiteinheit, das vom System unter Last verarbeitet werden kann;

- Stresstest: Ermittlung der Belastungsgrenzen eines Systems abhängig von der Zahl gleichzeitiger Nutzer oder dem Datenvolumen;

- Skalierungstests beschreiben ein Anwendungssystem bei Reduktion oder Erweiterung von Hardware- oder Systemkomponenten (Anzahl Prozessoren, Speichervolumen, Anzahl an Datenbankinstanzen in einem Cluster etc.).

Aus dem Testziel werden die Testszenarien abgeleitet. Ein Testszenario ist eine Art Drehbuch, in dem die Reihenfolge, der Zeitpunkt und die Anzahl der auszuführenden Funktionen festgelegt sind. Dafür müssen die Tester wissen, mit welchen Datenmengen sie es zu tun bekommen. Bei neu entwickelten Anwendungen lässt sich das nur schätzen. In allen anderen Fällen kann das Mengengerüst bei den Fachabteilungen erfragt werden.

Testszenarien lassen sich in den Abteilungen erfragen

Eine Verkaufsabteilung überblickt beispielsweise, wann und wie viele Bestellungen sie durchschnittlich eingibt und wie viele Lieferscheine sowie Rechnungen verarbeitet werden. Für die Szenarien sind schreibende und lesende Geschäftsprozesse zu unterscheiden, weil sie das zu testende System unterschiedlich belasten. Anschließend werden die benötigten Skripte für die einzelnen Geschäftsprozesse und Szenarien erstellt.

Ein wesentlicher Erfolgsfaktor für einen Performance-Test ist eine möglichst produktionsnahe Testumgebung. In dieser sind neben der zu testenden Anwendung die Hardware, das Netzwerk und Betriebssystem sowie die Systemkomponenten wie Applikations-Server oder Datenbanken einzurichten. Für den Test sind Daten zu beschaffen oder zu erzeugen. Sie müssen ein realistisches Volumen aufweisen, weil sonst das Testergebnis verfälscht wird. Die Verwendung von Echtdaten ist aus Gründen des Datenschutzes nicht möglich, auch dann nicht, wenn sie anonymisiert werden.

Detaillierte Dokumentation ist die Grundlage

Im Test werden die Szenarien ausgeführt, und zwar mehrmals wiederholt, da das System das erste Mal unter Last arbeitet und für einen erfolgreichen Abschluss weitere Konfigurationen beziehungsweise Anpassungen notwendig sind (Tuning und Sizing). Als Grundlage für die spätere Feinanalyse gilt es, alle Änderungen sowie (Zwischen-)Ergebnisse detailliert zu dokumentieren. Jede Iteration sollte mit einer Grobanalyse abschließen, um die Verwertbarkeit der Testergebnisse zu ermitteln. In der Auswertung werden die Testergebnisse aller Szenarien und Iterationen analysiert. Mit den meisten Performance-Testwerkzeugen lassen sich die so gewonnen Rohdaten visuell darstellen. Gemeinsam mit Administratoren, Architekten und Entwicklern können daraus Aussagen und Maßnahmen abgeleitet werden.

Kommerzielle Werkzeuge kontra Freeware-Tools

Für die Vorbereitung, Durchführung und Auswertung von Performance-Tests setzt man Werkzeuge ein, die eine Automatisierung und Verwaltung der Teilschritte erlauben. Neben den großen Anbietern kommerzieller Lösungen wie Mercury Loadrunner, IBM Rational Performance Tester, Compuware QA Center Performance, Segue Silk Performer und Rad View Webload gibt es eine ganze Reihe von Freeware-Tools, die spezifische Lösungen anbieten. Unter www.testingfaqs.org sind mehr als 40 Werkzeuge zu finden.

Der wesentliche Unterschied zwischen kommerziellen und Freeware-Tools sind die Anwendungsmöglichkeiten. So können mit der Produktsuite Mercury Loadrunner nahezu alle gängigen Standard-IT-Lösungen ohne weiteren Anpassungsaufwand getestet werden; ob Software von SAP, Oracle, Siebel oder Windows-Terminal-Server-Emulationen: Die Module und Adapter sind fast lückenlos. Einfache und preiswerte Lösungen verfügen über weniger Anwendungsmöglichkeiten, enthalten aber programmierbare Schnittstellen (APIs) oder Frameworks, um beliebige Systeme einzubinden. Die Programmierung ist jedoch mit erheblichem Mehraufwand und -kosten verbunden.

Aufbau und Funktionsweise der Produkte sind ähnlich

Architektur und Methoden der Testwerkzeuge unterscheiden sich dagegen nicht wesentlich. Sie bestehen aus den Grundbausteinen Generator, Agent (oder Lasttreiber), Controller und Analyzer. Der Generator zeichnet die Geschäftsprozesse und deren Anpassung auf. Der zu testen- de Geschäftsprozess startet über ein Interface, also über einen Client oder eine Systemschnittstelle. Das Testwerkzeug er- fasst im Hintergrund die ausgeführten Teilschritte auf Protokollebene (zum Beispiel HTTP) oder auf dem Graphical User Interface (GUI) und generiert ein initiales Skript. Dieses muss weiterbearbeitet werden, um etwa die Parametrisierung zu integrieren, das heißt, fixe Variablen ersetzen (etwa Kontonummer, Nutzer-ID, Kundenname). So kommt das Skript für eine Vielzahl von verschiedenen Eingabewerten zum Einsatz. Parametrisierung und Anpassung werden von den Testwerkzeugen unterschiedlich unterstützt. Gute kommerzielle Produkte bieten einen interaktiven Workflow über eine grafische Oberfläche an. Andere Werkzeuge ermöglichen nur manuelle Parametrisierung mit entsprechendem Aufwand. In jedem Fall müssen genügend gute Daten verfügbar sein, die im Lasttest verwendet werden können.

Der Agent simuliert die virtuellen Nutzer auf den Test-Client-Rechnern, nachdem die Skripte auf speziellen Lasttreibern installiert und die Testdaten bereitgestellt worden sind. Wesentlich für die Projektierung des Lasttests ist die Anzahl der virtuellen Nutzer pro Test-Client. Diese Größe wird in der Regel durch den RAM der Lasttreiber und den Speicherbedarf der Agenten des Testwerkzeugs pro virtuellen Nutzer limitiert. Sie kann je nach RAM-Ausstattung und Tool erheblich differieren.

Der Controller ist die Steuereinheit für den Lasttest. Er kontrolliert Testtreiber und Agenten, startet den Lasttestlauf gemäß einem vorher festgelegten Szenario und speichert die Testergebnisse und Daten für die Analyse. Er steuert weitere Monitoring-Module, welche die Messung von Netzwerkgrößen und Datendurchsätzen erlauben. In der Regel ist der Controller wie ein Cockpit gestaltet, an dem ein Testingenieur alle wesentlichen Größen des Tests mitverfolgen kann.

Der Analyzer stellt die Rohdaten zur Verfügung. Auch dabei unterscheiden sich die Testwerkzeuge erheblich in Bezug auf den Komfort, die Funktionalität und die Unterstützung der Analyse. Die Aufgabe besteht darin, die Rohdaten zu interpretieren und sie mit anderen Daten (zum Beispiel Log-Dateien) zu vergleichen, so dass daraus Erkenntnisse über die Ursachen von Performance-Problemen abgeleitet werden können.

Bestandteil fast aller Testwerkzeuge ist ein Skripteditor, mit dem Benutzerszenarien erstellt werden können, sowie ein Diagrammgenerator, der die Testergebnisse grafisch darstellt. Auch wenn die Testwerkzeuge einen Lasttest weitgehend unterstützen, ist in der Regel eine tiefere Programmierung der Testskripte notwendig.

Kosten für den Performance-Test entstehen durch den Kauf beziehungsweise die Miete des Testwerkzeugs. Sie hängen bei kommerziellen Produkten in der Regel von der Anzahl der benötigten virtuellen Nutzer (VU), den Adaptoren und Modulen, die zuzüglich zu einem Standardpaket eingesetzt werden, und - im Falle einer Mietlizenz - von der Nutzungsdauer ab. Bei einer dauerhaften Anschaffung kommt die Wartung dazu. Wenn das Testwerkzeug noch in anderen Projekten verwendet werden soll, kann sich das Lizenzmodell ändern.

Die einzelnen Kostenfaktoren können je nach Anbieter und Aufgabe sehr unterschiedlich sein. Preisdifferenzen um bis zu 50 Prozent sind möglich. Dabei ist es sinnvoll, bei der Auswahl genau auf die technischen Spezifikationen zu achten und gegebenenfalls ein unabhängiges Urteil einzuholen. Angesichts immenser Kosten für Test-Tools - sie liegen im fünf oder sechsstelligen Bereich - ist das eine lohnende Investition.

Weitere Kostenfaktoren sind die zu nutzende beziehungsweise zu mietende Hardware sowie die Arbeitszeiten der zum Testteam gehörenden Mitarbeiter. In der Regel kann davon ausgegangen werden, dass ein Lasttest eine relativ klar abgrenzbare Laufzeit hat. Einfachere Tests lassen sich schon innerhalb von ein bis zwei Wochen vorbereiten, durchführen und auswerten. Größere Tests können mehrere Monate dauern, vor allem dann, wenn Wiederholungen der Testläufe nach der Optimierung des Systems notwendig sind.

Der Nutzen eines Tests erschließt sich im Projekt

Ob der Aufwand gerechtfertigt ist, ist immer eine Abwägung von Kosten und Nutzen. Der Nutzen und das Potenzial eines Performance-Tests beziehungsweise der Verbesserungsmaßnahmen erschließt sich häufig erst im Lauf des Testprojekts. Die Erfahrung zeigt, dass jeder Performance-Test wesentliche Erkenntnisse zur Verbesserung der Antwortzeiten, der Ressourcennutzung und des Betriebs des IT-Systems und damit zur Gesamtqualität liefert. Performance-Steigerungen um bis zu 100 Prozent sind keine Seltenheit. (ue)