2 Performance

2.3 Vorgehensweise zur Bestimmung von Performance

2.3.5 Performancemessungen von Mehrschichtarchitekturen

Nachdem sich Benchmark-Tests hauptsächlich auf die Messungen von Hardware bzw. Computern beschränken, fehlen immer noch Techniken, um die Performance von komplexeren Systemlandschaften, wie Mehrschichtarchitekturen zu bestimmen. In komplexen Systemlandschaften spielt nicht nur die Performance jeder einzelnen Komponente eine große Rolle bei der Bestimmung der gesamten Systemperformance, sondern auch das Zusammenspiel der Komponenten untereinander. Das heißt, es ist nicht ausreichend die Performance jeder Komponente der Systemlandschaft zu bestimmen, und diese anhand von Annahmen auf das Gesamtsystem hochzurechnen. Es ist erforderlich, das gesamte System zu testen und eventuelle Engpässe festzustellen. Da es bereits schwierig ist, die Performance von einzelnen Komponenten zu definieren und zu messen, ist es notwendig, für die Performanceanalyse von Mehrschichtarchitekturen neue Ansätze zu finden.

2.3.5.1 Definition - Maß der Performance

Wie schon bei den Performancemessungen von Hardwarekomponenten gesehen, ist es schwierig, ein einheitliches Maß für die Performance zu definieren. Daher ist es unabdinglich vor jeder Messung zuerst festzulegen, welche Angaben die Performance des Systems am besten beschreiben. In den letzten Abschnitten wurden verschiedenste Definitionen vorgestellt, die versuchten die Performance der Systeme zu definieren. Bei den MIPS und FLOPS wurden die Anzahl der ausgeführten Befehle oder Operationen als Maß für die Performance gewählt, beim Dhrystone-Benchmark wurde ein eigenes Maß eingeführt, dass die Anzahl der Programmabläufe pro Sekunde darstellte. Doch in Mehrschichtarchitekturen kann ein solches Maß nicht verwendet werden, sondern es müssen neue Überlegungen angestellt werden.

In der hier gewählten Mehrschichtarchitektur einer Webanwendung ist ein geeignetes Maß für die Performance die Zeit die ein Nutzer warten muss, bis seine Anfrage bearbeitet wurde und er das Ergebnis seiner Anfrage erhält. Wie bereits erwähnt setzt sich diese Antwortzeit zusammen aus er Browserantwortzeit, der Netzwerkantwortzeit und der Serverantwortzeiten. Diese Antwortzeit im Zusammenhang mit der Anzahl der Benutzer, die gleichzeitig am System arbeiten, definiert ein Maß der Performance einer Webanwendung. Allerdings kann noch immer keine Aussage darüber getroffen werden, ob das entsprechende System performant ist oder nicht. Dies wird erst durch die Definition der Erwartungen an das System ermöglicht.

2.3.5.2 Erwartungsdefinition

Bezogen auf Webanwendungen, die aus vielen Seiten bestehen können, bedeutet dies, dass für jede mögliche Anfrage des Nutzers eine Antwortzeit definiert werden muss, die nicht überschritten werden darf, damit das System als performant bezeichnet werden kann.

Doch die Definition der Erwartungen ist ein großes Problem, da viele Parameter berücksichtigt werden müssen. Es beginnt mit der unterschiedlichen Komplexität der Anfragen und Ergebnisse, die diese Anfragen zurückliefern sollen. Die erwartete Antwortzeit eines kurzen Login-Dialogs sollte wesentlich kürzer als die erwartete Antwortzeit einer Anfrage sein, die Berechnungen über die Temperaturen der letzen Jahrhunderte durchführt und diese graphisch darstellt. Dazu kommen verschiedene Voraussetzungen und subjektive Eindrücke der Nutzer, die berücksichtigt werden müssen. Ein Nutzer der auf die Webanwendung mit einem 56kbit Modem zugreift ist es gewohnt, dass die Bearbeitung seiner Anfragen eine gewisse Zeit benötigt. Für ihn sind möglicherweise 10 Sekunden performant genug, wobei hingegen ein Nutzer der per Glasfaserkabel auf die Webanwendung zugreift und die gleiche Anfrage stellt, bereits nach 5 Sekunden kein Wort von Performance hören möchte.

Daran ist zu erkennen, dass die Erwartungsdefinition des Performancemaßes wohl überlegt und für jedes System neu abstrahiert und definiert werden muss.

2.3.5.2.1 Beispiel einer möglichen Erwartungsdefinition

Nachdem im letzten Abschnitt die Notwendigkeit der Festlegung einer Erwartungsdefinition erläutert wurde, wird nun anhand des Beispiels einer Webanwendung eine mögliche Definition angegeben.

Beim Zugriff auf eine Webanwendung müssen verschiedene Parameter beachtet werden, dazu gehören unter anderem:

Anhand dieser Parameter müssen im Idealfall für jede Kombination, Erwartungswerte für die Antwortzeiten der Nutzeranfragen definiert werden, bei denen die Anwendung in den geforderten Performancegrenzen arbeitet.

Da das Bestimmen der geforderten Antwortzeiten durch Schätzen nicht sehr erfolgversprechend ist und eine Berechnung für alle Fälle nicht möglich ist, müssen Verfahren gefunden werden, diese festzulegen.

Eine mögliche Vorgehensweise ist eine Festlegung eines Referenzwertes, der durch Messung eines ausgewählten Szenarios ermittelt werden kann. Dazu wird eine Basiskonfiguration aller Parameter festgelegt und es werden die Antwortzeiten alle Seiten der Webanwendung ermittelt.

Für die oben genannten Parameter sollten die bestmöglichen Annahmen gewählt werden. Das heißt, als Basisparameter sollten zum Beispiel die größte Bandbreite und eine sehr geringe Nutzerzahl herangezogen werden.

Nach der Bestimmung des Referenzwertes kann nun ein Akzeptanzfaktor festgelegt werden, der abhängig von den Parametern, die erwarteten bzw. geforderten Antwortzeiten definiert, die nicht überschritten werden dürfen, um das System als performant zu bezeichnen. Daraus lassen sich nun die maximal erlaubten Antwortzeiten für jede Seite der Webanwendung berechnen. Der Akzeptanzfaktor kann aus den Definitionen der verschiedenen Parameter zusammengesetzt werden.

Angenommen, Nutzer greifen über 3 verschiedene Bandbreiten auf die Webanwendung zu - 56k-Modem, ISDN-Modem mit Kanalbündelung und einer 2 MBit-DSL-Leitung. Der Referenzwert wurde mit der Basis der 2MBit-DSL-Leitung gewählt und definiert damit den Teilakzeptanzfaktor für den Bandbreitenparameter 2MBit-DSL mit AF-Bandbreite2MBit=1. Für den Zugriff über ein ISDN-Modem wird festgelegt, dass die Antwortzeiten 6-fach so hoch sein dürfen, für ein Modem sogar 9-fach. Daraus folgt AF-BandbreiteIsdn=6 und AF-Bandbreite56k=9.

Die Abhängigkeit des Akzeptanzfaktors von der parallelen Nutzerzahl, die gleichzeitig auf das System zu greifen, muss prozentual festgelegt werden.

Angenommen, dass für je 100 Nutzer die Antwortzeiten um 2% steigen dürfen, wird als Teilakzeptanzfaktor für die Nutzerzahl definiert:

AF-pNutzer = 0.02 x parallele Nutzerzahl / 100.

Der für dieses Beispiel nur aus zwei Parametern definierte Akzeptanzfaktor lässt sich nun formulieren als:

AFGesamt = AF-pNutzer x AF-Bandbreite.

Hierbei sind die Teilfaktoren, abhängig von den durchzuführenden Tests, einzusetzen.

Auf diese Weise ist der Akzeptanzfaktor erweiterbar auf weitere Teilfaktoren, die ein System beeinflussen können und in die Erwartungsdefinition einbezogen werden sollen.

Der Akzeptanzfaktor kann nun mit den ermittelten Referenzwerten für jede Seite (AZ-Ref-Seite) der Webanwendung multipliziert werden und liefert damit für jede Seite abhängig von den durchgeführten Tests die Erwartungs- bzw. Grenzwerte, die nicht überschritten werden dürfen.

EWSeite = AFGesamt x AZ-Ref-Seite

Durch diese Grenzwerte ist es nach der Durchführung der Tests möglich, konkret zu entscheiden, ob ein System den Anforderungen entspricht oder nicht. Ist der Erwartungswert größer als die ermittelten Antwortzeiten der entsprechenden Seite, so ist die Seite, als performant zu bezeichnen, ist der Erwartungswert kleiner, entspricht die Seite nicht der geforderten Performance.

Der Fall, dass Anfragen an eine Seite teilweise über und teilweise unterhalb des Erwartungswertes liegen, wird auftreten. Daher ist es sinnvoll sich statistischer Verfahren zu bedienen, welche den Standardfall herausfiltern können. Dieser sollte dann als Vergleichswert genutzt werden. Es bieten sich aus der Statistik Verfahren zur Berechnung des Streumaßes an, die bei der Bestimmung eines repräsentativen Wertes aus der Menge der Antwortzeiten einer Seite herangezogen und mit dem Erwartungswert verglichen werden kann. Während das arithmetische Mittel in vielen Fällen schon ausreichend ist, bieten Varianz, Standardabweichung, Variationskoeffizient oder Interquartialsabstand eine größere Sicherheit, dass wenige fehlerhafte Messwerte den Standardfall nicht zu sehr verfälschen.

Startseite - Sitemap - Impressum - nach oben
Hinzufügen zu Favoriten: Diese Seite zu Mister Wong hinzufügen

STRATO MultiServer: „Ich bin viele Server!“ 1&1 DSL

Nutzen Sie das City-Firmenportal um Ihre Firma bekannt zu machen!
Gogo Performance Berlin - Performance Gogo Girl Berlin - Gogo Tänzerin in Berlin


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