6 Weiterführende Aufarbeitung der Ergebnisse

6.5 Erstellen von Abfragen zur Visualisierung

Nach dem Import der Daten in die vorher entworfene Datenbank ist es nun möglich, Analysen über einen oder auch die Gesamtheit aller Tests durchzuführen.

Interessante Abfragen für die Analyse sind:

6.5.1 Allgemeine Abfragen zu einem Testdurchlauf

Diese Abfragen geben einen Überblick über die Durchführung des Testdurchlaufs. Es können globale Informationen, wie die Gesamtanzahl der simulierten Nutzer, den Datendurchsatz über den gesamten Testdurchlauf oder die Anzahl der erfolgreich und nicht erfolgreich durchgeführten Anfragen, abgefragt werden.

• Zeige die Anzahl der simulierten Nutzer, die Anzahl der erfolgreich und der nicht erfolgreich durchgeführten Anfragen und deren durchschnittliche Antwortzeit während des Testdurchlaufes
  • select tl.tl_gesNutzer, tl.tl_gesAnfragenErfolg, tl.tl_gesAnfragenFehler, tl.tl_gesAntwortzeitenMittel from testlaeufe tl where tl.id=1

Eine Verfeinerung der globalen Information erhält man zum Beispiel dadurch, dass die Zeitpunkte einer erhöhten Last genauer herausgefiltert werden.

• Zeige die 10 Zeitpunkte und die derzeitige Nutzerlast, zu denen die höchste durchschnittliche Antwortzeit alle Anfragen bestand
  • select td.td_Time, td.td_UserLoad, td.td_DurationAvg from testdaten_global td, testlaeufe tl where td.id=tl.td_id and tl.id=1 order by td.td_DurationAvg asc limit 10

Diese Beispiele haben ihre Informationen aus den zusammengefassten Daten über alle Anfragen eines Testdurchlaufes bezogen. Im folgenden werden Anfragen erstellt, die Rückschlüsse auf die Performance von einzelnen Testfällen oder sogar einzelner Anfragen ermöglichen.

6.5.2 Anfragenspezifische Abfragen zu einem Testdurchlauf

• Zeige die 10 Anfragen mit den höchsten durchschnittlichen Antwortzeiten
  • select tf.tf_name, a.a_name, td.td_DurationAvg from testdaten_anfrage td, testlaeufe tl, anfragen a, testfaelle tf, testfallverteilung tfv, testfall_anfrage tfa where td.tl_id=1 and tl.tsz_id = tfv.tsz_id and tfv.tf_id=tfa.tf_id and tfa.a_id=td.a_id order by td.td_DurationAvg asc limit 10

• Zeige die 10 Anfragen mit der höchsten Fehlerzahl
  • select tf.tf_name, a.a_name, sum(td.td_Errors) from testdaten_anfrage td, testlaeufe tl, anfragen a, testfaelle tf, testfallverteilung tfv, testfall_anfrage tfa where td.tl_id=1 and tl.tsz_id = tfv.tsz_id and tfv.tf_id=tfa.tf_id and tfa.a_id=td.a_id group by td.td_Errors, a.a_name, tf.tf_name order by td.td_Errors asc limit 10

Neben dem Anfragenamen wird auch der Testfall aufgeführt, zu der die Anfrage gehört. Verwenden mehrere Testfälle dieselben Anfragen, kann auch von den Testfällen abstrahiert und die Werte über die Testfälle hinaus zusammengefasst werden.

• Zeige die 10 Anfragen mit der höchsten Fehlerzahl unabhängig von den festgelegten Testfällen
  • select a.a_name, sum(td.td_Errors) from testdaten_anfrage td, testlaeufe tl, anfragen a, testfaelle tf, testfallverteilung tfv, testfall_anfrage tfa where td.tl_id=1 and tl.tsz_id = tfv.tsz_id and tfv.tf_id=tfa.tf_id and tfa.a_id=td.a_id group by td.td_Errors, a.a_name order by td.td_Errors asc limit 10

Auf der anderen Seite kann es auch sinnvoll, die Daten abhängig von den verwendeten Testfällen zu analysieren, aber auf die Unterscheidung der Anfragen zu verzichten.

• Zeige die durchschnittlichen Antwortzeiten aller Anfragen eines Testfalls
  • select tf.tf_name, avg(td.td_DurationAvg) from testdaten_anfrage td, testlaeufe tl, anfragen a, testfaelle tf, testfallverteilung tfv, testfall_anfrage tfa where td.tl_id=1 and tl.tsz_id = tfv.tsz_id and tfv.tf_id=tfa.tf_id and tfa.a_id=td.a_id group by td.td_DurationAvg, tf.tf_name order by td.td_Errors asc limit 10

Diese Beispiele zeigen einen kleinen Ausschnitt der möglichen Abfragen, die über die gesammelten Daten zu einem Testdurchlauf erstellt werden können. Jede dieser Abfragen führt zu einem Mehrwert an Informationen über die Performance des Systems. Die Identifikation von potentiellen Anfragen mit zu hohen Antwortzeiten oder der Vergleich der Antwortzeiten von verschiedenen Testfällen kann auf Schwachstellen im System oder in der Implementierung der Anwendung hinweisen.

Eine tiefergehende Analyse der Testdaten erfolgt in der Auswertung, der in vorangegangenen Kaptiteln beschriebenen Analyse mittels erstellter Hierarchien.

6.5.3 Abfragen zur Analyse mittels Hierarchien

Die meisten Lasttesttools ermöglichen eine Analyse nur über einen durchgeführten Performancetest, bieten aber nicht die Funktionalitäten, verschiedene Testdurchläufe mit unter-schiedlichen Testparametern zu vergleichen. Dies ist aber gerade für die Bottleneck-Analyse auf Basis von Hierarchien notwendig und zeigt den Mehrwert, der durch die Erstellung des Datenbankschemas erreicht wird.

In den folgenden Abschnitten werden Anfragen formuliert, die auf Basis des erstellten Datenbankschemas und der definierten Hierarchien zur erweiterten Analyse genutzt werden können.

6.5.3.1 Lokale Hierarchie

Mittels der Analyse mit Hilfe der lokalen Hierarchie ist ein Vergleich der Antwortzeiten der verschiedenen Zugänge in das System möglich. Dadurch wird erkennbar, ob Architektur-Komponenten, die zwischen den lokalen Schichten liegen, einen Engpass im System darstellen. Hierzu werden gleiche Testszenarios von verschiedenen Netzwerkeinstiegspunkten abgefragt.

• Zeige die durchschnittlichen Antwortzeiten der verschiedenen Netzwerkeinstiegspunkte für das Testszenario mit der Id 1
  • Um die SQL-Abfrage übersichtlich zu halten, wurde auf die Auswahl der Testlaufparameter verzichtet. Diese oder die Auswahl der gewünschten Testläufe für die Analyse müssen der Abfrage hinzugefügt werden.
  • select tlk.tlk_Netzwerkeinstieg, tl.tl_gesNutzer, tl.tl_gesAnfragenErfolg, tl.tl_gesAnfragenFehler, tl.tl_gesAntwortzeitenMittel from testlaeufe tl, testlaufkonfiguration tlk where tl.tlk_id=tlk.id and tl.tsz_id=1 and tlk.tlk_Netzwerkeinstieg is not null order by tlk.tlk_Netzwerkeinstieg asc

Als Ergebnis erhält man die gewünschten Informationen sortiert nach den Netzwerkeinstiegspunkten. Große Abweichungen deuten auf einen Engpass, leichte Abweichungen lassen sich durch den längeren Weg der Daten entfernterer Einstiegspunkte bzw. durch das Netzwerkrauschen erklären.

Es lassen sich alle in den oberen Abschnitten definierten Anfragen auf die lokale Hierarchie anwenden. Dadurch wird es wiederum möglich, die Testfälle oder sogar Anfragen zu identifizieren, die den Engpass zwischen den lokalen Schichten verursachen.

• Zeige für jeden Testfall des Testszenarios mit der Id 1, die Anfrage mit der höchsten durchschnittlichen Antwortzeit gruppiert nach den Netzwerkeinstiegspunkten.
  • Die Auswahl der entsprechenden Testläufe muss wiederum hinzugefügt werden.
  • select tlk.tlk_netzwerkeinstieg, tf.tf_name, a.a_name, max(td.td_DurationAvg) from testdaten_anfrage td, testlaeufe tl, anfragen a, testfaelle tf, testfallverteilung tfv, testfall_anfrage tfa, testlaufkonfiguration tlk where td.tl_id=tl.id and tl.tsz_id = tfv.tsz_id and tfv.tf_id=tfa.tf_id and tfa.a_id=td.a_id and td.a_id=a.id and tfv.tf_id=tf.id and tfa.tf_id=td.tf_id and tf.id=td.tf_id and tl.tsz_id=1 and tl.tlk_id=tlk.id and tlk.tlk_netzwerkeinstieg is not null group by tlk.tlk_netzwerkeinstieg, td.tf_id order by tf.tf_name asc

Eine mögliche Ausgabe zu einem kleinen System mit zwei Netzwerkeinstiegspunkten (A und B) und einem gewählten Testszenario, bestehend aus 3 Testfällen (CM TS_A - CM TS_C) ist in Abbildung 6.5-1 dargestellt.

Abbildung 6.5-1 - Ergebnis der Abfrage zur lokalen Hierarchie

Anhand dieser Daten, die für den Netzwerkeinstiegspunkt A deutlich höhere Werte liefern, ist ein Bottleneck in den Komponenten zu vermuten, die ausschließlich vom Netzwerkeinstiegspunkt A benutzt werden. Dies könnte eine Firewall oder aber auch eine langsame Netzwerkverbindung sein.

6.5.3.2 Qualitative Hierarchie

Durch den Vergleich von Antwortzeiten spezieller Testszenarios, die sich durch unterschiedliche Nutzung von Systemkomponenten auszeichnen, sind Anfragen zu erkennen, die besonders schwergewichtig sind und eventuell Optimierungen erfordern. Hierbei darf jedoch nicht vernachlässigt und muss in der Interpretation der Daten beachtet werden, dass bestimmte Testszenarios von Ihrer Art her mehr Zeitaufwand benötigen. Durch die Verknüpfung der Testszenarios sind aber auch Einflüsse erkennbar, die durch Korrelation von Systemkomponenten hervorgerufen werden.

Hierzu könnten als Beispiel folgende Abfragen formuliert werden. Diese entsprechen den Abfragen aus den vergangenen Abschnitten, welche durch das Angeben der entsprechenden Testfälle oder Testszenarios ergänzt werden müssen:

• Zeige die 10 maximalen Antwortzeiten der Testszenarios/Testfälle, die nur die Authentifizierung der Nutzer vornehmen.
• Zeige die 10 maximalen Antwortzeiten der Testszenarios/Testfälle, die nur lesend auf die Datenbank zu greifen, ohne das Nutzer sich authentifizieren müssen.
• Zeige die 10 maximalen Antwortzeiten der Testszenarios/Testfälle, die nur lesend auf die Datenbank zu greifen und die Nutzer authentifiziert sein müssen bzw. die Authentifizierung erneut durchgeführt werden muss.

Das im dritten Punkt aufgeführte Testszenario sollte die Kombination aus den ersten beiden Punkten sein.

Diese Abfragen können auf Basis der Testszenarios oder auf der Basis von Testfällen durchgeführt werden und unterscheiden sich nur in der Auswahl der entsprechend genutzten Tabellen für die Abfragen.

Der Vergleich der Ergebnisse dieser Abfragen vermittelt einen Überblick über den Einfluss einzelner Systemkomponenten auf die Gesamtperformance.

Diese Methode kann auf allen Ebenen der qualitativen Hierarchie angewendet werden, um so den Einfluss der Korrelation zwischen zwei oder mehreren Ebenen aufzudecken.

6.5.3.3 Quantitative Hierarchie

Die quantitative Hierarchie bilden die Lasttests mit den festgesetzten parallelen Nutzerzahlen. Gleiche Testszenarios, die mit verschiedenen Nutzerzahlen ausgeführt werden, repräsentieren das Verhalten des Systems unter steigender Last. Durch die Verwendung von definierten Sollantwortzeiten bzw. des eingeführten Akzeptanzfaktors ist für jedes Testszenario, die maximale Nutzerzahl erkennbar. Als repräsentativer Wert kann entweder der 90%-Durchschnittswert, bei dem die 5% der geringsten und 5% der höchsten Antwortzeiten ignoriert werden oder die über die Standardabweichung oder durch andere statistische Methoden normalisierten Antwortzeiten gewählt werden.

Die minimale bestimmte Nutzerzahl aller Testszenarios legt die maximale Nutzerzahl fest, unter der, das Gesamtsystem in den geforderten Grenzen arbeitet. Dies ist eine der wichtigsten Information zur Bestimmung der Gesamtperformance eines Systems.

• Zeige für jedes Testszenario und jede Nutzerzahl jedes Lasttests auf dem Produktivsystem die minimale, maximale und durchschnittliche Antwortzeit
  • select tl.tsz_id, td.td_UserLoad, td.td_DurationMin, td.td_DurationMax, td.td_DurationAvg from testlaeufe tl, testlaufkonfiguration tlk, testdaten_global td where tl.tlk_id=tlk.id and tl.td_id=td.id and tlk.tlk_System='PS' and tlk.tlk_Testart='Lasttest' group by tl.tsz_id, td.td_UserLoad

Eine mögliche Ausgabe für 2 Testszenarios mit durchgeführten Lasttests mit 200, 500 und 1000 parallelen Nutzern ist in Abbildung dargestellt.

Abbildung 6.5-2 - Ergebnis der Abfrage zur quantitativen Hierarchie

Für den Fall, dass die Anforderungen an die Anwendung definiert sind, kann nun die Nutzerzahl ermittelt werden, für die das Gesamtsystem in den vorgegebenen Grenzen arbeitet. Je nach der Genauigkeit der erstellten Anforderungen - Gesamtheit aller Anfragen, testszenariobasiert oder anfragenbasiert, muss diese Anfrage angepasst werden. In diesem Fall ist sie für Testszenarios erstellt worden. Sei für alle Anfragen des Testszenarios 1 die geforderte maximale Antwortzeit von 7 Sekunden angegeben, so erfüllt das System dies noch für 500, aber nicht mehr für 1000 parallele Nutzer. Sind nur globale Grenzen für die Antwortzeiten gesetzt, kann die Abfrage verallgemeinert werden oder die Werte aller Testszenarios müssen in die Auswertung mit einfließen.

Sind die jeweiligen geforderten Antwortzeiten ebenfalls in der Datenbank gespeichert, werden nun Abfragen möglich, welche die maximale Nutzerzahl bestimmt, die das Gesamtsystem in den geforderten Grenzen arbeiten lässt. Hierzu werden die gewünschten Werte einfach verglichen und somit die maximale parallele Nutzerzahl bestimmt.

All diese Anfragen setzen voraus, dass die gesammelten Daten der verwendeten Tests unter den gleichen Testbedingungen erfasst und dass bei den erstellten Abfragen auch auf mögliche Fehlerquellen geachtet wurde. Zu diesen gehören Verfälschungen der Antwortzeiten durch nicht korrekt gestellte Anfragen oder Fehlverhalten des Systems, zum Beispiel Timeouts oder durch fehlende Authentifizierung oder ungültige Syntax abgelehnte Anfragen.

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