2 Performance

2.3 Vorgehensweise zur Bestimmung von Performance

Die Planung und Durchführung von Performancetests ist ein wichtiger, aber auch komplexer und aufwendiger Prozess. In den letzten Jahren wurden viele Methoden nicht nur für viele Bereiche der Informatik entwickelt, um die Performance von Softwareprodukten, Komponenten oder komplexen Systemen zu bestimmen.

Diese grundlegenden Schritte sind:

• Bestimmung der Parameter, welche die Leistung des Systems ausdrücken.
• Definition der geforderten Performancegrenzen
• Durchführung von Performancetests
• Vergleich von Ist- und Sollwerte
• Interpretation der Daten zur Bestimmung der Schwachstelle
• Optimierung des Systems bzw. der Software

B. Beizer unterteilt die Phasen zur Bestimmung der Performance auf folgende Weise:

"Performance testing can be undertaken to: 1) show that the system meets specified performance objectives, 2) tune the system, 3) determine the factors in hardware or software that limit the system's performance, and 4) project the system's future load- handling capacity in order to schedule its replacements". [7]

Da sich diese Arbeit mit Performancetests und der Bestimmung von Engpässen in Multischichtarchitekturen befasst, wird nicht näher auf die Möglichkeiten der Performanceanalyse von Software eingegangen, sondern nur Methoden vorgestellt, die auch auf die Bestimmung der Performance von Systemen und ihren Komponenten ausgelegt sind. Einige dieser Methoden werden selbstverständlich auch in anderen Bereichen angewendet.

2.3.1 Benchmarking

Sowohl in der Informatik als auch in anderen Bereichen sind Benchmark-Tests weit verbreitet. In der Informatik dienen sie der Messung von Hardwarekomponenten oder -systemen und ermöglichen durch Vergleich der Ergebnisse, Aussagen über ihre Performance zu treffen.

2.3.1.1 Mips und Flops

In den 70iger Jahren wurde Performance von Prozessoren in Mips und Flops dargestellt. Die Abkürzung Mips steht für Millionen von Befehlen pro Sekunde ("Million Instructions per Second"), die Abkürzung Flops für Fließkomma-Operationen pro Sekunde ("Floating-Point Operations per Second"). Diese Einheiten waren weit verbreitet und sollten die Möglichkeit geben die Performance von verschiedenen Prozessoren zu vergleichen. Doch eine wirkliche Aussagekraft über die Gesamtperformance ist durch diese Angaben nicht erreichbar, da nicht nur die Anzahl der Operationen oder Befehle eine Rolle spielt, sondern auch die Art der Befehle und deren Verarbeitung. Hier seien nur die unterschiedlichen Ansätze RISC ("Reduced Instruction Set Computer") und CISC ("Complex Instruction Set Computer") erwähnt.

Die Messungen und die erlangten Ergebnisse sind nicht ausreichend, um wirklich die Performance des Gesamtsystems darzustellen.

2.3.1.2 Whetstone-, Dhrystone-, Linpack- und Livermore-Benchmarks

Einige der bekanntesten Benchmarks sind Whetstone-, Dhrystone-, Linpack- und Livermore-Benchmarks, die während der 70iger und 80iger Jahre entwickelt wurden. Nachdem erkannt wurde, das die Ermittlung der Performance von Systemen nicht nur durch "Zählen der ausgeführten Befehle" erfolgen kann, aber die Notwendigkeit gesehen wurde, Systeme anhand ihrer Performance einzuteilen, wurden Benchmarks entwickelt. Dabei handelt es sich um Testprogramme, die auf den zu testenden Systemen ausgeführt werden und entsprechende Werte aufzeichnen.

Der Whetstone-Benchmark war der erste Benchmark, der geschrieben wurde, um die Performance von Systemen zu bestimmen. Dazu simuliert er Fließkommazahloperationen. Beim Dhrystone-Benchmark werden verschiedene Operationen zur Ermittlung der CPU sowie der Speicher-Performance verwendet. Dazu gehören Integer- und String-Operationen. Die Einheit Dhrystone gibt die Anzahl der Durchläufe pro Zeiteinheit an, wobei ein Dhrystone einen Programmdurchlauf pro Sekunde darstellt. Der Linpack-Benchmark wurde abgeleitet von realen Anwendungen und basiert auf einer Sammlung von Funktionen aus der linearen Algebra. Er führt ebenfalls Fließkommazahloperationen aus, deren Ergebnisse in MFLOPS angegeben werden. [8][9]

2.3.1.3 SPEC - "Standard Performance Evaluation Corporation" [10]

SPEC wurde 1988 von einer kleinen Gruppe von Hardwareanbietern gegründet und stellen Benchmarks zur Verfügung, die es ermöglichen die Performance von Hardwarekomponenten oder Systemen zu vergleichen. SPEC entwickelt portable Testprogramme, die auf den unterschiedlichsten Systemen arbeiten können. Die Firmen, welche ihre Systeme messen lassen wollen, können diese Testprogramme ausführen und ihr System so anpassen, dass die Testprogramme, die für das System besten Ergebnisse liefern. Diese Ergebnisse werden von SPEC gesammelt und jedem zur Verfügung gestellt. Da die Testprogramme von SPEC dabei nicht verändert werden, sind die gesammelten Daten von allen Firmen in einem hohen Maße vergleichbar. SPEC führt ihre Testprogramme ebenfalls auf Referenzmaschinen aus um einen festen Vergleichspunkt zu besitzen. Für die Testprogramme SPEC92 war dies eine VAX-11/780, für die SPEC95 eine SPARCstation 10/40 (40MHz SuperSPARC ohne L2 Cache).

Auf diese Weise ist es Ihnen gelungen die Performance von Systemkomponenten und Systemen in bezug auf die getesteten Parameter vergleichbar zu machen. Ein Problem besteht darin, dass viele Firmen ihre Systeme speziell auf die Testprogramme ausrichten und optimieren, so dass die Gesamtperformance nicht vollständig auf die getesteten Parameter zurückzuführen ist.

2.3.2 Black-Box-Tests

Bei einem Black-Box-Test werden Testdaten in ein System eingegeben. Ohne das Wissen darüber, wie diese Eingaben von System verarbeitet werden, zeichnet man die Ergebnisse und Umgebungsvariablen auf, um Aussagen über das Arbeiten des Systems zu treffen.

In einer Mehrschichtarchitektur, hier eine komplexe Webanwendung, heißt dies, dass die Eingaben einzelne Webanfragen von Nutzern sind, deren Ausführung und Darstellung der gewünschten Seite eine gewisse Zeit benötigen. Diese Zeit wird gemessen, ohne zu wissen, welche Schritte vom Absenden der Anfrage, bis zum Darstellen der Seite, durchgeführt worden sind.

Ein Problem bei Black-Box-Tests ist die Auswahl der Testfälle. Da das Testen aller möglichen Eingabekombinationen meist nicht realisierbar ist, müssen repräsentative Testfälle gewählt werden. Hier seien nur "Equivalence Partitioning", "Grenzwertanalyse" und "Error Guessing" genannt. [11]

2.3.3 White-Box-Tests

Im Gegensatz zu den Black-Box-Tests, bei denen das Wissen über die Struktur des zu testenden Systems nicht berücksichtigt wird, setzen White-Box-Test genau bei diesem konkreten Wissen an. Allgemein gesehen, versuchen White-Box-Tests möglichst viele Teile eines Systems oder Programms durch Testfälle abzudecken.

Das Ziel von White-Box-Tests in der Softwareentwicklung ist es, dass Codesegmente oder auch Programme bestimmte Kriterien erfüllen. Diese können nach kontrollflussabhängigen und datenflussabhängigen Testkriterien unterschieden werden. Die datenflussabhängigen Kriterien beziehen sich auf Variablen und ihre zulässigen Werte, die kontrollflussabhängigen Kriterien werden weiter unterschieden nach anweisungsüberdeckend, zweigüberdeckend, Mehrfachbedingungsüberdeckung und Pfadüberdeckung. Dementsprechend werden Testfälle generiert, die diesen Anforderungen entsprechen und somit ein gutes Testszenario liefern, um mögliche Fehler zu entdecken. Allerdings reichen diese Testkriterien nicht aus, da die Testfälle nicht die Semantik des Systems wiederspiegeln und eventuell nicht alle Kontrollflüsse erfasst worden sind.

Das Problem, der Erfassung aller Kontrollflüsse, ist schon bei größeren Programmen eine kaum zu meisternde Aufgabe, da die Anzahl der Pfade für die Pfadüberdeckung exponential mit der Anzahl der Anweisungen steigt. Bei mehrschichtigen Architekturen bleibt dieses Problem bestehen und ermöglicht es kaum, eine vollständige Menge von Testfällen auf diese Art zu erzeugen. Aus diesem Grund wird der traditionelle White-Box-Test auch als "codebasierter Test" bezeichnet.[12]

Allerdings ist das Wissen über die Struktur auch bei mehrschichtigen Architekturen hilfreich und unterstützt die Erstellung von speziellen Testfällen, die zum Beispiel einzelne Komponenten stärker belasten oder sogar ausklammern. Dies unterstützt die Fehlersuche erheblich.

2.3.4 Grey-Box-Tests

Der Grey-Box-Test ist eine Methode, welche die Vorteile der eben aufgeführten Black-Box- und White-Box-Tests vereinigt. Die genaue Anwendung ist unterschiedlich. So können wie beim Black-Box-Test die Testdaten an der Schnittstelle des Systems eingegeben, aber für die Analyse, das Wissen über die Struktur des zu testenden Systems benutzt werden, um Schwachstellen zu identifizieren. Für Webanwendungen in einer Multischichtarchitektur ist dies ein nicht zu verachtender Vorteil.

Hung Quoc Nguyen beschreibt in seiner Arbeit "Testing Applications on the Web" die Vorteile des Grey-Box-Tests.

"Es vereinigt die Einsicht eines Software-Entwicklers in das Produkt (interne Datenstrukturen, Architektur auf Source-Code Ebene), die im White-Box Testing benutzt wird, mit der Sichtweise des End-Benutzers, der das erwartete Verhalten der Anwendung testet (Black-Box Testing). Für das Testen von Web-Applikationen ist diese Vorgehensweise des Gray-Box Testing wesentlich, da Web-Applikationen eine Vielzahl von Komponenten (sowohl Hard- als auch Software) enthalten." [13]

Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren  Black box test White box test Grey box test testnutzer Virtuelle User Lasttest