Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.01.2007

Ratgeber: Lasttests mit Open Source

Armin Billens 
Quelloffene Lösungen für Last- und Performance-Tests können eine Alternative zu kommerziellen Tools sein. Doch Vorsicht: Es lauern verborgene Kosten- und Stolperfallen.
Die Kurve gibt an, mit welchem zeitlichen Aufwand (Personentage) zu rechnen ist, wenn Testläufe manuell mit Hilfe einer Tabellenkalkulation ausgewertet werden. Für die Entwicklung einer automatischen Auswertung über eine Zusatzkomponente sind etwa zehn Tage zu veranschlagen (1). Bei mehr als 20 Testläufen lohnt sich also die Erstellung eines solchen Programms. Soll die automatische Auswertung nicht als Zusatzkomponente, sondern als integrierte Tool-Funktion realisiert werden, müssen rund 20 Tage Entwicklungszeit einkalkuliert werden. Das rechnet sich erst dann, wenn mehr als 40 Testläufe geplant sind (2).
Die Kurve gibt an, mit welchem zeitlichen Aufwand (Personentage) zu rechnen ist, wenn Testläufe manuell mit Hilfe einer Tabellenkalkulation ausgewertet werden. Für die Entwicklung einer automatischen Auswertung über eine Zusatzkomponente sind etwa zehn Tage zu veranschlagen (1). Bei mehr als 20 Testläufen lohnt sich also die Erstellung eines solchen Programms. Soll die automatische Auswertung nicht als Zusatzkomponente, sondern als integrierte Tool-Funktion realisiert werden, müssen rund 20 Tage Entwicklungszeit einkalkuliert werden. Das rechnet sich erst dann, wenn mehr als 40 Testläufe geplant sind (2).

Last- und Performance-Tests (LPTs) stellen Unternehmen häufig vor ein Problem: Einerseits kosten die kommerziellen Tools nicht selten so viel wie ein Automobil der Oberklasse - mit einer nach oben offenen Preisskala. Andererseits birgt der Verzicht auf Lasttests ein unkalkulierbares Risiko: Engpässe im System sind meist die Vorboten eines totalen Ausfalls, und werden diese nicht frühzeitig erkannt, sind sehr schnell bedrohliche Kostendimensionen die Folge. Verlockend ist daher die Alternative, kostenlose Open-Source-Tools (OSTs) einzusetzen.

Hier lesen Sie ...

• wo die Stärken aber auch die Grenzen von quelloffenen Tools für Last- und Performance-Tests liegen;

• für welche Szenarien solche Werkzeuge sinnvoll sind;

• dass kostenlose Software unter Umständen den Anwender trotzdem teuer zu stehen kommen;

• welche Erfahrungen Experten mit diesen Programmen in der Praxis gesammelt haben.

Fazit

• Kommerzielle Tools für Last- und Performance-Tests sind in beliebigen Systemlandschaften einsetzbar, bieten Auswertungskomfort und Support. Das hat seinen Preis.

• Open-Source-Tools sind kostenfrei, verursachen in der Regel jedoch zusätzlichen Aufwand und sind meist auf Web- und Java-Applikationen beschränkt.

• Bleibt der Aufwand für Anpassung und Entwicklung unter dem Preis eines kommerziellen Produkts, sind Open-Source-Werkzeuge durchaus eine Alternative zu herkömmlichen Lösungen.

Pro und Kontra

Open-Source-Tools

- Kostenlos;

- Customizing (frei zugäng- licher Quellcode;

- erweiterbar;

- unbegrenzte Anzahl von Usern.

- Meist beschränkt auf Techniken mit hohem Verbreitungsgrad (Web etc.);

- zusätzlicher Aufwand für Auswertungsfunktionen, Protokolle und Tool- Features;

- Simulation von Usern erfordert viele Hardwareressourcen.

Kommerzielle Produkte

- Vielfältige Auswertungsmöglichkeiten;

- Monitoring von Systemkomponenten;

- automatisierte Korrelation;

- Protokollvielfalt;

- geringe Hardwareres- sourcen für die Simula- tion von Benutzern erforderlich.

- Teuer;

- der Preis steigt mit der Anzahl simulierter Benutzer.

Definitionen

• Last: Anzahl von gleichzeitigen Nutzern, Transaktionen, Zugriffen, Prozessen etc.;

• Performance: Laufzeitverhalten der Anwendung bei der Ausführung einzelner Geschäftsprozesse in Relation zur Anzahl der gleichzeitigen Nutzer, Transaktionen, Zugriffe, Prozesse etc.;

• Lasttest: Überprüfung des Systemverhaltens bei einer großen Anzahl von gleichzeitigen Nutzern, wobei die Last bis auf 100 Prozent des später erwarteten Wertes skaliert werden kann;

• Performance-Test: Messen des Laufzeitverhaltens der Anwendung bei der Ausführung einzelner Geschäftsprozesse in Relation zur Anzahl der gleichzeitigen Nutzer.

Open-Source-Lösungen und ihre Grenzen

• Junit (www.junit.org/index.htm): Für Lasttests ist Junit nicht geeignet. Konzipiert wurde das Tool für Tests von Java-Units.

• Grinder (grinder.sourceforge.net/): Die Software bietet keine echte Endbenutzersicht, komplexe User-Profile können nicht abgebildet werden.

• Dieseltest (sourceforge.net/projects/dieseltest/): Das Werkzeug erlaubt keine komplexen Lastszenarien.

• OpenSta (www.opensta.org/): OpenSta bietet eine an kommerzielle Tools angelehnte echte Last- und Performance-Suite. Die Nachteile: proprietäre Skriptsprache zur Skripterstellung, schlechte Dokumentation, das Projekt dümpelt vor sich hin.

• JMeter (jakarta.apache.org/jmeter/): Das Projekt stellt ein vollwertiges Last- und Performance-Werkzeug. Es verfolgt einen völlig anderen Ansatz für die Erstellung von virtuellen Geschäftsprozessen. Aktionen werden in einer Explorer-artigen Darstellung abgebildet. Kenntnisse einer bestimmten Programmiersprache sind nicht nötig, aber die Programmierlogik muss verstanden werden.

Mehr zum Thema

www.computerwoche.de/

576708: Performance-Tests effizienter gestalten;

1206315: Wege zu performanten Applikations-Servern;

579292: HP kauft Mercury;

582508: Tuning-Tipps für Java-Server.

Ein grundlegender Gedanke der Open-Source-Bewegung ist es, hochwertige Software durch die Bündelung von Ressourcen und Entwicklungs-Know-how zu schaffen. Für den versierten Anwender bietet sich über den frei zugänglichen Quellcode die Möglichkeit, die Software exakt nach seinen Bedürfnissen zu modifizieren. Während in einigen Bereichen Open-Source-Produkte inzwischen unbedenklich für professionelle Anwendungen verwendet werden, steht der Einsatz von OSTs für Last- und Performance-Tests noch am Anfang. Die zögerliche Akzeptanz der Anwender erklärt sich daraus, dass Lasttests in der Regel für strategisch wichtige Anwendungen eingesetzt werden. Nach dem Motto "Qualität muss kosten" trauen einige Unternehmen den Gratisprodukten in diesem sensiblen Bereich nicht zu, die geforderten Aufgaben zuverlässig zu erfüllen und Schwächen einer Anwendung zu entdecken. Eine Einschätzung, die erfahrungsgemäß aber so pauschal nicht mehr zutrifft.

Für Web- und Java-Applikationen

Allerdings können OSTs nicht für beliebige Systemlandschaften, sondern lediglich für bestimmte Techniken mit hohem Verbreitungsgrad wie zum Beispiel Web- und Java-Applikationen eingesetzt werden. Der Test komplexer Systemlandschaften mit nativen oder gar proprietären Kommunikations-Protokollen bleibt ohne Alternative konkurrenzlos in der Hand kommerzieller Hersteller. Daran wird sich auch in naher Zukunft nichts ändern. Grund ist, dass die Beschreibung von Protokollen für bestimmte herstellerspezifische Anwendungen nicht frei zugänglich ist. Im Vergleich zu Web-basierenden Applikationen ist die Verbreitung solcher Systeme jedoch vergleichsweise klein, da der allgemeine Trend eindeutig in Richtung Browser-gestützter Software weist.

Zu den Aufgaben eines Last- und Performance-Tests gehören die Simulation und das Messen der Performance aus Endbenutzersicht, die Ermittlung des Last- und Antwortzeitverhaltens sowie die Überwachung der Systemauslastung. Im Rahmen einiger Kundenprojekte wurde von RDS Consulting untersucht, wie verschiedene Open-Source- Tools diese Aufgaben in Bezug auf Java-basierende Web-Applikationen (J2EE) erfüllen. Das Kommunikationsprotokoll, das für die Skripterstellung verwendet wurde, war somit HTTP(s). Von den fünf ausgewählten Gratis-Tools ließen sich nur mit "OpenSta" und "JMeter" die genannten Anforderungen vollständig erfüllen. Insbesondere die Darstellung der Performance aus Endbenutzersicht sowie die Abbildung des Lastverhaltens waren mit den gewählten Tools sehr gut zu realisieren. Die Ergebnisse waren mit denen kommerzieller Produkte vergleichbar. Auch der Entwicklungsaufwand für Skripte war etwa identisch - Tool-Erfahrung vorausgesetzt. Die Entscheidung fiel letztlich für das Tool JMeter der Apache-Group, da dessen Weiterentwicklung besonders viel verspricht - sie wird forciert und verläuft dynamisch.

Kommerziellen Tools ebenbürtig

Qualitativ sind die genannten OSTs ihren kommerziellen Pendants im Web-Umfeld ebenbürtig. Lediglich die Auslastung einzelner Komponenten komplexer Systemlandschaften kann mit OSTs aus den genannten Gründen nicht gemessen werden. Hier ist eine manuelle Korrelation von Daten zur Systemauslastung mit den Messergebnissen der Lastsimulation notwendig.

Verborgene Kostenfallen

Auch wenn die OSTs frei verfügbar sind, lauern einige Kostenfallen, die bei der Entscheidung zwischen kommerziell und Open Source eine maßgebliche Rolle spielen. Welche Kosten tatsächlich entstehen, hängt von der Qualifikation und Erfahrung der Mitarbeiter ab, der Größe und Komplexität der Simulation sowie der vorhandenen Hardware und der IT-Landschaft.

Ein Beispiel: Ein Mitarbeiter will eine Individualsoftware mit einem OST testen. Er kennt sich mit Testthemen aus und hat Programmier-Grundkenntnisse, ist jedoch kein Tool-Spezialist im LPT-Bereich. Das hat zur Folge, dass die Testvorbereitung meist länger dauert. In der Regel gibt es jedoch im Open-Source-Bereich weder eine Schulung noch direkten Support. Im Vergleich zu einem kommerziellen Tool entsteht deshalb je nach Vorkenntnissen ein zwei- bis dreimal höherer Aufwand für die Initialisierungsphase. Einer Woche Schulung bei einem kommerziellen Tool stehen etwa drei Wochen Einarbeitung in das kostenlose Werkzeug gegenüber.

Vor allem die Skriptvorbereitung ist aufwändiger. Für die Simulation müssen virtuelle Nutzer und Prozesse angelegt werden. Bei OSTs sind Hilfen wie Wizards, interaktive Hilfen und Beispiele, Parameter-Voreinstellungen und anderes kaum oder gar nicht vorhanden. Mit einem kommerziellen Tool erstellt unser Muster-Mitarbeiter ein Web-Skript in fünf Tagen, mit einem OST benötigen Tool-Unerfahrene zehn Tage - es verdoppelt sich also der Entwicklungsaufwand. Mit kommerziellen Lösungen dagegen lassen sich diese Skripte - auch von "Anfängern" - komfortabler und meist mit interaktiver Hilfestellung erzeugen.

Mehr Hardware nötig

Zu beachten ist auch, dass mehr Hardware benötigt wird. Die von uns getesteten OSTs waren sehr speicherhungrig. Ein Test mit 250 virtuellen, durchschnittlichen Web-Usern lief auf einer Intel-Maschine mit 512 MB Arbeitsspeicher nur knapp eine Stunde. Danach traten Memory-Fehler auf. Zur fehlerfreien Testausführung wurden 1024 MB benötigt. Nach unserer Erfahrung bewältigt ein kommerzielles Tool diese User-Zahl mit etwa einem Drittel der Hardwareressourcen.

Wer die Auslastung seiner Systeme testen will, wird feststellen, dass für Standardwerte etwa zu CPU und Speicher die Bordmittel des Betriebssystems ausreichen. Um aber auch Aussagen beispielsweise über Netzwerke, Applikations-Server oder Datenbanken zu erhalten, sind zusätzliche Messwerkzeuge nötig, die häufig fünfstellige Summen kosten. Ein Programmierer, der sich in der Sprache des gewählten OST auskennt, wird für eine Erweiterung etwa drei Wochen benötigen. Diesen Aufwand gilt es gegenüber den Lizenzkosten abzuwägen.

Auswertung ist Schwachpunkt

Als Achillesferse erweist sich die Auswertung der Messdaten. Für die Analyse der Testergebnisse sind die Zusammenhänge zwischen den Ereignissen zum Zeitpunkt ihres Auftretens grundlegend. Kommerzielle Tools erzeugen diese Korrelation automatisch - OSTs jedoch nicht. Manuell können die Daten etwa mit Hilfe von Excel ausgewertet werden. Bei mehr als 32000 Datensätzen stößt ein herkömmliches Tabellenkalkulationsprogramm allerdings an seine Grenzen. Die Daten müssen dann in kleinere Pakete aufgeteilt werden. Der Nachteil liegt auf der Hand, denn eine manuelle Auswertung ist sehr mühsam, erfordert hohe Konzentration und führt leicht zu Fehlern. Der Aufwand dafür beträgt etwa einen Tag (siehe Grafik). Bei einer halbautomatisierten Analysen werden die Daten beispielsweise an geeignete Programme übergeben, ausgewertet und aufbereitet. Sowohl Datenauswertung als auch -aufbereitung finden dann außerhalb des Werkzeugs statt. Dies zu entwickeln dauert rund zwei Wochen. Wird die Auswertung direkt in das Tool integriert, ist der Entwicklungsaufwand etwa viermal so hoch.

Probleme und Grenzen

Solange keine ernsthaften Probleme auftreten, reicht die bislang beschriebene Basisausstattung aus. In der Praxis aber tauchen Szenarien auf, die zusätzliche Investitionen nach sich ziehen.

Ein simples Beispiel ist ein Protokoll, dessen Beschreibung zwar verfügbar ist, das aber vom OST nicht unterstützt wird. Für die Einbindung eines einfachen Protokolls braucht ein erfahrener Entwickler schätzungsweise zwei bis drei Wochen, für ein komplexes Protokoll etwa vier bis sechs. OSTs stoßen an ihre Grenzen, sobald die Protokollbeschreibung nicht verfügbar ist. Im Vergleich dazu sind in kommerziellen Tools über Protokoll-Bundles optional die gängigen Protokolle gegen entsprechenden Aufpreis erhältlich.

Ein anderes Beispiel sind Flaschenhälse. Nehmen wir an, während des Testlaufs tritt ein Engpass auf, der ad hoc eine komplexe Tool-gestützte Fehleranalyse erfordert. In einem kommerziellen Produkt sind dafür in der Regel entsprechende Features und Darstellungsmöglichkeiten integriert, die eine Fehleranalyse erleichtern und möglicherweise die Konsultation eines Experten überflüssig machen. Mit einem OST allein kommt man hier nicht weiter. Die Konsequenz: Ein zusätzliches Tool oder ein Experte, schlimmstenfalls beides, muss eingekauft werden. Die Kosten bei einem wenig komplexen Fehler betragen etwa 10000 Euro innerhalb von ein bis zwei Wochen. Für ein komplexeres Problem sind etwa 20000 Euro innerhalb von zwei bis drei Wochen zu kalkulieren. Außerdem muss das zusätzliche Tool mit beispielsweise erweiterten Darstellungsmöglichkeiten in das OST eingebunden werden.

Eine Frage der Kostenrechnung

Damit ist die Entscheidung für oder wider Open Source letztlich eine Kostenrechnung, die von der jeweiligen Konstellation und Aufgabenstellung abhängig ist. Open Source kommt immer dann in Frage, wenn die Kosten für den zusätzlichen Aufwand kleiner sind als der Anschaffungspreis für ein kommerzielles Tool. Wer vorab bei strategisch wichtigen Anwendungen mit ernsthaften Komplikationen rechnet und/oder mit einer komplexen Systemlandschaft arbeitet, sollte eher zu einem kommerziellen Tool greifen.

Open Source im Kontext von Last- und Performance-Tests bedeutet im Vergleich zu kommerziellen Lösungen zunächst einen Verzicht auf Komfort und Support. Außerdem sind je nach Aufgabenstellung weiterer Entwicklungsaufwand und Investitionen in zusätzliche Tools einzukalkulieren. Bezogen auf die Kostenrechung bieten Open-Source-Programme aber einen Vorteil: Es können unbegrenzt viele simulierte User für den Test verwendet werden. Dagegen sind kommerzielle Werkzeuge in der Regel preislich nach der Anzahl der zu simulierenden Benutzer gestaffelt. In Situationen, in denen man sehr viele User simulieren müsste, treibt das die Kosten oft so in die Höhe, dass ein solcher Test nicht mehr sinnvoll erscheint. (ue)