*/-->
/*
@licstart The following is the entire license notice for the
JavaScript code in this tag.
Copyright (C) 2012 Free Software Foundation, Inc.
The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
@licend The above is the entire license notice
for the JavaScript code in this tag.
*/
*///-->
Lasttests sind ein wichtiges Instrument, um vor dem öffentlichen Start eines
Webangebotes die vorgesehene Infrastruktur daraufhin zu prüfen, ob
sie der erwarteten Zahl von Besuchern gewachsen ist, oder um
unabhängig von Erwartungen zu eruieren, welche Belastungen mit
ausreichender Leistung zu schultern sind.
Mit diesem ersten Teil einer Serie von Artikeln, gebe ich einen
Überblick in die eingesetzte Software – allesamt OpenSource-Projekte
– und einen Ausblick auf die vertiefenden Artikel die in dieser
Reihe zu erwarten sind.
Einführung
Kein Angebot, das am Markt bestehen will, kann längere
Unerreichbarkeit oder dauerhaft schlechte Performance
tolerieren. Last- und Stresstests sind ein probates Mittel, Engpässe
zu erkennen und zu beseitigen, bevor der Erfolg eines Produktes durch
Überlastung den Misserfolg einleitet.
Dabei muss klargestellt werden, dass Last- und Stresstests weder Unit-
noch Integrationstests ersetzen können. Um Vergleichbarkeit zwischen
Testläufen gewährleisten zu können, werden fest definierte Szenarien
der Nutzung der zu testenden Applikation zur Generierung der Last
genutzt.
Ich stelle im Folgenden eine teilautomatisierte Lösung zur Erstellung und
Ausführung von Last- und Stresstests vor, die komplett mit
quelloffener Software realisiert wird.
Eingesetzte Software
- org-mode:: Dokumentation und Erstellung der Tests durch literate
programming, sowie dir Erstellung der finalen Testberichte. - zsh:: Skripte im zsh-Dialekt führen Zwischenschritte im Gesamtablauf
aus. - CLIF:: Erstellen von Szenarien, ausführen der Lasttests und sammeln der
Performancedaten. - Eclipse:: Ein IDE-Framework, das von CLIF genutzt wird, um
grafische Werkzeuge anbieten zu können. - GNU R:: Erzeugt die statistischen Analysen und Ergebnisse
präsentierenden Grafiken. - make:: Steuert die automatisierbaren Abläufe
- LaTeX:: Erstellt den druckfertigen Bericht als .pdf-Datei (tetex).
Definitionen
- Lasttest
- Eine Anwendung an ihre Belastungsgrenze bringen.
- Stresstest
- Eine Anwendung über ihre bekannte Belastungsgrenze
hinaus testen. - CLIF
- CLIF is a Load Injection Framework; das System, mit dem
wir die Loadtests durchführen werden. - SUT
- System Under Test; die zu testenden Systeme
- Probe
- Messgeber; z.B. für CPU-Last, Speicherauslastung, …
- Registry
- Zentraler CLIF-Server eines CLIF Testlaufs; koordiniert die
Loadinjektoren und sammelt die Messergebnisse der Probes - Injector
- CLIF-Server, der die Arbeitslast auf den zu testenden
Systemen erzeugt (HTTP-Traffic,
Kommandozeilenwerkzeuge, Rtp-Traffic, …) - Blade
- Ein Blade ist ein Messgeber oder Injector.
- ISAC
- ISAC is a Scenario Architecture for CLIF; Über XML Dateien
konfigurierbare Komponente, über die Last erzeugende
Szenarien definiert werden können, die dann über einenIsacRunnerInjector von CLIF ausgeführt werden
Ablaufplan eines Lasttests
Die Grafik zeigt den Ablauf eines Tests, der in folgende Schritte
unterteilt werden kann:
- Das Testszenario
- Der erste Schritt eines jeden Tests ist die Festlegung dessen, was
getestet werden soll – d.h. in diesem Fall das vor allem Anderen
die Testszenarien erstellt werden müssen. CLIF stellt dafür ein
Eclipseplugin bzw. eine mit dem Eclipseframework erstellte
eigenständige IDE bereit. Komplexe Szenarien für Webanwendungen
können dabei mithilfe eines Proxys in der CLIF-IDE durch abarbeiten
im Browser aufgenommen werden. Allerdings werden immer Nacharbeiten
nötig sein. Die CLIF-Konsole und die Beispielhafte Erstellung eines
Szenarios wird im nächsten Artikel dieser Reihe vorgestellt. - Der Testplan
- Was ist die Motivation für den Test? Was wird getestet? Wo wird es
getestet? All dies ist Teil der Testdokumentation. Mit Hilfe von
Templates wird ein .org-Dokument erstellt, das nicht nur diese
Fragen beantwortet, sondern dank org-babel, der literate
programming Unterstützung von org-mode, einen Testplangenerator
erstellt und ausführt. Nach Abschluss diesen Schrittes haben wir
sowohl die Testdokumentation als PDF-Datei, als auch den genauen
CLIF-Testplan, der festlegt, was auf welchen Maschinen zu testen
ist.
Wie sehen diese Templates aus, wie arbeiten sie, was genau ist ein
CLIF-Testplan? Diese Fragen werden im 3. Artikel dieser Reihe
beantwortet werden. - Der Testlauf
- Wie wird CLIF live aufgesetzt? Welche Hürden gibt es? Wie läuft
der Test ab? Dieser Schritt ist nicht komplett ohne weiteres
automatisiert durchzuführen. Der vierte Artikel dieser Reihe wird
das im Bild gezeigte Setup näher erläutern.
- Der Testbericht
- Auf jeder beteiligten Maschine hat CLIF Daten
gesammelt. Mithilfe eines Programms wird aus den gesammelten Daten
ein org-mode-Dokument erzeugt, das, während des Exports in eine
PDF-Datei, die Daten mit Hilfe von GNU R statistisch auswertet und
den Abschlussbericht als Endprodukt, mit dem Umweg über LaTeX,
liefert. Der fünfte Artikel dieser Reihe wird diesen Prozess
erläutern.
Ausblick
Ich hoffe, ich habe euch neugierig gemacht, wie die Details letztlich
ausgestaltet sind. Stay Tuned… der nächste Artikel kommt bestimmt.