Sie sind hier: Startseite » Kapitel 4 - Bottleneck- Analyse » Black-Box-Tests und Analyse-Hierarchien 

4 Bottleneck-Analyse in Mehrschichtarchitekturen

4.1.4 Bottleneck-Analyse mittels Black-Box-Tests und Analyse-Hierarchien

Da reine Black-Box-Test nicht zu erfolgversprechenden Ergebnissen führen, wird die Black-Box in diesem Ansatz etwas gelockert. Die Struktur der Black-Box ist während der Vorbereitung der Testdaten, die über die Schnittstelle in das System übermittelt werden, bekannt. Während der Durchführung der Tests wird das Gesamtsystem aber weiterhin als Black-Box betrachtet und es fließen nur die Ein- und Ausgaben an der Schnittstelle in die Analyse ein.

Die Aufgabe, Engpässe im Gesamtsystem zu identifizieren, wird nun darüber gelöst, indem die Testdaten so gewählt werden, dass nur bestimmte Komponenten im System unter Last gesetzt werden. Durch den Vergleich der erhaltenen Antwortzeiten der verschiedensten Testszenarios ist es dann möglich, Engpässe aufzudecken.

Die Schwierigkeit besteht nun darin, Testszenarios so anzulegen, dass eine Hierarchie der Systemkomponenten aufgebaut werden kann. Diese Testszenarios sind sehr speziell und müssen für jedes zu testende System neu angelegt werden.

Am Beispiel der oben vorausgesetzten Webanwendung kann eine Hierarchie der Komponenten durch folgende Testszenarios aufgebaut werden:

• Testszenarios, die nur Anfragen an das System stellt, die weder Zugriff auf die Datenbank noch irgendeine Authentifizierung benötigen. Hierzu gehören alle statischen Webseiten, die kein Login der Nutzer benötigen.
• Testszenarios, die nur die Authentifizierung der Nutzer durchführen. Hierzu gehören die Login-Webseiten und der Aufruf von Seiten, die bereits eingeloggte Nutzer voraussetzen.
• Testszenarios, die nur lesenden Zugriff auf der Datenbank ausführen. Seiten die Suchformulare aufbauen und die Seiten die Ergebnisse möglicher Suchen darstellen, gehören in diese Kategorie.
• Testszenarios, die auch schreibenden Zugriff auf der Datenbank ausführen. In zum Beispiel Shopsystemen gehören Seiten zum Erstellen von neuen Nutzern oder Artikeln dazu.
• In Anwendungen, die eine komplexe Applikationslogik besitzen, sollten auch Testszenarios erstellt werden, welche komplexe Berechnungen oder ähnliches anstoßen. Dies setzt dann hauptsächlich die Applikationsserver und eventuell die Datenbank unter Last.
• Testszenarios, die einen möglichst realen Mix des späteren Nutzerverhaltens darstellen.

Nach Erstellung der Testszenarios und der Ermittlung der Rauschwerte des Netzwerkes werden die Lasttests für alle Testszenarios durchgeführt. Hierzu werden die Tests mit verschiedenen parallelen Nutzeranzahlen gestartet. Durch den Vergleich der ermittelten Antwortzeiten der einzelnen Testszenarios, lassen sich zum einen die Komponenten identifizieren, die den größten Anteil der Gesamtantwortzeit in Anspruch nehmen und zum anderem kann die Lastgrenze für jede beteiligte Systemkomponente identifiziert werden. Kann eine einzelne Komponente die gewünschten Anforderungen schon nicht erfüllen, so wird es das Gesamtsystem definitiv auch nicht.

Sobald das System optimiert wurde, so dass die einzelnen Testszenarios den Anforderungen entsprechen, kann das letzte Testszenario zum erneuten Test des Gesamtsystems genutzt werden. Treten hierbei erneut Performanceprobleme auf, die durch die Korrelation der einzelnen Systemkomponenten entstehen können, ist eine schrittweise Integration der Hierarchieebenen notwendig. Dies setzt das Verschmelzen zweier oder mehrerer Testszenarios und den Aufbau einer höher abstrahierten Hierarchie voraus.

4.1.4.1 Vorteile

• Es werden nur die Antwortzeiten aller Anfragen der Testszenarios betrachtet. Dies minimiert die Datenmenge, die verwaltet werden muss.
• Keine Abhängigkeit von möglicherweise ungenauen Performancezählern.
• Durch die Hierarchie der Testszenarios können einzelne Systemkomponenten getestet und optimiert werden.

4.1.4.2 Nachteile

• Es müssen viele spezielle Testszenarios erstellt werden, bei denen ein breites und tiefgehendes Wissen, über den Aufbau und die Implementierung des zu testenden Systems, vorausgesetzt wird. Dies ist ein sehr zeitaufwendiger Prozess.
• Die Anzahl der Tests steigt exponentiell mit den zu betrachten Umgebungseinflüssen. Erwähnt seien hier, unterschiedliche Zugriffsbereiche auf das System - intern/extern (mit/ohne Firewalls), verschiedene Zugangsbandbreiten der Nutzer - DSL/ISDN/Modem.
• Die erstellten Testszenarios müssen für jedes zu testende System neu entworfen werden und können meist nicht wiederverwertet werden.
• Während der gesamten Testphase muss ein funktionales und stabiles Testsystem vorliegen, welches durch keine neueren Versionen verändert werden sollte, da dies zu Problemen in der Analyse der ermittelten Ergebnisse führen würde.

4.1.4.3 Fazit

Die Bottleneck-Analyse mit Hilfe von Black-Box-Tests und Analyse-Hierarchien setzt einen erheblichen Vorbereitungsaufwand bei der Erstellung der Testszenarios voraus. Dieser Aufwand ermöglicht aber eine sehr gute Analyse der Gesamtperformance des Systems und dadurch das Aufdecken von Engpässen. Durch die Wahl der Testszenarios ist es ebenfalls in kleineren Testphasen möglich, die Systemkomponenten, die als Engpass identifiziert worden sind, zu optimieren und erneut zu testen.