Proxy Sniffer V4.0-P User s Guide

Transkript

2 Inhaltsverzeichnis 1 Einleitung Menü-Übersicht und Navigation Installation System-Anforderungen Windows Installation Unix Installation Architektur-Übersicht Konfiguration des Web-Browsers Lokale Popup-Fenster Zulassen Umkonfigurieren des Web-Browsers zur Aufzeichnung Beispiel Proxy-Konfiguration für Microsoft Internet Explorer: Beispiel Proxy-Konfiguration für Mozilla Firefox Web-Browser Warnung bei verschlüsselten Verbindungen Aufzeichnen von Web-Browser Sessions Löschen des Web-Browser Caches im Internet Explorer Löschen des Web-Browser Caches im Mozilla Firefox Aufzeichnen nachfolgender Web-Seiten Abspeichern der Aufzeichnung Kontrolle der aufgezeichneten Web-Session Kontrolle der getesteten Web-Server Kontrolle der automatischen Inhaltsüberprüfung Session Cutter Weitere Hinweise zum Aufzeichnen von Web-Browser Sessions Unterstütze HTTP/S Clients Proxy-Recorder und GUI Einstellungen (Personal Settings Menü) Proxy Kaskadierung (Connect to Next Proxy) HTTPS Settings NTLM Authentication HTTPS Client Certificate Authentication GUI Settings Inner Loops Bedingtes Ausführen von Teilen der Web-Session Nachbearbeiten der Web Session dynamische Session-Parameter Variablen Handler (Var Handler) Input Files Weitere Hinweise zu Input Files by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 2 / 125

3 6.3 User Input Fields Weitere Hinweise zu User Input Fields Dynamisch ausgetauschte Session-Parameter Automatische Behandlung von dynamisch ausgetauschten Session-Parametern (Var Finder) Manueller Extrakt von dynamisch ausgetauschten Session-Parametern Ersetzen von Textmustern Zusammenfassung der möglichen Extrakt- und Zuweisungs-Operationen Direkte Definition von Variablen J2EE URL-Rewriting Erzeugen des Lasttest-Programms Lasttest-Programme mit Input Files Ausführen von Lasttest-Programmen Exec Agent Jobs Real-Time Job Statistik Laden des Statistik-Files Jobs Menü (Exec Agents) Cluster-Jobs Real-Time Cluster-Job Statistik Laden des Statistik-Files von Cluster-Jobs Jobs Menü (Cluster) Scripting von Lasttest-Jobs Project Navigator Konfiguration des Project Navigator Haupt-Directories Auswerten der Messergebnisse Detailergebnisse Test Scenario Diagram: Response Time per Page Results per URL Call (Overview) Results per URL Call (Details) Diagram: Response Time Percentiles Diagram: Top Time-Consuming URLs Diagram: Concurrent Users Diagram: Average Session Time Diagram: Web Transaction Rate Diagram: Completed Loops Diagram: Average Network Connect Time Diagram: Total Network Throughput Diagram: HTTP Keep-Alive Efficiency Diagram: SSL Cache Efficiency by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 3 / 125

4 Diagram: Session Failures Diagram: Top Error Types Diagram: Number of Errors per Page Diagram: Number of Errors per URL Error-Snapshots Pseudo-Fehlercodes Übersetzen der URL Test-Nummerierung Lastkurven-Diagramme Vergleichs-Diagramme Konfiguration und Architektur bei verteilten Lasttests Konfiguration von weiteren Last-auslösenden Rechnern Konfiguration von Last-auslösenden Clustern Starten von verteilten Lasttests Konfiguration vom mehreren IP Adressen pro Last-auslösenden Rechner Schritt 1: Konfiguration des Betriebsystems Windows Unix Schritt 2 und 3: Konfiguration des Exec Agents und Starten des Testlaufs Manuelle Anpassungen an Java Lasttest-Programmen / Java API Externe Klassen und Jar-Libraries Direkter Zugriff auf Messergebnisse Web Tools Page Scanner Eingabe-Parameter, Fortschritts-Anzeige und Abspeichern des Scan-Resultats Analyse des Scan-Resultats Analyse der Scan-Details Konvertierung des Scan-Resultats in eine Web-Browser Session Hersteller und Support UNIX is a registered trademark of The Open Group in the U.S. and other countries. Solaris and Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. Windows is a trademark of Microsoft Corporation by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 4 / 125

5 1 Einleitung Wir danken Ihnen für den Gebrauch des Web Lasttest Produkts Proxy Sniffer. Sie erhalten ein leistungsfähiges Produkt, das in der Regel einfach und weitgehend intuitiv bedienbar ist. Dennoch sind einige Konzepte nicht sofort durchschaubar, so dass wir Sie bitten, diese Bedienungsanleitung möglichst vollständig zu lesen. Für Ihren Lasttest drücken wir Ihnen schon jetzt den Daumen. 1.1 Menü-Übersicht und Navigation Die Menüführung ist bei Proxy Sniffer etwas anders als bei anderen Programmen. Die Menüführung erfolgt immer Prozess- und Kontextbezogen, d.h. es werden innerhalb eines Fensters nur diejenigen Option dargestellt welche gerade relevant sind. Es gibt kein eigentliches Hauptmenü oder Hauptfenster (auch wenn es ein Menü mit diesem Namen gibt). Dafür gibt es drei Menüs welche zentral sind: Das Main Menü erlaubt das Aufzeichnen von Web-Browser Sessions sowie das Nachbearbeiten bzw. das Erweitern der gewonnen Aufzeichnung mit zusätzlichen Funktionalitäten. Über das Zwischenmenü Generate Load Test Program kann danach die Aufzeichnung in ein lauffähiges Lasttest-Programm konvertiert werden. Der Project Navigator erlaubt das Verwalten der aufgezeichneten Web-Browser Sessions und das Verwalten der Lasttest-Programme. Darüber hinaus können die Lasttest-Programme vom Projekt Navigator aus gestartet werden und legen ihre Testbzw. Mess-Resultate wiederum im Project Navigator ab. Das Analyse Load Test Menu erlaubt das analysieren der Test- und Mess-Resultate sowie den Vergleich von verschiedenen Testresultaten untereinander by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 5 / 125

6 Von diesen 3 zuvor erwähnten zentralen Menüs arbeitet nur der Project Navigator mit permanenten d.h. Disk-gestützten Daten. Die beiden anderen Menüs (wie auch die meisten weitern Menüs) arbeiten mit transienten Daten welche sich im temporären Speicherbereiche des Programms befinden. Die weiteren Menüs welche in der vorangehenden Darstellung eingezeichnet sind haben folgende Funktionalitäten: Web Tools / Page Scanner: erlaubt das automatische Scannen ganzer Web-Sites inklusive aller darin enthaltenen Web-Pages. Das Resultat kann direkt in eine Web-Browser Session umgewandelt werden aus der wiederum ein Lasttest-Programm erzeugt werden kann. Dies stellte eine schnelle und automatisch durchführbare Alternative zum manuellen Aufzeichnnen von Web-Browser Sessions im Main Menu dar, welche jedoch nur zum Testen von einfach aufgebauten Web-Sites angewandt werden kann. Eigentliche Web-Applikationen können hingegen nur mit manuell, im Main Menu aufgezeichneten Web-Browser Sessions, getestet werden. Var Finder: erlaubt eine schnellen Überblick über alle ausgetauschten GGI- und Formular-Parameter einer ganzen Web-Browser Session. Mittels dieses Menüs können zudem dynamisch ausgetauschte Session-Parameter automatisch mit einem Maus-Klick nachbehandelt werden (z.b..net VIEWSTATE-Parameter). URL Details / Var Handler: zeigt einerseits alle Details eines aufgezeichneten URL-Aufrufs an. Andererseits können im Var Handler auch Input-Files definiert und deren Inhalt URL-Parametern zugewiesen werden, was z.b. das Anmelden an eine Web-Applikation mittels unterschiedlichen Benutzeraccounts erlaubt. Mittels des Var-Handlers können auch eine Vielzahl vom weiteren Lasttest Programm-Optionen dynamisch behandelt werden wie z.b. die Abänderung des zu testenden Web-Server(-Namens). Response Test Configuration: Proxy Sniffer prüft während eines Lasttests nebst dem HTTP Status-Code der URL-Aufrufe auch den empfangenen Inhalt der Web-Pages mittels eines automatisch angewandten heuristischen Verfahrens um sogenannte false positive Messungen auszuschliessen. Mittels dieses Menüs kann der automatische angewandte Inhalts-Test manuell modifiziert werden. Session Cutter: erlaubt das Zusammenschneiden einer oder mehrerer aufgezeichneten Web-Browser Sessions zu einer neuen Web-Browser Session analog einem Schneidetisch auf dem ein Film zusammengeschnitten wird. Zusätzlich können Web-Browser Sessions auch von externen Definitions-Files importiert werden. Execute Load Test: zeigt die wichtigsten Statistiken eines Lasttests währen dessen Ausführung in real-time an. Eventuell aufgetretene Fehler können bereits während des laufenden Lasttests dargestellt und analysiert werden. Load Curve Diagrams: zeigt die Lastkurven eines Web-Servers bzw. einer Web-Applikation an. D.h. wie sich die Antwortzeiten, der Durchsatz und die Stabilität unter verschiedenen Lastbedingungen verhalten. Mittels dieses Menüs kann auch die maximale Leistungsfähigkeit eines Web- Servers oder einer Web-Applikation bestimmt werden. Comparison Diagrams: zeigt einen grafischen Vergleich der gemessenen Antwortzeiten desselben Testprograms an, welches zu unterschiedlichen Zeitpunkten ausgeführt wurde. So kann z.b. die Auswirkung von Server-Tuning-Massnahmen dargestellt werden, indem die Antwortzeiten vor dem Tuning denen nach dem Tuning gegenübergestellt werden by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 6 / 125

7 Detail Statistics & Diagrams: zeigt alle gesammelten Messresultate eines einzelnen Tests im Detail an. Dies umfasst über 21 verschiede Statistiken und Diagramme. Error Details: zeigt alle Details der während eines Lasttests aufgetretenen Fehler an. Das Menü kann zur Laufzeit eines Lasttests wie auch nach dem Ende eines Lasttests aufgerufen werden. Beachten Sie bitte, dass die Liste der vorgenannten Menus nicht vollständig ist. Zusätzlich stehen viele weitere Menüs zur Verfügung welche zum Beispiel Daten exportieren, PDF-Reports erzeugen, Such-, Lösch- oder Filter-Funktionen enthalten oder die Konfiguration des Proxy Sniffer Produkts betreffen. Weitere hier nicht erwähnte Menüs erlauben das Ausführen von Lasttests auf Remote-Systemen oder auch die Kombination von mehreren Last-auslösenden Systemen zu einem Cluster. All diese weiteren Menüs sind im vorliegenden User s Guide beschrieben, sofern diese nicht offensichtlich einfach bedienbar sind. Bei allen Menüs steht Ihnen zusätzlich ein Menü-spezifischer Help-Text in Englischer Sprache zur Verfügung, welchen Sie über das Help-Icon des entsprechenden Menüs situationsbezogen abrufen können. Beispiel: Die nachfolgenden Kapitel enthalten nun eine Schritt-für-Schritt Anleitung zur Bedienung des Proxy Sniffer Produkts by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 7 / 125

8 2 Installation Während der Installation sind Administratoren-Rechte nötig. Nach der Installation d.h. während des normalen Betriebs benötigt das Produkt auch weiterhin schreib-zugriff auf das Installations-Directory. 2.1 System-Anforderungen Unterstützt Betriebssysteme: Windows NT/2000/XP/2003/Vista oder Unix: Solaris, Linux, BSD, Mac OS X Arbeitsspeicher: MB Ram (empfohlen), mindestens jedoch 256 MB Ram Bildschirm: Auflösung mindestens 1280 x 800 Pixel, mit geringerer Auflösung ist die Bedienung des GUIs nicht mehr übersichtlich Benötigter Disk-Speicherplatz: ca. 80 MB Web Browser: Mozilla Firefox ab V1.0 oder Microsoft Internet Explorer ab V6.0 Bei Unix-Systemen muss zusätzlich ein Java SDK vorinstalliert sein (V1.3, 1.4 oder 1.5). Prüfen Sie mit which java und which javac oder auch mittels find / -name javac -print ob auf dem Unix-System bereits ein Java SDK installiert ist. Das Windows Installations-Kit enthält ein eigenes, integriertes Java-Kit, welches keinen Einfluss auf andere, bereits installierte Java Versionen hat. Unter Windows ist keine Vorinstallation nötig by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 8 / 125

9 2.2 Windows Installation Starten Sie Prx40P.exe und folgen Sie den Anleitungen des Installations-Menüs. Nach der Installation befinden sich auf dem Desktop 3 neue Icons: Hinweis: falls Sie die neuen Desktop-Icon stören so können Sie diese löschen. Dieselben Einträge im Windows Start-Menü bleiben dabei erhalten. Weitere Einträge sind danach auch im Windows Start-Menü vorhanden: Sie finden hier u.a. das Application Reference Manual, welches die System-Architektur des Produkts genauer beschreibt. Um das Produkt zu starten müssen Sie zuerst auf das Icon/Startmenü Proxy Sniffer Server und danach auf das Icon/Startmenü Proxy Sniffer GUI klicken by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 9 / 125

10 2.3 Unix Installation 1. Erzeugen Sie das Installations-Directory /usr/local/prxsniff von Hand 2. Kopieren Sie das File prxsniff.jar in das Installations-Directory (Sie können dieses File auch einer Windows-Installation entnehmen) 3. Erzeugen Sie das File prxsniff.key im Installations-Directory mittels eines Texteditors (z.b. vi). Dieses File muss den Proxy Sniffer Lizenz-Key enthalten. 4. Setzen Sie die Java CLASSPATH Umgebungs-Variable so, dass diese das Installations-Directory, das Default-Directory ("."), sowie den Pfad zum File prxsniff.jar enthält. Beispiel 1: export CLASSPATH="/usr/local/prxsniff:.:/usr/local/prxsniff/prxsniff.jar" Beispiel 2: export CLASSPATH=.:prxsniff.jar 5. Starten Sie Proxy Sniffer mit folgendem Befehl: java -Xmx256m -Xbootclasspath/p:/usr/local/prxsniff/prxsniff.jar ProxySniffer -WebAdmin -JobController -ExecAgent -tz ECT 6. Starten Sie den Mozilla Firefox Web-Browser und geben Sie folgende URL ein Architektur-Übersicht Beim Starten des Produkts werden 4 Server auf Ihrem lokalen System gestartet: 1. Ein spezieller Proxy Server welcher zum Aufzeichnen von Web-Browser Sessions dient (Proxy Sniffer) 2. Ein integrierter Web-Server für das GUI (Web Admin) 3. Ein Server welcher das Ausführen von Lasttest-Jobs erlaubt (Exec Agent) 4. Ein Server welcher die Kombination von mehreren Systemen bzw. Exec Agents zu einem Last-auslösenden Cluster erlaubt (Job Controller) Die nachfolgenden TCP/IP Server Ports werden auf Ihrem lokalen System verwendet: TCP/IP Port Nummer Beschreibung 7990 Integrierter Web-Server, GUI (Web Admin) 7993 Lasttest ausführender Server (Exec Agent) 7995 Unterstützung von Exec Agent Clustern (Job Controller) 7998 Interner Kommunikations-Port (Proxy Sniffer Server) 7999 HTTP Proxy Port (Proxy Sniffer Server) 7997 HTTPS Proxy Port (Proxy Sniffer Server) 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 10 / 125

11 3 Konfiguration des Web-Browsers Nachdem Sie Proxy Sniffer installiert und gestartet haben und das URL in Ihrem Web-Browser eingegeben haben oder auf das Icon Proxy Sniffer GUI geklickt haben, sehen Sie das Main Menu. Dieses wird auch als Web Admin bezeichnet: Bevor Sie jedoch Web-Browser Sessions aufzeichnen können müssen Sie zuerst Ihren Web-Browser umkonfigurieren: o o Lokale, vom eigenen Rechner erzeugte Popup-Fenster müssen zugelassen werden. Ein spezieller, lokaler Proxy Server wurde bereits mit dem Produkt gestartet. Um eine Aufzeichnung einer Web-Browser Session vorzunehmen müssen Sie Ihren Web-Browser so umkonfigurieren, dass der Datenverkehr zwischen Web-Browser und Web-Server (indirekt) durch den lokalen Proxy Server des Produkts hindurch fliesst. Diese zwei Konfigurationsänderungen werden nachfolgend genauer beschrieben by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 11 / 125

12 3.1 Lokale Popup-Fenster Zulassen Das Web GUI erzeugt Popup-Fenster, welche vom eigenen Rechner stammen. Sie müssen darum den Web-Browser und gegebenenfalls weitere lokal installierte Security-Software so konfigurieren, dass Popup-Fenster vom eigenen Rechner zugelassen werden. Dies ist kein Sicherheitsproblem, da Popup-Fenster von externen Web-Servern weiterhin blockiert bleiben. Die nachfolgenden Screenshots zeigen, wie lokale Popup-Fenster beim Microsoft Internet Explorer zugelassen werden. Verwenden Sie dazu immer die fixe IP Loopback-Adresse Gehen Sie wie folgt vor wenn der Internet Explorer diesbezüglich einen Sicherheitshinweis anzeigt: Alternativ können Sie den Internet Explorer auch direkt über Extras Internetoptionen Datenschutz konfigurieren by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 12 / 125

13 Die nachfolgenden Screenshots zeigen, wie lokale Popup-Fenster beim Mozilla Firefox zugelassen werden: Hinweis: falls Sie Google Toolbar verwenden müssen Sie auch dessen Popup-Blocker konfigurieren bzw. de-aktivieren by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 13 / 125

14 3.2 Umkonfigurieren des Web-Browsers zur Aufzeichnung Während der Aufzeichnung fliesst der Datenverkehr zwischen Web-Browser und Web-Server durch das Produkt hindurch, dazu wurde lokal auf Ihrem Rechner ein so genannter HTTP/S Proxy-Server gestartet. Darum müssen Sie Ihren Web-Browser so konfigurieren, dass dieser den Proxy Server auf Ihrem eigenen Rechner verwendet. Dessen Ports sind 7999 für HTTP und 7997 für HTTPS. Beim verschlüsselten HTTPS Protokoll entschlüsselt der lokale Proxy-Server die Daten zur Laufzeit. Sie erhalten darum im Web-Browser während der Aufzeichnung eine Warnungsmeldung bezüglich des Server-Zertifikats, welche Sie (nur in diesem Zusammenhang) ignorieren können. Hinweis: ist keine echte TCP/IP Adresse sondern die virtuelle Loopback-Adresse des eigenen Rechners. D.h. jeder Rechner kann sich selbst unter dieser Adresse ansprechen. Verwenden Sie immer und nie eine reale Adresse zur Konfiguration. Die Konfiguration des Proxy-Servers im Web-Browser sollten Sie nach dem Aufzeichnen einer Web-Browser Session wieder rückgängig machen. Die Konfiguration wird nur zum Aufzeichnen, jedoch nicht bei beim Ausführen von Lasttests benötigt. Falls Sie bereits firmenintern einen Proxy-Server verwenden und Aufzeichnungen gegenüber firmenexternen Web-Servern machen möchten, so müssen Sie Proxy Sniffer zusätzlich mit Ihrem firmeninternen Proxy-Server kaskadieren. Das einsprechende Menü dazu finden sie im Proxy Sniffer Hauptmenü unter Personal Settings, Kapitel by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 14 / 125

15 3.2.1 Beispiel Proxy-Konfiguration für Microsoft Internet Explorer: Fall der Reiter Connections bzw. Verbindungen im Options-Menü nicht angezeigt wird, so hat ihre IT-Abteilung diesen abgeschaltet. Versuchen Sie mittel regedit diesen wieder zu aktivieren: Setzen Sie dazu den Wert von "\HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Control Panel\ConnectionsTab" von 1 auf 0 (0=eingeschaltet) by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 15 / 125

17 3.2.3 Web-Browser Warnung bei verschlüsselten Verbindungen Beim Aufzeichnen von verschlüsselten HTTPS-Verbindungen werden Sie von Web-Browser eine Warnungsmeldung erhalten, da Proxy Sniffer zur Laufzeit zum Zweck der Aufzeichnung eine Entschlüsselung durchführt, und darum das originale Web-Server Zertifikat durch ein eigenes ersetzt. Je nach Web-Browser Produkt welches Sie einsetzen sieht diese Warnungsmeldung anders aus. Klicken Sie gegebenenfalls mehrmals auf ignorieren / weiterfahren / fortsetzen um die Aufzeichnung fortzusetzen. Wichtiger Hinweis: ignorieren Sie solche Warnungen niemals, wenn Sie nicht mit Proxy Sniffer aufzeichnen Ihre vermeintlich verschlüsselte Verbindung könnte im Klartext von unberechtigten Dritten abgehört werden, oder von Cyber Criminals" modifiziert bzw. missbraucht werden by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 17 / 125

18 4 Aufzeichnen von Web-Browser Sessions Web-Browser Sessions müssen zuerst aufgezeichnet werden bevor daraus ein Lasttest-Programm erzeugt werden kann. Alternativ dazu können Sie für einfache Anwendungszwecke auch das Page Scanner Tool verwenden (Kapitel 13.1). Tests gegenüber eigentlichen Web-Applikationen müssen jedoch immer manuell aufgezeichnet werden. Hierzu benötigen Sie ein zweites Web-Browser Fenster um die Aufzeichnung vorzunehmen. Die Aufzeichnung erfolgt in der Art, dass Sie im zweiten Browser-Fenster die Web-Browser Session manuell vor-surfen. Gehen Sie wie folgt vor: 1. Starten Sie ein zweites Web-Browser Fenster 2. Löschen Sie den Web-Browser Cache * (im zweiten Web-Browser Fenster) 3. Klicken Sie im ersten Web-Browser Fenster, im Web Admin GUI, auf Start Record 4. Geben Sie im zweiten Web-Browser Fenster die erste URL des Ziel-Servers ein, welcher getestet werden soll (Start Web-Seite der Aufzeichnung) Die erste Web-Seite sollte nun aufgezeichnet sein. Klicken Sie zur Kontrolle im Web Admin GUI (erstes Fenster) rechts oben auf das Refresh Display Icon. Dadurch erschein eine technische Darstellung der einzelnen URLs (HTML-File, Bilder etc.) der Web-Seite. Hinweis: wenn Sie die Aufzeichnung der ersten Seite nicht sehen, so ist die Proxy-Konfiguration des Web-Browsers nicht richtig konfiguriert. Erstes Web-Browser Fenster: Web Admin GUI Zweites Web-Browser Fenster: Vor-Surfen der Web-Browser Session * Beachten Sie bitte, dass Sie den Web-Browser Cache jedes Mal wieder löschen müssen, bevor Sie eine neue Web-Browser Session aufzeichnen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 18 / 125

20 4.2 Aufzeichnen nachfolgender Web-Seiten Bevor Sie nun weitere Web-Seiten aufzeichnen d.h. bevor Sie im zweiten Web-Browser Fenster auf einen Hyperlink klicken oder ein Formular abschicken müssen Sie einen Seitenwechsel-Kommentar (Page Break) eingeben. Der Grund liegt darin, dass der universelle Proxy Recorder nur einzelne Teile eine Web-Seite wie HTML Dateien oder Bilder sieht, jedoch nicht erkennen kann, wann eine Seite anfängt und wie diese endet. Gehen Sie für alle nachfolgenden Web-Seiten einer Aufzeichnung wie folgt vor: 1. Überlegen Sie zuerst, als was Sie im zweiten Browser-Fenster klicken würden, bzw. welches Formular Sie absenden würden: nur denken, noch nicht klicken. 2. Geben Sie einen Seitenwechsel-Kommentar (Page Break) ein. Beschreiben Sie mit ein, zwei Stichworten, welche Web-Seite als nächstes aufgezeichnet wird. 3. Führen Sie die geplante Aktion der Aufzeichnung nun durch: klicken Sie im zweiten Browser-Fenster auf den Hyperlink oder senden Sie das Formular ab. Erstes Browser-Fenster: Web Admin GUI Zweites Browser-Fenster: Vor-Surfen der Web-Browser Session Die Zeit in Sekunden, welche neben dem Seitenwechsel-Kommentar steht, ist die natürliche Bedenkzeit zum Betrachten der Web-Seite (user s think time) welche nachher im Lasttest pro Benutzer appliziert wird, bevor die nächste Web-Seite aufgerufen wird. Der daneben stehende Prozentwert ist die zufällige Abweichung von dieser Zeit, so dass nicht alle Benutzer genau gleich lange warten bzw. überlegen. Sie können diese Werte auch nachträglich noch ändern oder mit Variablen versehen.? Klicken Sie auf Stop Record im Web Admin GUI, nachdem Sie die letzte Web-Seite aufgezeichnet haben by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 20 / 125

21 4.3 Abspeichern der Aufzeichnung Nach der Aufzeichnung sollten Sie nun die Web-Browser Session abspeichern. Geben Sie nebst dem File-Namen auch noch einen kurzen Kommentar zur Web-Session ein, damit Sie sich später besser erinnern können, was aufgezeichnet wurde. Nach dem Abspeichern erscheint das Projekt Navigator Menü. Sie können später eine ausgezeichnete Web-Browser Session wieder laden, indem Sie auf das entsprechende Icon im Projekt Navigator klicken by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 21 / 125

22 4.4 Kontrolle der aufgezeichneten Web-Session Nachdem die Web-Browser Session aufgezeichnet wurde sollten Sie folgendes kontrollieren: 1. Enthält die Web-Browser Session ausschliesslich URL-Aufrufe der Web-Server, welche auch getestet werden sollen? 2. Ist die automatisch angewandte Inhalts-Überprüfung der Web-Seiten sinnvoll vor-konfiguriert? Kontrolle der getesteten Web-Server Bei einigen Web-Seiten sind eventuell Referenzen (1 Pixel grosse Bilder) auf externe Session-Tracking Server integriert, welch Sie nicht unter Last setzen sollten. Beim Aufzeichnen von verschlüsselten HTTPS-Verbindungen mit dem Microsoft Internet Explorer überprüft dieser vor dem Zugriff auf die eigentliche Web-Site oft zuvor mit einem HTTP Aufruf an Microsoft die Gültigkeit der Stammzertifikate. Solche URL-Aufrufe werden auch aufgezeichnet. Diese sollten Sie jedoch aus der Web-Browser Session entfernen bevor Sie den Lasttest erzeugen. Überprüfen Sie kurz bei jeder aufgezeichneten Web-Seite die URL-Aufrufe auf unerwünschte Rechner-Namen oder IP-Adressen, welche nichts mit der Web-Applikation bzw. Web-Site zu tun haben, welche Sie testen möchten. Entfernen Sie solche URL-Aufrufe indem Sie diese löschen mit einem Klick auf das Delete-Icon eines URLs öffnet sich ein Menü welches dies erlaubt. Alternativ können Sie auch den Host-Filter nutzen, indem sie den Rechner- Namen der Web-Applikation eingeben, oder einen unerwünschten Rechner-Namen herausfiltern in dem Sie ein Ausrufzeichen (!) vor den Rechner- Namen im Host-Filter setzen. Mehrere Rechner-Namen, getrennt durch Kommas, können auch eingegeben werden.? 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 22 / 125

23 4.4.2 Kontrolle der automatischen Inhaltsüberprüfung Durch einen Klick auf das View Icon ändert sich die Ansicht der aufgezeichneten Web-Browser Session, so dass Sie nun kontrollieren können, wie der empfangene Dateninhalt der URL-Aufrufe während des Lasttests überprüft wird. Eine gute Prüfung ist oft wichtig, da nur so in HTML-Seiten verpackte Fehlermeldungen der Web-Applikation gefunden werden können. Verzichten Sie niemals auf die Überprüfung des Inhalts in dem Sie diese abschalten die Ergebnisse solcher Lasttests sind dadurch oft nicht gültig. Bilder (*.gib, *.jpg) werden während des Lasttests aufgrund der empfangenden Grössen geprüft. Dies ist effizient und meistens problemlos. HTML- Seiten (und auch XML-Files) werden so geprüft, dass ein bestimmter Text in der Seite gefunden werden muss. Proxy Sniffer benutzt dazu einen automatischen, heuristischen Algorithmus, welcher pro HTML-Seite nach einem möglichst passenden Text-Fragment in der Aufzeichnung des entsprechenden URL-Aufrufs sucht und dieses als Kontrolle des Inhalts während des Lasttests appliziert. Diese sog. Test-Strings der HTML-Seiten sollten Sie kurz dahingehend prüfen, ob auch aussagekräftige Text-Fragmente darin enthalten sind.? Klicken Sie auf das Lupen-Icon, um einen Test-String zu ändern, Sie gelangen dadurch in das Response Test Configuration Menü des URL-Aufrufs. Hinweis: nachdem Sie die Kontrolle des Inhalts abgeschlossen haben, sollten Sie nochmals auf das View Icon klicken um die ursprüngliche Ansicht wiederherzustellen nur diese zeigt Ihnen alle möglichen Optionen an (mit Ausnahme natürlich der Inhaltsüberprüfung) by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 23 / 125

24 Im Response Test Configuration Menü sehen Sie, welche Text-Fragmente der HTML-Seite der heuristische Algorithmus bestimmt und bewertet hat. Die Bewertungs-Skala (Quality) hat einen Bereich von 1.0 bis 0.0 wobei 1.0 die best mögliche Bewertung ist. Falls das automatisch ausgewählte Text-Fragment zu wenig aussagekräftig ist, können Sie dieses ändern, indem Sie auf einen roten Balken in der List of proposed test-strings klicken oder indem Sie einen freien Text im Feld String eingeben. Bei der Eingabe eines freien Texts stehen Ihnen zusätzlich weitere Möglichkeiten zur Verfügung: Beispiele: [!<Text>] Dieser Text darf auf der Web-Seite nicht auftreten #<Anzahl>[<Text>] Der Text muss auf der Web-Seite genau <Anzahl> mal auftreten. #<min. Anzahl>-[<Text>] Der Text muss auf der Web Seite mindestens <min. Anzahl> mal auftreten. #<min. Anzahl>-<max. Anzahl>[<Text>] Der Text muss auf der Web Seite mindestens <min. Anzahl> mal auftreten, jedoch nicht mehr als <max. Anzahl>![ORA-01652] Der Text ORA darf nicht auftreten #1[Vielen Dank für Ihren Einkauf] Vielen Dank für Ihren Einkauf darf genau einmal auftreten. #1-2[Ihre Zahlung] Der Text Ihre Zahlung muss einmal, darf jedoch höchstens zweimal auftreten Hinweis: Es ist darüber hinaus auch möglich, einzelnen (auch mehrere) Teile des Texts, oder den ganzen Text mit variablen Werten zu versehen, welche z.b. von einem bestimmten Benutzer-Account abhängen. Das Format für das Einsetzen einer Variable ist {$<Variablen-Name>}. Beispiel: Willkommen {$Geschlecht} {$Name}. Mehr Informationen zum Umgang mit Variablen erhalten Sie in Kapitel 6.1, Variablen Handler by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 24 / 125

25 4.5 Session Cutter Das Session Cutter Menü erlaubt das Zusammenschneiden einer oder mehrerer Web-Browser Sessions zu einer neuen Web-Browser Session analog dem Zusammenschneiden eines Films auf einem Schneidetisch. Dabei können jedoch nur rohe Web-Browser Sessions zusammengeschnitten werden, d.h. solche Web-Browser Sessions, bei denen noch keine Nachbearbeitung erfolgte (mittels des Var Finders Kapitel oder mittels des Var Handlers Kapitel 6.1). Wird eine nachbearbeitete Web-Browser Session in den Session Cutter geladen, so erscheint eine Warnungsmeldung. Bei einem Übergehen dieser Warnungsmeldung werden danach alle Nachbearbeitungen gelöscht, d.h. diese müssen gegebenfalls nach dem Aufruf des Session Cutters neu appliziert werden. Einzelne Web-Pages können selektiert werden, in dem auf den Namen der Web-Page geklickt wird. Danach können die selektierten Web-Pages mittels der Knöpfe move here oder copy here verschoben bzw. kopiert werden. Nach der Zusammenschneiden der Web-Browser Session kann das Session Cutter Menü durch einen Klick auf den Close Knopf oder durch einen erneuten Klick auf das Session Cutter Icon verlassen werden. Hinweis: zusätzlich können Web-Browser Sessions auch von externen Definitions-Files importiert werden. Klicken Sie auf das Help-Icon des Import-Dialogs um mehr über das Datenformat von externen Definitions-Files zu erfahren by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 25 / 125

26 4.6 Weitere Hinweise zum Aufzeichnen von Web-Browser Sessions Unterstütze HTTP/S Clients Zur Bedienung des Web Admin GUIs werden nur die Web-Browser Produkte Microsoft Internet Explorer ab Version 6.0 sowie Mozilla Firefox ab Version 1.0 unterstützt. Zum Vor-Surfen (Aufzeichnen) der Web-Session kann jedoch jeder beliebige Web-Browser und ebenso technische HTML Client- Applikationen ohne Oberfläche verwendet werden. So kann z.b. eine Web-Session mit einem Opera Browser oder mit einem technischen SOAP Client auch aufgezeichnet werden. Dabei fliesst die spezifische Charakteristik des HTML-Clients genau in das Lasttest-Programm ein, d.h. der spezifische Datenverkehr wird während des Lasttests genau so simuliert, wie dieser aufgezeichnet wurde (inklusiv der Client-Kennzeichnung / HTTP Header Field User-Agent ) Proxy-Recorder und GUI Einstellungen (Personal Settings Menü) Mittel des Personal Settings können Sie diverse Optionen einstellen welche während einer Aufzeichnung einer Web-Browser Session zu Anwendung kommen. Sie können den lokalen Proxy Server von Proxy Sniffer mit einem weiteren, abgehenden Proxy-Server kaskadieren (z.b. dem Ihrer Firma). Auch können Sie spezielle Authentisierungs-Methoden gegenüber einer Web-Applikation setzen, wie NTLM und X509 Client- Zertifikat basierende Authentisierung. Eine spezielle Konfiguration ist jedoch nicht nötig für HTML Formularbezogene Authentisierungs-Verfahren oder für Basic-Authentication Proxy Kaskadierung (Connect to Next Proxy) Checkbox im Titel: diese muss auf aktiv gesetzt werden damit die Proxy Kaskadierung wirksam wird. Hinweis: um einen Lasttest über einen Proxy Server auszuführen müssen Sie später beim Erzeugen des Lasttest-Programms, im Menü Generate HTTP(S) Load Test Program (Kapitel 7) die Option Load Test over HTTP(S) Proxy" verwenden. Eingabefelder: Next Proxy HTTP Host: DNS-Name oder IP-Adresse des kaskadierten Proxy Servers für unverschlüsselte HTTP-Verbindungen. Next Proxy HTTP Port: TCP/IP Port Nummer des kaskadierten Proxy Servers für unverschlüsselte HTTP-Verbindungen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 26 / 125

27 Next Proxy HTTP Cache disabled: falls diese Checkbox aktiviert ist so wird der kaskadierten Proxy Server angewiesen, den übertragenen Inhalt nicht zu cachen (empfohlene Option). Next Proxy HTTPS Host: DNS-Name oder IP-Adresse des kaskadierten Proxy Servers für verschlüsselte HTTPS-Verbindungen. Next Proxy HTTPS Port: TCP/IP Port Nummer des kaskadierten Proxy Servers für verschlüsselte HTTPS-Verbindungen. Next Proxy Auth Username: Benutzername, falls der Zugriff auf den kaskadierten Proxy Server eine Authentisierung benötigt. Next Proxy Auth Password: Passwort, falls der Zugriff auf den kaskadierten Proxy Server eine Authentisierung benötigt. No Next Proxy for Host/Domain: Ausschluss-Liste von Host- oder Domain-Namen, für welche der kaskadierte Proxy Server nicht verwendet werden soll. Die einzelnen Host- oder Domain-Namen müssen durch Kommas oder Strichpunkte getrennt werden HTTPS Settings Mittels diesen Einstellungen können Sie das Verhalten des lokalen Proxy Servers bei der Aufzeichnung von verschlüsselt übertragenen Daten bestimmen. Eingabefelder: SSL Version: erlaubt das Setzen einer bestimmten SSL Protokoll-Version (v2 / v3 / TLS / automatisch bestimmt) SSL Session Cache enabled: schaltet den Client-seitigen SSL-Cache ein (empfohlene Option). SSL Session Cache Timeout: Verweildauer der SSL Verbindungsdaten im Client-seitigen SSL-Cache (falls dieser eingeschaltet ist) Enhanced Compatibility Mode: aktiviert einen erweiterten SSL Kompatibilitätsmodus welcher auch Web-Server unterstützt, die das SSL Protokoll nur fehlerhaft handhaben. HTTPS Response Timeout: maximale Zeitdauer eines verschlüsselten HTTPS URL-Aufrufs. Wird diese Zeitdauer überschritten, so wird der URL-Aufruf abgebrochen (keine Antwort vom Web-Server erhalten) NTLM Authentication Erlaubt dass sich der lokale Proxy Server gegenüber einer Web-Applikation mittels des NTLM Verfahrens Authentisiert. Checkbox im Titel: diese muss auf aktiv gesetzt werden damit die NTLM Authentisierung wirksam wird. Hinweis: um einen Lasttest mittels NTLM Authentisierung auszuführen müssen Sie später beim Erzeugen des Lasttest-Programms, im Menü Generate HTTP(S) Load Test Program (Kapitel 7), die Option NTLM Authentication" verwenden. Dabei kann auch festgelegt werden, dass jedem simulierten Lasttest-Benutzer einen eigener NTLM-Account zugewiesen wird by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 27 / 125

28 Eingabefelder: Protocol: NTLM Protokoll-Version welche zur Aufzeichnung verwendet wird (üblicherweise v2) Domain: Name der Windows-Domain Username: Windows-Benutzername, welcher zur Aufzeichnung verwendet wird Password: Password des Windows-Benutzernamens HTTPS Client Certificate Authentication Erlaubt dass sich der lokale Proxy Server gegenüber einer Web-Applikation mittels eines X509 Client-Zertifikats Authentisiert. Das X509 Client-Zertifikat muss im PKCS#12 File-Format vorliegen. Hinweis: gewöhnliche HTTPS Verbindungen benötigen kein Client-Zertifikat. Hinweis: um einen Lasttest mittels einer X509 Client-Zertifikats basierender Authentisierung auszuführen müssen Sie später beim Erzeugen des Lasttest-Programms, im Menü Generate HTTP(S) Load Test Program (Kapitel 7), die Option HTTPS Client Certificates" verwenden. Dabei kann auch festgelegt werden, dass jedem simulierten Lasttest-Benutzer einen eigenes X509 Client-Zertifikat bzw. PKCS#12 File zugewiesen wird. Nach dem Laden eines Client-Zertifikats erscheint unter der Spalte Active ein roter Balken. Sie müssen in den roten Balken klicken, damit das Zertifikat bei der Aufzeichnung verwendet wird. Dadurch verwandelt sich dieser in ein grünes Häkchen GUI Settings Eingabefelder: Time Zone: erlaubt das Setzen der Zeitzone welche vom GUI und von den Lasttest-Programmen verwendet wird. Number Format: erlaubt das Setzen der Formatierung von Zahlen bzw. des Tausender-Trennzeichens, welche vom GUI angewandt wird ( oder 123,456.78). Background Color: erlaubt das Setzen der Hintergrundfarbe aller GUI-Windows by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 28 / 125

29 5 Inner Loops Sie können optional auch innere Schlaufen (Inner Loops) um Teile der aufgezeichneten Web-Session definieren. Zum Beispiel sollen die Benutzer während eines Lasttests sich einmal anmelden, danach aber mehrere aufgezeichnete Web-Seiten in einer Schlaufe wiederholen, und sich danach wiederum (einmal) abmelden. Die Inner Loops werden während des Lasttests durch (äussere) Loops umfasst, d.h. wenn Sie z.b. einen Lasttest mit 3 Loops pro Benutzer starten (und eine unbegrenzte Zeitdauer angeben), so wird pro Benutzer die ganze aufgezeichnete Web-Session dreimal wiederholt und innerhalb einer solchen Wiederholung repetitiv jeweils der bzw. die Inner Loops ausgeführt. Inner Loops können nur um ganze Web-Seiten (eine oder mehrere) umfassen, jedoch nicht einzelne URL-Calls. Sie können jedoch auch nachträglich an beliebigen Stellen Page Breaks (Seitenwechsel-Kommentare) einfügen. Um einen Inner Loop zu definieren klicken Sie bei einem Page Break ganz links auf der Zeile in dessen Item-Nummer. Optionen: Inner Loop Description: frei wählbarer Text zur Beschreibung des Inner Loops (Pflichtfeld) Inner Loop End Page: Web-Seite, auf welcher der Inner Loop endet (inklusiv der URL-Calls dieser Seite). Loop Iterations: Anzahl Iterationen welche ausgeführt werden. Die Anzahl kann auch variabel sein und z.b. durch Werte eins Input Files (Kapitel 6.2) oder User Input Fields gesteuert werden (Kapitel 6.3). Action if planned duration of Load Test exceeded: steuert was passiert, wenn die Zeitdauer des Lasttests erreicht wird und sich ein Benutzer gerade in einem Inner Loop befindet. - abort inner loop after current iteration: die aktuelle Iteration wird zu Ende geführt. Danach wird der Inner Loop abgebrochen - continue with iterations: alle noch ausstehenden Iterationen werden wie geplant noch durchgeführt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 29 / 125

30 Enable Pacing: bestimmt die minimale Zeitdauer einer Iterationen. Dauert eine Iteration kürzer als bei dieser Option angegeben, so wird die Iteration verzögert. Die Zeitdauer kann auch variabel sein. Hinweis: Inner Loops werden im Web Admin durch schwarze Balken links aussen gekennzeichnet und können auch verschachtelt definiert werden: 5.1 Bedingtes Ausführen von Teilen der Web-Session Sind die Anzahl Iterationen eines Inner Loops von einer Variablen abhängig (Kapitel 6), so darf diese auch den Wert 0 annehmen, was bedeutet, dass der Inner Loop übersprungen wird, so dass einzelnen Benutzer während des Lasttests Teile der Aufzeichnung nicht ausführen. Die Variablen zur Steuerung der Iterationen werden dazu üblicherweise aus Input Files gewonnen, welche auf dem Sichtbarkeitslevel new line per user oder new line per loop definiert werden (Kapitel 6.2). Damit die Statistik des Lasttest-Programms stimmt ist es jedoch erforderlich, dass ein Inner Loop mindestens einmal von irgendeinem Benutzer während des Lasttests durchlaufen wird by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 30 / 125

31 6 Nachbearbeiten der Web Session dynamische Session-Parameter Nachdem eine Web-Session aufgezeichnet wurde kann das entsprechende Lasttest-Programm erzeugt werden (siehe Kapitel 7). Oft ist es jedoch wünschenswert oder sogar erforderlich, dass die Web-Session zuvor nachbearbeitet wird. Mögliche Beispiele dazu sind: Die aufgezeichnete Session enthält einen HTML Formular-basierender Login-Vorgang und Sie möchten diesen so anpassen, dass jeder Benutzer einen eigenen Account währen des Lasttests verwendet. Sie möchten Parameter der Web-Session variabel gestalten, in der Art, dass diese Parameter vor jeder Testausführung individuell gesetzt werden können, oder dass jeder Benutzer während des Lasttests eigene Parameter verwendet. Die aufgezeichnete Session enthält vom Server erzeugte, dynamische Session-Parameter, welche zur Laufzeit aus Web-Seiten extrahiert und nachfolgenden Web-Seiten übergeben werden müssen, damit der Test erfolgreich läuft. Beispielsweise eine Bestell-Nummer bei einem Web Shop welche bei jedem Einkauf wieder ändert. Das Nachbearbeiten von Web-Sessions geschieht mittels eines zentralen, GUI basierten Variablen Handlers, welcher alle dynamischen Änderungen der Web-Session verwaltet. Die dazu nötigen Operationen erfolgen immer in zwei Schritten: 1. Extrahieren oder definieren einer oder mehrer dynamischer Variablen 2. Zuweisen einer oder mehrer dynamischer Variablen Oder anders formuliert: eine Variable muss zuerst extrahiert werden, bevor diese einem Zweck zugewiesen werden kann. Viele Dialoge enthalten jedoch auch Optionen zur automatischen Zuweisung um den Benutzerkomfort zu erhöhen. Das Extrahieren einer Variablen ist von der Zuweisung vollkommen unabhängig. Es entstehen so viele mögliche Kombinationen welche flexibel angewandt werden können. Variablen können über das GUI von folgenden Quellen extrahiert werden: - Aus Input Files, welche zur Laufzeit des Lasttests eingelesen werden (Kapitel 6.2) - Aus User Input Fields, d.h. aus frei definierbaren Programm-Optionen welche beim Starten eines Tests gesetzt werden können (Kapitel 6.3) - Aus Parametern von HTML-Formularen, z.b. Werte von hidden Formular-Feldern - Aus Werten von CGI-Parametern von Hyperlinks, von HTTP-Umleitungen (Redirections) und von HTML Formular-Aktionen - Aus beliebigen HTML oder XML Text-Fragmenten 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 31 / 125

32 Eine Variable, gleichgültig wie diese extrahiert wurde, lässt sich mittels des GUI folgenden Zwecken zuweisen: - einem Wert eines HTML-Formular Felds - einem Wert eines CGI-Parmeters eines URL-Aufrufs - einem Text-Fragment eines URL-Aufrufs - dem Protokoll, Hostnamen oder TCP/IP Port eines URL-Aufrufs - der User s Think Time einer Web-Seite - der Inhaltsüberprüfung einer Web-Seite: gesuchtes Textfragment oder Grösse der empfangenen Daten (siehe Kapitel 4.4.2) - der Anzahl Iterationen und dem Pacing Delay von Inner Loops (siehe Kapitel 5) Jeder Variable ist immer an einem Sichtbarkeitslevel (sog. Scope) gebunden. Mögliche Sichtbarkeitslevels sind: - global: alle Benutzer des Lasttests sehen den selben Wert der Variablen. - user: obwohl die Variable nur einmal definiert wurde, sieht jeder Benutzer während des Lasttests seinen eigenen Wert, d.h. von der Variable existieren so viele virtuelle Kopien, wie Benutzer während des Lasttests emuliert werden. - loop: wird die aufgezeichnete Web-Browser Session vom gleichen Benutzer mehrmals repetitiv ausgeführt, so werden die einzelnen Repetitionen als Loop bezeichnet. Eine Variable mit dem Sichtbarkeitslevel loop kann während jeder Ausführung einer solchen Repetition pro Benutzer einen anderen Wert annehmen. - inner loop: die Sichtbarkeit ist auf einen Teil der Web-Browser Session begrenzt, welcher innerhalb des Loops wiederum repetitiv ausgeführt wird (siehe Kapitel 5). Der Umgang mit Variablen erscheint auf den ersten Blick etwas komplex. Wie Sie aber noch sehen werden unterstützt Sie das GUI des Variablen Händlers mit komfortablen und leistungsfähigen Dialogen, so dass Sie nach kurzer Zeit fähig sind, anspruchsvolle Problemstellungen mit wenigen Maus-Klicks zu lösen. Programmierkenntnisse sind dazu nicht nötig by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 32 / 125

33 6.1 Variablen Handler (Var Handler) Sie gelangen zum Variablen Handler Menü (auch Var Handler genannt), indem Sie auf ein beliebiges aufgezeichnetes URL klicken. Im linken Teil des Fensters sehen Sie alle Details des aufgezeichneten URLs welche von URL zu URL anders sind. Im rechten Teil sehen Sie den Variablen Handler, welcher eine Zusammenfassung aller Variablen und deren Definitionen anzeigt dieser Teil des Fensters bleibt für alle URL gleich by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 33 / 125

34 6.2 Input Files Klicken Sie im Var Handler auf Add File um ein neues Input File zu definieren und geben Sie den Namen des Input Files ohne Pfadangabe ein Option File Scope Line Order Comment Tag Var Delimiter EOF Action Beschreibung Definiert die Sichtbarkeit welche später die Variablen erhalten, welche aus diesem Input File gewonnen werden: global (one-line): macht hier oft wenig Sinn, da nur eine einzige Zeile während des ganzen Lasttests gelesen würde. new line per user: pro emulierten Benutzer wird während des Lasttests je eine Zeile eingelesen. Dies ist der richtige Scope zum einlesen von Benutzer-Accounts new line per loop: jedes Mal, wenn ein Benutzer einen Loop ausführt, wird eine neue Zeile eingelesen. Dabei kann nicht gesteuert werden, welcher Benutzer welche Zeilen- Sequenzen erhält. NL per inner loop: für jede Iteration eines Inner Loops, egal von welchem Benutzer diese durchgeführt wird, wird eine neue Zeile eingelesen. Dieser Scope steht nur zur Verfügung wenn Inner Loops definiert wurden. Steuert, ob die Zeilen sequenziell oder in zufälliger Reihenfolge (randomized) eingelesen werden. Einzelne Zeilen können im File auch auskommentiert werden. Das Kommentarzeichen am Anfang der Zeile ist frei wählbar; es kann auch eine Zeichensequenz sein. Variablen-Trennzeichen. Aus einer Zeile können mehrere Variablen gleichzeitig extrahiert werden, welche durch ein Trennzeichen separiert sind. Steuert was während des Lasttests passiert, wenn alle Zeilen des Files bereits eingelesen wurden, und nun eine weitere Zeile verlangt wird: reopen file bedeutet, dass das File neu geöffnet wird. Wurde zusätzlich eine randomized Line Order gesetzt, so werden die Zeilen nun auch nochmals neu gemischt. stop load test bedeutet, dass der Lasttest abbricht. Diese Option kann z.b. sinnvoll sein, wenn eine Applikation das doppelte Anmelden mit gleichen Benutzer-Accounts nicht unterstützt. Beachten Sie bitte, dass auch bei zufälliger Line Order die EOF Bedingung eintreten kann dann wenn jede Zeile einmal gelesen wurde. Es gibt keine doppelten Zeilennummern solange noch zufällige Zeilen frei sind by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 34 / 125

35 Nachdem ein Input File definiert wurde müssen Sie dieses noch erstellen bzw. ein bereits vorhandenes File kopieren. Das Input-File muss in demselben Directory des Projekt Navigators sein, in sich später das Lasttest-Programm befindet. Öffnen Sie dazu das Projekt Navigator Menü und wählen Sie ein bestehendes Directory aus, oder erzeugen Sie ein neues Directory: Links oben im Projekt Navigator sehen Sie das aktuelle Directory; hierhin oder in ein entsprechendes Subdirectory sollten Sie ein bestehendes Input-File kopieren. Mittels des Icons können Sie im Projekt Navigator ein neues, leeres File definieren und dessen Inhalt eingeben. Klicken Sie nach dessen abspeichern auf Refresh im Projekt Navigator rechts oben. Mittels des Icons können Sie ein neues Subdirectory im Projekt Navigator anlegen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 35 / 125

36 Kehren Sie nun wieder zum Var Handler zurück, indem Sie den Projekt Navigator mit dem Close Icon (rotes Kreuz, oben rechts) schliessen. Als nächstes sollten Sie das korrekte Parsing des Input Files prüfen, indem Sie auf das Icon des Input Files klicken: Nun können Sie die Variablen aus dem Input File extrahieren, indem Sie auf Das Variablen-Extraktor Icon klicken: Optionen: Line#Column bezeichnet aus welcher Spalte (1, 2, 3..) der Zeile die Variable extrahiert wird Var Name bezeichnet den Variablen Namen. Dieser darf nur aus den Zeichen A..Z, a..z, 0..9 sowie _ bestehen und darf keine Leerzeichen enthalten. Der Name darf nicht mit einem _ beginnen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 36 / 125

37 Die vollständige Definition des Input-Files noch ohne die Zuweisung der extrahierten Variablen sieht in diesem Beispiel so aus: Die roten Balken mit dem Text password und username sind die Namen der Variablen. Dahinter folgt in eckigen Klammern der Sichtbarkeitslevel (Scope). Die blauen Pfeile nach links bedeuten, dass der Wert der Variablen extrahiert wird. Am Ende der selben Zeile erfolgt ein Hinweis, woraus der Extrakt gewonnen wird. Mit einem Klick auf die das Lupen-Icon können weitere Einzelheiten dargestellt werden, wie der Wert der Variablen extrahiert wird. Sie können dabei auch die Definition des entsprechenden Variablen-Extraktors löschen. Durch einen Klick auf einen der roten Balken können Sie die Definition einer Variable bzw. eines Input Files wieder löschen. Um dieses Beispiel zu vervollständigen, muss nun der Benutzername und das Passwort dem entsprechenden Formular-Werten des Login-Vorgangs zugewiesen werden, bzw. dessen URL-Aufruf. Sie können dazu im Hauptmenü die Aufzeichnung aller URLs durchsehen, und dann auf das entsprechende URL klicken, um die Details des URL-Aufrufs anzuzeigen und zu modifizieren. Falls Sie jedoch den entsprechenden URL-Call nicht sofort finden, so können Sie auch die ganze aufgezeichnete Session nach einem Stichwort durchsuchen. In diesem Fall bietet sich als Stichwort das Passwort des Benutzer Accounts an, welches während der Aufzeichnung der Web-Session verwendet wurde. Um den URL-Call des aufgezeichneten Passworts zu suchen klicken Sie auf das Search Overall Menu und geben Sie als Suchtext das Passwort ein: Klicken Sie im Suchergebnis auf den roten Pfeil nach rechts um zu den Details der URL-Calls zu gelangen. Hinweis: rote Pfeile nach Rechts im Suchergebnis bedeuten, dass der Text bei einem URL-Call vom Web Browser an den Server gesendet wurde. Blaue Pfeile nach links bedeuten, dass der Text in einer URL-Antwort des Servers gefunden (empfangen) wurde by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 37 / 125

38 Nachdem Sie den URL-Call gefunden haben, welcher die Login-Daten übermittelt, können Sie die Variablen den entsprechenden Formular- Parametern zuweisen. Optionen der Zuweisung: Assign from Var: wählen Sie hier die Variable aus, welche dem Formular-Parameter zugewiesen wird Var value conversion: none: der Wert der Variable wird unverändert zugewiesen. encode: der Wert der Variable wird zuerst URLkodiert und dann zugewiesen. Beispiel Zürich HB ergibt Z%FCrich+HB. Sie müssen bei Formular-Parametern diese Option verwenden, wenn der Wert der Variable Sondezeichen oder Leerzeichen enthalten kann. decode: ist die Umkehroperation von encode. Diese Option wird normalerweise niemals verwendet. Assign var to all request parameters with same recorded value: durch diese Option werden alle Parameter aller URL-Calls der aufgezeichneten Web Session untersucht, ob derselbe aufgezeichnete Wert des Parameters ein weiters mal verwendet wurde. Werden bei anderen URL-Calls solche Parameter gefunden, so wird die Variable auch diesen zugewiesen (globales ersetzen des Wertes) Die vollständige Definition im Var Handler sieht danach so aus: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 38 / 125

39 6.2.1 Weitere Hinweise zu Input Files Das da extrahieren von Variablen getrennt von deren Zuweisung erfolgt, können Sie Input Files für viele weitere Zwecke nutzen. Beispielsweise: o o o o Zum Testen von Suchmasken, wobei z.b. die erste Variable einer Zeile den Suchbegriff enthält und z.b. die zweite Variable derselben Zeile ein Stichwort enthält, welches im Suchresultat gefunden werden muss. Zum variablen gestalten der User s Think Time pro Benutzer Zum variablen gestalten, wie viele Iterationen in einem Inner Loop ausgeführt werden Als Eingabe der Artikelbezeichnung oder Warennummer bei einem Bestellvorgang Sie können auch mehrere Input Files für eine Web-Session definieren. 6.3 User Input Fields User Input Fields sind frei definierbare globale Variablen, deren Werte beim Starten eines Lasttest Programms jedes Mal neu abgefragt bzw. eingegeben werden. Diese können auch mit einem Default-Wert versehen werden. Im nachfolgenden Beispiel wird ein User Input Field verwendet, um den Hostnamen (der Name des Web-Servers) variabel zu gestalten, so dass z.b. das gleiche Lasttest-Programm zum Testen eines Testsystems wie auch des produktiven Systems eingesetzt werden kann. Optionen: Var Name: Name der Variable. Dieser darf nur die Zeichen A..Z, a..z, 0..9 sowie _ enthalten. Der Name darf nicht mit einem _ beginnen. Var Label Text: bezeichnet einen freien Text, mit welchem das User Input Field auf dem GUI dargestellt wird (Stichwort, Sinn). Default Value: dies ist die Vorbelegung des Werts des User Input Fields auf dem GUI by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 39 / 125

40 Nachdem das User Input Field definiert wurde kann dieses dem Hostnamen zugewiesen werden. Dazu kann in der Regel ein beliebig aufgezeichneter URL-Call verwendet werden: Optionen: Assign to: hier können Sie festlegen ob die Variable dem Protokoll (http, https) oder dem Hostnamen oder dem TCP/IP Port zugewiesen wird. Falls Sie zwei oder alle drei Werte variabel gestalten möchten, so müssen Sie zusätzliche User Input Fields definieren und zuweisen. Assign from Var: wählen Sie hier die Variable aus, welche zugewiesen wird Assign var to all requests with same protocol, host and port: aktivieren Sie die Checkbox (empfohlen), um die Variable allen aufgezeichneten URL-Calls zuzuweisen. Beachten Sie jedoch, dass eine solche automatische Zuweisung nur für URL- Calls gilt, welche das gleiche Protokoll und den gleichen Hostnamen und den gleichen Port verwenden. Wenn beispielsweise die aufgezeichnete Web- Session sowohl http wie auch https Aufrufe enthält, so müssen Sie diesen Vorgang einmal bei einem URL- Call vornehmen, welcher mit http aufgezeichnet wurde und noch einmal bei einem anderen URL-Call vornehmen, welcher mit https aufgezeichnet wurde. Zum setzen des Hostnamens recht dazu jedoch eine Variable, d.h. Sie benötigen hier nur ein User Input Field. Falls die Web-Session über mehrere verschiedene Web-Server aufgezeichnet wurde, so müssen Sie diese Option auf einem URL-Call vornehmen, welcher den richtigen Web Server enthält by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 40 / 125

41 Später, beim Starten des Lasttest-Programms wird das User Input Field angezeigt. Pro Web-Session können Sie bis zu 12 verschiedene User Input Fields definieren Weitere Hinweise zu User Input Fields User Input Fields werden auch oft verwendet, um die User s Think Time variabel zu gestalten oder auch um z.b. ein Buchungsdatum bei Banküberweisungen vorzugeben. Falls Sie später einmal einen Lasttest nicht über das GUI starten sondern über ein Script, so müssen Sie beachten, dass das User Input Field im Script als zusätzlicher Parameter angegeben werden muss, wobei der Name des Parameters dem Namen der Variable entspricht. Beispiel: java PrxJob transmitclusterjob Cluster 1 Test01 -u 100 -d 300 -t 60 -nolog -hostname testsys.ggjhkjg.com 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 41 / 125

42 6.4 Dynamisch ausgetauschte Session-Parameter Das HTTP Protokoll selbst ist zustandslos von URL-Call zu URL-Call. Darum werden üblicherweise Session-Cookies verwendet, um auf dem Web- Server den dazu nötigen roten Faden zu erhalten, in welchem Zustand sich ein Benutzer gerade befindet. Cookies werden automatisch unterstützt, so dass dies auf den ersten Blick kein Problem zu sein scheint. Nun ist es leider jedoch so, dass viele Web-Applikationen zusätzlich zu Cookies weitere dynamische ausgetauschte Session-Parameter verwenden, deren Werte zur Laufzeit vom Web-Server zuvor in ausgegebenen HTML-Code eingesetzt werden, z.b. in hidden Formular Feldern oder als zusätzliche CGI-Parameter bei Hyperlinks. Der Web-Server erwartet nun, dass bei einem nachfolgenden URL-Call der von ihm gesetzte Wert wieder zurückgesendet wird. Das Problem besteht nun darin, dass damals als die Web-Session aufgezeichnet wurde, der Wert wohl richtig war, später jedoch, wenn der Lasttest ausgeführt wird, der Wert des Parameters veraltet ist oder nicht mehr zum aktuellen Session-Cookie des Benutzers passt, und Sie darum fälschlicherweise anstelle der verlangten Web-Page während des Lasttests eine Fehlermeldung vom Web-Server erhalten (z.b. es ist ein interner Applikations-Fehler aufgetreten ). Ein typischer Fall ist der _VIEWSTATE Parameter, welcher vom Microsoft spezifischen Server-Applikationen verwendet wird. Die Lösung dieses Problem besteht darin, dass nun währen der Laufzeit des Lasttests die Werte solcher dynamisch ausgetauschten Session-Parameter aus HTML-Seiten extrahiert werden müssen und den nachfolgenden URL-Calls übergeben werden müssen. Damit Sie diese Aufgabe auch lösen können, ohne die Entwickler der Web-Applikation zu Fragen, stellt Ihnen Proxy Sniffer das Var Finder Menü zur Seite. Sie könne den Var Finder vom Hauptmenü oder von Var Handler aus aufrufen: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 42 / 125

43 6.4.1 Automatische Behandlung von dynamisch ausgetauschten Session-Parametern (Var Finder) Das Var Finder Menü zeigt über die ganze Web-Session, über alle URL-Calls eine Übersicht aller jemals verwendeten Request-Parameter und deren Werte an. Dabei wird ein Request-Parameter welcher immer den gleichen Wert enthält nur ein Mal dargestellt, auch wenn dieser bei mehreren URL-Calls verwendet wurde. Wurde jedoch derselbe Parameter (-Name) mit unterschiedlichen Werten gefunden, wird dieser pro unterschiedlichen Wert mehrmals dargestellt. Gehen Sie wie folgt vor: 1. Schätzen Sie als erstes anhand der Parameter- Werte (Recorded Value) ab, welche Parameter als Kandidaten für einen dynamischen Austausch in Frage kommen. Enthält der Wert eine lange Nummer oder eine kryptische Zeichenkombination, so haben Sie einen potentiellen Kandidaten gefunden Im Beispiel links sind dies die potentiellen Parameter levid, id und VIEWSTATE. Jedoch nicht type und Status1:ins_step22:txtPolicyNumber da deren Werte währen der Aufzeichnung von Hand eingegeben wurden. 2. Versuchen Sie als nächstes, eine automatische Behandlung des dynamischen Parameters durchzuführen. Dies gelingt in ca. 50% aller Fälle. Klicken Sie dazu auf das Icon des Parameters: Erhalten Sie danach eine Erfolgsmeldung, so müssen Sie nichts Weiteres mehr bezüglich dieses Parameters tun: Die entsprechenden Definitionen zum extrahieren und zuweisen des Parameters werden im Var Handler automatisch vorgenommen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 43 / 125

44 Erhalten Sie jedoch eine Fehlermeldung, so müssen Sie den Wert des Parameter von Hand extrahieren (siehe folgendes Unterkapitel). Bei diesem Beispiel konnte auch der Parameter VIEWSTATE automatisch behandelt werden. Es bleibt also nur noch der Parameter id übrig, welcher von Hand extrahiert werden muss. Dieser ist jedoch zweimal aufgeführt (wegen unterschiedlicher Werte). D.h. dieser Parameter muss auch zweimal extrahiert und zugewiesen werden. Tipp: Sie können das Var Finder Menü auch als Checkliste benutzen um zu sehen, welche Parameter bereits dynamisch behandelt wurden. Überall dort, wo in den Spalten First Extract und First Assign gleichzeitig blaue und rote Pfeile vorhanden sind ist die dynamische Behandlung bereits erfolgreich geschehen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 44 / 125

45 6.4.2 Manueller Extrakt von dynamisch ausgetauschten Session-Parametern Gelingt die automatische Behandlung eines Parameters nicht, so müssen Sie auf das Lupen-Icon links in der Zeile des Var Finders klicken. Dadurch wird die ganze Web-Session nach dem Wert des Parameters durchsucht: Die blauen Peile nach links bedeuten, dass der Parameter vom Web-Server empfangen wurde. Die roten Pfeile nach rechts bedeuten, dass der Parameter an den Web-Server gesendet wurde. Sie müssen nun den Wert des Parameters extrahieren bevor dieser gesendet wurde. Dazu bietet sich in diesem Beispiel Item 19 (URL-Call 19) an. Wichtig ist auch, ob der Wert aus dem HTTP Response Header (bei einer Umleitung) oder aus dem HTTP Response Content (Dateninhalt) extrahiert werden kann. Bei diesem Beispiel steht neben dem blauen Pfeil Found in Response Content, d.h. der Wert des Parameters lässt sich aus dem empfangenen Dateninhalt extrahieren. Hinweis: die Zuweisung geschieht (später) automatisch. Wie Sie jetzt schon sehen muss dieser dynamische Parameter den URL-Calls 33, 35 und 38 zugewiesen werden. Klicken Sie nun auf den ersten blauen Pfeil nach links by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 45 / 125

46 Es erscheint darauf hin in diesem Beispiel das URL Details Menü des URL-Calls 19. Klicken Sie auf search um den Dateninhalt nach dem Wert zu durchsuchen. Der gefundene Wert wird rot markiert. Da die automatische Behandlung fehlschlug, können Sie wahrscheinlich den Wert nicht mittels des HTML Formular-Parsers extrahieren (HTTP Response Content Forms Extract) und auch nicht mittels des Hyperlink-Parsers (HTTP Response Content Unique Hyperlinks Extract). In einem solchen Fall müssen Sie darum den frei definierbaren Textmuster-Parser verwenden. Gegen Sie wie folgt vor: 1. Scollen Sie zum Anfang der Zeile des gefundenen Werts und merken Sie sich die Zeilennummer (hier 232): 2. Suchen Sie in der Nähe der Stelle, wo der Wert gefunden wurde, ein eindeutiges Textmuster, welches im ganzen empfangenen Inhalt nur einmal vorkommt. Dieses kann sich auch einige Zeilen vor oder nach dem Wert befinden. 3. Markieren Sie dieses eindeutige Textmuster und klicken Sie auf das Extrakt-Icon. Das markierte Textmuster darf den Wert selbst nicht umfassen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 46 / 125

47 4. Warten Sie 3 Sekunden bis das Textmuster in den Var Handler kopiert wurde (Feld: Search Text) und klicken Sie danach auf Test Extract. Wenn sich das eindeutige Textmuster nicht auf der Zeile des Werts befindet, so müssen Sie zuvor noch den relativen Zeilen-Offset im Feld Extract Var on eingeben (Differenz zwischen diesen Zeilen). 5. Vergleichen Sie die Zeilennummer welche bei Extracted on Line im Var Handler ausgegeben wird mit derjenigen Zeilennummer, auf welchem sich der Wert des zu extrahierenden Parameters befindet (bei Schritt 1). Wenn die beiden Zeilennummern nicht übereinstimmen so ist das Testmuster nicht eindeutig. Sie müssen in einem solchen Fall ein anderes Textmuster wählen (zu Schritt 2 dieser Liste zurückkehren).? 6. Schauen sie im Dateninhalt nach, durch welche Zeichen der rot markierte Wert umfasst wird. In diesem Beispiel sind dies r und : Geben Sie diese beiden Zeichen welchen den Wert umfassen im Feld Token Delimiters ein. Klicken Sie danach wiederum auf Test Extract und danach auf das daneben stehende blaue Fragezeichen?. 7. Es wird nun ein Popup-Fenster angezeigt, welche alle Textfragmente der Zeile des Werts enthält. Geben Sie die Nummer des Textfragments welches den Wert enthält im Feld Extract Token Nr. des Var Handlers ein und klicken sie wiederum auf Test Extract by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 47 / 125

48 8. Kontrollieren Sie danach, ob der Wert genau ohne weitere Zeichen am Anfang und Ende unter Recorded Value in blauer Farbe dargestellt wird. 9. Geben Sie zum Schluss einen frei wählbaren Variablen-Namen im Feld Map to Var Name ein (in diesem Beispiel id_1 anstelle von nur id, da der Parameter zweimal extrahiert werden muss, wegen unterschiedlicher Werte im Var Finder). Aktivieren Sie die Checkbox Assign var to all request parameter with same recorded value um das automatischer Ersetzen des Werts zu gewährleisten und lassen Sie die Checkbox Try Url Encoding aktiviert. Klicken Sie danach auf den Extract Button.? Die entsprechende Konfiguration im Var Handler für den Variable id_1 zeigt nun, dass diese von URL 19 extrahiert und den URLs 33, 35 und 38 zugewiesen wurde. Dies entspricht den Erwartungen welche Sie ganz am Anfang sahen, all Sie auf das Lupen-Icon im Var Finder geklickt haben. Hinweis: bei diesem Beispiel müssten Sie den ganzen Vorgang nochmals wiederholen, um den zweiten gefundenen dynamischen Wert von id auch variabel zu gestalten. Nach der Modifikation des Var Handlers sollte die Web- Session wiederum abgespeichert werden, damit die neuen Definitionen nicht verloren gehen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 48 / 125

49 6.4.3 Ersetzen von Textmustern In seltenen Fällen kommt es vor, dass nicht der ganze Wert eines Parameters ersetzt werden soll, sondern nur ein Teil dessen. Weitere seltene Fälle sind, wenn der Parameter-Name selbst variabel ist (anstelle oder zusätzlich zum Wert) oder ein File-Pfad eines URL-Calls einen variablen Wert enthält. Gehen sie in einem solchen Fall wie folgt vor: 1. Benutzen Sie wie im Unterkaptitel zuvor beschrieben den frei definierbaren Text-Parser um den Wert zu extrahieren. 2. Verwenden Sie nun anstelle der Option Assign var to all request parameter with same recorded value die Option Assign var to all matching request file and request content patterns with same recorded value. Hinweis: in weiteren seltenen Fällen kann ein Textmuster nicht aus dem Inhalt eines URL-Calls extrahiert werden, weil eine HTTP Redirection (Umleitung) aufgetreten ist, aus welcher nun der Wert mit dem Text- Parser extrahiert werden muss. Auch dies wird unterstützt. Falls zwei Extraktor-Icons vorhanden sind, so müssen Sie dazu das letztere verwenden: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 49 / 125

50 6.5 Zusammenfassung der möglichen Extrakt- und Zuweisungs-Operationen Das nachfolgende Bild zeigt eine Übersicht aller Möglichkeiten der Extrakt- und Zuweisungs-Operationen von URL-Calls. Beachten Sie bitte dass bei User Input Fields und bei Input Files keine automatische Zuweisung erfolgt, d.h. dass Sie diese manuell durchführen müssen. Wert einem CGI- Parameter zuweisen Wert dem Protokoll, Host- Namen oder Port zuweisen Wert eines Textmusters eines Formulars ersetzen. Wert eines Textmusters des URL-Pfads ersetzen Wert einem Formular- Parameter zuweisen Wert aus einem Formular- Parameter extrahieren Textmuster aus dem empfangenen Inhalt extrahieren Wert eines CGI-Parameters einer Umleitung extrahieren Textmuster einer Umleitung extrahieren CGI-Parameter aus einem Hyperlink extrahieren 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 50 / 125

51 6.6 Direkte Definition von Variablen Üblicherweise werden Variablen implizit definiert, aufgrund von User Input Fields, Input Files, durch den Var Finder oder beim manuellen extrahieren von Werten im Var Handler. Für spezielle Zwecke können Variablen jedoch auch direkt definiert werden und je nach Sichtbarkeitslevel (Scope) mit verschiedenen Initialwerten versehen werden. Unterstützte Kombinationen von Scope und Initialwerten sind: Initial Value G U L IL fixed value null current user counter - loop counter ¹ ² - - inner loop counter system time milliseconds load source ip host name ³ ³ - load source ip address ³ ³ - G = [global var] U = [user var] L = [loop var] IL = [inner loop var] ¹ = (äusserer) Loop Zähler über alle Benutzer ² = (äusserer) Loop Zähler des Benutzers ³ = unterstützt zusätzlich auch multihomed Systeme-Konfigurationen (Kapitel 11) Initial-Werte: - text: (oberste Option rechts oben im Bild). Die Variable wird mit einem konstanten, frei definierbaren Wert initialisiert - null: der Wert der Variable wird (vorerst) als ungültig markiert - current user counter: Laufnummer des aktuellen Benutzers (0, 1, 2..) während des Lasttests - loop counter: je nach Scope (global oder user) (äusserer) Loop Zähler über alle Benutzer bzw. Loop Zähler des aktuellen Benutzers - inner loop counter: Iterations-Zähler des Inner Loops (0, 1, 2..) - system time milliseconds: aktuelle Systemzeit im Millisekunden seit load source ip host name: Rechnername des Exec Agents (Last-auslösender Rechner) - load source ip address: IP Adresse des Exec Agents (Last-auslösender Rechner) 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 51 / 125

52 6.7 J2EE URL-Rewriting Java Applikationsserver können so konfiguriert werden, dass diese anstelle von Web-Session-Cookies das Verfahren URL-Rewriting verwenden. Dieses Verfahren funktioniert so, dass jedem vom Applikationsserver ausgegebenen HTML Formular und Hyperlink der Name und Wert des Web- Sessions-Parameters (anstelle des Cookies) zur Laufzeit hinzugefügt wird, bevor die Daten an den Web-Browser gesendet werden. Beispiel eine Hyperlinks welcher vom Applikationsserver mit URL-Rewriting versehen wurde: <A HREF=" Der URL-Rewriting Parameter wird noch vor den CGI-Parametern dem File-Pfad des URLs hinzugefügt. Als Trennzeichen wird ein Semikolon (Strichpunkt) verwendet. Üblicherweise unterstützt ein Java Applikationsserver gleichzeitig Session-Cookies wie auch URL-Rewriting, wobei pro Benutzer jedoch nur eines der beiden Verfahren zur Anwendung kommt. Der Default-Algorithmus eines Applikationsservers läuft wie folgt ab: 1. Beim allerersten Aufruf des Benutzers auf eine beliebige Web-Seite des Applikationsservers weiss dieser noch nicht, ob der Web-Browser Cookies unterstützt. Darum enthält die Antwort des Servers einerseits ein Session-Cookie und andererseits werden auch alle ausgegebenen Formulare und Hyperlinks mit URL-Rewriting versehen. 2. Klickt nun der Benutzer auf einen Hyperlink oder sendet dieser ein Formular ab so wird das Session-Cookie an den Web-Server zurück übertragen und der Applikationsserver erkennt daran, dass der Web-Browser Cookies unterstützt. Für alle nachfolgenden Web-Seiten führt der Applikationsserver nun kein URL-Rewriting mehr durch. 3. Es kann jedoch auch sein, dass der Web-Browser keine Session-Cookies unterstützt oder dass der Applikationsserver so umkonfiguriert wurde, dass dieser gar kein Session-Cookies sendet und nur auf Basis von URL-Rewriting arbeitet. In einem solchen Fall wird bei alle nachfolgenden Web-Seiten wiederum URL-Rewriting vom Applikationsserver appliziert. Üblicherweise müssen Sie nichts Spezielles konfigurieren, da der Java Applikationsserver Session-Cookies unterstützt. Lässt dieser jedoch nur URL-Rewriting zu, so müssen Sie dessen Unterstützung zuerst im Var Handler konfigurieren, damit später der Lasttest erfolgreich abläuft. Sie erkennen dies daran, dass bei mehr als nur eine aufgezeichnete Web-Seite diese mit URL-Rewriting Parametern und Werten versehen wurde. Gehen Sie wie folgt vor: 1. Klicken Sie bei einem beliebigen URL-Call auf das URL-Rewriting Icon im Var Handler 2. Geben Sie den Namen des URL-Rewriting Parameters ein. 3. Geben Sie einen neuen, frei definierbaren Variablen-Namen ein 4. Übernehmen Sie den Default-Wert automatically für die dynamische Behandlung des URL- Rewriting Parameters 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 52 / 125

53 Nach der erfolgreichen Konfiguration des URL-Rewritings zeigt der Var Handler nur den ersten Extrakt des URL-Rewriting Parameters an, nicht jedoch dessen Zuweisung an nachfolgende URL-Calls. Dies ist normal d.h. Sie müssen nichts weiter konfigurieren, die Zuweisung erfolgt später automatisch während des Lasttests. Hinweis: der Name des URL-Rewriting Parameters heisst nicht zwingend jsessionid. Die Entwickler können dessen Namen im Server frei konfigurieren. In einem solchen Fall müssen Sie die den aktuellen Namen des Parameters im Feld Rewrite Parameter eingeben. Sie erkennen ein URL-Rwriting in jedem Fall daran, das in den File-Pfaden der URL-Calls ein Semikolon vorhanden ist, gefolgt von einem Parameter-Namen, einem Gleichheitszeichen und einem kryptischen Wert. Je nach Programmierung der Applikation kommt es manchmal vor, dass der Wert des Parameters während der Web-Session ändert, z.b. nach einem Login- oder Logout-Vorgang. Proxy Sniffer erkennt und behandelt dies automatisch. In einem solchen Fall zeigt der Var Handler mehrere Extrakte des URL- Rewriting Parameters an by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 53 / 125

54 7 Erzeugen des Lasttest-Programms Beachten Sie, dass nur diejenigen URL-Calls in das Lasttest-Programm übernommen werden, welche Sie im Hauptmenü auch sehen. D.h. Sie können den Filter im Hauptmenü dazu benutzen um gewisse Arten von URL-Calls nicht in das Lasttest-Programm einfliessen zu lassen: Filter Optionen: - No Binary Data (Images...): filtert alle URL-Calls weg, deren empfangene Daten binär sind wie z.b. Bilder und Flash-Animationen. - No CSS, JS (Only HTML): filtert alle URL-Calls weg, deren empfangene Daten in lesbarem Textformat sind, jedoch nicht HTML-Code enthalten. Z.B. JavaScript Dateien oder auch Style Sheets werden weggefiltert. - No Cached Data (304): aufgezeichnete URL-Calls mit dem HTTP Status-Code 304 sind auf ein Missverständnis des Cache-Verhaltens zwischen Web-Browser und Web-Server zurückzuführen. Diese Filter-Option sollte immer aktiv sein. - No Errors: werden fehlerhafte URL-Calls aufgezeichnet, so wird während des Lasttests geprüft, ob der Fehler auch immer noch vorhanden ist (Erfolg = Fehler vorhanden). Sie können dieses Verhalten unterdrücken indem Sie fehlerhafte URL-Calls wegfiltern. - Host: wird ein Hostname angegeben, so werden alle URL-Calls, welche nicht diesen Host betreffen, weggefiltert. Alternativ kann ein Ausrufzeichen (!) vor dem Hostnamen angegeben werden, was bedeutet, dass nur URL-Calls zu diesem Host weggefiltert werden. Mittels dieser Option können Sie z.b. URL-Calls zu einem externen Web Session-Tracking Server (externe Zugriffstatistik) wegfiltern. Es können auch mehrere Hostnamen eingegeben werden, getrennt durch Kommas (,) mit oder ohne Ausrufezeichen vor dem Hostnamen. Klicken Sie auf das Generate Load Test Icon im Hauptmenu oder im URL-Detail / Var Handler Menü um das Lasttest-Programm zu erzeugen: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 54 / 125

55 Üblicherweise geben Sie hier nur den Namen des Lasttest- Programms sowie einen kurzen stichwortartigen Kommentar ein, ohne weitere Optionen zu wählen. Spezielle Optionen sind nötig wenn: - Sie eine Lasttest über einen abgehenden Proxy-Server ausführen möchten - wenn Sie mehrere Benutzer-Accounts für Basic Authorisation verwenden möchten - Wenn eine NTLM Authentisierung erforderlich ist - Wenn HTTPS/SSL Client-Zertifikate zur Authentisierung erforderlich sind Optionen: - Java Code Model: bestimmt die innere Struktur des Java Lasttest-Programms. Dieser Wert wird normalerweise automatisch richtig gesetzt. Falls (später) die Kompilation mit der Meldung fehlschlägt, dass eine Methode zu gross sei (zu viele Bytes), so erzeugen Sie das Lasttests-Programm nochmals, wobei Sie diesmal den Wert large wählen. - Content Test Algorithm: bestimmt, wie der Inhalt der empfangenen Daten während des Lasttests geprüft wird: o [+] apply (heuristic) methods from recorded session to check received content: bedeutet, dass die Konfiguration der automatischen Inhaltsüberprüfung sowie alle Änderungen welche Sie an dieser vorgenommen haben angewandt wird. Zusätzlich wird der HTTP Status- Code (200, 302..) sowie der MIME-Type (image/gif, text/html..) jedes URL-Calls geprüft. Nur diese Option garantiert, dass die Web- Seiten richtig geprüft werden. o [±] compare received content of all URL calls with recorded size (+/- 5%): bedeutet, dass der empfangene Inhalt aller URL-Calls nur bezüglich der Grösse geprüft wird wobei Abweichungen von ± 5% zulässig sind. Die automatische Inhaltsüberprüfung wird nicht angewandt, jedoch wird der HTTP Status-Code sowie der MIME-Type während des Lasttests geprüft. Die Resultate solcher Lasttests sind oft nicht gültig, da so Fehlermeldungen innerhalb von Web-Seiten nicht immer erkannt werden, oder bei dynamisch erzeugten Web- Seiten irrtümlich Fehler aufgrund variierender Grösse des Inhalts gemessen werden. o [ ] none - response content test disabled: bedeutet, dass bei allen URL-Calls der empfangene Dateninhalt nicht geprüft wird; d.h. es wird nur der HTTP Status-Code sowie der MIME-Type während des Lasttests geprüft. Die Resultate solcher Lasttests sind oft nicht gültig, da Fehlermeldungen innerhalb von Web-Seiten so nicht erkannt werden by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 55 / 125

56 - HTTP Protocol Version: 1.1 bedeutet, dass das normale Standard-Verhalten aller Web-Browser angewandt wird, indem (pro Benutzer) dieselbe Netzwerk-Verbindung mehrmals für den Aufruf der URL-Calls wieder verwendet wird (HTTP Keep-Alive Unterstützung des Clients). Version 1.0 bedeutet, dass für jeden einzelnen URL-Call eine eigene Netzwerk-Verbindung aufgebaut und danach wieder geschlossen wird. - Allow Keep-Alive: die HTTP Keep-Alive Unterstützung des Clients kann für HTTP 1.1 optional deaktiviert werden. Dies ist jedoch nicht empfohlen. - Strip Referer Header Field: das Referer Header Field enthält Zusatzinformationen bei einem URL-Call, welche beschreiben, von welcher Web- Seite dieser initiiert wurde. Diese Information wird jedoch vom Web-Server nicht interpretiert. Viele lokale Security-Tools entfernen auch gezielt diese Information, damit das Surf-Verhalten des Benutzers auf dem Web-Server nicht ausspioniert werden kann. Das Referer Header Field ist nicht nötig und wird darum standardmässig nicht in das Lasttest-Programm übernommen. - Strip Accept Header Field to */*: Mit dem (historischen) Accept Header Field gibt (gab) der Web-Browser dem Web-Server bekannt, welche Datentypen (MIME-Typen) zur Darstellung im Web-Browser unterstützt werden. Dies ist ein sehr langer Text, welcher von heutigen Web-Servern nicht mehr interpretiert wird. Anstelle dessen wird als Default-Wert beim Lasttest */* übertragen was bedeutet, dass alle Datentypen vom Client unterstützt werden. - Load Test over HTTP(S) Proxy: wählen Sie diese Option wenn das Lasttest-Programm einen abgehenden Proxy-Server verwenden soll. Die Daten des Proxy-Servers werden aus der Proxy-Konfiguration des Personal Setting Menüs (Kapitel ) direkt in das Lasttest-Programm übernommen. - Basic Authorisation: falls eine Basic Authorisation während Aufzeichnung nötig war, so wird der Benutzername und das Passwort automatisch in das Lasttest-Programm übernommen ohne dass diese Option aktiviert werden muss. Soll jedoch während des Lasttests jeder Benutzer einen unterschiedlichen Account zur Basic Authorisation verwenden, so müssen Sie diese Option aktivieren und zusätzlich folgende Schritte durchführen o Erstellen Sie vor oder nach dem erzeugen des Lasttest-Programms ein File mit dem Namen basicauth.txt in demselben Project Navigator Directory, in dem das Lasttest-Programm abgespeichert wird. Auf jeder Zeile dieses Files muss jeweils zuerst der Name des Accounts und danach das Passwort des Accounts eingetragen werden getrennt durch ein Semikolon (Strichpunkt). o Nach dem kompilieren des Lasttest-Programms (*.java *.class) müssen Sie das kompilierte Programm (*.class) im Projekt-Navigator mit Hilfe der integrierten Zip-Funktion zusammen mit dem File basicauth.txt zu einem Archiv zippen, bevor Sie den Lasttest ausführen (siehe Kapitel 7.1). Das Archiv selbst (*.zip) muss danach als Lasttest-Programm gestartet werden anstelle des kompilierten *.class Files. - NTLM Authentication: falls eine NTLM Authentication während der Aufzeichnung nötig war, so müssen Sie beim erzeugen des Lasttest- Programms diese Option aktivieren. Dabei stehen zwei Möglichkeiten zur Verfügung: o use common NTLM account from personal settings: für alle Benutzer wird während des Lasttests derselbe NTLM Account verwendet, welcher im Personal Settings Menü definiert wurde (Kapitel ). Die Daten des Accounts werden direkt in das Lasttest-Programm übernommen. o apply individual NTLM account per user from input file (ntlmauth.txt): jeder Benutzer verwendet während des Lasttests einen eignen NTLM Account. Erstellen Sie vor oder nach dem erzeugen des Lasttest-Programms ein File mit dem Namen ntlmauth.txt in demselben Project Navigator Directory, in dem das Lasttest-Programm abgespeichert wird. Auf jeder Zeile dieses Files muss jeweils zuerst der 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 56 / 125

57 Domain-Name, danach Name des Accounts und danach das Passwort des Accounts eingetragen werden jeweils getrennt durch ein Semikolon (Strichpunkt). Nach dem kompilieren des Lasttest-Programms (*.java *.class) müssen Sie das kompilierte Programm (*.class) im Projekt-Navigator mit Hilfe der integrierten Zip-Funktion zusammen mit dem File ntlmauth.txt zu einem Archiv zippen, bevor Sie den Lasttest ausführen (siehe Kapitel 7.1). Das Archiv selbst (*.zip) muss danach als Lasttest-Programm gestartet werden anstelle des kompilierten *.class Files. - HTTPS Client Certificates: falls ein PKCS#12 Client-Zertifikat während der Aufzeichnung nötig war, so müssen Sie beim erzeugen des Lasttest- Programms diese Option aktivieren. Dabei stehen zwei Möglichkeiten zur Verfügung: o use common, active PKCS#12 certificate from personal settings: für alle Benutzer wird während des Lasttests dasselbe Client- Zertifikat verwendet, welches im Personal Settings Menü geladen wurde (Kapitel ). Die Daten des Zertifikats werden direkt in das Lasttest-Programm übernommen. o apply individual PKCS#12 certificate per user from input file (pkcs12auth.txt): jeder Benutzer verwendet während des Lasttests sein eigenes Client-Zertifikat. Erstellen Sie vor oder nach dem erzeugen des Lasttest-Programms zwei Files: im ersten File pkcs12certs.zip müssen die PKCS#12 Dateien aller Benutzer in einem eigenen ZIP-Archiv enthalten sein. Im zweiten File pkcs12auth.txt muss auf jeder Zeile zuerst der Name einer PKCS#12 Datei eingetragen werden, gefolgt von dem Passwort des Zertifikats getrennt durch ein Semikolon (Strichpunkt). Nach dem kompilieren des Lasttest-Programms (*.java *.class) müssen Sie das kompilierte Programm (*.class) im Projekt-Navigator mit Hilfe der integrierten Zip-Funktion zusammen mit den beiden Files pkcs12certs.zip und File pkcs12auth.txt zu einem Archiv zippen, bevor Sie den Lasttest ausführen (siehe Kapitel 7.1). Dieses Archiv selbst (*.zip) muss danach als Lasttest-Programm gestartet werden anstelle des kompilierten *.class Files. Hinweis zur einfacheren Bedienung: anstelle auf den Continue Button zu klicken können Sie auch die Enter-Taste drücken. Sie gelangen dadurch zum nächsten Dialog: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 57 / 125

58 Links im Dialog können Sie das Project Navigator Directory wählen, in welchem das Lasttest- Programm abgespeichert wird. Das aktuelle Directory ist blau markiert. Mittels des Icons lassen sich neue Sub-Directories anlegen.? Rechts im Dialog können Sie mittels Display Load Test Program den automatisch erzeugten Java- Code betrachten, bevor das Programm gespeichert wird. Gleich darunter wird unter Content Test Summary eine Zusammenfassung der automatischen Inhaltsüberprüfung dargestellt. Die Zusammenfassung enthält nur URL-Calls deren empfangener Inhalt mittels eines Text- Fragments geprüft wird. deren Inhaltsüberprüfung manuell modifiziert wurde (z.b. Prüfung der Inhaltsgrösse bei einem bestimmten GIF-Bild manuell deaktiviert, da es sich um wechselnde Banner-Werbung handelt) Sie habe hier nochmals die Möglichkeit, die Inhaltsüberprüfung durchzusehen und falls nötig anzupassen, indem Sie auf das entsprechende Lupen-Icon klicken. Speichern Sie die Web-Session nochmals mittels des Icons, falls Sie Anpassungen an der Inhaltsüberprüfung vorgenommen haben. Klicken Sie auf den Save Load Test Program Button, um das automatisch erzeugte Lasttest-Programm zu speichern. Alternativ können Sie auch auf die Enter-Taste drücken. Es erscheint nun das Projekt Navigator Menü: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 58 / 125

59 Das neu erzeugte Lasttest-Programm wird mit dunkelblauem Hintergrund markiert. Klicken Sie auf den Compile Button oder drücken Sie die Enter-Taste um dieses zu kompilieren. Hinweis: Sie können ein Lasttest- Programm auch kompilieren indem Sie auf dessen Icon klicken. Falls Sie später dasselbe Lasttest Programm ein weiteres Mal erzeugen, so müssen Sie zu zuerst im Projekt Navigator bestätigen, dass die alte Version des Programms überschrieben werden soll: Klicken sie dazu auf den yes Button. Alternativ können Sie auch die Enter- Taste drücken. Durch das kompilieren des automatisch erzeugten Java-Programms (*.java) wird der direkt ausführbares Lasttest-Programm erzeugt ( *.class, kompilierter Code). Sie können nun den Lasttest starten indem Sie auf dessen Icon klicken: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 59 / 125

60 7.1 Lasttest-Programme mit Input Files Lasttest-Programme, welche Input Files verwenden, müssen zuerst mit den Input Files zusammen gezippt werden. Danach muss ein solches Zip-Archiv selbst als Lasttest-Programm gestartet werden. Proxy Sniffer kontrolliert beim starten eines einfachen Lasttests-Programms ob dieses Input Files enthält Sie erhalten eine entsprechende Fehlermeldung wenn Sie in einem solchen Fall direkt auf das Icon des Programms klicken: Gehen Sie wie folgt vor: 1. Selektieren Sie das kompilierte Lasttest-Programm (*.class) und die dazu nötigen Input Files 2. Klicken Sie auf das Zip Icon im Projekt Navigator 3. Klicken Sie danach auf den Continue Button oder drücken Sie die Enter-Taste. Nachdem das Zip-Archiv erzeugt wurde können Sie dieses nun (selbst) als Lasttest starten: Hintergrund: Lasttests lassen sich mittels des GUIs auch remote auf anderen Rechnern ausführen. Das Zip-Archiv an sich bildet darum mit den Input Files einen Kontext, welcher alle Daten umfasst, die zur Lasttest-Ausführung nötig sind. Hinweis: wenn eines der Files des Zip- Archivs neuer ist als das Archiv selbst, so wird dies beim Starten des Lasttests erkannt. In einem entsprechenden Dialog wird dabei zuvor automatisch ein Re-Zip durchgeführt d.h. Sie können später Input-Files modifizieren und danach direkt auf das Zip-Archiv des Lasttest- Programms klicken by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 60 / 125

61 8 Ausführen von Lasttest-Programmen Nachdem das Lasttest-Programm mittels des Projekt Navigators aufgerufen wurde können Sie verschiedene Optionen wählen. Die wichtigsten Optionen sind Number of Concurrent Users sowie Load Test Duration. Unter Annotation sollten Sie einen kurzen Kommentar zum Test-Lauf eingeben. Liste aller Optionen: - Execute Test Form: steuert von welchem Rechner oder Cluster der Lasttests durchgeführt wird. Falls Sie keine remote Exec Agents bzw. keinen Exec Agent Cluster definiert haben (siehe Kapitel 10), so steht Ihnen vorerst nur die Auswahl Host: Local Exec Agent zur Verfügung, was bedeutet, dass der Lasttest vom eigenen Rechner durchgeführt wird. - Number of Concurrent Users: Anzahl gleichzeitige Benutzer während des Lasttests. - Load Test Duration: geplante Zeitdauer des Lasttests. Nachdem diese Zeit erreicht wurde beendet jeder Benutzer noch seine aktuellen Loop (Repetition der Web-Session). Darum dauert der Lasttest etwas länger als die geplante Zeitdauer. Falls die weitere Option Max. Loops per User nicht auf unlimited steht kann es sein, dass der Lasttest vor der geplanten Zeitdauer beendet wird, weil alle Benutzer schon die maximale Anzahl Loops erreicht haben. - Max. Loops per User: maximale Anzahl der Web- Session Repetitionen pro Benutzer. Falls die weitere Option Load Test Duration nicht auf unlimited steht kann es sein, dass der Lasttest beendet wird, bevor alle Benutzer ihre Anzahl Loops ausgeführt haben, weil die maximale Zeitdauer des Tests überschritten wurde. - Startup Delay per User: beim Starten des Lasttests werden üblicherweise nicht alle Benutzer sofort gestartet, sondern einer nach dem anderen, wobei jeweils eine kurze Zeitdauer dazwischen liegt. Diese Zeitdauer (startup ramp of load) können Sie hier festlegen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 61 / 125

62 - Max. Network Bandwidth per User: erlaubt die maximale Netzwerkbandbreite pro Benutzer künstlich zu reduzieren, um so den Zugriff der Benutzer über langsame DSL- oder Modem-Leitungen zu simulieren. Die Downlink- und Uplink-Bandbreite kann separat eingestellt werden um asymmetrische Bandbreiten zu simulieren. - Request Timeout per URL: legt fest, wie lange ein einzelner URL-Call währen des Lasttests dauern darf, bevor dieser abgebrochen und als Fehler behandelt wird (z.b. weil keine Antwort von Web-Server erhalten wurde). - Max. Error-Snapshots per URL: tritt ein Fehler während des Lasttests auf, so wird nebst den inkrementieren des Fehler-Zählers auch ein so genannter Error-Snapshot angelegt, welche die ganze Fehlersituation ausführlich protokolliert und auch alle aktuell ausgetauschten Daten des fehlgeschlagenen URL-Calls enthält (siehe Kapitel 9.2). Ein einziger solcher Error-Snapshot kann bis zu einem Megabyte gross sein. Darum ist die Anzahl Error-Snapshots pro URL-Call limitiert, welche sich jedoch hier in gewissen Grenzen einstellen lassen. Wird diese Grenze überschritten, so werden keine weiteren Error-Snapshots mehr für den entsprechenden URL-Call erstellt; der Fehler-Zähler wird jedoch nach wie vor erhöht. - Statistic Sampling Interval: bestimmt das Zeitintervall in dem während des Lasttests Stützpunkte für Diagramme bezüglich des zeitlichen Verlaufs einiger Messgrössen gewonnen werden (Anzahl Benutzer über die Zeit, Anzahl Fehler über die Zeit, usw.). Dieser Wert sollte in etwa einem zehntel bis einem hundertstel der gesamten Zeitdauer des Lasttests entsprechen. - Additional Sampling Rate per Page Call: sammelt zusätzlich zum periodischen Sampling noch weitere Daten (Antwortzeiten) jedes Mal wenn eine Web-Page vollständig von einem beliebigen Benutzer erfolgreich ausgeführt wurde. 100% bedeuten, dass jede Ausführung protokolliert wird. 1% bedeutet dass nur jede hundertste Ausführung protokolliert wird. Es müssen mindesten 5 Messwerte während des Tests gesammelt werden, damit nach dem Abschluss des Tests die Percentile-Diagramme sowie Diagramme über den Verlauf der Antwortzeiten der Web-Pages über die Dauer des Tests dargestellte werden können (Kapitel 9.1.5). - Additional Sampling Rate per URL Call: sammelt zusätzlich zum periodischen Sampling noch weitere Daten jedes Mal wenn ein URL-Aufruf von einem beliebigen Benutzer erfolgreich ausgeführt wurde. 100% bedeuten, dass jede Ausführung protokolliert wird. 1% bedeutet dass nur jede hundertste Ausführung protokolliert wird. Es müssen mindesten 5 Messwerte während des Tests gesammelt werden, damit nach dem Abschluss des Tests die Percentile-Diagramme sowie die Diagramme über den Verlauf der Antwortzeiten der URL-Aufrufe über die Dauer des Tests dargestellte werden können (Kapitel 9.1.5). Für Dauertests über mehrere Stunden sollte diese Option nicht verwendet werden. Weitere Optionen, Add: o o o o o o --- recommended: es wird nur die Antwortzeiten der URL-Aufrufe protokolliert (empfohlene Option). Falls Sie eine andere, untenstehende Option verwenden ist der Lasttest bei 100% URL Sampling Rate auf ca. 10 Minuten Dauer limitiert, da sonst zu viele Daten im Speicher gesammelt werden und deshalb ein interner Fehler während des Lasttests auftritt. Performance Details per Call: es werden folgende internen Zeiten der URL-Aufrufen zusätzlich protokolliert: Netzwerk Verbindungs- Aufbauzeit, Request Übertragungszeit, Response Header Wartezeit, Response Header Empfangszeit, Response Content Empfangszeit. Request Headers: zusätzlich wird der Request Header jedes URL-Aufrufs protokolliert. Request Content (Form Data): zusätzlich wird der Request Content (HTML Formulardaten) jedes URL-Aufrufs protokolliert. Req. Headers & Content: zusätzlich wird der Request Header und der Request Content jedes URL-Aufrufs protokolliert. Response Headers: zusätzlich wird der Response Header jedes URL-Aufrufs protokolliert by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 62 / 125

63 o o o Resp. Headers & Content: zusätzlich wird der Response Header und der Response Content jedes URL-Aufrufs protokolliert. All - without Resp. Content: zusätzlich wird der Request Header, der Request Content und der Response Header jedes URL-Aufrufs protokolliert. All - full URL Snapshots: zusätzlich wird der Request Header, der Request Content, der Response Header und der Response Content jedes URL-Aufrufs protokolliert. Hinweis: die gesammelten Daten können nach der Testausführung dargestellt und auch in Form von HTML-Tabellen exportiert werden. - Debug Options: nebst den statistischen Daten (*.prxres File) wird während des Lasttests zusätzlich noch ein Log-File geschrieben (*.out File). Die Debug-Optionen legen fest, welche Daten in das Log-File einfliessen. Beachten Sie, dass üblicherweise das Log-File niemals zur Analyse der Messergebnisse benötigt wird, sondern gewöhnlich nur zur aufspüren von Produkt-Fehlern dient: o o o o o o o none recommended: ist der Standard-Wert, was bedeutet, das im Wesentlichen nur die Start-Parameter sowie das eine kurze Zusammenfassung der Statistik in das Log-File geschrieben wird. Sie sollten üblicherweise diesen Standard-Wert verwenden. debug loops (including var handler): schreibt zusätzlich eine kurze Information jedes einzelnen URL-Calls sowie die Werte der extrahierten Variablen in das Log-File. Erlaubt das Debuggen der Var Handler Definitionen. debug headers & loops: enthält die Option debug loops und schreibt zusätzlich die gesendeten und empfangenen HTTP-Header aller URL-Calls in das Log-File. debug content & loops: enthält die Option debug loops und schreibt zusätzlich die gesendeten und empfangenen HTTP Inhalts-Daten aller URL-Calls in das Log-File, sofern diese ASCII Text enthalten (z.b. gesendete Formular-Daten und empfangene HTML-Daten). debug cookies & loops: enthält die Option debug loops und schreibt zusätzlich den Inhalt aller empfangenen und gesendeten Cookies in das Log-File. debug keep-alive & loops: enthält die Option debug loops und schreibt zusätzlich Daten über wieder verwendete Netzwerkverbindungen in das Log-File. debug SSL handshake & loops: enthält die Option debug loops und schreibt zusätzlich ein Protokoll jedes ausgeführten SSL- Handshakes in das Log-File - Additional Options: hier können weitere Optionen eingegeben werden. Alle diese Optionen anhalten ein Minuszeichen, unmittelbar gefolgt von dem Text. Mehrere Optionen könne durch Leerschläge getrennt werden: o o o -multihomed bedeutet, dass die Last-auslösenden Rechner mehrere IP-Adressen während des Lasttests verwenden. Die entsprechende Exec Agenten müssen jedoch entsprechend konfiguriert sein, damit diese Option wirksam wird (siehe Kapitel 11).. -sslcache <Sekunden> setzt die Zeitlimite des SSL Client-Caches, d.h. die maximale Zeitdauer innerhalb welcher eine SSL-Verbindung nach dem Abbruch der entsprechenden TCP/IP Verbindung regeneriert werden kann, ohne dass ein neuer SSL-Handshake nötig ist. Der Default-Wert ist 300 Sekunden. -sslcreset: die simulierten Benutzer behalten nach der Ende eines Loops den SSL Client-Cache und verwenden diesen beim nächsten Loop erneut. Dies kann mit dieser Option beim Starten eines Lasttests übersteuert werden was bewirkt, dass am Anfang eines Loops ein neuer (leerer) SSL Client Cache für den entsprechenden Benutzer erzeugt wird by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 63 / 125

64 o o -sslcmode erhöht die Toleranz bei fehlerhaftem SSL-Verhalten von Web-Servern, welche Teile des SSL-Protokolls falsch handhaben. -tz <Zeitzone> erlaubt das setzen einer anderen Zeitzone während des Lasttests. Eine Übersicht aller Zeitzonen-Werte ist im Application Reference Manual beschrieben (Kapitel 6). - SSL: beeinflusst, welche Verschlüsselungs-Protokoll-Variante bei HTTPS verwendet wird: o o o o v2/v3/tls: dies ist das normale Verfahren, welche die meisten modernen Web-Browser applizieren. Zuerst wird versucht, eine verschlüsselte Verbindung mittels TLS zum Server aufzubauen. Gelingt dies nicht, so wird SSL v3 verwendet. Gelingt dies auch nicht, so wird SSL v2 verwendet. TLS: es wird nur TLS verwendet. v3: es wird nur SSL v3 verwendet. v2: es wird nur SSL v2 verwendet. - Annotation: hier können Sie einen kurzen Kommentar zum Testlauf eingeben. Dies erleichtert später ganz erheblich die Übersicht, wenn Sie mehrere Testläufe mit demselben Lasttest-Programm ausführen, und dient Ihnen auch als Gedankenstütze bezüglich der Server-Konfiguration welche Sie getestet haben by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 64 / 125

65 8.1 Exec Agent Jobs Nachdem Sie beim Aufruf des Lasttest-Programms dessen Optionen gewählt haben und der Test mittels eines einzelnen Last-auslösenden Rechners durchgeführt werden soll (lokal oder remote, jedoch nicht bei einem Last-auslösenden Cluster), so wird der Lasttest in einem ersten Schritt in den lokalen oder remote Exec Agent Prozess übertragen. Es wird dabei im Exec Agent Prozess ein Lasttest-Job erzeugt, welcher eine Job-Nummer hat und zunächst im Zustand konfiguriert ist, d.h. noch nicht läuft: Mittels der Option Display Real-Time Statistic können Sie wählen, ob Sie direkt nach dem Starten des Jobs dessen real-time Statistik betrachten möchten. Hinweis: der entsprechenden Exec Agents Prozesses führt alle Lasttest- Jobs immer im Hintergrund durch, wobei auch mehrere Jobs gleichzeitig ausgeführt werden können. Die Option Display Real-Time Statistic bedeutet in diesem Zusammenhang nur, dass das Web Admin GUI über den Exec Agent direkt auf die real-time Daten des Jobs bzw. dessen laufendes Lasttest-Programms Zugriff nimmt. Klicken Sie nun auf den Start Load Test Job Button um den Lasttest zu starten. Falls Sie die Option Display Real-Time Statistic deaktiviert haben, so wird dieser Dialog nach wenigen Augenblicken geschlossen. Sie können danach jedoch jederzeit über das Jobs Menü des Project Navigators auf den Job zugreifen und dessen real-time Statistik betrachten bzw. dessen finale Messergebnisse laden (siehe Kapitel 8.1.3). Hinweis: wenn Sie dieses Fenster schliessen, ohne dabei auf den Start Load Test Button zu klicken, so verbleibt der Lasttest Job im Exec Agent im Zustand configured (bereit zum Start). Sie können später über das Jobs Menü (Kapitel 8.1.3) einen solchen Job starten oder auch löschen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 65 / 125

66 8.1.1 Real-Time Job Statistik Die real-time Statistik eines Jobs enthält nur einen Auszug der wichtigsten Messdaten und wird ca. alle 5 Sekunden neu berechnet. Sie erhalten bereits jetzt Zugriff auf gemessene Fehler (Error Snapshots), so dass Sie mit der Fehleranalyse beginnen können, während der Lasttest noch läuft. Ganz oben im dunkelgrau hinterlegten Text wird des Exec Agent angezeigt, der den Job ausführt, sowie dessen Job-Nummer. Darunter werden die Job-Parameter angezeigt (siehe Application Reference Manual, Kapitel 3.7). Noch etwas darunter sehen Sie, wann der Job gestartet wurde, wie lange dieser dauern soll, und wie viel Zeit bereits verstrichen ist. Statistiken: - Web Transaction Rate: die Anzahl erfolgreich durchgeführter URL-Calls pro Sekunde gemessen über alle Benutzer. Dies entspricht dem Durchsatz bzw. der Leistungsfähigkeit des Web-Servers. - Session Failures: die Anzahl Fehler welche aufgetreten sind - Concurrent Active Users: die Anzahl gleichzeitiger Benutzer Messwerte: - Total Passed URL Calls: Total der erfolgreich durchgeführten URL-Calls - Total Failed URL Calls: Total der fehlgeschlagenen URL-Calls - Keep-Alive Efficiency (%): Prozentsatz der wieder verwendeten Netzwerk-Verbindungen - Web Transaction Rate: Mittelwert der erfolgreich durchgeführten URL- Calls pro Sekunde (Server-Durchsatz) - Total Passed Loops: Total der erfolgreich durchgeführten Loops (Repetitionen der Surf-Session) - Total Failed Loops: Total der fehlgeschlagenen Loops - User's Think Time (Sec): kumulierte User s Think Time eines Benutzers pro Loop 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 66 / 125

67 - Average Session Time (Sec): gesamte Zeitdauer eines Loops pro Benutzer - Total Transmitted Bytes: Total der Anzahl Bytes welche vom Lasttest gesendet und empfangen wurden - Net. Connect Time (Millisec): mittlere Zeit welche benötigt wurde, um eine Netzwerk-Verbindung zum Web-Server zu öffnen (bevor die Daten des URL-Calls gesendet werden) - Net. Thr. per User: mittlerer Netzwerkdurchsatz eines Benutzers im kilobytes pro Sekunde - Total Net. Throughput (Mbit/s): mittlerer Netzwerkdurchsatz des Lasttests in kilobit pro Sekunde Durch einen Klick auf den Abort Job Button können Sie den Job vorzeitig abbrechen, wobei die bereits gesammelten Daten erhalten bleiben. Es wird ein Abort-Befehl an das Lasttest-Programm gesendet, welches dann das Statistik-File (*.prxres) schreibt uns sich selbst beendet. Dies kann darum einige Sekunden dauern. Durch einen Klick auf den Detailed Statistic Button können Sie weitere Messdaten einblenden, welche die Antwortzeiten der Web-Seiten und der URL- Calls enthalten und auch Zugang zu den Error-Snapshots erlauben. Ganz links sehen Sie blau markiert, wie viele Benutzer gerade eine bestimmte Web- Seite bzw. einen bestimmten URL-Call ausführen. Die Statistik der URL-Calls enthält nur die Calls einer einzigen Web-Seite (Default: der ersten Web- Seite). Durch einen Klick auf das Lupen-Icon einer anderen Web-Seite erhalten Sie deren entsprechende Statistik der URL-Calls. Ist der Wert in der Spalte Failed grösser 0 (Anzahl Fehler), so wird diese rosa hinterlegt und Sie erhalten durch einen Klick auf das Lupen-Icon Zugang zu den entsprechenden Error-Snapshots (Kapitel 9.2). Die real-time Statistiken werden direkt aus dem laufenden Lasttest-Programm in das GUI übertragen und sind nicht mehr verfügbar wenn der Job beendet wurde. Das Statistik-File des Jobs (*.prxres) hält alle diese Daten jedoch auch fest inklusive der Error-Snapshots. Diese können Sie nach dem Ende des Jobs in Menu Analyse Load Test betrachten. Hinweis: Das schliessen dieses Dialogs/Fensters stoppt den Lasttest nicht. Sie können bei einem schliessen des Fensters (später) das Jobs Menü im Project Navigator aufrufen und zur real-time Statistik des Jobs zurückkehren bzw. nach dem Ende des Jobs dessen Statistik-File (*.prxres) laden by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 67 / 125

68 8.1.2 Laden des Statistik-Files Nachdem das Lasttest-Programm beendet wurde liegt dessen Statistik-File (*.prxres) im Job-Directory des lokalen oder remote Exec Agent vor. D.h. Sie müssen das Statistik-File zuerst laden, bzw. auf den lokale Rechner zurück-transferieren, bevor die Statistiken angezeigt werden können: Das Menu zeigt alle Files des lokalen bzw. remote Jobs an, wobei in der Regel jedoch nur das Statistik-File benötigt wird dieses ist bereits vorselektiert. Das Log-File des Jobs hat die Dateierweiterung *.out in welche gegebenenfalls Debug-Information vorhanden sind. Das *.err File ist üblicherweise leer und enthält Fehler bei Programm-Abstürzen. Durch einen Klick auf den Acquire Selected Files Button werden die Files in den (lokalen) Project Navigator übertragen. Ist die Option Load *.prxres File on Analyse Load Test Menu aktiv (Default), so wird das Statistik-File zusätzlich in den (flüchtigen) Speicher des Analyse Load Test Menüs geladen, in welchem die Messresultate betrachtet und auch mit den Resultaten anderer Testläufe verglichen werden können by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 68 / 125

69 8.1.3 Jobs Menü (Exec Agents) Mittels des Jobs Menüs, welches vom Project Navigator aus aufgerufen werden kann, können Sie jederzeit auf einzelnen Jobs zugreifen. Durch die Option Display Exec Agen Jobs of kann der entsprechende Exec Agent selektiert werden, dessen Jobs angezeigt werden. Zum betrachten von Cluster-Jobs (Kapitel 8.2.3) müssen Sie die Option Display Cluster Jobs wählen. Jeder Job hat eine eindeutige Nummer, welche lokal vom entsprechenden Exec Agent vergeben wird. In der Spalte Status wird der aktuelle Zustand der Jobs angezeigt. Mögliche Zustände sind: - running: der Job ist zur Zeit aktiv, d.h. das Lasttest-Programm läuft noch. Durch einen Klick auf das Lupen-Icon können Sie zu der real-time Statistik des Jobs zurückkehren mittels der Sie gegebenenfalls auch den Job vorzeitig abbrechen können. - completed: der Job wurde bereits durchgeführt und ist beendet. Durch einen Klick auf das Lupen- Icon können Sie das Statistik-File laden. - configured: der Job ist bereit, wurde jedoch noch nicht gestartet (siehe Kapitel 8.1). Durch einen Klick auf das Lupen-Icon können Sie diesen starten. -???: der Job ist in einem undefinierten Zustand da dessen Daten korrupt sind. Einen solchen Job können sie nur löschen In der Spalte Date wird das Start- bzw. Definitions-Datum des Jobs angezeigt. Die Spalte Test enthält den Namen des Lasttest-Programms sowie dessen Parameter (siehe Architecture Reference Manual, Kapitel 3.7). Durch einen Klick auf das Icon kann ein Job gelöscht werden (ohne weiteren Dialog!). Hinweis: rufen Sie dieses Menü ab und zu auf, um alte Jobs zu löschen deren Statistik-Files Sie bereits geladen haben. Sie können dazu auch den Button Clean Up: Delete Old Completed Jobs benutzen, welcher alle durchgeführten Jobs mit Ausnahme des Letzten löscht. Jobs welche im Zustand??? sind sollten Sie sofort löschen, da diesen den Aufbau des Fensters erheblich verzögern by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 69 / 125

70 8.2 Cluster-Jobs Nachdem Sie beim Aufruf des Lasttest-Programms dessen Optionen gewählt haben und der Test mittels eines Last-auslösenden Clusters durchgeführt werden soll (siehe auch Kapitel 10.2), so wird der Lasttest in einem ersten Schritt in den lokalen Cluster Job Controller übertragen, welcher selbstständig die entsprechenden Cluster-Member (Exec Agents) koordiniert. Es wird dabei ein Cluster-Job erzeugt, welcher eine Cluster-Job-Nummer hat und zunächst im Zustand konfiguriert ist, d.h. noch nicht läuft: Dabei wird der Cluster-Job bzw. die Anzahl emulierte Benutzer automatisch auf die Cluster-Member verteilt, abhängig davon, welche Leistungsfähigkeit (Load Factor) einem Cluster-Member zugewiesen wurde. Enthält des Lasttest-Programm Input Files, so wird pro Input File ein zusätzlicher Dialog angezeigt (Split File?), mittels dessen sich der Inhalt des Files auf die Cluster-Member aufteilen lässt. Dies ist z.b. dann sinnvoll, wenn das Input File Daten von Benutzer-Accounts enthält, jedoch die Web-Applikation keine doppelten Logins/Anmelden desselben Benutzer-Accounts erlaubt. Mittels des entsprechenden Lupen-Icons kann eingesehen werden, wie der Inhalt des Input-Files auf die Cluster-Member aufgeteilt wird. Wird die Split-Funktion nicht verwendet, so erhalten alle Cluster-Member eine vollständige Kopie des Input Files. Die Verteilung der Benutzer kann auch von Hand angepasst werden. Dies ist nur dann sinnvoll, wenn ein Exec Agent / Cluster- Member momentan nicht erreichbar ist (rosa hinterlegt) und sich der Cluster-Job darum nicht starten lässt. Durch eine Korrektur der Anzahl Benutzer dieses nicht-verfügbaren Cluster-Members auf 0 und der Zuweisung dessen Benutzer an andere Cluster-Member kann der Job dann dennoch gestartet werden. Sie müssen in einem solchen Fall etwas Geduld haben; die temporäre, Job-bezogene Konfigurationsänderung des Clusters kann einige Zeit dauern. Ansonsten entspricht die Funktionalität dieses Menüs analog derselben wie bei einfachen Exec Agent Jobs (Kapitel 8.1). Hinweis: eine Konfigurationsänderung des Clusters hat nach dem starten des Tests keinen Einfluss mehr auf den Cluster-Job, da eine Kopie der Cluster-Definition im entsprechenden Job des Cluster Job Controllers angelegt wird und nur diese während des Lasttests zur Anwendung kommt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 70 / 125

71 8.2.1 Real-Time Cluster-Job Statistik Die real-time Statistik eines Cluster-Jobs enthält nur die wichtigsten Messergebnisse. Der Cluster-Job selbst enthält wiederum Exec Agent Jobs, welche vom Cluster Job Controller erzeugt wurden. Durch einen Klick auf das Lupen-Icon eines der beteiligten Exec Agent Jobs gelangen Sie (zusätzlich) in die real-time Statistik eines Exec Agent Jobs. Nur in dieser erhalten Sie Zugriff auf Error-Snapshots während des Lasttests. Hinweis: falls Sie einen Cluster-Job abbrechen möchten, so sollten Sie das auf dieser Ebene tun, was zum Abbruch aller beteiligten Exec Agent Jobs führt. Das Abbrechen eines korrespondierenden Exec Agent Jobs in dessen realtime Statistik stoppt nur diesen, jedoch nicht den ganzen Cluster-Job. Dasselbe gilt auch das Laden des Statistik-Files wenn der Cluster-Job beendet wurde auch dies muss auf dieser Ebene erfolgen. Die dargestellten Statistiken im oberen Bereich des Fensters enthalten eine gemeinsame Sicht über alle Cluster-Member by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 71 / 125

72 8.2.2 Laden des Statistik-Files von Cluster-Jobs Das Statistik-File eines Cluster-Jobs enthält die vereinigten (verschmolzenen) Messergebnisse aller Cluster-Member. Die dazu nötigen Berechnungen sind relativ aufwändig, so dass es bis zu 30 Sekunden dauern kann, bis dieser Dialog erscheint. Zusätzlich zu den vereinigten Messergebnissen sind in demselben Statistik-File auch separat nochmals die Statistiken der einzelnen Exec Agents enthalten (eingebettet). Das Statistik-File ist blau markiert und bereits vorselektiert. Das Laden geschieht analog wie bei einfachen Exec Agent Jobs. Durch einen Klick auf das Lupen-Icon eines Exec Agent erhalten Sie Zugang zu den *.out und *.err Files des entsprechenden Exec Agents und können so z.b. im Debug-Output nachvollziehen, wie dessen Teil-Test genau abgelaufen ist. Üblicherweise arbeiten Sie im Analyse Load Test Menü nur mit dem vereinigten Messergebnissen; diese können jedoch auch expandiert werden, um so Zugriff auf die Messergebnisse eines einzelnen Exec Agent Jobs zu erhalten: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 72 / 125

73 Dies kann unter anderem dazu genutzt werden um zu Kontrollieren, ob von allen Exec Agents des Cluster-Jobs in etwa gleiche Antwortzeiten gemessen wurden. Beachten Sie jedoch, dass Streuungen in einem Rahmen von ± 20% durchaus normal sein können: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 73 / 125

74 8.2.3 Jobs Menü (Cluster) Mittels der Option Display Cluster Jobs gelangen Sie im Jobs Menü zur Ansicht der Cluster-Jobs. Dieses ist analog dem Menü für normale Jobs aufgebaut (Kapitel 8.1.3). Wiederum können Sie zur real-time Statistik von laufenden Cluster-Jobs gelangen oder das vereinigte Statistik-File von bereits beendeten Cluster-Jobs laden. Hinweis: alte Cluster-Jobs sollten sie in diesem Menü löschen. Dadurch werden auch die entsprechenden Exec Agent Jobs gelöscht by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 74 / 125

75 8.3 Scripting von Lasttest-Jobs Mittels des Web Admin GUIs lassen sich mehrere Lasttest-Jobs gleichzeitig starten. Das GUI bietet jedoch keine direkte Unterstützung um Sequenzen von mehreren Jobs automatisch durchzuführen oder um die Ausführung verschiedene Jobs untereinander zu synchronisieren. Um solche Anforderungen zu realisieren müssen Sie Lasttest-Scripts erstellen, welche in der natürlichen Script-Sprache Ihres Betriebssystems geschrieben werden (*.bat bei Windows-Systemen, bzw. *.sh, *.csh, *.ksk.. etc. bei Unix-Systemen). Als Schnittstelle zur Nutzung der Produkt- Architektur steht Ihnen das leistungsfähige PrxJob Utility zur Verfügung, welches in solchen Scripts verwendet wird. Bei der Windows-Installation des Produkts wird im Projekt Navigator automatisch das Directory ScriptExamples erstellt, welches entsprechende Beispiele enthält. Diese sind jedoch (noch) nicht lauffähig, da die in den Scripts angesprochenen Lasttest-Programme fehlen. Mittels des PrxJob Utility lassen sich analog dem GUI auch Lasttest-Programme auf entfernten Rechnern starten und kontrollieren, und auch Cluster- Jobs ausführen. Die erstellten Scripts können von Web Admin GUI / Project Navigator direkt aufgerufen werden oder vom einer Konsole oder von einem Scheduler-Programm (nicht im Produkt enthalten). Weitere Informationen zum PrxJob Utility sind im Application Reference Manual, Kapitel 4 enthalten by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 75 / 125

76 8.4 Project Navigator Das Project Navigator Menü (kurz der Project Navigator genannt) bietet nebst dem Starten und Verwalten von Lastest-Programmen noch weitere hilfreiche Funktionalitäten, welche in diesem Teil-Kapitel kurz erklärt werden. Als erstes möchten wir Ihnen empfehlen, eine möglichst leicht fassbare Directory-Struktur anzulegen, welche einen Bezug zu Ihren Projekten hat. Dabei ist es zur Übersicht oft sinnvoll, wenn Sie für einzelne getestete Releases oder sogar für einzelne Test- Tage eigene Sub-Directories anlegen. Zum Anlegen eines neuen Sub- Directories müssen Sie zuerst (links) ein bestehendes Directory selektieren und danach auf das Create Directory Icon klicken. Hinweis: alternativ können Sie neue Directories auch über das Betriebssystem anlegen (z. B. von einem File-Explorer oder von einem System-Terminal aus). Das Project Navigator Menü wurde bewusst so realisiert, das keine Divergenzen mit Vorgängen auf Betriebssystem-Ebene auftreten können. Nach dem Anlegen eines neuen Sub- Directories können Sie auch bereits bestehende Lasttest-Programme inkl. deren Web- Browser Session und Input-Files in das neue Sub-Directory kopieren, indem Sie diese mittels der entsprechenden Checkbox markieren, und dann auf das Copy Selected Files Icon klicken. Danach können Sie im Project Navigator links das (neue) Ziel- Sub-Directory mit einem Klick auswählen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 76 / 125

77 Einzelne Java-Lasttest Programmen können auch umbenannt werden (oder mit neuen Namen kopiert werden). Dies kann jedoch nur über den Project-Navigator erfolgen, d.h. nicht über das Betriebssystem, da Java-Programme im Source-Code Referenzen auf den eigenen Namen enthalten und darum nach einem gewöhnlichen umbenennen nicht mehr kompilierbar oder lauffähig sind. Der Project Navigator unterstützt das umbenennen von Java-Programmen indem die entsprechenden Referenzen im Source-Code automatisch korrigiert werden. Hinweis: kompilierte Java-Programme (*.class) können niemals umbenannt werden. Nur Source-Code Dateien (*.java) lassen sich umbenennen. Beachten Sie bitte, dass der Project-Navigator z.b. beim überschreiben oder löschen von Dateien mittels einer rosa hinterlegten Status-Zeile eine Bestätigung anfordert, ob die Aktion wirklich durchgeführt werden soll. Sobald die die rosa hinterlegte Status-Zeile erscheint sollten Sie deren Inhalt kurz durchlesen und gegebenfalls den Vorgang bestätigen. Beispiel im Bild links: löschen von Files. Durch einen Klick das Icon im Projekt Navigator wird im Directory-Listing zusätzlich eine Vorschau der Messdaten der Statistik-Files angezeigt, inklusive dem Kommentar des entsprechenden Testlaufs. Zusätzlich werden auch die Kommentare zu den aufgezeichneten Web-Browser Sessions und der Lasttest-Programmen ausgegeben (falls vorhanden). Diese Funktionalität erlaubt Ihnen u.a. einzelne Statistik-Files von anderen zu unterscheiden, auch wenn der entsprechende Lasttest mit genau den gleichen Input-Parametern gestartet wurde. Voraussetzung hierzu ist jedoch, dass Sie beim jedem Start eines Lasttest-Programms einen unterschiedlichen Kommentar eingegeben haben by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 77 / 125

78 8.4.1 Konfiguration des Project Navigator Haupt-Directories Sie können Proxy Sniffer so konfigurieren, dass das Project Navigator Haupt-Directory MyTests auf eine gemeinsame Datei-Ablage zeigt (shared Disk oder shared Directory), so dass z.b. alle Mitglieder desselben Teams dieselbe Ansicht haben. Bei Windows-Systemen muss dazu ein sog. Share vorhanden sein. Bei Unix-Systemen muss dazu das gemeinsame Haupt-Directory zuvor über NFS oder Samba gemountet werden. Gehen Sie dazu wie folgt vor: Bei Windows-Systemen müssen Sie die Proxy Sniffer Konfigurations-Datei mytests.dat mit einem Text-Editor wie z.b. Notepad editieren, so dass deren Inhalt (welcher nur aus einer einzigen Text-Zeile besteht) auf die Disk bzw. das Directory der gemeinsamen Ablage zeigt. Gegebenfalls müssen Sie das Directory in der gemeinsamen Ablage zuvor manuell über das Betriebssystem erzeugen. Die Proxy Sniffer Konfigurations-Datei mytests.dat befindet sich im Installations-Directory des Proxy Sniffer Produkts (üblicherweise in C:\Programme\ProxySniffer). Bei Unix-Systemen müssen Sie das File mytests.dat zuerst manuell in Proxy Sniffer Installations-Directory z.b. mittel vi erzeugen, und in diesem als einzige Text-Zeile den Pfad des neuen Haupt-Directories eingeben. Die Proxy Sniffer Konfigurations-Datei mytests.dat muss im Installations-Directory des Proxy Sniffer Produkts angelegt werden (üblicherweise in /usr/local/prxsniff). Hinweis: bei Unix-Systemen auf denen nur ein sog. Exec Agent gestartet wurde ist dies nicht nötig. Nachdem Sie das neue Project Navigator Haupt-Directory gesetzt haben müssen Sie zuerst Proxy Sniffer beenden. Danach müssen Sie unbedingt alle Cookies in Ihrem Web-Browser löschen, da das (alte) Haupt-Directory zusätzlich auch als Cookie im Web-Browser gesetzt wurde. Danach können Sie Proxy Sniffer erneut starten. Informationen zu weiteren Proxy Sniffer Konfigurationsfiles finden Sie im Application Reference Manual, Kapitel by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 78 / 125

79 9 Auswerten der Messergebnisse Das Auswerten der Messergebnisse geschieht im Analyse Load Test Menü, in welches die Statistik-Files (*.prxres) geladen werden. Das Laden eines Files geschieht durch einen Klick auf das Icon eines Statistik-Files im Projekt Navigator oder auch implizit, wenn Sie ein Statistik-File eines gerade beendeten Testlaufs laden (zusätzlich wird dieses dabei im Projekt Navigator abgelegt). Das Menü arbeitet mit einem flüchtigen Speicher, d.h. wenn Sie ein geladenes File hier löschen, so wird dieses nur aus dem Speicher entfernt dabei bleibt jedoch das eigentliche File im Projekt Navigator erhalten. Sie können dieses Menü auch vom Hauptmenü oder vom Projekt Navigator aus aufrufen, ohne Statistik-Files zu laden. Spalten: Load Test: Name des Lasttest-Programms Start Date: Start-Datum und -Zeit des Testlaufs Users: Anzahl Benutzer Detailergebnisse der Testläufe Test Duration: Zeitdauer des Testlaufs Web. Trans.: Anzahl erfolgreiche URL-Aufrufe pro Sekunde (Durchsatz des Web-Servers) Sess. Failures: Prozentsatz der fehlgeschlagenen Loops Lastkurven und Vergleichsdiagramme Vergleich über mehrere Testläufe Net. Throughput: mittlerer Netzwerkdurchsatz des Testlaufs Annotation: Kommentar des Testlaufs bei dessen Start 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 79 / 125

80 9.1 Detailergebnisse Pro Testlauf können viele verschiedene Detailergebnisse dargestellt werden. Rechts oben im Titel des Fensters ist das Report- Icon, welches das erstellen eines PDF-Reports erlaubt. Danach folgen, gelb hinterlegt, die Eckdaten der Programmausführung. Darunter werden weitere, allgemeine Daten des Testlaufs angezeigt: Advanced Test Parameter: Dies ist ein Auszug der Test Input-Parameter. Measured Results per Single User per Loop: Diese Messergebnisse beziehen sich die Mittelwerte eines Loops, gemessen pro Benutzer: - AV Session Time per Loop: mittlere Zeitdauer einer Surf-Session Repetition - AV Response Time per Page: mittlere Antwortzeit einer Web-Seite (über alle Web- Seiten). - Network Throughput per User: mittlerer Netzwerkdurchsatz, pro Benutzer Overall Test Results: - Web Transaction Rate: Mittelwert der Anzahl erfolgreich durchgeführten URL- Calls pro Sekunde, über alle Benutzer und über die ganze Zeitdauer des Testlaufs gemessen. Dies entspricht dem Durchsatz des Web-Servers - Session Failure Rate: der Prozentsatz der fehlgeschlagenen Loops (Fehlerrate), über alle Benutzer gemessen. Durch einen Klick auf den Prozentsatz gelangen Sie zu den Error-Snapshots (Kapitel 9.2) - Total Network Throughput: mittlerer Netzwerkdurchsatz des gesamten Testlaufs Falls mehrere Resultate geladen wurden, so können Sie in der rechten oberen Ecke unter Load Test zwischen diesen navigieren. Weitere Details des Testlaufs lassen sich abrufen, indem Sie auf einen Titel im rot umrahmten Bereich klicken. In den nachfolgenden Unterkapiteln werden diese kurz erklärt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 80 / 125

81 9.1.1 Test Scenario Gibt einen Überblick über die Testumgebung, die Input-Parameter des Testlaufs und die aufgezeichnete Web-Session Diagram: Response Time per Page Zeit die mittlere Antwortzeit der Web-Seiten an by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 81 / 125

82 9.1.3 Results per URL Call (Overview) Zeigt die eine Statistik über alle URL-Calls an. Spalten: - Test: fortlaufende Nummerierung. Durch einen Klick auf die Test-Nummer gelangen Sie in das URL Detail Menu. - # Passed: Anzahl erfolgreiche Aufrufe - # Failed: Anzahl fehlgeschlagene Aufrufe, ist dieser grösser 0, so führt ein Klick zu den entsprechenden Error- Snapshots des URL-Calls (Kapitel 9.2) - AV Time: mittlere Zeitdauer des URL-Calls - <= 90 %: maximale Zeitdauer des URL-Calls, ohne die 10% der langsamsten Messungen (90% Percentile Wert). Die Percentile Werte sind nur verfügbar, wenn beim starten des Tests eine Percentile Sampling Rate gesetzt wurde, und mindesten 5 Einzel-Messungen gesammelt wurden. Durch einen Klick auf den Wert gelangen Sie in das entsprechende Percentile Diagramm. - AV Size: mittlere Grösse der gesendeten und empfangenen Daten pro URL-Call - URL: Bezeichnung des URLs 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 82 / 125

83 9.1.4 Results per URL Call (Details) Zeigt Messdetails pro URL-Call an. Wenn der Aufruf von einer Test-Nummer der Statistik über alle URL-Calls kam (vorhergehendes Unterkapitel), so ist der entsprechende URL-Call blau hinterlegt und mit einem kleinen roten Pfeil markiert. Spalten: Test: fortlaufende Nummerierung Av Net Con: mittlere Zeitdauer zum Aufbau einer TCP/IP Netzwerkverbindung zum Web-Server bevor Daten ausgetauscht werden (socket connect time). Falls Keep-Alive vom Server unterstützt wird enthalten einige URL-Calls keine solche Zeit, da kein Verbindungs-Aufbau mehr nötig war. Av Req Trm: mittlere Zeitdauer zum senden der URL-Anfrage an den Web-Server, nachdem die Netzwerkverbindung steht. eintrifft. Av Wait: mittlere Wartezeit des URL-Calls, nachdem die Anfrage übermittelt wurde, bis das erste Byte der Antwort des Servers Av Header Rcv: mittlere Zeitdauer zum Empfang des HTTP Response-Headers vom Server, nachdem das erste Byte eingetroffen ist. Av Content Rcv: mittlere Zeitdauer zum Empfang der Content-Daten (HTML, Gif-Bild etc.), nachdem der HTTP Response-Header empfangen wurde Min Time: kleinste jemals gemessene Zeitdauer des URL-Calls Av Time: mittlere Zeitdauer des URL-Calls Max Time: grösste jemals gemessene Zeitdauer des URL-Calls Av Throughput: mittlerer Netzwerkdurchsatz des URL-Calls Hinweis: durch einen Klick auf die Test-Nummerierung gelangen Sie wieder zurück in die Statistik über alle URL-Calls by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 83 / 125

84 9.1.5 Diagram: Response Time Percentiles Zeigt pro Web-Seite und pro URL-Call die kumulierte statistische Verteilung der Antwortzeiten an, falls beim Starten des Testlaufs (Kapitel 8) eine Additional Sampling Rate per Page Call und/oder eine Additional Sampling Rate per URL Call gewählt wurde und mindesten 5 Einzel-Messungen während des Testlaufs gesammelt wurden. Mittels der Auswahl-Optionen lässt sich die Web-Seite und innerhalb dieser ein URL-Call auswählen. --- fur URL-Calls bedeutet, dass das Percentile Diagramm bezüglich der Antwortzeit für die gesamte Web-Seite gilt. Es wird eine kumulierte Verteilung der Antwortzeiten angezeigt. 90% bedeutet, die Antwortzeit des langsamsten je gemessenen URL-Calls innerhalb aller 90% der schnellsten URL-Calls (d.h. ohne die 10% Ausreisser). Durch einen Klick auf den Apply Button werden zusätzlich alle gesammelten Einzelmessungen unterhalb des Diagramms dargestellt, welche sich auch in Form einer HTML-Tabelle exportieren lassen by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 84 / 125

85 9.1.6 Diagram: Top Time-Consuming URLs Zeigt eine Zusammenstellung der langsamsten URL-Calls der Web-Session an. Die einzelnen Zeiten sind Mittelwerte Diagram: Concurrent Users Zeigt die Anzahl der Benutzer über die Zeitdauer des Testlaufs an. Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Testlaufs bestimmt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 85 / 125

86 9.1.8 Diagram: Average Session Time Zeigt die Zeitdauer eines Loops an (aufgezeichnete Web-Session pro Benutzer) über die Zeitdauer des Testlaufs an. Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Tests bestimmt. Die kumulierte User s Think Time über die Web-Session (Loop) wird rot dargestellt keiner als diese Zeit kann die Zeitdauer eines Loops nicht werden. Die Differenz zur blauen Kurve ist die kumulierte Wartezeit auf die Antworten des Web-Servers während eines Loops Diagram: Web Transaction Rate Zeigt die Anzahl erfolgreiche URL-Calls pro Sekunde über die Zeitdauer des Testlaufs an. Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Testlaufs bestimmt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 86 / 125

87 Diagram: Completed Loops Zeigt die Anzahl Loops (Web Surf-Sessions) an, welche pro Minute erfolgreich durchgeführt wurden über alle Benutzer gemessen Diagram: Average Network Connect Time Zeigt die Mittlere Zeitdauer zum Aufbau einer TCP/IP Netzwerkverbindung zum Web-Server über die Zeitdauer des Testlaufs an bevor Daten ausgetauscht werden (socket connect time). Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Testlaufs bestimmt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 87 / 125

88 Diagram: Total Network Throughput Zeigt den Netzwerkdurchsatz über die Zeitdauer des Testlaufs an (Netzwerkbelastung). Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Testlaufs bestimmt Diagram: HTTP Keep-Alive Efficiency Zeigt die HTTP Keep-Alive Effektivität des gesamten Testlaufs an (Prozentsatz der wieder verwendeten Netzwerkverbindungen) by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 88 / 125

89 Diagram: SSL Cache Efficiency Zeigt die Effektivität des SSL Session Client-Caches an gemessen über alle Benutzer. D.h. wie oft bestehende Client-seitige SSL-Sessions wieder verwendet werden konnten (dieser Wert wird durch die SSL-Konfiguration des Web-Servers massgeblich beeinflusst). Das Diagramm steht nur zur Verfügung wenn jeder Benutzer mindestens 5 Loops ausgeführt hat und verschlüsselte HTTPS-Verbindungen verwendet wurden Diagram: Session Failures Zeigt die Anzahl der aufgetretenen Fehler über die Zeitdauer des Testlaufs an. Die Stützpunkte werden durch die Statistic Sampling Rate beim Starten des Testlaufs bestimmt. Hinweis: im nebenstehenden Diagramm sind einige Stützpunkte etwas verwischt. Dies kommt daher, dass der Testlauf ein Cluster-Job war, welcher das vereinigte Resultat alle Daten der Cluster-Member aggregiert. Da jedoch aus Stabilitäts- und Performance-Gründen während des Testlaufs keine Synchronisation der Cluster-Member geschieht, ergeben sich kleine Laufzeitunterschiede bezüglich der Stützpunkte. Die entsprechenden Hüllkurven der Cluster-Member werden korrekt vereinigt, dabei fallen jedoch während eines Sampling-Intervalls nicht alle Stützpunkte auf den genau gleichen Zeitpunkt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 89 / 125

90 Diagram: Top Error Types Zeigt die häufigsten Fehler-Ursachen an (Fehler-Typen) Diagram: Number of Errors per Page Zeigt die Web-Seiten an, bei welchen am häufigsten ein Fehler aufgetreten ist by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 90 / 125

91 Diagram: Number of Errors per URL Zeigt die URL-Calls an, bei welchen am häufigsten ein Fehler aufgetreten ist. Die Nummern der URL-Calls (in eckigen Klammern) entsprechen den Test- Nummern der Statistik über alle URL-Calls 9.2 Error-Snapshots Tritt während des Testlaufs ein Fehler auf, so wird der entsprechende Fehler-Zähler des URL-Calls erhöht, und gleichzeitig ein Error-Snapshot angelegt, falls die maximale Anzahl Error-Snapshots des URL-Calls noch nicht überschritten wurde (maximale Anzahl = Konfiguration beim Starten des Testlaufs). Ein solcher Error-Snapshot enthält im übertragenen Sinn die umfassenden, gefrorenen Daten des URL-Calls, zu genau dem Zeitpunkt, an dem der Fehler aufgetreten ist. Das erstellen eines Error-Snapshots während eines Lasttests beansprucht Ressource und eventuell sehr viel Speicher. Aus diesem Grund ist deren Anzahl pro URL-Call limitiert. Ein Error-Snapshot enthält folgende Daten: 1. Eine Übersicht des aufgetretenen Fehlers, inkl. eine Tipp, warum der Fehler aufgetreten ist. 2. Die vollständigen gefrorenen Daten des fehlgeschlagenen URL-Calls, inklusive des HTTP Request-Headers, des Request-Contents, des Response-Headers und des Respons-Contents (falls vorhanden) 3. Den Log/Debug-Output des aktuellen Loops auch wenn keine Debug-Option beim Starten des Testlaufs gewählt wurde 4. Einen Schnappschuss der Aktivitäten aller Benutzer, zum Zeitpunkt als der Fehler auftrat by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 91 / 125

92 Ablaufschritt des URL-Calls, als der Fehler auftrat. Mögliche Werte sind: o o o o o o No Step / not Initialized: der URL-Call wurde noch nicht gestartet Der obere Teil des Fensters enthält eine Liste von Error- Snapshots; je nach aufgerufenem Kontext über den gesamten Testlauf / oder pro Web Page / oder pro URL- Call. Die Liste lässt sich nach URL-Calls oder nach dem Zeitpunkt der Fehler sortieren. Durch einen Klick auf das Lupen-Icon wird im unteren Teil des Fensters der eigentliche Error-Snapshot darggestellt: In fetter schwarzer Schrift wird die Nummer des URL-Calls, eine fortlaufende relative Fehlernummer, und eine kurze Begründung des Fehlers (Fehler-Type) dargestellt. Unmittelbar rechts daneben kann ein entsprechender Tipp aufgerufen werden, welcher erklärt weshalb der Fehler aufgetreten ist (Error Explanation). Darunter erfolgt rosa hinterlegt eine Übersicht des Fehlers: - Page: die Web-Seite auf welcher der Fehler aufgetreten ist - Error Date: Datum und Zeitpunkt des Fehlers; und in runden Klammern der relative Zeitpunkt nach dem Starten des Testlaufs. - Currrent Thread: aktuelle Benutzer-Nummer (0, 1, 2..) - URL [Testnummer]: fehlgeschlagener URL-Call, HTTP Status-Code, Fehler-Typ - URL Exec Step: aktueller innerer Zustand, bzw. Open Network Connection to Proxy: es wird eine Netzwerk-Verbindung zu einem abgehenden Proxy-Server aufgebaut Open Network Connection: es wird eine Netzwerk-Verbindung zum Web-Server aufgebaut Transmit HTTP Request: der HTTP Request-Header und (gegebenenfalls) -Content wird gesendet (URL-.Anfrage) Wait for Server Response: es wird auf eine Antwort des Web-Servers gewartet (noch kein erstes Byte eingetroffen) Receive HTTP Header: der HTTP Response-Header der Server-Antwort wird empfangen 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 92 / 125

93 o o o Receive Content: der HTTP Response-Content der Server-Antwort wird empfangen (Nutzdaten: HTML, GIF-Bild, etc.) Close Network Connection: die Netzwerk-Verbindung zum Web-Server wird geschlossen All Done: der URL-Aufruf wurde bezüglich des HTTP-Protokolls erfolgreich abgeschlossen, jedoch ist der empfangene HTTP Status- Code, oder der empfangene MIME-Type oder der empfangene Dateninhalt falsch. - Error-Log: Link auf den Log-Output des Loops und ausführliche Fehlermeldung Danach erfolgt die Darstellung des HTTP Request-Header, des Request-Contents, des Response-Headers und des Respons-Contents (falls jeweils vorhanden). Falls der Response-Content im HTML-Format vorliegt, so kann dieser nachträglich im Web-Browser dargestellt werden (jedoch ohne Bilder). Dabei werden die Daten aus dem Statistik-File gewonnen, d.h. dies ist auch dann noch möglich, wenn der Web-Server nicht mehr verfügbar / offline ist by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 93 / 125

94 Anschliessend erfolgt die Ausgabe des Debug-Outputs des Loops. Dabei können auch die (damals) aktuellen Werte von Variablen des Var Handlers betrachtet werden: Ganz zum Schluss erfolgt eine die Darstellung der Aktivität aller Benutzer zum Zeitpunkt des Fehlers. Der fehlgeschlagene URL-Call ist rosa hinterlegt. Diese Statistik ist während des real-time Monitoring (noch) nicht verfügbar. In der Spalte Threads wird die Anzahl der Benutzer angezeigt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 94 / 125

95 9.2.1 Pseudo-Fehlercodes Ein URL-Call liefert in der Regel einen HTTP Status-Code zurück (200, 302, 404..) welche vom Web-Server gesetzt wird. Es können jedoch Fehlerfälle auftreten, bei denen es gar nicht dazu kommt, dass der Web-Server einen Status-Code setzen kann, oder bei denen der Status-Code wohl richtig war, jedoch etwas mit dem Inhalt der empfangenen Daten nicht stimmt. In solchen Fällen wird ein Pseudo-Fehlercode anstelle des HTTP Status-Codes verwendet, welcher immer einen negativen Wert hat. Mögliche Werte sind: Pseudo-Fehlercode Bedeutung -100 Es stehen nicht genug Daten zur Verfügung, um den URL-Call durchzuführen (interner Fehler) -99 Der URL-Call wurde niemals ausgeführt -98 Es ist ein interner Netzwerk-Fehler beim Last-auslösenden Exec Agent aufgetreten. Es stehen auf Client-Seite nicht genug Netzwerk-Ressourcen zur Verfügung um den URL-Call zu initiieren. -11 Es konnte keine SSL-Netzwerkverbindung zu einem abgehenden Proxy-Server aufgebaut werden -10 Der Name des Web-Servers konnte nicht in eine IP-Adresse übersetzt werden (DNS Problem oder falscher Name) -9 Der Web-Server hat den Aufbau der Netzwerkverbindung verweigert (zurückgewiesen) -8 Der Web-Server hat die Netzwerkverbindung akzeptiert, danach jedoch diese mitten währen des laufenden Datentransfers geschlossen (abgebrochen) -7 Der Web-Server lieferte eine Antwort, welche im HTTP-Protokoll nicht vorgesehen ist (Protokollverletzung) -2 Der Web-Server lieferte keine Antwort. Der URL-Call wurde wegen Zeitüberschreitung abgebrochen -1 Es ist ein allgemeiner Fehler aufgetreten Übersetzen der URL Test-Nummerierung Falls Sie den Filter im Hauptmenü beim Erzeugen des Lasttest-Programms eingesetzt haben, so sind die URL-Calls des Testlaufs nun anders durchnummeriert als die der aufgezeichneten Web-Session. Eine Gegenüberstellung der beiden Nummerierungen erhalten Sie dadurch, dass Sie im Hauptmenü auf das View Icon klicken. Die Spalte Item enthält die Nummerierung der Web-Session. Die Spalte Test enthält die entsprechende Nummerierung der URL-Calls des Testlaufs by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 95 / 125

96 9.3 Lastkurven-Diagramme Um die maximale Leistungsfähigkeit des Web-Servers bzw. der Web-Applikation zu erfahren müssen Sie denselben Test mehrere Male nacheinander durchführen, jedoch bei jedem Testlauf eine unterschiedliche Anzahl Benutzer verwenden. Wir empfehlen Ihnen die Last bei jedem Testlauf logarithmisch zu steigern, um so schnell einen Überblick zu erhalten (z.b. Testläufe mit 1, 2, 5, 10, 20, 50, 100, 200, 500, Benutzer). Sie erhalten dadurch die Lastkurven, d.h. das Antwortzeitverhalten, den Server-Durchsatz und die Server-Stabilität in Abhängigkeit von der Anzahl Benutzer. Bei geringer Last sind die Antwortzeiten unabhängig von der Anzahl Benutzer konstant. Wird nun die Last gesteigert und der maximale Durchsatz des Servers erreicht (gemessen in URL-Calls pro Sekunde Web Transaction Rate), so steigen ab dieser Belastung die Antwortzeiten mindesten Linear mit der Last an, da die Leistungsgrenze des Servers erreicht wurde. Web-Seiten bzw. URLs, bei denen die Antwortzeiten unter Last stärker steigen als bei anderen sind potentielle Tuning-Kandidaten. D.h. es sollte untersucht werden, wieso deren Antwortzeiten plötzlich stark steigen. Im Leitfaden zum erfolgreichen Durchführen von Lasttests, welchen Sie auf der Produkt- Homepage finden, erhalten Sie mehr Informationen zu dieser Thematik by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 96 / 125

97 Selektieren Sie im Analyse Load Test Menü mehrere Testläufe des gleichen Lasttest-Programms mit jeweils einer unterschiedlichen Anzahl Benutzer und wählen Sie die Option Load Curve um die Lastkurven darzustellen: 2007 by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 97 / 125

98 Rechts oben, im Titel des Fensters, könne Sie einen PDF-Report erzeugen und die Messdaten auch exportieren. Die rot markierten Rhomben der Diagrame sowie deren Legenden können Sie anklicken, und gelangen so zu den Detailergebnissen der entsprechenden Testläufe. Alle 4 dargestellten Diagramme sind voneinander unabhängig. Sie können mittels der Auswahllisten wählen, welche Messwerte dargestellt werden: - Average Session Time per User - per Loop: kumulierte Zeit eines Loops pro Benutzer. Diese ist das Antwortzeitverhalten des Web-Servers. - Web Transaction Rate: Anzahl URL- Calls pro Sekunde. Dies ist der Durchsatz des Web-Servers. - Session Failure Rate: Prozentsatz der fehlgeschlagenen Loops. Dies ist die Stabilität des Web-Servers. - Average Network Connect Time: Aufbauzeit der Netzwerkverbindungen (Stabilität des Netzwerks und des TCP/IP Stacks des Servers) - Total Network Throughput: Dies ist der Netzwerkdurchsatz (Netzlast) - Highest URL Throughput >= 4096 Bytes: Netzwerkdurchsatz des schnellsten URL-Calls mit mindesten 4096 Bytes empfangenen Daten. - URL: Antwortzeit eines URL-Calls: In den beiden unteren Diagrammen können Sie auch mehrere URL-Calls gleichzeitig selektieren. - Page: Antwortzeit einer Web-Seite. In den beiden unteren Diagrammen können Sie auch mehrere Web-Seiten gleichzeitig selektieren by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 98 / 125

99 9.4 Vergleichs-Diagramme Mittels Vergleichs-Diagrammen können Sie die Antwortzeiten verschiedener Testläufe direkt miteinander Vergleichen. Dies wird vor allem zur Visualisierung von Tuning-Fortschritten verwendet (vorher / nachher Vergleich), wobei oft Testläufe mit einer gleichen Anzahl von Benutzern verglichen werden. Dies ist aber nicht zwingend Sie können beliebige Testläufe miteinander vergleichen solange diese dieselben Web-Seiten umfassen (Kriterium: gleicher, übereinstimmender Seitenwechsel-Kommentar der verglichenen Lasttest-Programme): Rechts oben, im Titel des Fensters, könne Sie einen PDF-Report erzeugen. Das obere Diagramm zeigt einen Vergleich der Antwortzeiten aller Web-Seiten an. Im unteren Diagramm wird ein Vergleich aller URL-Calls einer Web- Seite dargestellt (Default: der Ersten). Durch einen Klick in einen Balken oder in die Legende des obern Diagrams kann im unteren Diagramm der Vergleich der URL-Calls für eine andere Web-Seite dargestellt werden. Durch einen Klick auf einen Balken im unteren Diagramm werden die Detailergebnissen des entsprechenden Testlaufs angezeigt by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 99 / 125

100 10 Konfiguration und Architektur bei verteilten Lasttests Lasttests lassen sich nicht nur vom lokalen Rechner aus starten, sondern können auch auf Remote-Rechner übertragen werden. Ebenso kann ein einziger Lasttest auch auf mehrere Rechner aufgeteilt werden, indem die Last-auslösenden Rechner zu einem virtuellen Applikations-Cluster kombiniert werden. Die Konfiguration geschieht sehr einfach und elegant und setzt nur voraus, dass auf den beteiligten Last-auslösenden Systemen ein Exec Agent Prozess installiert ist. Dies ist z.b. implizit der Fall, wenn das Produkt auf mehreren Windows- oder Unix-Systemen installiert und gestartet wurde (jedes System enthält dabei bereits einen Exec Agent). Alternativ können einzelne Exec Agent Prozesse auch separat als Windows-Service bzw. Unix-Daemon installiert werden. Weitere Informationen hierzu sind im Application Reference Manual enthalten. Die Kommunikation zwischem dem Web Admin GUI und den remote Exec Agent Prozessen geschieht üblicherweise mittels roher Netzwerkverbindungen auf dem TCP/IP Port Die Nummer des Ports lässt sich jedoch frei konfigurieren. Die Kommunikation kann alternativ auch über HTTP oder HTTPS erfolgen (tunneling), wobei dabei der Datenverkehr auch (optional) über einen zwischengeschalteten (abgehenden) HTTP/S Proxy-Server erfolgen kann. Die Unterstützung von Proxy-Servern bedeutet in diesem Zusammenhang, das auch Lasttests von Arbeitsplätzen in geschützten Firmen-Netzwerken gestartet werden können, welche danach irgendwo im Internet laufen ohne dass dabei abgehende Firewall-Rules geschaltet werden müssen. Die Rechner eines Last-auslösenden Clusters können auch heterogen sein, d.h. es lassen sich Windows- und Unix-Systeme im gleichen Cluster mischen. Die einzelnen Rechner eines Cluster können sich auch an verschiedenen Standorten befinden und über unterschiedliche Protokolle mit dem Web Admin GUI bzw. dem Cluster Job Controller kommunizieren by Ingenieurbüro David Fischer GmbH, Switzerland Alle Rechte vorbehalten Seite 100 / 125