NEOTYS NeoLoad vs. HP LoadRunner - Teil 2

Wie schlägt sich David gegen Goliath?

von Alexander Vukovic

Teil 2: Lasttest Szenarios, Monitoring und Durchführung

Nach Betrachtung des Scriptings von Virtuellen Benutzern im ersten Teil, widmen wir uns im zweiten Teil unseres Vergleiches der Konfiguration der Lasttest Szenarios und der Durchführung eines Lasttests.
Die Begrifflichkeiten sind in beiden Tools unterschiedlich, wenngleich die Konzepte dahinter ähnlich sind. Dieser Teil der Serie bezieht sich bereits auf NeoLoad 3.2, welches vor kurzem erschienen ist und LoadRunner 11.

Populations und VUser-Groups

NeoLoad kennt sogenannte Populations, vergleichbar mit den VUser-Gruppen in LoadRunner, im Szenario können die Laufzeiteinstellungen pro Population bzw. VUser-Gruppe in beiden Tools verändert werden, wodurch komplexe Szenarios ermöglicht werden.

Ramp-Up und Ramp-Down

Beispiel für eine LoadRunner Szenario Konfiguration
Beispiel für eine LoadRunner Szenario Konfiguration

Mit der Definition eines Ramp-Ups werden die Virtuellen Benutzer nach einem kontrollierten zeitabhängigen Schema hinzugeschaltet, um einen realistischeren Lastverlauf zu erhalten und die Server nicht unrealistisch mit zu vielen gleichzeitigen Zugriffen zu stressen. Mit dem Ramp-Up lassen sich auch die Monitorwerte nach dem Lasttest besser interpretieren, da sie mit der Anzahl der gleichzeitigen Benutzer verglichen werden können. Nach dem gleichen Schema macht man ein Ramp-Down, baut also die Last kontrolliert wieder ab, um etwaige Veränderungen auf den Systemen beobachten zu können. Bei Ramp-Downs lassen sich insbesondere Memory-Leaks oder hängengebliebene Prozesse gut identifizieren.

Beide Tools bieten die unterschiedlichsten Möglichkeiten, um Ramp-Ups zu definieren, z. B. über die Angabe "2 User alle 30 Sekunden hinzuschalten". Beim Ramp-Down hat LoadRunner klare Vorteile, NeoLoad bietet keine Möglichkeit eines vordefinierten oder mit ähnlicher Angabe definierten Ramp-Downs. Will man hier einen Ramp-Down machen, muss man ein "Benutzer-definiertes Scenario" konfigurieren, welches aber jeden beliebigen Verlauf über einen visuellen Editor konfigurieren lässt. Insgesamt erweist sich der LoadRunner Controller bei der Definition der Lasttest Szenarios flexibler aber auch komplizierter zu bedienen als NeoLoad.

NeoLoad definiert Gruppen von Virtuellen Benutzern zur Design-Time in sogenannten Populations
NeoLoad definiert Gruppen von Virtuellen Benutzern zur Design-Time in sogenannten Populations

Caching, Browsersimulation, Bandbreite

Besonderes Augenmerk sollte man auf die Realitätsnähe des Lasttestszenarios legen. In den meisten Fällen benutzen die echten Benutzer unterschiedliche Browser um auf den Server zuzugreifen, haben das Caching unterschiedlich eingestellt, nutzen unterschiedliche Bandbreiten. All diese Dinge sollte man in einem guten Lasttestwerkzeug auch für einzelne Benutzergruppen definieren können. Beide Werkzeuge ermöglichen dies.

Unterschiede ergeben sich beim Caching. So kennt NeoLoad nur die Einstellung "No Cache", hierbei werden immer alle Elemente einer Seite heruntergeladen, und "Cache", hierbei werden alle Dinge, aus der Aufzeichnung bereits im Cache gehalten und somit ggf. nie heruntergeladen. LoadRunner kennt zusätzlich noch die Einstellung "Clear Cache on each iteration", womit auch Virtuelle Benutzer simuliert werden können, die erstmalig auf die Seite kommen, wichtige Dateien cachen und dann bei komplexeren Geschäftsfällen auch vom Cache profitieren. NeoLoad erlaubt derzeit noch kein Cache-Clearing.

Beide Werkzeuge ermöglichen unterschiedliche Browserkennungen mitzuschicken und so ggf. unterschiedliche browserabhängige Seiten zu testen.

Die Bandbreite der Virtuellen Benutzer lässt sich sowohl in NeoLoad als auch in LoadRunner einschränken um z. B. die Anbindung über eine Mobilverbindung zu simulieren.

Einbindung der Lastgeneratoren

Beide Werkzeuge erlauben die Verwendung und zentrale Steuerung mehrerer Lastgeneratoren. Damit wird die Rechnenleistung mehrerer Rechner zur Lasterzeugung genutzt und größere Zahlen von Virtuellen Benutzern ermöglicht. Die Lastgeneratoren werden ggf. auch in anderen Lokationen positioniert um z. B. die Last aus unterschiedlichen Filialen über das Internet aufzubringen. Die Steuerung wird über die zentrale Konsole des Controllers vorgenommen.

NeoLoad zeigt sich bei der Wahl der Generatoren etwas flexibler als LoadRunner und unterstützt neben Windows und Linux auch MacOSX, LoadRunner unterstützt Windows und Linux für die Lastgeneratoren. Der Controller ist in NeoLoad integriert und damit unter Windows und Linux verfügbar. Der LoadRunner Controller läuft nur unter Windows.

Die Installation der Lastgeneratoren ist bei NeoLoad etwas leichtgewichtiger (65 MB) und einfacher als bei LoadRunner (540 MB). Dafür erlaubt NeoLoad keinerlei Monitoring über einen Lastgenerator. Das Monitoring erfolgt ausschließlich über den Controller. Beide Tools bieten eine Oberfläche, um die Lastgeneratoren einzubinden und vor dem Start des Testlaufs die Verbindung zu testen.

Flexibel zeigt sich NeoLoad beim "Selbstmonitoring", so werden automatisch CPU und Memory des Controllers und der Lastgeneratoren mit gemonitored. In LoadRunner muss man dies manuell konfigurieren.

Monitoring der Infrastruktur

Lange Zeit war LoadRunner im Enterprise-Bereich, das einzige Tool, das mehr oder weniger alle typischen Infrastrukturkomponenten monitoren konnte. Seit dem die Nutzung von Open Source Software auch im Unternehmensbereich immer mehr Bedeutung gewinnt, verliert LoadRunner hier an Terrain. Typische Open Source Stacks wie Tomcat und MySQL lassen sich nur durch Installation und Einbindung eines Zusatzwerkzeugs HP SiteScope monitoren. LoadRunner bringt für SiteScope 500 Monitorpunkte als Lizenz mit.

NeoLoad-RunTimeAlerts
In NeoLoad können Messwerte mit Alerts hinterlegt werden, diese wer- den in der RunTime-Alerts-Ansicht während der Durchführung gezeigt

NeoLoad unterstützt die heute gängigsten Infrastrukturstacks, Datenbanken, Betriebssysteme und Applikationsserver auch Open Source Stacks out of the box. Dafür müssen unter NeoLoad die Monitore für die Durchführung, wenn auch sehr günstig, zusätzlich lizenziert werden. Enterpriseapplikationen wie SAP können mit NeoLoad nicht nativ gemonitored werden. Es muss hier z. B. auf SNMP ausgewichen werden.

Vorteile für NeoLoad gibt es auch im Bereich Linux. Hier setzt LoadRunner immer noch auf rstatd, wobei sich der Monitor unter Last als nicht sehr stabil Interessant ist auch das Feature von NeoLoad vor und nach dem Lasttest eine Referenzmonitoring-Zeit zu monitoren. D.h. monitoring der Infrastruktur ohne Last z. B. für 30 Sekunden vor und nach dem Test um eine realistische Basislinie der Systemauslastung zu bekommen.

Lasttestdurchführung und Laufzeitüberwachung

Bei der Durchführung ist es sehr wichtig, über die Geschehnisse Überblick zu behalten, also die Auslastung der Systeme im Auge zu behalten, festzustellen, ob Virtuelle Benutzer unerwartete Fehler bekommen oder die Antwortzeiten stimmen.

Beide Tools zeigen sich dabei äußerst flexibel. Mit frei konfigurierbaren Graphen in NeoLoad kann jeder Monitorwert auf einzelne Panels aufgeschaltet werden, LoadRunner ist hier auf bis zu 8 Panels eingeschränkt, NeoLoad bietet frei definierbar viele Panels, wobei zu viele sich auch auf die Performance des Controllers negativ auswirken können.

LoadRunnerGraphs
LoadRunner zeigt bis zu 8 Graphen zur Überwachung während der Durchführung
NeoLoadGraphs
Die grafische Überwachung des Lasttests ist auch in NeoLoad möglich

LoadRunner ermöglicht mehr Eingriffsmöglichkeiten. So können zusätzliche Virtuelle Benutzer auch während des Testlaufs zugeschaltet oder abgeschaltet werden. NeoLoad ermöglicht keinerlei Eingriff zur Laufzeit des Tests. Die Anzeige der Fehler ist in LoadRunner seit Jahren unverändert unflexibel in ein kleines Fenster gepackt. Dafür kann bis auf die Codezeile hinunter überprüft werden, wo das Problem im VUser-Skript aufgetreten ist. Beide Tools ermöglichen die "Oberfläche" einzelner virtueller Benutzer zur Laufzeit anzuzeigen, bei beiden ist dies aus Performancegründen nicht zu empfehlen.

Stabilität und Speicherverhalten

Der LoadRunner Controller ist extrem stabil und belastbar. Die Steuerung von mehreren tausend Benutzern verteilt über mehrere Lastgeneratoren stellt keinerlei Problem auch über eine längere Laufzeit hinweg dar. Die kompletten Monitordaten werden erst am Ende der Laufzeit von den Lastgeneratoren "collected". Anders hier NeoLoad: Hier werden alle Informationen zur Laufzeit an den Controller übertragen. NeoLoad erweist sich insbesondere bei komplexen Scripts und großen Mengen an virtuellen Benutzern als weniger stabil. Hier muss z. B. nachträglich an den Memory-Einstellungen für den Controller und den Lastgeneratoren geschraubt werden. Der Benutzer wird beim NeoLoad Tuning durch ein eigenes Handbuch für "große Lasttests" unterstützt.

Fazit

David und Goliath schenken sich auch in der Auseinandersetzung zur Laufzeit nichts. NeoLoad ist knapp an LoadRunner dran und hat ihn z. B. im Bereich des Monitoring sogar bereits überholt. Dennoch steht der Goliath noch, in Sachen Stabilität kann ihm niemand so schnell etwas vormachen.

Artikel teilen
SEQIS News RSS
Autor
SEQIS Autor Alexander Vukovic

Alexander Vukovic

Managing Partner, Founder

Newsletter

Um neue Beiträge per E-Mail zu erhalten, hier die E-Mail-Adresse eingeben.

Unsere Autoren

Informieren Sie sich über unsere Autoren und erfahren Sie mehr über unsere Spezialisten und ihre Fachbereiche:

Zu den Autoren

Sie haben eine Frage?

Zurück

Kommentare
(Bitte geben Sie eine gültige URL mit "http://" ein.)
  • SEQIS
  • NEOTYS NeoLoad vs. HP LoadRunner - Teil 2
Zum Seitenanfang navigieren