Kolumne

Quality Time: Performancemessung, aber bitte richtig!
Kommentare

Da derzeit wieder eine Reihe von Framework-Benchmarks im Internet kursiert, wollen wir uns in dieser Kolumne mit dem Thema Last- bzw. Performancetests auseinandersetzen. Die meisten dieser „Mein Framework ist besser als dein Framework“-Vergleiche setzen dabei auf Werkzeuge wie ApacheBench [1] oder Siege [2], um eine Aussage über die Performance der getesteten Produkte zu treffen. Mit beiden Tools kann man einen oder mehrere URLs über einen definierten Zeitraum und unzählige Requests, verteilt auf konkurrierende Threads, abrufen und bekommt abschließend einen Bericht über die erzielten Antwortzeiten, den durchschnittlichen Datendurchsatz oder während des Tests aufgetretene Fehler.

Die Frage, die sich hierbei stellt, ist natürlich: Wie aussagekräftig sind solche simplen Tests für Applikationen in der freien Wildbahn? Die Antwort auf diese Frage kann eigentlich nur lauten: überhaupt nicht. Bei realen Applikationen existieren komplexe Workflows, wie z. B. der Bestellprozess in einem Onlineshop, bei dem einzelne Seiten über GET, POST usw. abgerufen werden. Außerdem existieren in aller Regel gewisse Peak-Zeiten, in denen viele konkurrierende Requests auf rechenintensiven Seiten die Hardware an ihre Belastungsgrenze bringen. Und was passiert in einer solchen Situation? Stabilisiert sich das System nach kurzer Zeit wieder oder kommt es zu einem Dominoeffekt zwischen Webserver, Anwendung, Datenbank und Web Services?

Genau um solche komplexen Szenarien zu testen und sicherzustellen, dass Anwendung und Hardware die gestellten Performanceanforderungen erfüllen, bietet sich das etablierte Testwerkzeug Apache JMeter [3] an. JMeter enthält von Haus aus eine Vielzahl an Erweiterungen für die unterschiedlichsten Anwendungsfälle, Übertragungsprotokolle und Datenformate. Sollte aber doch einmal etwas fehlen oder über die Konfigurationsparameter nicht einstellbar sein, kann man jederzeit die gewünschte Funktionalität durch eigene Skripte hinzufügen.

JMeter organisiert einzelne Tests bzw. Workflows in Thread-Gruppen. Je Gruppe kann eine Reihe von Konfigurationsparametern angegeben werden, etwa die Anzahl der konkurrierenden Requests, der Startzeitpunkt für diese Gruppe oder die Ramp-up-Zeit, in der JMeter kontinuierlich weitere Threads startet und so das System langsam unter Last setzt. Den eigentlichen Ablauf einer Thread-Gruppe definiert man über so genannte Logik-Controller. Sie sind weitgehend vergleichbar mit den Kontrollstrukturen einer regulären Programmiersprache. So existieren Schleifen-, If-, Switch- oder Random-Controller, die beliebig ineinander geschachtelt werden können und je nach Kombination den logischen Ablauf eines Tests vorgeben. Innerhalb der Controller definiert man dann die eigentlichen Request Sampler, Validierungsregeln oder Post-Prozessoren. Ein typischer Ablauf für eine solche Kombinaten aus Sampler, Validierung und Post-Prozessor sähe dann so aus:

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -