NEOTYS NeoLoad vs. HP LoadRunner - Teil 1
Wie schlägt sich David gegen Goliath?
von Alexander Vukovic
Teil 1: Scriptentwicklung
Eine neue Alternative bei den kommerziellen Lasttestwerkzeugen drängt auf den Markt: NeoLoad der Firma NEOTYS. Mit Sitz in Gemenos bei Marseille in Frankreich, versucht erstmals ein europäisches Unternehmen mit der Strategie, ausschließlich ein Produkt anzubieten, den leicht stagnierenden Lasttestmarkt zu beleben. Beherrscht wird der Markt nach wie vor vom Marktführer HP LoadRunner, eine Enterprise-Lösung für Lasttests mit diversen unterschiedlichen Protokollen.
Desktest
Am Papier versprechen Anbieter oft mehr als sie halten können. NeoLoad positioniert sich als Lasttestwerkzeug und Alternative im Web-Lasttestbereich. Unterstützt werden also Technologien wie AJAX, Web, Webservices, Flex, Web-Push, etc. LoadRunner versucht mit seinem Multiprotokoll-Ansatz auch Protokolle über Web hinausgehend zu unterstützen, z. B. SAP, Oracle, bis hin zu nativem TCP/IP.
NeoLoad ist eine Java-basierte Applikation, die vollständig auf Windows, Solaris und Linux lauffähig ist. LoadRunner benötigt für die Hauptkomponenten Windows und kann die Lasterzeugung wahlweise über Windows- oder Linux-Rechner abwickeln. Aufgrund der Einprodukt-Strategie sind auf der NeoLoad-Homepage weitaus mehr Infos zu finden, als im Bereich HP LoadRunner auf der HP Seite. Diverse Tutorials und Videos erleichtern den Einstieg in NeoLoad.
Scriptrecording
Im Zuge einer Aufzeichnung mit NeoLoad können die aufgezeichneten Schritte in Container zusammengefasst werden.
Mit LoadRunner erfolgt das Recording noch komfortabler, es können zusätzlich zur Anlage von Actions (ähnlich dem Container), auch Textverifikationen und Transaktionstart und –ende eingefügt werden.
Skriptentwicklung
Die Programmierung eines Virtuellen Benutzers erfolgt in NeoLoad per Mausklick. Das heißt aus einem Set von vordefinierten Programmschritten wird das Skript zusammengeklickt oder zuerst aufgezeichnet und dann verändert. Jeder Schritt im Skript hat eine eigene Konfigurationsoberfläche über die Einstellungen vorgenommen werden können.
LoadRunner kennt ebenfalls eine baumartige Darstellung des VUser-Skripts über die per Mausklick gearbeitet werden kann. Darüber hinaus bietet LoadRunner auch den Scriptview an, in dem der vorliegende Sourcecode direkt bearbeitet werden kann. Dies kommt insbesondere erfahrenen Lasttestentwicklern entgegen, da die Änderungen im Skript weitaus schneller und zielgerichteter vorgenommen werden können. NeoLoad kennt keine vollständige Skriptansicht. Spezielle Programmieraufgaben können über einen JavaScript-Code-Step erstellt werden, welcher dann per Mausklick in das VUser-Skript eingefügt wird.
Skriptmodularisierung und Parametrisierung
LoadRunner teilt Virtuelle Benutzerskripts in sogenannte Actions, diese können ähnlich einem Funktionsaufrufes im Skript wiederverwendet und der Ablauf so modularisiert aufgebaut werden. Über eine zentrale Oberfläche können Skriptparemeter künstlich erzeugt oder von externen Quellen eingelesen werden.
NeoLoad ermöglicht die Modularisierung durch sogenannte Shared Container, wobei sich Container als Zusammenfassung einzelner Schritte direkt mit den Actions in LoadRunner gleichsetzen lassen. Skriptparameter lassen sich ebenfalls zentral konfiguieren. Die Oberfläche ähnelt in diesem Bereich sehr stark der von LoadRunner, wobei aber typische Usability-Schwächen, die seit vielen Versionen in LoadRunner vorhanden sind, ausgemerzt wurden. So ist z. B. für eine CSV-Datei nur ein Parameter zu definieren, die Spalten können dann in NeoLoad umbenannt werden und die einzelnen Parameter können dann über Parametername.Spaltenname angesprochen werden. In LoadRunner ist für jede Spalte die Definition eines eigenen Parameters notwendig.
Skriptverifikation und Debugging
LoadRunner ermöglicht eingeschränktes Script-Debugging. So ist es möglich, Breakpoints zu setzen und durch das Skript hindurchzusteppen. Über einen Runtime-Browser werden die vom VUser aufgerufenen Seiten mit etwas Zeitverzögerung und Darstellungsschwierigkeiten bei JavaScript und anderen aktiven Inhalten angezeigt. Variableninhalte und Parameterwerte können zur Laufzeit nur über Logausgaben sichtbar gemacht werden.
Neoload wählt hier einen anderen Zugang. Bei der Skriptverifkation werden die Skriptschritte in einem eigenen Fenster visualisiert und zu jedem Schritt dargestellt, wie der Request zum Server aussah, was die Antwort des Servers war und wie sich Variablen und Parameterwerte verändert haben. Auch eine grafische Darstellung der heruntergeladenen Webseite ist vorhanden. Breakpoints und Stepping sind in NeoLoad nicht möglich. Die vollständige Ablaufdokumentation, betreffend Variablen und Paremeter, hilft dabei Probleme dennoch rasch zu identifizieren.
Correlation
Gerade im Bereich des Webscriptings ist Correlation ein wichtiges Thema. Dabei werden dynamische Parameter gesucht, die meist in einer Server-Antwort definiert werden und dann im Folgerequest korrekt mitgegeben werden müssen. Das klassische Beispiel hierfür ist die Session-ID. Würde der Virtuelle Benutzer immer die gleiche Session-ID aus der Aufzeichnung verwenden, wäre diese auf dem Server nicht mehr gültig. Das Skript würde fehlschlagen.
Beide Tools bieten die Möglichkeiten automatisch zu korrelieren, also automatisch nach solchen dynamischen Werten zu suchen und diese durch Variablen (NeoLoad) oder Parameter (LoadRunner) zu ersetzen.
LoadRunner setzt hier auf den bewährten Left/Right-Boundaryansatz: vor einem Request, der zum Server geht, wird eine linke und eine rechte Grenze definiert, nach der in der Serverantwort gesucht wird. Die gefundenen Inhalte zwischen der linken und der rechten Grenze werden in einem Parameter gesichert und stehen damit für weitere Schritte zur Verfügung.
NeoLoad bietet die gleiche Möglichkeit mit linker und rechter Grenze, darüber hinaus können auch komplexe Regular Expressions definiert werden. Auch hier gibt es auf Seiten der Usability Vorteile für NeoLoad, es ist z. B. direkt auf Basis der aufgezeichneten Serverantwort möglich zu verifzieren, ob ein bzw. welcher Wert gefunden wird.
Transaktionen und Messklammern
Eine Transaktion oder Messklammer dient zur Messung der Antwortzeiten einzelner oder zusammenhängender Abläufe und Requests. LoadRunner kennt hierfür das Konzept der Transaktionen, welche im Skript gestartet und gestoppt werden können. Weiters können auch Actions als übergeordnete Zusammenfassung automatisch in Transaktionen zusammengefasst werden.
In NeoLoad werden Transaktionen auch über Container abgebildet. Jeder Container ist nicht nur eine Zusammenfassung einzelner Schritte sondern auch gleichzeitig eine Messklammer oder Transaktion. Container können in NeoLoad beliebig geschachtelt werden.
Web-Protokollunterstützung
Das Scripting normaler Web-Lasttests wird von beiden Werkzeugen hervorragend unterstützt.
AJAX-Protokollunterstützung
Asynchrounus JavaScript & XML, kurz AJAX, stellt die derzeit größte Herausforderung im Lasttestbereich dar. Über AJAX werden Webbrowser zu teilweise lokalen Anwendungen. Ein großer Teil der Programmlogik wird nicht mehr am Server sondern am Client abgebildet. Lasttestwerkzeuge setzen normalerweise auf Protokollebene auf, das heißt der Virtuelle Benutzer agiert dem Server gegenüber wie ein Browser, ohne den Browser selbst visuell darzustellen oder lokales JavaScript ablaufen zu lassen. Natürlich kann man trotzdem auf diesem Wege Last am Server erzeugen, indem man die Requests, die eigentlich vom lokalen JavaScript erzeugt werden, aufzeichnet und dann gegen den Server abspielt. Dies ist z. B. bei einfachen AJAX-Anwendungen wie einer Auto-Complete-Funktion möglich und sinnvoll. Der asynchrone Request kann leicht verändert werden.
Komplexer wird die Sache, wenn über JavaScript am Client komplexere Berechnungen vorgenommen werden. Als Beispiel sei der Herold-Routenplaner http://www.herold.at/routenplaner/ angeführt. Über die angezeigten Buttons kann die Karte in alle Himmelsrichtungen navigiert werden. Über JavaScript wird, abhänging von den aktuellen Koordinaten, errechnet, wie die URLs für die nachzuladenden Kartenteile lauten. Will man also dynamisch nach einem Ort suchen, die Karte dazu anzeigen und dann nach Norden blättern, so müsste man entweder eigene Scripts für jeden Ort bauen oder den Algorithmus zur URL-Berechnung im Lasttestskript nachbauen. Beide Lösungen sind programmiertechnisch wenig elegant und aufwendig.
NeoLoad ist auf diese beiden Lösungsmöglichkeiten eingeschränkt und damit nur für einfache AJAX-Anwendungen geeignet.
LoadRunner geht hier technologisch einen Schritt weiter und bietet ein eigenes AJAX-Protokoll, in dem nicht mehr URL-Requests, sondern auch JavaScript-Aktionen definiert werden. Will man nach Norden blättern, so wird im Virtuellen Benutzer nicht der Request für die Kartenteile sondern der Schritt "Klicke auf Button Norden" erfasst. Der ablaufende JavaScript-Code erzeugt zur Laufzeit die korrekten Requests. Dies setzt voraus, dass für jeden Virtuellen Benutzer dann zur Laufzeit auch das heruntergeladene JavaScript interpretiert und durchgeführt wird. Darin lag bisher auch die größte Einschränkung des LoadRunner-AJAX Click & Script-Protokolls, wenn AJAX-Frameworks wie JQuery oder GWT zum Einsatz kamen. Der eingebaute JavaScript-Interpreter verhielt sich dann manchmal nicht anders, als der Interpreter in den gängigen Browsern: AJAX-Elemente im realen Browser funktionierten, während des Lasttests mit LoadRunner wurden aber durch den eigenen JavaScript-Interpreter Fehler erzeugt.
Um dieses Manko zu beseitigen hat HP mit LoadRunner 11 das TruClient-Protokoll eingeführt. Dabei erhält jeder Virtuelle Benutzer einen realen Browser (derzeit Mozilla Firefox), über den die JavaScript-Exekution durchgeführt wird.
Webservices
Ähnlich wie bei AJAX lässt sich ein Webservice-Test auch über normale Web-Requests abbilden. Hierfür müssen die SOAP-Requests manuell zusammengebaut und dann zum Server geschickt werden. XML-Antworten müssen manuell geparst werden. Um dies zu vereinfachen bieten beide Werkzeuge zusätzliche Funktionen für Webservice-Lasttests an.
LoadRunner unterscheidet hierfür zwischen Web- und Webservice-Protokoll. Beim Webservice-Protokoll kann das WSDL als Vorgabe für die Requestparametrisierung herangezogen werden. Parameterwerte im SOAP-Request können aus dem zentralen Parameterpool übernommen werden. Mitteles eigener XML-Funktionen wird das Parsing der SOAP-Antworten erleichtert.
Der Ansatz von NeoLoad unterscheidet sich dahingend, dass in NeoLoad nur zwischen Web-Requests und Webservice-Requests unterschieden wird. Somit können Web- und Webservice-Requests innerhalb eines virtuellen Benutzers beliebig gemischt werden. Auch NeoLoad bietet die Möglichkeit über die Angabe eines WSDLs Requestvorlagen zu erzeugen. Das Parsen von XML-Resulaten erfolgt mittels der Abfragesprache XPath.
Fazit
Im Skriptingbereich ist David NeoLoad dem Goliath LoadRunner dicht auf den Fersen. Die fehlende Skriptansicht und die fehlenden Breakpoints macht NeoLoad mit der intuitiven Skriptverifikationsansicht wieder wett. Im Bereich der Correlation und normaler Weblasttests und bei Webservices sind die beiden Werkzeuge gleichwertig mit leichten Usability-Vorteilen auf der Seite von NeoLoad. Bei komplexeren AJAX-Applikation kann Goaliath LoadRunner derzeit seine Vormachtsstellung noch behaupten.
Weiterführende Links
