Proxy Sniffer V4.1-C User`s Guide Deutsche Ausgabe

Transcrição

Ingenieurbüro David Fischer GmbH
Mühlemattstrasse 61, CH-3007 Bern
Switzerland
http://www.proxy-sniffer.com
E-Mail: [email protected]
Proxy Sniffer V4.1-C
User’s Guide
Deutsche Ausgabe
© 2008 by Ingenieurbüro David Fischer GmbH
Alle Rechte vorbehalten
Proxy Sniffer V4.1-C User‟s Guide
Deutsche Ausgabe
Inhaltsverzeichnis
1
2
3
4
5
6
Einleitung .................................................................................................................................................................................................................... 5
1.1
Menü-Übersicht und Navigation ........................................................................................................................................................................... 5
Installation ................................................................................................................................................................................................................... 8
2.1
System-Anforderungen ........................................................................................................................................................................................ 8
2.2
Windows Installation............................................................................................................................................................................................. 9
2.3
Installation bei Unix-ähnlichen Betriebssystemen ............................................................................................................................................... 10
2.4
Architektur-Übersicht .......................................................................................................................................................................................... 11
Konfiguration des Web-Browsers .............................................................................................................................................................................. 12
3.1
Lokale Popup-Fenster Zulassen ......................................................................................................................................................................... 13
3.2
JavaScript Einstellungen für Mozilla Firefox ....................................................................................................................................................... 15
3.3
Umkonfigurieren des Web-Browsers zur Aufzeichnung ...................................................................................................................................... 16
3.3.1
Beispiel Proxy-Konfiguration für Microsoft Internet Explorer: ....................................................................................................................... 17
3.3.2
Beispiel Proxy-Konfiguration für Mozilla Firefox 2 ........................................................................................................................................ 18
3.3.3
Web-Browser Warnung bei verschlüsselten Verbindungen ......................................................................................................................... 19
Aufzeichnen von Web-Browser Sessions .................................................................................................................................................................. 20
4.1.1
Löschen des Web-Browser Caches und der Cookies im Internet Explorer 7 ............................................................................................... 21
4.1.2
Löschen des Web-Browser Caches und der Cookies im Mozilla Firefox 2 .................................................................................................. 21
4.2
Aufzeichnen nachfolgender Web-Seiten............................................................................................................................................................. 22
4.3
Abspeichern der Aufzeichnung ........................................................................................................................................................................... 23
4.4
Kontrolle der aufgezeichneten Web-Session ...................................................................................................................................................... 24
4.4.1
Kontrolle der getesteten Web-Server .......................................................................................................................................................... 24
4.4.2
Kontrolle der automatischen Inhaltsüberprüfung ......................................................................................................................................... 25
4.5
Session Cutter.................................................................................................................................................................................................... 27
4.6
Weitere Hinweise zum Aufzeichnen von Web-Browser Sessions ....................................................................................................................... 28
4.6.1
Unterstütze HTTP/S Clients ........................................................................................................................................................................ 28
4.6.2
Proxy-Recorder und GUI Einstellungen (Personal Settings Menü) .............................................................................................................. 28
4.6.2.1
Proxy Kaskadierung (Connect to Next Proxy)....................................................................................................................................... 29
4.6.2.2
HTTPS Settings ................................................................................................................................................................................... 29
4.6.2.3
NTLM Authentication ............................................................................................................................................................................ 30
4.6.2.4
HTTPS Client Certificate Authentication ............................................................................................................................................... 30
4.6.2.5
GUI Settings ......................................................................................................................................................................................... 31
Inner Loops ............................................................................................................................................................................................................... 32
5.1
Bedingtes Ausführen von Teilen der Web-Session ............................................................................................................................................. 33
Nachbearbeiten der Web Session – dynamische Session-Parameter ....................................................................................................................... 34
6.1
Variablen Handler (Var Handler) ........................................................................................................................................................................ 36
6.2
Input Files .......................................................................................................................................................................................................... 37
© 2008 by Ingenieurbüro David Fischer GmbH, Switzerland
Seite 2 / 138
Deutsche Ausgabe
6.2.1
Weitere Hinweise zu Input Files .................................................................................................................................................................. 42
6.3
User Input Fields ................................................................................................................................................................................................ 42
6.3.1
Weitere Hinweise zu User Input Fields ........................................................................................................................................................ 45
6.4
Dynamisch ausgetauschte Session-Parameter .................................................................................................................................................. 47
6.4.1
Automatische Behandlung von dynamisch ausgetauschten Session-Parametern (Var Finder) ................................................................... 48
6.4.2
Manueller Extrakt von dynamisch ausgetauschten Session-Parametern ..................................................................................................... 50
6.4.3
Ersetzen von Textmustern........................................................................................................................................................................... 54
6.4.4
Extrahieren und Zuweisen von Werten von/an SOAP- und XML-Daten....................................................................................................... 55
6.5
HTTP File-Uploads ............................................................................................................................................................................................. 56
6.6
Zusammenfassung der am häufigsten verwendeten Extrakt- und Zuweisungs-Operationen .............................................................................. 57
6.7
Direkte Definition von Variablen (stand-alone Variablen) .................................................................................................................................... 58
6.8
J2EE URL-Rewriting .......................................................................................................................................................................................... 59
7 Erzeugen des Lasttest-Programms ........................................................................................................................................................................... 61
7.1
Lasttest-Programme mit Input Files .................................................................................................................................................................... 67
8 Ausführen von Lasttest-Programmen ........................................................................................................................................................................ 68
8.1
Exec Agent Jobs ................................................................................................................................................................................................ 72
8.1.1
Real-Time Job Statistik ............................................................................................................................................................................... 73
8.1.2
Laden des Statistik-Files ............................................................................................................................................................................. 75
8.1.3
Jobs Menü (Exec Agents) ........................................................................................................................................................................... 76
8.2
Cluster-Jobs ....................................................................................................................................................................................................... 77
8.2.1
Real-Time Cluster-Job Statistik ................................................................................................................................................................... 78
8.2.2
Laden des Statistik-Files von Cluster-Jobs .................................................................................................................................................. 79
8.2.3
Jobs Menü (Cluster) .................................................................................................................................................................................... 81
8.3
Scripting von Lasttest-Jobs ................................................................................................................................................................................ 82
8.4
Wiederholen von Lasttest-Jobs .......................................................................................................................................................................... 82
8.5
Project Navigator ................................................................................................................................................................................................ 85
8.5.1
Konfiguration des Project Navigator Haupt-Directories ................................................................................................................................ 87
9 Auswerten der Messergebnisse ................................................................................................................................................................................ 88
9.1
Detailergebnisse ................................................................................................................................................................................................ 89
9.1.1
Test Scenario .............................................................................................................................................................................................. 90
9.1.2
Diagram: Response Time per Page ............................................................................................................................................................ 90
9.1.3
Results per URL Call (Overview) ................................................................................................................................................................. 91
9.1.4
Results per URL Call (Details) ..................................................................................................................................................................... 92
9.1.5
Diagram: Response Time Percentiles ......................................................................................................................................................... 93
9.1.6
Diagram: Top Time-Consuming URLs ......................................................................................................................................................... 94
9.1.7
Diagram: Concurrent Users ......................................................................................................................................................................... 94
9.1.8
Diagram: Average Session Time ................................................................................................................................................................. 95
9.1.9
Diagram: Web Transaction Rate ................................................................................................................................................................. 95
9.1.10 Diagram: Completed Loops ......................................................................................................................................................................... 96
Seite 3 / 138
Deutsche Ausgabe
9.1.11 Diagram: Average Network Connect Time .................................................................................................................................................. 96
9.1.12 Diagram: Total Network Throughput ............................................................................................................................................................ 97
9.1.13 Diagram: HTTP Keep-Alive Efficiency ......................................................................................................................................................... 97
9.1.14 Diagram: SSL Cache Efficiency................................................................................................................................................................... 98
9.1.15 Diagram: Session Failures .......................................................................................................................................................................... 98
9.1.16 Diagram: Top Error Types ........................................................................................................................................................................... 99
9.1.17 Diagram: Number of Errors per Page .......................................................................................................................................................... 99
9.1.18 Diagram: Number of Errors per URL ......................................................................................................................................................... 100
9.2
Error-Snapshots ............................................................................................................................................................................................... 100
9.2.1
Pseudo-Fehlercodes ................................................................................................................................................................................. 104
9.2.2
Übersetzen der URL Test-Nummerierung ................................................................................................................................................. 104
9.3
Lastkurven-Diagramme .................................................................................................................................................................................... 105
9.4
Vergleichs-Diagramme ..................................................................................................................................................................................... 108
10
Konfiguration und Architektur bei verteilten Lasttests ........................................................................................................................................... 109
10.1 Konfiguration von weiteren Last-auslösenden Rechnern .................................................................................................................................. 110
10.2 Konfiguration von Last-auslösenden Clustern .................................................................................................................................................. 111
10.3 Starten von verteilten Lasttests ........................................................................................................................................................................ 112
11
Konfiguration vom mehreren IP Adressen pro Last-auslösenden Rechner .......................................................................................................... 113
11.1 Schritt 1: Konfiguration des Betriebsystems ..................................................................................................................................................... 114
11.1.1 Windows ................................................................................................................................................................................................... 114
11.1.2 Unix-ähnliche Betriebssysteme ................................................................................................................................................................. 114
11.2 Schritt 2 und 3: Konfiguration des Exec Agents und Starten des Testlaufs ....................................................................................................... 115
12
Lasttest Plug-Ins .................................................................................................................................................................................................. 116
12.1 Plug-In Template Generator ............................................................................................................................................................................. 116
13
Manuelle Anpassungen an Java Lasttest-Programmen / Java API ...................................................................................................................... 120
13.1 Externe Klassen und Jar-Libraries.................................................................................................................................................................... 121
13.2 Direkter Zugriff auf Messergebnisse ................................................................................................................................................................. 122
14
Web Tools ........................................................................................................................................................................................................... 124
14.1 Page Scanner .................................................................................................................................................................................................. 125
14.1.1 Eingabe-Parameter, Fortschritts-Anzeige und Abspeichern des Scan-Resultats ....................................................................................... 126
14.1.2 Analyse des Scan-Resultats...................................................................................................................................................................... 130
14.1.2.1 Analyse der Scan-Details ................................................................................................................................................................... 131
14.1.3 Konvertierung des Scan-Resultats in eine Web-Browser Session ............................................................................................................. 136
15
Hersteller und Support ......................................................................................................................................................................................... 138
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.
Seite 4 / 138
Deutsche Ausgabe
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.
Seite 5 / 138
Deutsche Ausgabe
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ährend dessen Ausführung in „real-time“ an. Eventuell aufgetretene Fehler
können auch 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 WebServers 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.
Seite 6 / 138
Deutsche Ausgabe
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.
Seite 7 / 138
Deutsche Ausgabe
2 Installation
Während der Installation unter Windows sind eventuell Administratoren-Rechte nötig, abhängig vom gewählten Installations-Directory. Bei der
unveränderten Übernahme der bei der Installation vorgeschlagenen Default-Werte sind keine Administratoren-Rechte nötig. Nach der Installation, d.h.
während des normalen Betriebs, benötigt das Produkt schreib-Zugriff auf das eigene Installations-Directory sowie dessen Sub-Directories.
2.1
System-Anforderungen
Unterstützt Betriebssysteme: Windows NT/2000/XP/2003/Vista oder Unix-ähnliches Betriebssystem: z.B. Solaris, Linux, BSD, Mac OS X …
Arbeitsspeicher: 512 - 1024 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. 120 MB
Web Browser: Mozilla Firefox ab V1.0 oder Microsoft Internet Explorer ab V6.0
Optional: Adobe Reader zum Betrachten der Dokumentation und zum Betrachten der erzeugten PDF-Reports
Bei Unix-Systemen muss zusätzlich ein Java SDK 1.5 (5) vorinstalliert sein. 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 mit der richtigen Java-Version installiert ist.
Das Windows Installations-Kit enthält ein eigenes, integriertes Java 1.5 Kit, welches keinen Einfluss auf andere, bereits installierte Java Versionen hat.
Unter Windows ist keine Vorinstallation nötig.
Seite 8 / 138
2.2
Deutsche Ausgabe
Windows Installation
Starten Sie Prx41C.exe und folgen Sie den Anleitungen des Installations-Menüs. Nach der Installation befinden sich neue Einträge
unter Start  Programme  ProxySniffer und es werden zusätzlich auch 3 neue Desktop-Icons angelegt.
Falls Sie die neuen Desktop-Icon stören so können Sie diese löschen. Dieselben Einträge im Windows Start/Programme-Menü bleiben
dabei erhalten.
Starten Sie nun Proxy Sniffer indem Sie zuerst auf das Icon Proxy Sniffer Console und danach auf das Icon Proxy Sniffer GUI
klicken.
Unter Start  Programme  ProxySniffer finden Sie u.a. auch das
Application Reference Manual, welches die System-Architektur des
Produkts (in Englischer Sprache) genauer beschreibt.
Seite 9 / 138
2.3
Deutsche Ausgabe
Installation bei Unix-ähnlichen Betriebssystemen
1. Erzeugen Sie das frei wählbare Installations-Directory von Hand, z.B. /usr/local/prxsniff oder /Users/<Ihr-name>/prxsniff (Mac OS X)
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 sowie das File ExecAgentTicket.dat im Installations-Directory mittels eines Texteditors (z.B. vi). Das File
prxsniff.key muss den GUI Lizenz-Key enthalten und das File ExecAgentTicket.dat muss das „Exec Agent License Ticket“ 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 http://127.0.0.1:7990
Alternativ zu den zuvor beschriebenen Schritten 4. Und 5. können Sie Proxy Sniffer auch im „Konsolen Window-Modus“ durch die Eingabe folgender
Befehle starten:
 cd /usr/local/prxniff – oder – cd /Users/< Ihr-name >/prxsniff
 export CLASSPATH=.:prxsniff.jar
 java -Xmx256m -Xbootclasspath/p:prxsniff.jar ProxySnifferConsole -tz ECT
Hinweis: das -tz Argument ist die Zeitzone. Kapitel 6 des Application Reference Manual enthält eine
Liste aller Zeitzonen. Zusätzliche Argumente wie -jobdir oder -dgs könne auch angegeben werden.
Die entsprechende Beschreibung hierzu finden Sie in Kapitel 3.1 des Application Reference Manual.
Spezieller Hinweis für Mac OS X Server welche über kein X11 Display (kein Grafikadapter) verfügen:
verwenden Sie zusätzlich das Java Argument -Djava.awt.headless=true
Beispiel: java -Djava.awt.headless=true …
Seite 10 / 138
2.4
Deutsche Ausgabe
Architektur-Übersicht
Beim Starten des Produkts werden 4 Server auf Ihrem lokalen Server gestartet:
1. Ein spezieller Proxy Server welcher zum Aufzeichnen von WebBrowser 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
7999
HTTP Proxy Port
7997
HTTPS Proxy Port
(Proxy Sniffer Server)
Seite 11 / 138
Deutsche Ausgabe
3 Konfiguration des Web-Browsers
Nachdem Sie Proxy Sniffer installiert und gestartet haben – und das URL http://127.0.0.1:7990 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
Lokale, vom eigenen Rechner erzeugte Popup-Fenster müssen zugelassen werden.
o
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.
Seite 12 / 138
3.1
Deutsche Ausgabe
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 127.0.0.1 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 127.0.0.1. 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.
Seite 13 / 138
Deutsche Ausgabe
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.
Seite 14 / 138
3.2
Deutsche Ausgabe
JavaScript Einstellungen für Mozilla Firefox
Falls Sie Firefox zur Bedienung des Web Admin GUIs verwenden so sollten Sie noch zusätzlich folgende JavaScript Einstellungen vornehmen:
Seite 15 / 138
3.3
Deutsche Ausgabe
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 127.0.0.1 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: 127.0.0.1 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 127.0.0.1 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 4.6.2.1.
Seite 16 / 138
Deutsche Ausgabe
3.3.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).
Seite 17 / 138
Deutsche Ausgabe
3.3.2 Beispiel Proxy-Konfiguration für Mozilla Firefox 2
Seite 18 / 138
Deutsche Ausgabe
3.3.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.
Seite 19 / 138
Deutsche Ausgabe
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 14.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 und alle Cookies * (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
* Loschen Sie den Web-Browser Cache und die Cookies jedes Mal
bevor Sie eine neue Web-Browser Session aufzeichnen.
Seite 20 / 138
Deutsche Ausgabe
4.1.1 Löschen des Web-Browser Caches und der Cookies im Internet Explorer 7
4.1.2 Löschen des Web-Browser Caches und der Cookies im Mozilla Firefox 2
Seite 21 / 138
4.2
Deutsche Ausgabe
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.
Seite 22 / 138
4.3
Deutsche Ausgabe
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.
Seite 23 / 138
4.4
Deutsche Ausgabe
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?
4.4.1 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 RechnerNamen der Web-Applikation eingeben, oder einen unerwünschten Rechner-Namen herausfiltern in dem Sie ein Ausrufzeichen (!) vor den RechnerNamen im Host-Filter setzen. Mehrere Rechner-Namen, getrennt durch Kommas, können auch eingegeben werden.
?
Seite 24 / 138
Deutsche Ausgabe
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. HTMLSeiten (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).
Seite 25 / 138
Deutsche Ausgabe
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:
[!<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>
Beispiele:
![ORA-01652]
Der Text „ORA-01652“ 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 {$Anrede} {$Name}“. Mehr Informationen zum Umgang mit Variablen erhalten Sie in Kapitel 6.1, Variablen Handler.
Seite 26 / 138
4.5
Deutsche Ausgabe
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 6.4.1 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.
Seite 27 / 138
4.6
Deutsche Ausgabe
Weitere Hinweise zum Aufzeichnen von Web-Browser Sessions
4.6.1 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 ClientApplikationen 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“).
4.6.2 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 ClientZertifikat basierende Authentisierung. Eine spezielle Konfiguration ist jedoch nicht nötig für HTML Formularbezogene Authentisierungs-Verfahren oder für Basic- oder Digest-Authentication.
Seite 28 / 138
4.6.2.1
Deutsche Ausgabe
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.
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.
4.6.2.2
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.
Seite 29 / 138
Deutsche Ausgabe
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).
4.6.2.3
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.
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
4.6.2.4
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.
Seite 30 / 138
4.6.2.5
Deutsche Ausgabe
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
(123„456.78 oder 123,456.78).
Background Color: erlaubt das Setzen der Hintergrundfarbe aller GUI-Windows.
Seite 31 / 138
Deutsche Ausgabe
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.
Seite 32 / 138
Deutsche Ausgabe
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.
Seite 33 / 138
Deutsche Ausgabe
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 jedoch prinzipiell von
deren späteren 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 Lasttests gesetzt werden können (Kapitel 6.3)
-
Aus Parametern von HTML-Formularen , z.B. Werte von „hidden“ Formular-Feldern (Kapitel 6.6)
-
Aus Werten von geparsten SOAP- und XML-Daten (Kapitel 6.4.4)
-
Aus Werten von CGI-Parametern von Hyperlinks, von HTTP-Umleitungen (Redirections) und von HTML Formular-Aktionen (Kapitel 6.6)
-
Aus beliebigen HTML oder XML Text-Fragmenten (Kapitel 6.4.2)
-
Aus Feldern von HTTP Response-Headern
Seite 34 / 138
Deutsche Ausgabe
Eine Variable, gleichgültig wie diese extrahiert wurde, lässt sich mittels des GUI folgenden Zwecken zuweisen:
-
einem Wert eines HTML-Formular Felds (Kapitel 6.6)
-
einem Wert eines CGI-Parmeters eines URL-Aufrufs (Kapitel 6.6)
-
Werten von SOAP- und XML-Daten (Kapitel 6.4.4)
-
einem beliebigen Text-Fragment eines URL-Aufrufs (sowohl im HTTP Request-Headers wie auch im HTTP Request-Content, Kapitel 6.4.3)
-
dem Protokoll, Hostnamen oder TCP/IP Port eines URL-Aufrufs (Kapitel 6.6)
-
der User’s Think Time einer Web-Seite (Kapitel 6.3.1)
-
der Inhaltsüberprüfung einer Web-Seite: in der Web-Seite gesuchtes Textfragment oder Grösse-Kontrolle der empfangenen Daten (Kapitel
4.4.2)
-
der Anzahl Iterationen und dem Pacing Delay von Inner Loops (Kapitel 5)
-
den Werten von einigen HTTP Request-Header Feldern (die meisten HTTP Request-Header Feldern werden durch Proxy Sniffer automatisch
behandelt)
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.
Seite 35 / 138
6.1
Deutsche Ausgabe
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.
Seite 36 / 138
6.2
Deutsche Ausgabe
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
Beschreibung
File Scope
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 ZeilenSequenzen 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.
Line Order
Steuert, ob die Zeilen sequenziell oder in zufälliger Reihenfolge (randomized) eingelesen
werden.
Comment Tag
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.
Var Delimiter
Variablen-Trennzeichen. Aus einer Zeile können mehrere Variablen gleichzeitig extrahiert
werden, welche durch ein Trennzeichen separiert sind.
Trim Extracted
Values
Steuert ob Leerzeichen am Anfang und am Ende der (aus den Zeilen) extrahierten Werte
entfernt werden sollen.
EOF Action
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.
Seite 37 / 138
Deutsche Ausgabe
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.
Seite 38 / 138
Deutsche Ausgabe
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.
Seite 39 / 138
Deutsche Ausgabe
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
den Details der URL-Calls zu gelangen.
um zu
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.
Seite 40 / 138
Deutsche Ausgabe
Nachdem Sie den URL-Call gefunden haben, welcher die Login-Daten übermittelt, können Sie die Variablen den entsprechenden FormularParametern zuweisen. Klicken Sie dazu auf die entsprechenden Icons
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 URL-kodiert
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:
Seite 41 / 138
Deutsche Ausgabe
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
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.
o
Zum variablen Gestalten der User‟s Think Time pro Benutzer
o
Zum variablen Gestalten, wie viele Iterationen in einem Inner Loop ausgeführt werden
o
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.
Seite 42 / 138
Deutsche Ausgabe
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 URLCalls gilt, welche das gleiche Protokoll und den
gleichen Hostnamen und den gleichen Port
verwenden.
Wenn beispielsweise die aufgezeichnete WebSession sowohl http wie auch https Aufrufe enthält, so
müssen Sie diesen Vorgang einmal bei einem URLCall 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.
Seite 43 / 138
Deutsche Ausgabe
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.
Seite 44 / 138
Deutsche Ausgabe
6.3.1 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 (z.B. Zuweisung an Formular-Parameter, siehe Kapitel 6.6)
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“
Beispiel:
Das folgende Beispiel zeigt wie Sie die User‟s Think Time für die Web-Pages mit Hilfe eines User Input Fields variabel gestalten können:
1. Erzeugen Sie zuerst ein User Input Field und legen Sie einen Default-Wert fest (bei diesem Fall in Sekunden).
2. Weisen Sie danach im Main Menü allen Page-Breaks dieselbe Variable für die User‟s Think Time zu, wobei dies auf dem ersten Page-Break der
Aufzeichnung geschehen sollte.
3. Danach können Sie beim Starten des Lasttests die User‟s Think Time der Web-Pages frei wählen. Im Detail-Resultat eines bereits ausgeführten
Lasttests können Sie auch nachträglich die (damals) gewählte User‟s Think Time betrachten.
Seite 45 / 138
Deutsche Ausgabe
Seite 46 / 138
6.4
Deutsche Ausgabe
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 WebServer 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:
Seite 47 / 138
Deutsche Ausgabe
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 ParameterWerte (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.
Seite 48 / 138
Deutsche Ausgabe
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.
Seite 49 / 138
Deutsche Ausgabe
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.
Seite 50 / 138
Deutsche Ausgabe
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.
Seite 51 / 138
Deutsche Ausgabe
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.
Seite 52 / 138
Deutsche Ausgabe
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 WebSession wiederum abgespeichert werden, damit die
neuen Definitionen nicht verloren gehen.
Seite 53 / 138
Deutsche Ausgabe
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 TextParser extrahiert werden muss. Auch dies wird unterstützt. Falls zwei Extraktor-Icons vorhanden sind, so
müssen Sie dazu das letztere verwenden:
Seite 54 / 138
Deutsche Ausgabe
6.4.4 Extrahieren und Zuweisen von Werten von/an SOAP- und XML-Daten
Falls SOAP- und XML-Daten aufgezeichnet wurden so werden diese im GUI automatisch geparst. Um den Umgang mit solchen Daten zu erleichtern
steht Ihnen zusätzlich noch ein spezieller Variablen-Extractor und ein zusätzlicher Variablen-Assigner zur Verfügung. Dies wird dadurch angezeigt, dass
im Titel des entsprechenden Requests-Contents bzw. des Response-Contents ein zusätzliches XML-Icon dargestellt wird.
Seite 55 / 138
6.5
Deutsche Ausgabe
HTTP File-Uploads
Falls eine aufgezeichnete Web-Browser Session HTTP File-Uploads enthält so können Sie die Files, welche zum Web-Server gesendet werden, auch
durch Variablen bestimmen. Oft werden solche Variablen aus Input-Files extrahiert, welche eine Liste von File-Namen (ohne Pfadangaben) enthalten.
Bevor Sie einen solchen Lasttest starten müssen Sie alle Files welche an den Web-Server gesendet werden in das Project-Navigator Directory
kopieren, welches auch Ihr Lasttest-Programm enthält. Danach müssen Sie das kompilierte Lasttest-Programm (*.class) zusammen mit allen Files
(Daten) und zusammen mit allen verwendeten Input-Files in einem ZIP-Archiv zusammenfassen. Danach können Sie den Lasttest dadurch starten
indem Sie auf das Icon des Zip-Archivs klicken.
Seite 56 / 138
6.6
Deutsche Ausgabe
Zusammenfassung der am häufigsten verwendeten Extrakt- und Zuweisungs-Operationen
Das nachfolgende Bild zeigt eine Übersicht der am häufigsten verwendeten Extrakt- und Zuweisungs-Operationen von URL-Calls. Die vorliegende
Darstellung ist nicht abschliessend. Beachten Sie bitte, dass bei extrahieren von Variablen aus User Input Fields und aus Input Files keine automatische
Zuweisung erfolgt, d.h. dass Sie diese manuell durchführen müssen.
Wert einem CGIParameter zuweisen
Wert dem Protokoll, HostNamen oder Port zuweisen
Wert eines Textmusters eines
Formulars ersetzen.
Wert einem FormularParameter zuweisen
Wert eines Textmusters
dem URL-Pfad zuweisen
Wert aus einem FormularParameter extrahieren
Textmuster aus dem
empfangenen Inhalt extrahieren
Wert eines CGI-Parameters
aus einer Umleitung extrahieren
Textmuster aus einer
Umleitung extrahieren
CGI-Parameter aus einem
Hyperlink extrahieren
Seite 57 / 138
6.7
Deutsche Ausgabe
Direkte Definition von Variablen (stand-alone 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 1970
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)
Seite 58 / 138
6.8
Deutsche Ausgabe
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 WebSessions-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="http://www.d-fischer.com:8080/prxtool/servlet/WebMainMenu;jsessionid=bu3fy0bbj1?currentDir=344">weiter</A>
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.
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 URLRewriting Parameters
Seite 59 / 138
Deutsche Ausgabe
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 URLRewriting Parameters an.
Seite 60 / 138
Deutsche Ausgabe
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:
Seite 61 / 138
Deutsche Ausgabe
Üblicherweise geben Sie hier nur den Namen des LasttestProgramms sowie einen kurzen stichwortartigen Kommentar ein,
ohne weitere Optionen zu wählen.
Spezielle Optionen nur sind nötig wenn:
-
Sie eine Lasttest über einen abgehenden Proxy-Server
ausführen möchten (siehe auch Kapitel 4.6.2.1)
-
wenn Sie mehrere Benutzer-Accounts für Basic- oder Digest
Authentisierung verwenden möchten
-
Wenn eine NTLM Authentisierung erforderlich ist (siehe auch
Kapitel 4.6.2.3)
-
Wenn HTTPS/SSL Client-Zertifikate zur Authentisierung
erforderlich sind (siehe auch Kapitel 4.6.2.4)
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 (siehe auch Kapitel 4.4.2).
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 WebSeiten 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.
Seite 62 / 138
Deutsche Ausgabe
-
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 WebSeite 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 4.6.2.1) direkt in das Lasttest-Programm
übernommen.
-
Basic Authentication: falls eine Basic Authentication 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 Authentication 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.
-
Digest Authentication: falls eine Digest Authentication während der Aufzeichnung nötig war, so müssen Sie beim Erzeugen des LasttestProgramms diese Option aktivieren. Dabei stehen zwei Möglichkeiten zur Verfügung:
o use common Username: für alle Benutzer wird während des Lasttests derselbe Digest Account verwendet. Die Daten des Accounts
werden direkt in das Lasttest-Programm übernommen.
o Apply individual Digest Authentication per user from input file (digestauth.txt): jeder Benutzer verwendet während des Lasttests
einen eignen Digest Account. Erstellen Sie vor oder nach dem Erzeugen des Lasttest-Programms ein File mit dem Namen digestauth.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 – jeweils getrennt durch ein Semikolon
Seite 63 / 138
Deutsche Ausgabe
(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 digestauth.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 zur 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 4.6.2.3). 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
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 zur Aufzeichnung nötig war, so müssen Sie beim Erzeugen des LasttestProgramms 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 ClientZertifikat verwendet, welches im Personal Settings Menü geladen wurde (Kapitel 4.6.2.4). 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:
Seite 64 / 138
Deutsche Ausgabe
Links im Dialog können Sie das Project Navigator
Directory wählen, in welchem das LasttestProgramm 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 JavaCode 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
a) deren empfangener Inhalt mittels eines TextFragments geprüft wird. – oder –
b) 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. Hinweis zur einfacheren
Bedienung: anstelle auf den Continue Button zu klicken können Sie auch die Enter-Taste drücken.
Es erscheint nun das Projekt Navigator Menü:
Seite 65 / 138
Deutsche Ausgabe
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 LasttestProgramm 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 EnterTaste 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:
Seite 66 / 138
7.1
Deutsche Ausgabe
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:
1. Selektieren Sie das kompilierte
Lasttest-Programm (*.class) und
die dazu nötigen Input Files
2. Klicken Sie auf das Zip
Projekt Navigator
Icon im
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 ZipArchivs 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 LasttestProgramms klicken.
Seite 67 / 138
Deutsche Ausgabe
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 WebSession 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.
Seite 68 / 138
Deutsche Ausgabe
-
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
--- 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.
o
o
Performance Details per Call: es werden folgende internen Zeiten der URL-Aufrufen zusätzlich protokolliert: Netzwerk VerbindungsAufbauzeit, Request Übertragungszeit, Response Header Wartezeit, Response Header Empfangszeit, Response Content Empfangszeit.
Request Headers: zusätzlich wird der Request Header jedes URL-Aufrufs protokolliert.
o
o
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.
o
Response Headers: zusätzlich wird der Response Header jedes URL-Aufrufs protokolliert.
Seite 69 / 138
Deutsche Ausgabe
o
Resp. Headers & Content: zusätzlich wird der Response Header und der Response Content jedes URL-Aufrufs protokolliert.
o
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.
o
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 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.
o 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.
o 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.
o 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).
o debug cookies & loops: enthält die Option „debug loops“ und schreibt zusätzlich den Inhalt aller empfangenen und gesendeten Cookies
in das Log-File.
o debug keep-alive & loops: enthält die Option „debug loops“ und schreibt zusätzlich Daten über wieder verwendete
Netzwerkverbindungen in das Log-File.
o debug SSL handshake & loops: enthält die Option „debug loops“ und schreibt zusätzlich ein Protokoll jedes ausgeführten SSLHandshakes 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 -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).
o -collect <measuring agent host>[:port][,<measuring agent host>[:port]]…
Beispiel: -collect measuringhost1,measuringhost2
Weist das Lasttest-Programm an, zusätzliche Daten von externen Messagenten während des Test zu sammeln, wie z.B. Daten über die
CPU-Belastung von Routern, Firewalls und Unix-ähnlichen Betriebssystemen.
o
-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.
Seite 70 / 138
o
o
o
-
-
Deutsche Ausgabe
-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.
-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 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.
o TLS: es wird nur TLS verwendet.
o
v3: es wird nur SSL v3 verwendet.
o
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.
Seite 71 / 138
8.1
Deutsche Ausgabe
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 LasttestJobs 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.
Seite 72 / 138
Deutsche Ausgabe
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.
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.
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 URLCalls pro Sekunde (Server-Durchsatz)
Seite 73 / 138
Deutsche Ausgabe
-
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
-
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
Während der Test-Ausführung können Sie
auch real-time Kommentare eingeben.
Diese werden nach dem Test-Ende in den
Diagrammen der Detail-Resultate
dargestellt.
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 URLCalls enthalten und auch Zugang zu den Error-Snapshots erlauben. Ganz links sehen Sie blau markiert, wie viele Benutzer gerade eine bestimmte WebSeite bzw. einen bestimmten URL-Call ausführen. Die Statistik der URL-Calls enthält nur die Calls einer einzigen Web-Seite (Default: der ersten WebSeite). 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.
Seite 74 / 138
Deutsche Ausgabe
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.
Seite 75 / 138
Deutsche Ausgabe
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 LupenIcon 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.
Seite 76 / 138
8.2
Deutsche Ausgabe
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 / ClusterMember 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.
Seite 77 / 138
Deutsche Ausgabe
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.
Seite 78 / 138
Deutsche Ausgabe
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:
Seite 79 / 138
Deutsche Ausgabe
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:
Seite 80 / 138
Deutsche Ausgabe
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.
Seite 81 / 138
8.3
Deutsche Ausgabe
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 ProduktArchitektur 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 ClusterJobs 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.
8.4
Wiederholen von Lasttest-Jobs
Bei jedem interaktiven Start eines Lasttests wird zusätzlich (automatisch) noch eine Job-Vorlagen Datei im XML-Format erzeugt und im entsprechenden
Directory des Project-Navigators abgelegt. Eine solche XML-Datei enthält alle Konfigurationsdaten welche nötig sind um den genau gleichen LasttestJob ein weiteres Mal zu wiederholen. Durch einen Maus-Klick auf das entsprechende Icon des XML-Files wird der Job erneut erzeugt und an den
entsprechenden Exec Agenten bzw. Exec Agent Cluster übertragen. Danach ist dieser sofort startbereit.
Gewöhnlicher interaktiver Start – mit Konfiguration der Input-Daten
parameters
Wiederholen desselben Lasttests
Editieren der Job-Vorlage
Umbenennen oder Kopieren der Job-Vorlage
Seite 82 / 138
Deutsche Ausgabe
Zusätzlich können auch mehrere Job-Vorlagen in einem ZIP-Archiv zusammengefasst werden. Durch einen Maus-Klick auf ein solches Archiv werden
dann alle darin enthaltenen Jobs gleichzeitig Job erneut erzeugt:
XML-Attribute einer Job-Vorlagen Datei: (siehe auch Kapitel 8: Ausführen von Lasttest-Programmen):
Attribut Name
loadTestProgramPath
startFromExecAgentName
startFromClusterName
concurrentUsers
testDuration
loopsPerUser
startupDelayPerUser
downlinkBandwidth
uplinkBandwidth
Beschreibung
Absoluter Datei-Pfad des kompilierten Lasttest-Programms (*.class) oder des Lasttest-Program-Archivs
(*.zip)
Name des Exec Agenten von welchem aus der Lasttest gestartet wird (bei Cluster-Jobs: Leerwert)
Name des Exec Agent Clusters von welchem aus der Lasttest gestartet wird (Leerwert falls kein
Cluster-Job)
Anzahl der gleichzeitige Benutzer
Geplante Testdauer in Sekunden (0 = unlimitiert)
Geplante Anzahl der Web-Session Repetitionen pro Benutzer (0 = unlimitiert)
Startup-Verzögerung pro Benutzer in Millisekunden
Reduzierte Downlink-Bandbreite pro Benutzer in Kilobits pro Sekunde (0 = nicht reduziert)
Reduzierte Uplink-Bandbreite pro Benutzer in Kilobits pro Sekunde (0 = nicht reduziert)
Seite 83 / 138
requestTimeout
maxErrorSnapshots
statisticSamplingInterval
percentilePageSamplingPercent
percentileUrlSamplingPercent
percentileUrlSamplingPercentAddOption
debugOptions
additionalOptions
sslOptions
testRunAnnotation
userInputFields
Deutsche Ausgabe
Timeout pro URL-Aufruf in Sekunden
Maximal Anzahl von Fehler-Schnappschüssen pro aufgezeichnetes URL (0 = unlimitiert)
Periodischer Zeitintervall in Sekunden zum Sammeln von Stützpunkten bei Diagrammen
Prozentwert der Web-Pages über welche zusätzliche statistische Daten gesammelt werden (0..100)
Prozentwert der URL-Aufrufe über welche zusätzliche statistische Daten gesammelt werden (0..100)
Weitere Optionen beim Sammeln von zusätzliche statistischen Daten pro URL-Aufruf:
0: -- recommended (keine weitere Option, empfohlener Wert)
1: Performace Details per Call (Netzwerk Verbindungs-Aufbauzeit, Request Übertragungszeit, …)
2: Request Headers (Kopie der Request-Header der URL-Aufrufe)
3: Request Content (Kopie des Request-Contents – Formulardaten – der URL-Aufrufe)
4: Request Headers & Content
5: Response Headers (Kopie der Response-Header der URL-Aufrufe)
6: Response Headers & Content (Kopie der Response-Header und des Contents der URL-Aufrufe)
7: All – without Response Content (Kopie aller URL-Daten, jedoch ohne Response-Content)
8: All – full URL Snapshot (vollständige Kopie aller URL-Daten)
Debug Optionen: (Text-Wert)
“”: (none – recommended)
“-dl”: debug loops (including var handler)
“-dh”: debug headers & loops
“-dc”: debug content & loops
“-dC”: debug cookies & loops
“-dK”: debug keep-alive & loops
“-dssl”: debug SSL handshake & loops
Weitere Optionen zur Programm-Ausführung (Text-Wert)
SSL/HTTPS Optionen: (Text-Wert)
“all”: automatisch (beste) Erkennung der SSL Protokoll-Version (TLS bevorzugt)
“tls”: SSL Protokoll-Version auf TLS festgelegt
“v3”: SSL Protokoll-Version auf V3 festgelegt
“v2”: SSL Protokoll-Version auf V2 festgelegt
Kommentar zum Testlauf (Text-Wert)
Label, Variablen-Name und Default-Wert bei User-Input Fields
Seite 84 / 138
8.5
Deutsche Ausgabe
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 TestTage 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 WebBrowser 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) ZielSub-Directory mit einem Klick auswählen.
Seite 85 / 138
Deutsche Ausgabe
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.
Seite 86 / 138
Deutsche Ausgabe
8.5.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 7.
.
Seite 87 / 138
Deutsche Ausgabe
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
Test Duration: Zeitdauer des
Testlaufs
Detailergebnisse
der Testläufe
Web. Trans.: Anzahl
erfolgreiche URL-Aufrufe pro
Sekunde (Durchsatz des
Web-Servers)
Sess. Failures: Prozentsatz
der fehlgeschlagenen Loops
Net. Throughput: mittlerer
Netzwerkdurchsatz des
Testlaufs
Lastkurven und Vergleichsdiagramme –
Vergleich über mehrere Testläufe
Annotation: Kommentar des
Testlaufs bei dessen Start
Seite 88 / 138
9.1
Deutsche Ausgabe
Detailergebnisse
Pro Testlauf können viele verschiedene Detailergebnisse dargestellt werden.
Rechts oben im Titel des Fensters ist das ReportIcon, 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 WebSeiten).
-
Network Throughput per User: mittlerer
Netzwerkdurchsatz, pro Benutzer
Overall Test Results:
-
Web Transaction Rate: Mittelwert der
Anzahl erfolgreich durchgeführten URLCalls 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.
Seite 89 / 138
Deutsche Ausgabe
9.1.1 Test Scenario
Gibt einen Überblick über die Testumgebung, die Input-Parameter des Testlaufs und die aufgezeichnete Web-Session.
9.1.2 Diagram: Response Time per Page
Zeit die mittlere Antwortzeit der Web-Seiten an.
Seite 90 / 138
Deutsche Ausgabe
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 ErrorSnapshots 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
Seite 91 / 138
Deutsche Ausgabe
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.
Av Wait: mittlere Wartezeit des URL-Calls, nachdem die Anfrage
übermittelt wurde, bis das erste Byte der Antwort des Servers
eintrifft.
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.
Seite 92 / 138
Deutsche Ausgabe
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.
Seite 93 / 138
Deutsche Ausgabe
9.1.6 Diagram: Top Time-Consuming URLs
Zeigt eine Zusammenstellung der langsamsten URL-Calls der Web-Session an. Die einzelnen Zeiten sind Mittelwerte.
9.1.7 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.
Seite 94 / 138
Deutsche Ausgabe
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.
9.1.9 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.
Seite 95 / 138
Deutsche Ausgabe
9.1.10 Diagram: Completed Loops
Zeigt die Anzahl Loops (Web Surf-Sessions) an, welche pro Minute erfolgreich durchgeführt wurden – über alle Benutzer gemessen.
9.1.11 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.
Seite 96 / 138
Deutsche Ausgabe
9.1.12 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.
9.1.13 Diagram: HTTP Keep-Alive Efficiency
Zeigt die HTTP Keep-Alive Effektivität des gesamten Testlaufs an (Prozentsatz der wieder verwendeten Netzwerkverbindungen).
Seite 97 / 138
Deutsche Ausgabe
9.1.14 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.
9.1.15 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.
Seite 98 / 138
Deutsche Ausgabe
9.1.16 Diagram: Top Error Types
Zeigt die häufigsten Fehler-Ursachen an (Fehler-Typen)
9.1.17 Diagram: Number of Errors per Page
Zeigt die Web-Seiten an, bei welchen am häufigsten ein Fehler aufgetreten ist.
Seite 99 / 138
Deutsche Ausgabe
9.1.18 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 TestNummern 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.
Seite 100 / 138
Deutsche Ausgabe
Der obere Teil des Fensters enthält eine Liste von ErrorSnapshots; je nach aufgerufenem Kontext über den
gesamten Testlauf / oder pro Web Page / oder pro URLCall. 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 URLCalls, 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.
Ablaufschritt des URL-Calls, als der Fehler auftrat. Mögliche Werte sind:
o
No Step / not Initialized: der URL-Call wurde noch nicht gestartet
o
Open Network Connection to Proxy: es wird eine Netzwerk-Verbindung zu einem abgehenden Proxy-Server aufgebaut
o
Open Network Connection: es wird eine Netzwerk-Verbindung zum Web-Server aufgebaut
o
Transmit HTTP Request: der HTTP Request-Header und (gegebenenfalls) -Content wird gesendet (URL-.Anfrage)
o
Wait for Server Response: es wird auf eine Antwort des Web-Servers gewartet (noch kein erstes Byte eingetroffen)
o
Receive HTTP Header: der HTTP Response-Header der Server-Antwort wird empfangen
Seite 101 / 138
-
Deutsche Ausgabe
o
Receive Content: der HTTP Response-Content der Server-Antwort wird empfangen (Nutzdaten: HTML, GIF-Bild, etc.)
o
Close Network Connection: die Netzwerk-Verbindung zum Web-Server wird geschlossen
o
All Done: der URL-Aufruf wurde bezüglich des HTTP-Protokolls erfolgreich abgeschlossen, jedoch ist der empfangene HTTP StatusCode, 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.
Seite 102 / 138
Deutsche Ausgabe
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.
Seite 103 / 138
Deutsche Ausgabe
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
9.2.2 Ü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.
Seite 104 / 138
9.3
Deutsche Ausgabe
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, 1000 .. 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 ProduktHomepage finden, erhalten Sie
mehr Informationen zu dieser
Thematik.
Seite 105 / 138
Deutsche Ausgabe
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:
Seite 106 / 138
Deutsche Ausgabe
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 URLCalls 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)
Bytes: Netzwerkdurchsatz des schnellsten URL-Calls mit mindesten 4096 Bytes empfangenen Daten.
Highest URL Throughput >= 4096
-
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.
Seite 107 / 138
9.4
Deutsche Ausgabe
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 WebSeite 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.
Seite 108 / 138
Deutsche Ausgabe
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 7993. 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.
Seite 109 / 138
Deutsche Ausgabe
10.1 Konfiguration von weiteren Last-auslösenden Rechnern
Weitere Last-auslösende Rechner können mittels des Network Menüs hinzugefügt werden, welches vom Project Navigator aus zugänglich ist:
Im oberen, linken Bereich des Fensters wird eine
Liste aller bereits definierten Exec Agenten
angezeigt. Im unteren Bereich des Fensters kann ein
neuer Exec Agent erfasst oder die Konfiguration
eines bestehenden Exec Agents modifiziert werden
(durch einen Klick auf das Lupen-Icon in der Liste).
Eingabefelder zur Erfassung oder Modifikation:
-
Description: frei wählbare Bezeichnung des
Exec Agents
-
Host: TCP/IP Adresse oder Hostname des
Rechners
-
Port: TCP/IP Port
-
Protokoll: Kommunikationsprotokoll
-
Username / Passwort: nur bei beim HTTP
bzw. HTTPS Protokoll kann der Aufruf des
Exec Agents optional mit einem
Benutzernamen und einem Passwort
geschützt werden
-
Die weiteren Felder bezüglich der Proxy
Konfiguration kommen nur zur Anwendung
falls die Kommunikation bei HTTP/S über
einen abgehenden Proxy-Server erfolgt.
Die Erreichbarkeit bzw. die richtige Konfiguration eines Exec Agents kann durch einen Klick auf das entsprechende
Agenten geprüft werden.
Icon in der Liste der Exec
Seite 110 / 138
Deutsche Ausgabe
10.2 Konfiguration von Last-auslösenden Clustern
Nachdem mehrere Exec Agenten definiert wurden, können diese zusätzlich zu einem Last-auslösenden Cluster aggregiert werden. Es können auch
mehrere Cluster konfiguriert werden, welche ganz oder teilweise dieselben Exec Agenten umfassen.
Nachdem der frei definierbare Name des Clusters
eingegeben wurde, lassen sich die Cluster-Member
unter Available Exec Agents hinzufügen, indem auf
den entsprechenden blauen Pfeil geklickt wird.
Durch einen Klick auf das Lupen-Icon kann der LastFaktor (Load Factor) eines Cluster-Members
modifiziert werden. Der Last-Faktor bestimmt, wie die
Benutzer während des Lasttests auf die
entsprechenden Cluster-Member aufgeteilt werden
(entsprechend der Leistungsfähigkeit der Exec
Agents).
Es ist nicht erforderlich, dass die einzelnen ClusterMember dieselbe Systemzeit haben. Beim Starten
eines Cluster-Jobs nimmt der Cluster Job Controller
automatisch eine Zeit-Differenzmessung vor, deren
Resultate währen der Vereinigung der Statistik-Daten
mitberücksichtigt werden.
Der Last-Faktor eines Exec Agents kann auch automatisch bestimmt werden, indem auf das Icon eines Exec Agents geklickt wird und der
(unverbindliche) Vorschlag in die Cluster-Konfiguration übernommen wird. Eventuell müssen Sie jedoch mehrmals auf das Icon klicken um einen
stabilen Wert zu erhalten.
Seite 111 / 138
Deutsche Ausgabe
10.3 Starten von verteilten Lasttests
Nachdem weitere Last-auslösende Rechner oder Cluster definiert wurden kann beim Starten eines Testlaufs gewählt werden, von welchem Rechner
oder von welchem Cluster aus der Lasttest durchgeführt wird. Die Behandlung des Testlaufs erfolgt dabei durch das GUI absolute transparent – genau
gleich, als würde dieser nur lokal durchgeführt:
Seite 112 / 138
Deutsche Ausgabe
11 Konfiguration vom mehreren IP Adressen pro Last-auslösenden Rechner
Manchmal kann es erforderlich sein, dass Sie während eines Lasttests Clients mit unterschiedlichen IP Adressen von (nur) einem Rechner aus
simulieren. Dies ist dann z.B. der Fall, wenn einem Web-Server-Cluster ein Load-Balancer vorgeschaltet ist, welcher pro Client-IP Adresse nur einen Ast
bzw. nur einen Rechner des Web-Server-Clusters bedient (sog. Sticky-Bit des Load-Balances zum Schutz von Session-Cookies). Gehen Sie wie folgt
vor:
1. Damit Sie mehrere IP Adressen auf demselben Rechner verwenden können müssen Sie dessen Betriebssystem zuerst so konfigurieren, das
einem physikalischem Netzwerk-Interface mehrere IP Adressen zugewiesen werde. Dies ist sowohl bei Windows- wie auch bei Unix-Systemen
möglich.
2. Danach müssen Sie die Konfiguration des Exec Agents so anpassen, dass dieser auch mehrere IP Adressen für das Ausführen der Lasttests
verwendet. Falls auf demselben Rechner ein Web Amin Prozess gestartet wurde, so können Sie dies im Setup Menü des Projekt Navigators tun.
Anderenfalls müssen Sie das Konfigurations-File des Exec Agenten javaSetup.dat manuell mit einem Texteditor anpassen. Fügen Sie dazu
dem Eintrag javaVirtualIpAddresses alle IP Adressen des Rechners hinzu (getrennt durch Kommas) .
3. Nun können Sie den Lasttest starten, bei welchem Sie im Input-Feld Additional Options von Hand noch den Wert -multihomed eintragen.
Jeder Benutzer erhält nun eine eigene IP Adresse während des Lasttests; bzw. wenn mehr Benutzer gefahren werden als IP Adressen zur
Verfügung stehen so werden die IP Adressen gleichmässig auf die Benutzer verteilt. Diese Option wird auch von Cluster-Jobs unterstützt, wobei
Sie die IP Adressen der entsprechenden Cluster-Member (Exec Agents) konfigurieren müssen.
Seite 113 / 138
Deutsche Ausgabe
11.1 Schritt 1: Konfiguration des Betriebsystems
11.1.1 Windows
11.1.2 Unix-ähnliche Betriebssysteme
Um mehrere IP Adressen zu konfigurieren müssen Sie den System-Befehl ifconfig verwenden. Je nach Ausprägung des Unix-System (Solaris, Linux ..)
sind dessen Argumente etwas verschieden. Bitte konsultieren Sie die man pages bezüglich der genauen Syntax.
Seite 114 / 138
Deutsche Ausgabe
11.2 Schritt 2 und 3: Konfiguration des Exec Agents und Starten des Testlaufs
Bei der Konfiguration des lokalen Exec Agents über das Setup Menü des Projekt Navigators steht Ihnen zusätzlich eine Auto Detect Option zur
Verfügung, welche alle konfigurierten IP Adressen des Betriebsystems automatisch erkennt:
Bei externen Exec Agenten ohne Web Admin GUI müssen Sie
das File javaSetup.dat mit einem Texteditor anpassen. Dieses
befindet sich im Installations-Directory:
...
javaOptions=
javaVirtualIpAddresses= 192.16.4.5, 192.16.4.6, 192.16.4.7
javaEditor=
Nach der Konfigurationsänderung muss das Produkt gestoppt
neu gestartet werden.
Wichtig: Sie müssen die Option -multihomed beim Starten
des Tests eingeben damit während des Testlaufs mehrere IP
Adressen verwendet werden:
Seite 115 / 138
Deutsche Ausgabe
12 Lasttest Plug-Ins
Lasttest Plug-Ins sind selbst erstellte Funktionserweiterungen des Proxy Sniffer Produkts welche im „Var Handler“ GUI konfiguriert und während eines
Lasttests ausgeführt werden. Nur – für diese spezielle Funktionalität – können wir unser Versprechen nicht halten, dass keine Programmierkenntnisse
nötig sind. Die Kernfunktion eines Plug-Ins muss von jemanden erstellt werden welcher bereits Erfahrung mit Java-Programmierung hat. Nachdem ein
Plug-in erstellt wurde kann es in jedem beliebigen Lasttest-Programm verwendet werden. Die Verwendung und die Konfiguration eines Plug-Ins selbst
benötigen keine Programmierkenntnisse.
12.1 Plug-In Template Generator
Um den Prozess zum Erstellen eines eigenen Plug-Ins zu vereinfachen steht ein “Plug-In Template Generator” zur Verfügung welche den gesamten
Java-Code, welcher zur Integration des Plug-Ins in das Proxy Sniffer Produkt nötig ist, automatisch erzeugt – so dann nur noch die eigentliche
Kernfunktion des Plug-ins von Hand programmiert werden muss.
Die nachfolgenden Illustrationen zeigen anhand eines Beispiels das Erstellen und die Konfiguration eines Plug-Ins welches dazu verwendet wird um ein
Buchungsdatum zu berechnen, wobei dem aktuellen Datum zwei Tage hinzugefügt werden. Das Resultat wird als drei Variablen ausgegeben welche
das Jahr, den Monat und den Tage des Buchungsdatums enthalten. Diese Variablen können danach den entsprechenden Formular-Parametern der
Buchungsanfrage zugewiesen werden.
1. Navigierten Sie im Project Navigator zum “Plugins” Directory und rufen Sie den “Plug-In Template Generator” auf.
Seite 116 / 138
Deutsche Ausgabe
2. Geben Sie den Namen und Beschreibung des Plug-Ins ein und konfigurieren Sie den Initialisierungs- und Ausführungs-Scope des Plug-Ins.
Geben Sie auch alle Input- und Output-Parameter des Plug-Ins ein welche zur Interaktion mit dem Var Handler GUI dienen:
Seite 117 / 138
Deutsche Ausgabe
3. Speichern Sie Ihre Eingaben ab und generieren Sie danach den Java-Code des Plug-Ins. Nachdem der Code erzeugt wurde müssen Sie den
Kern Ihres Plug-Ins in der Methode “public void execute(Object context)” programmieren – mit Hilfe eines Text-Editors oder einer IDE. Entfernen
Sie allen unnötigen Beispiel-Code und setzen Sie dort Ihren Code ein:
4. Kompilieren Sie das Plug-In und navigieren Sie danach im Projekt-Navigator zu dem Directory zurück in welchem sich Ihre Aufzeichnung der
Web-Session befindet:
Seite 118 / 138
Deutsche Ausgabe
5. Sie können nun das Plug-In im Var Handler konfigurieren. Danach können Sie die neu erzeugten Variablen dem Formular zuweisen:
Hinweis: Das Laufzeitverhalten eines Plug-Ins lässt sich debuggen indem beim Starten eines Job in der Auswahlliste “Debug Options” eine der Optionen
gewählt wird welche “debug loops” enthält. Der Debug-Output wird in die entsprechende *.out Datei des Jobs geschrieben.
Seite 119 / 138
Deutsche Ausgabe
13 Manuelle Anpassungen an Java Lasttest-Programmen / Java API
Proxy Sniffer verfolgt die Philosophie, dass möglichst alle Funktionalitäten zum Ausführen von Lasttests mittels des GUI vorgenommen werden – ohne
dass dabei Programmierkenntnisse nötig sind. Dennoch ist es möglich, auch die automatisch erzeugten Lasttest-Programme manuell anzupassen um
so Effekte zu erzielen, welche mittels des GUI nicht zugänglich sind. D.h. Sie können auf dieser „zweiten Ebene“ die Programme ganz nach Ihren
Wünschen modifizieren. Bedenken Sie jedoch, dass Ihre Anpassungen am Programmcode nicht geschützt sind. D.h. wenn Sie dasselbe Programm
wiederum automatisch erzeugen, so werden Ihre Änderungen überschrieben. Stellen Sie darum sicher, dass alle Var Handler Definitionen bereits
vorgenommen wurden, bevor Sie das Programm erzeugen und danach modifizieren.
Sämtliche Klassen und Methoden welche nicht zum Standard-Sprachumfang von Java gehören sind ausführlich in der Proxy Sniffer Java API
Dokumentation beschrieben, so dass Sie genau nachvollziehen können wie das Lasttest-Programm abläuft. Die innere Struktur eines LasttestProgramms ist wie folgt aufgebaut:
Das Hauptmethode main, ganz unten im Bild blau hinterlegt, liest zuerst
die Input-Daten des Testlaufs ein und erzeugt danach so viele Instanzen
der eigenen Klasse, wie parallele Benutzer erzeugt werden sollen. Dabei
wird für jeden Benutzer der Konstruktor der Klasse aufgerufen. Danach
wird in der Hauptmethode nun jede Instanz als unabhängiger Thread
gestartet was dazu führt, dass pro Benutzer die Methode run ausgeführt
wird (d.h. die Hauptmethode des entsprechenden Threads). Die Methode
run ruft danach für jeden Loop eines Benutzers wiederholt die Methode
execute auf, welche die aufgezeichnete Web-Session enthält. Dies so
oft, bis die maximale Zeitdauer des Lasttest verstrichen ist. Die
Hauptmethode main wartet in der Zwischenzeit, bis die Aktivität aller
Threads bzw. Benutzer beendet wurde. Danach wird das Statistik-File
geschrieben und das Programm wird beendet.
Dieses Konzept hat direkten Einfluss darauf wie Variablen im Programm
definiert werden:
-
globale, bzw. static Variablen gelten für alle Benutzer gemeinsam,
d.h. der Zugriff auf solche Variablen muss synchronisiert werden,
wenn es sich nicht um einzelne primitive Datentypen handelt.
-
Gewöhnliche Variablen gelten hingegen pro Benutzer, d.h. jeder
Benutzer sieht seinen eigenen Wert.
Seite 120 / 138
Deutsche Ausgabe
Falls Sie zu Debug-Zwecken eine Ausgabe in die Log-Datei (*.out) vornehmen möchten, so sollten Sie nicht System.out.println() verwenden, da dadurch
der Output aller gleichzeitigen Benutzer wild durcheinander gewürfelt wird. Wir empfehlen Ihnen anstelle dessen die Methode log zu verwenden, welche
den Output eines Benutzers während eines Loops sammelt und danach diesen am Ende jeden Loops synchronisiert schreibt. Verwenden Sie beim
Starten des Programms/Testlaufs im Web Admin GUI darum die Option debug loops um den Output zu erhalten.
Hinweis: Sie können ein Lasttest-Programm auch ohne Exec Agent direkt von der Kommandozeile des Betriebssystems starten (siehe auch
Application Reference Manual, Kapitel 3.7) Bei Windows-Systemen ist unter Start  Programme  ProxySniffer  Compile and Run Proxy
Sniffer Load Tests bereits eine entsprechende Konsole zugänglich, welche die Umgebungsvariablen PATH und CLASSPATH korrekt setzt. Dies
geschieht über das File setenv.bat welches im Project Navigator Haupt-Directory abgelegt ist. Um den Debug-Output zu erhalten müssen das
Programm mit dem Argument -dl (debug loops) starten.
Nebst den spezifischen Methoden zum Ausführen von Lasttest-Programmen enthält das Proxy Sniffer Java API noch zusätzliche Klassen und
Methoden, mit denen Sie direkt auf Statistik-Files zugreifen können und so prinzipiell eigene Statistiken erstellen können. Die Haupt-Methode um ein
Statistik-File nach dem Ende eines Testlaufs zu laden ist PerformanceData.readObjectFromFile(<Filename>).
13.1 Externe Klassen und Jar-Libraries
Falls Sie eigene Klassen oder Jar-Libraries dem Lasttest-Programm hinzufügen und dieses über das Web Admin GUI oder das PrxJob Utility starten
möchten, so müssen Sie das Lasttest-Programm zusammen mit den Klassen und Libraries zu einem Archiv zippen, und danach das Zip-Archiv als
Lasttest starten (analog dem Umgang mit Input Files).
Auf den entsprechenden (remote) Exec Agenten müssen Sie nichts installieren und nichts konfigurieren. Lokal müssen Sie jedoch bei WindowsSystemen den CLASSPATH des Web Admin ergänzen, indem Sie den Eintrag lax.class.path im File Proxy Sniffer Server.lax erweitern, sowie
gegebenenfalls auch Ergänzungen im Setup Menü des Projekt Navigators für den Java-Compiler vornehmen. Die Datei Proxy Sniffer Server.lax
finden Sie im Installationsdirectory des Produkts.
Für das direkte Ausführen von Lasttest-Programmen über eine Betriebssystem-Konsole sind die vorgenannten Modifikationen sowie das Zippen nicht
nötig. Sie müssen bei Windows-Systemen hier nur den CLASSPATH im File setenv.bat ergänzen, welches im Hauptdirectory des Projekt Navigators
liegt. Bei Unix-Systemen müssen Sie die Umgebungsvariable CLASSPATH direkt modifizieren.
Seite 121 / 138
Deutsche Ausgabe
13.2 Direkter Zugriff auf Messergebnisse
Das Proxy Sniffer Java API erlaubt auch die Messergebnisse aus den Statistik-Files (*.prxres) direktes auszulesen. Dadurch können eigene
Zusammenstellungen der gemessenen Resultate gemacht werden. Zusätzlich lassen sich auch einige Messwerte auslesen welche im Web Admin GUI
nicht dargestellt werden. Das nachfolgende Programm-Beispiel extrahiert alle Web-Pages aus den Error-Snapshots (missgebildete Web-Pages) und
speichert diese als HTML-Dateien ab, welche danach eigenständig im Web Browser dargestellt werden können. Die Hauptmethode um auf ein StatistikFile zuzugreifen ist PerformanceData.readObjectFromFile(<result file name>).
import
import
import
import
import
java.io.FileOutputStream;
dfischer.utils.PerformanceData;
dfischer.utils.PerformanceDataRecord;
dfischer.utils.PerformanceDataRecordFailureInfo;
dfischer.utils.HttpTestURL;
/**
* Writes the response content of all error snapshots to files if they contain ASCII (HTML,XML) data.
* Program Argument: name of the result file (*.prxres).
*/
public class ExtractErrors
{
public static void main(String[] args)
{
try
{
// read result file from disk
PerformanceData performanceData = new PerformanceData();
performanceData.readObjectFromFile(args[0]);
// loop over all measured url calls and page breaks
PerformanceDataRecord[] performanceDataRecord = performanceData.getPerformanceDataRecord();
for (int x = 0; x < performanceDataRecord.length; x++)
{
switch (performanceDataRecord[x].getDataType())
{
case PerformanceDataRecord.TYPE_PERFORMANCE_DATA:
// loop over all error snapshots per url call
PerformanceDataRecordFailureInfo[] failureInfo = performanceDataRecord[x].getFailureInfo();
for (int y = 0; y < failureInfo.length; y++)
{
// get data of failed url call
HttpTestURL testURL = performanceDataRecord[x].getFailedUrl(failureInfo[y]);
if (testURL != null)
{
// now we have access to all frozen url data
String fileStartName = "url_" + x + "_error_" + (y + 1);
// write response content to file - no binary data are written
if (testURL.isAsciiContent())
Seite 122 / 138
Deutsche Ausgabe
{
FileOutputStream fout = new FileOutputStream(fileStartName + "_response_content.html");
fout.write(testURL.getDecompressedContent());
fout.close();
}
}
}
break;
case PerformanceDataRecord.TYPE_PAGE_BREAK:
break;
default:
break;
}
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
Seite 123 / 138
Deutsche Ausgabe
14 Web Tools
Aus dem Hauptmenü lässt sich das Web Tools Menü aufrufen welches 4 kleinere Utilities enthält, die Ihnen gegebenenfalls zur Untersuchung der
Kommunikation zwischen Web-Browser und Web-Server nützlich sind. Darüber kann über das Web Tools Menü auch das Page Scanner Tool
aufgerufen werden, mit welchem sich alle Web-Pages einer Web-Site automatisch erfassen lassen.
Die 4 kleineren Utilities bestehen aus:
-
Base64 Text Transformation: führt eine Base64 Transformation bzw.
deren Umkehroperation aus. Der Base64 Algorithmus wird oft
verwendet um CGI Parameter-Werte zu „verschleiern“
-
Escape/Unescape URL/CGI Text Value: führt eine URL-Encoding
Transformation bzw. deren
Umkehroperation aus. Dieser
Algorithmus wird oft dazu
verwendet um Sonderzeichen in
CGI Parameter-Werten zu
maskieren. Auch HTML
Formulare verwenden dies bei
dem Senden der FormularParameter an den Web-Server
-
Examine SSL Configuration of
HTTPS Server - Encryption
Protocols and Algorithms:
untersucht die SSL-Konfiguration
eines HTTPS Web-Servers „von
Aussen“ und gibt Hinweise zu
SSL-Fehlkonfigurationen des
Web-Servers.
-
Test HTTP(S) Request: führt
einen URL-Aufruf aus, dessen
Input „von Hand“ eingegeben
wird. Dient zur Untersuchung des
HTTP Protokoll-Verhaltens des
Web-Servers.
Seite 124 / 138
Deutsche Ausgabe
14.1 Page Scanner
Das Page Scanner Tool (kurz „Page Scanner“ genannt) erlaubt das Einlesen bzw. das automatische Scannen von ganzen Web-Sites inkl. aller darin
enthaltenen Web-Pages auf rekursive Art, analog einem „Web-Spider“ oder „Web-Crawler“ (Suchmaschine).
1. Primärer Anwendungszweck: das Scan-Resultat kann in eine „normale“ Web-Browser Session konvertiert werden aus welcher (wiederum) wie
gewohnt ein Lasttest-Programm erzeugt werden kann (Kapitel 7). Dadurch können für einfache Web-Sites, welche hauptsächliche statischen
Content enthalten, Lasttest-Programme mit einer breiten Abdeckung aller Web-Pages schnell und einfach erzeugt werden – ohne dass eine
manuell vorgenommene Aufzeichnung einer Web-Browser Session Seite-für-Seite durchgeführt werden muss. Das Page Scanner Tool folgt
jedoch nur „gewöhnlichen“ Hyperlinks der eingelesenen Web-Pages und führt keine Formulareingaben durch. D.h. dieses Tool bietet keinen
Ersatz zur Aufzeichnung von Web-Browser Sessions für eigentliche Web-Applikationen.
2. Sekundärer Anwendungszweck: das Tool erstellt eine grafische Statistik über die grössten und auch über die langsamsten Web-Pages der
gesamten Web-Site. Weiterhin werden sog. „Broken Links“, d.h. Hyperlinks ohne gültiges Ziel, automatisch erkannt und rapportiert. Zudem
lassen sich alle eingelesenen Web-Pages nach einem Stichwort-Text durchsuchen.
Das Page Scanner Tool führt keinen JavaScript Code der eingelesenen Web-Pages aus, unterstützt jedoch sämtliche Authentisierungs-Verfahren
welche nicht HTML Formular-basierend sind, wie „Basic Autorisation“, NTLM Authentisierung und SSL Client Zertifikate (im PKCS#12 File-Format). Dies
bedeutet, dass auch zugriffsgeschützte Web-Sites eingelesen werden können. Ebenso werden Cookies automatisch unterstützt.
Hinweis 1: beachten Sie bitte, dass das Page Scanner Tool während eines
Scans sämtliche eingescannte Daten, d.h. alle Web-Pages inklusive deren
Inhalte, in komprimierter Form im temporären Speicherbereich des Programs
hält. Aufgrund der Komprimierung können auch grosse Web-Sites gescannt
werden, jedoch ist der temporäre Speicher nicht unerschöpflich. Falls Sie
während eines Scans die Fehlermeldung "java.lang.OutOfMemoryError" in der
Proxy Sniffer Konsole erhalten, so sollten Sie Proxy Sniffer stoppen und danach
mit 1024 MB temporärem Speicher erneut starten.
Seite 125 / 138
Deutsche Ausgabe
Hinweis 2: Beachten Sie bitte, dass das Page Scanner Tool aufgrund mangelhaft realisierter Web-Pages (des Web Servers) oder aufgrund der
Verwendung von unüblichen oder veralteten HTML-Optionen in Web-Pags gegebenfalls nur unvollständige oder gar keine Resultate liefert. Obwohl
das Tool zuvor ausführlichen Tests unterzogen wurde ist dessen fehlerfreie Funktionalität nicht garantiert. Eventuell aufgetretene, Web-Site oder
Web-Page spezifische Fehler können aufgrund von wiedersprechenden Anforderungen oder aufgrund der Komplexität oft nicht behoben werden.
Das Tool verhält sich im Wesentlichen wie andere Suchmaschinen, welche auch solchen Einschränkungen unterworfen sind.
14.1.1 Eingabe-Parameter, Fortschritts-Anzeige und Abspeichern des Scan-Resultats
Das Page Scanner Fenster besteht aus zwei Teilen. Der obere Teil des Fensters zeigt den aktuellen Fortschritt des
Scans an, bzw. eine kurze Übersicht des Scan-Resultats nach dem Ende des Scans. Im unteren Teil des Fensters
können die Eingabe-Parameter eines Scans gesetzt werden. Von hier aus kann auch ein Scan gestartet werden.
Eingabe-Parameter:
Starting Web Page: URL von welchem aus der Scan gestartet wird. Wird ein
tieferliegendes URL einer Web-Site eingegeben, so werden nur diejenigen
Web-Pages gescannt, welche sich auf der gleichen Ebene oder unterhalb der
Ebene des eingegebenen URLs befinden. Auf diese Weise können auch nur
Teilbereiche einer Web-Site gescannt werden. Beispiel.
http://www.<domain>/sales/customers.html
Char Encoding: erlaubt das Übersteuern der automatischen Erkennung des
auf den Web-Pages verwendenden Zeichensatzes. Bei falsch erstellten WebPages kann es vorkommen, dass der im HTML Header der Web-Pages
spezifizierte Zeichensatz mit dem eigentlichen verwendeten Zeichensatz in den
Web-Pages nicht übereinstimmt. Eventuell kann darum das Page Scanner
Tools den Inhalt solcher Web-Pages nicht auswerten. Sie können in einem
solchen Fall versuchen, die Option “ISO-8859-1” oder “UTF-8” anstelle der
Default-Option “Auto Detect” anzuwenden um dennoch ein Scan-Resultat zu
erhalten.
Exclude Path Patterns: erlaubt gewisse URL-Pfade vom Scan
auszuschliessen, indem ein oder mehrere Ausschluss-Pfad-Fragmente
eingegeben werden. Die Trennung von mehreren Ausschluss-Pfad-Fragmenten
Seite 126 / 138
Deutsche Ausgabe
erfolgt mittels Kommas.
Follow Web Servers: erlaubt den Einbezug von Inhalten weiterer Web-Server in das Scan-Resultat. Diese kann z.B. dann verwendet werden,
wenn alle Bilder einer Web-Site von einem eigenen, separaten Web-Server geliefert werden. Sie können hier eine Liste von zusätzlichen WebServern eingeben, wobei die einzelnen Web-Server durch Kommas getrennt werden.
Beispiel: http://www.<domain1>, https://imgsrv.<domain2>:444. Das Protokoll (http oder https), der Server-Name (üblicherweise “www”) und der
Domain-Name, sowie der TCP/IP Port der zusätzlichen Web-Server werden dabei berücksichtigt. URL-Pfade werden jedoch ignoriert.
Verify External Links: erlaubt die Verifikation aller Hyperlinks zu allen anderen, von der Web-Site aus verlinkten (refernzierten) Web-Servern
bzw. „externen“ URLs. Diese Option wird üblicherweise dazu verwendet um nicht mehr gültige, externe Hyperlinks automatisch zu erkennen und
zu rapportieren (sog. „broken“ Links).
Include: bestimmt, welche zusätzlichen Elemente von Web-Pages nebst den HTML-Elementen in das Scan-Resultat einfliessen (z.B. Bilder und
Flash-Animationen). Um den Daten-Typ eines bestimmten Elements zu bestimmen verwendet Page Scanner ausser bei HTML-Elementen
immer nur die Datei-Erweiterung, welche im URL-Pfad eines Hyperlinks angegeben wurde. Dies erlaubt einen schnellen und effizienten ScanVorgang, birgt aber auch die Gefahr, dass URLs in das Scan-Resultat einfliessen, deren Daten-Typ unerwünscht ist, da dieser nicht
abschliessend zur Laufzeit bestimmt wurde. Sie können jedoch nach dem Ende eines Scan-Vorgangs solche unerwünschte Elemente mit Hilfe
eines Daten-Typ Filters entfernen (Kapitel 14.1.2.1, „remove URLs“ Formular). Folgende Gruppen von Elementen können in den Scan-Vorgang
einbezogen werden:
Element-Gruppe
Entsprechende Datei-Erweiterungen
Images, Flash, CSS, JS .img, .bmp, .gif, .pct, .pict, .png, .jpg, .jpeg, .tif, .tiff, .tga, .ico, .swf, .stream, .css, .stylesheet, .js, .javascript
PDF Documents
.pdf
Office Documents
.doc, docx, .ppt, .pps, .xls, .mdb, .wmf, .rtf, .wri, .vsd, .rtf, .rtx
ASCII Text Files
.txt, .text, .log, .asc, .ascii, .csv
Music and Movies
.mp2, .mp3, .mpg, .avi, .wav, .avi, .mov, .wm, .rm, .mpeg
Binary Files
.exe, .msi, .dll, .bat, .com, .pif, .dat, .bin, .vcd, .sav
Include Options: bestimmt, welche zusätzliche Datei-Erweiterungen von Web-Page Elementen auch in den Scan-Vorgang einbezogen, oder
von diesem ausgeschlossen werden. Dabei muss das Schlüsselwort „-add“ bzw. „-remove“, gefolgt von der Datei-Erweiterung inklusive eines
vorangehenden Punkt-Zeichens (.) eingegeben werden. Beispiel: -remove .gif -add .mp2. Hinweis: dieses Eingabefeld kann allein oder auch
ergänzend zu Include verwendet werden.
Max Scan Time: begrenzt die maximale Zeit eines Scan-Vorgangs.
Seite 127 / 138
Deutsche Ausgabe
Max Web Pages: begrenzt die maximale Anzahl der untersuchten Web-Pages. Bei einem Überschreiten dieser Anzahl wird der Scan-Vorgang
jedoch solange fortgesetzt, bis alle referenzierten „nicht HTML-Elemente“ der bereits eingelesenen Web-Pages auch untersucht wurden (wie z.B.
refernzierte Bilder). D.h. der Abbruch des Scans erfolgt bei einer Überschreitung nicht unmittelbar.
Max Received Bytes: begrenzt das Datenvolumen eines Scan-Vorgangs.
Max URL Calls: begrenzt die Anzahl von URL-Aufrufen (Web-Pages + deren Elemente, einzeln gezählt) eines Scan-Vorgangs.
URL Timeout: begrenzt die Antwortzeit eines einzelnen URL-Aufrufs währen des Scan-Vorgangs. Wird diese Zeit überschritten, so wird für die
entsprechende Web-Page bzw. deren Element der Fehler-Status “keine Antwort vom Web-Server erhalten” gesetzt.
Max Path Depth: begrenzt die maximale URL-Pfad-Tiefe der Web-Pages oder deren Elemente bei einem Scan-Vorgang. Beispiel:
http://www.<domain>/docs/content/about.html hat eine URL-Pfad-Tiefe von 3.
Follow Redirections: begrenzt die maximale Anzahl von (HTTP-) Umleitungen während eines Scan-Vorganges (indirekt referenzierte Elemente
und Web-Pages).
Follow Path Repetitions: begrenzt die Anzahl von URL-Pfad-Repetitionen welche innerhalb eines einzelnen URL-Aufrufes auftreten können.
Diese Option schützt das Page Scanner Tool vor Endlosschlaufen. Empfohlene Wertebereiche sind 1 oder 2. Beispiel: das URL
http://www.<domain>/docs/images/images/images/x.gif hat einen URL-Pfad-Repetitions-Wert von 3.
Follow CGI Parameters: diese (üblicherweise deaktivierte) Option schützt davor, dass eine Vielzahl von weitgehend ähnlichen URL-Aufrufen
vom Page Scanner Tool als jeweils separate URL-Aufrufe behandelt werden. Ist diese Option wie üblich deaktiviert, so wird von mehreren URLAufrufen, welche sich nur durch unterschiedliche CGI-Parameter unterscheiden, nur der erste URL-Aufruf berücksichtigt, jedoch werden alle
weitere, ähnlichen URL-Aufrufe ignoriert. Beispiel: der erstmals aufgetretene URL-Aufruf http://www.<domain>/showDoc?context=12 wird
berücksichtigt, jedoch nachfolgende, ähnliche URL-Aufrufe wie http://www.<domain>/showDoc?context=10 oder
http://www.<domain>/showDoc?context=13 werden nicht berücksichtigt.
Authentication: erlaubt das Scannen von zugriffsgeschützen Web-Sites. Folgende Authentisierungs-Methoden werden unterstützt:
Authentisierungs-Methode
Beschreibung
Basic
Verwendet zur Authentisierung “HTTP Basic Authorization” (Base64 Transformation des Benutzernamens:
Passworts). Geben sie dazu den Benutzernamen und das Passwort in die entsprechenden Eingabefelder ein.
NTLM
Verwendet zur Authentisierung das NTLM-Protokoll. Dabei wird die NTLM-Konfiguration des “Personal
Settings” Menus angewandt (Kapitel 4.6.2.3)
PKCS#12 Client Certificate
Verwendet zur Authentisierung ein HTTPS/SSL Client-Zertifikat. Dabei wird das zuvor geladene, aktive ClientZertifikat des „Personal Settings” Menus angewandt (Kapitel 4.6.2.4)
Seite 128 / 138
Deutsche Ausgabe
Browser Language: diese Option kann beim Scannen von mehrsprachigen Web-Sites angewandt werden um die eine bevorzugte Sprache zu
setzen.
Use Proxy: diese Option erlaubt das Scannen von (externen) Web-Sites über einen abgehenden Proxy-Server (z.B. den Ihrer Firma). Dabei wird
die Proxy-Server Konfiguration des “Personal Settings” Menus angewandt (Kapitel 4.6.2.1).
SSL Version: erlaubt das Setzen der SSL Protokoll-Variante beim Scannen von verschlüsselt übertragenen HTTPS Web-Sites.
Annotation: geben Sie in diesem Eingabefeld einen kurzen Kommentar bezüglich des Scans ein. Diese Eingabe ist optional.
Ein laufender Scan-Vorgang lässt sich jederzeit durch einen Klick auf “Abort Scan” vorzeitig beenden.
Nachdem ein Scan-Vorgange beendet wurde sollten Sie dessen Resultat in
einer Datei abspeichern. Die Datei wird dabei im Project Navigator abgelegt.
Die Datei-Erweiterung ist immer *.prxscn.
Hinweis: ein abgespeichertes Scan-Resultat kann später wieder geladen werden, indem im Project Navigator auf das “Load Scan Icon” der
entsprechenden Datei geklickt wird:
Seite 129 / 138
Deutsche Ausgabe
14.1.2 Analyse des Scan-Resultats
Eine Übersticht der wichtigsten statistischen Daten des Scan-Resultats wird im orange hinterlegten Balken im ganz oben im Fenster dargestellt.
Unterhalb dieses orange hinterlegten Balkens können verschiedene Detail-Resultate ausgewählt werden (im Bild rot umrahmt).
Das Such-Formular, rechts neben der Auswahl der Detail-Resultate, erlaubt das durchsuchen aller gescannten Web-Pages inklusive deren Elemente
nach einem Such-Text. Dabei kann nicht nur über den Dateninhalt sondern auch über alle HTTP Request- und alle HTTP Response-Header gesucht
werden.
Das „remove URLs“ Formular, unterhalb der Auswahl der Detail-Resultate, erlaubt das entfernen von „Mengen“ von unerwünschten URLs aus dem
Scan-Resultat. Die „Menge“ der unerwünschten URLs kann über den Daten-Typ (MIME type) der URLs, sowie logisch verbunden mit einer UNDBedingung über den HTTP Status-Code (200, 302, …) bzw. über einen URL Fehler-Code wie z.B. „network connection failed“ ausgewählt werden.
Eingabefelder:
with content MIME type: bestimmt den gewählten Daten-Typ (MIME type, siehe auch http://www.iana.org/assignments/media-types). Das
Eingabefeld ist „case-insensitive“ (keine besondere Berücksichtigung von Gross- oder Kleinbuchstaben). any bedeutet, dass jeder beliebiger
Seite 130 / 138
Deutsche Ausgabe
Daten-Type gewählt wird. none bedeutet, dass nur solche URLs gewählt werden, deren empfangenes Resultat keinen Daten-Typ enthält (HTTP
Antwort-Header ohne "Content-Type"-Parameter).
HTTP status code: bestimmt den gewählten HTTP Status-Code (200, 302, …) bzw. den URL Fehler-Code.
14.1.2.1
Analyse der Scan-Details
Scan Input Parameter: zeigt alle Input-Daten des ausgeführten Scans an (jedoch ohne Authentisierungs-Daten).
Seite 131 / 138
Deutsche Ausgabe
Scan Statistic: zeigt weitere statistische Daten des Scans an. Similar Web Pages zeigt die Anzahl von gefundenen Web-Pages an, welche
zwar unterschiedliche URL-Pfade haben, jedoch den gleichen Dateninhalt enthalten (duplizierter Inhalt). Failed URL Calls zeigt die Anzahl der
fehlgeschlagenen URL-Aufrufe an, bei denen vom entsprechenden Web-Server gar keine Antwort erhalten wurde, oder deren HTTP StatusCode der Server-Antwort einem Server-seitig aufgetretenen Fehler entspricht (HTTP Status-Codes 400..599).
Non-Processed Web Servers: zeigt eine Liste aller (externen) Web-Server an, welche in Hyperlinks von gescannten Web-Pages zwar
referenziert wurden, jedoch vom Page Scanner Tool nicht weiter berücksichtigt wurden (verlinkte, jedoch nicht nachverfolgte Web Server). Die
Zahl am Anfang jeder Zeile zeigt an, wie oft ein solch (externer) Web-Server referenziert wurde – gezählt über alle gescannten Web-Pages.
Seite 132 / 138
Deutsche Ausgabe
Scan Result per Web Page: zeigt alle gescannte Web-Pages sowie deren Elemente an. Die einzelnen Elemente der Web-Pages wie z.B. Bilder
werden dabei so dargestellt, wie wenn diese von einem Web-Browser gecached würden. Dies bedeutet, dass z.B. ein bestimmtes, gleiches Bild
nur auf einer (der ersten) Web-Page aufgeführt wird, jedoch nicht mehr auf den nachfolgenden Web-Pages, auch wenn die nachfolgenden WebPages dieses (gleiche) Bild wiederum enthalten. Weitere Details zum entsprechenden URL-Aufruf bzw. Element einer Web-Page können durch
einen Klick auf dessen Hyperlink dargestellt werden.
Broken Links: zeigt eine Liste aller fehlgeschlagenen URL-Aufrufe an – sortiert nach Web-Pages.
Seite 133 / 138
Deutsche Ausgabe
Duplicated Content: zeigt eine Liste aller URLs an welche duplizierten (gleichen) Dateninhalt enthalten.
Largest Web Pages: zeigt eine Zusammenstellung der grössten Web-Pages an. Hinweis: Sie können im Diagramm in einen der roten Balken
klicken um die Elemente der entsprechenden Web-Page zu betrachten.
Seite 134 / 138
Deutsche Ausgabe
Slowest Web Pages: zeigt eine Zusammenstellung der langsamsten Web-Pages an. Hinweis: Sie können im Diagramm in einen der roten
Balken klicken um die Elemente der entsprechenden Web-Page zu betrachten.
Seite 135 / 138
Deutsche Ausgabe
14.1.3 Konvertierung des Scan-Resultats in eine Web-Browser Session
Das Scan-Resultat kann in eine „normale“ Web-Browser Session konvertiert werden, aus welcher danach ein Lasttest-Programm erzeugt werden kann.
Eingabe-Felder:
Filename: Datei-Name der Web-Browser Session.
Geben Sie hier einen einfachen Datei-Namen an,
ohne Pfad und ohne Datei-Erweiterung. Die DateiErweiterung ist immer *.prxdat. Die Datei wird im
gewählten Directory des Project Navigators
abgespeichert.
Web Pages: erlaubt eine Auswahl derjenigen WebPages, welche in die Web-Browser Session
einfliessen. „All Pages“ bedeutet alle Web-Pages.
Alternativ dazu können Sie die Option „Page
Ranges“ verwenden, bei der Sie eine Liste von
ausgewählten Web-Pages eingeben können.
Beispiel: "1, 3-5, 7, 38-81"
Max. URL Calls: begrenzt die Anzahl von URLAufrufen welche in die Web-Browser Session
einfliessen. Hinweis: es wird empfohlen, dass Sie
nicht mehr als 1000 URL-Aufrufe in eine WebBrowser Session konvertieren.
Annotation: diese Eingabe ist optional. Wir empfehlen Ihnen jedoch, dass Sie hier eine paar Stichworte zur Beschreibung der Web-Browser
Session eingeben.
Seite 136 / 138
Deutsche Ausgabe
Load Session into: Falls diese (Default-Option) gesetzt ist, wird die Web-Browser Session nach dem Abspeichern noch zusätzlich in das „MainMenü geladen, bzw. alternativ in eine Scratch-Area des Session Cutters.
Üblicherweise wird nach dem Abspeichern die Web-Browser
Session direkt in das „Main Menü“ geladen. Sie können
danach diese zuerst Nachbearbeiten (Kapitel 4.4, 5 und 6)
und dann das entsprechende Lasttest-Programm erzeugen
(Kapitel 7).
Seite 137 / 138
Deutsche Ausgabe
15 Hersteller und Support
Ingenieurbüro David Fischer GmbH
Mühlemattstrasse 61
CH-3007 Bern
Switzerland
Produkt-Homepage:
E-Mail:
Tipp: Wir empfehlen Ihnen bei Unklarheiten auch dem
integrierten, Menü-spezifische Help-Text durchzusehen:
http://www.proxy-sniffer.com
[email protected]
Wir bitten Sie, zusätzlich auch das Application Reference Manual
kurz durchzusehen, um einen Überblick über weiteren ProduktEigenschaften und -Features zu erhalten.
Seite 138 / 138

Proxy Sniffer V4.1-C User`s Guide Deutsche Ausgabe

Transcrição

Documentos relacionados

VPN unter MAC OS X

Bilder-Galerien

28.06.2006

Proxy Sniffer V4.0

Ingenieurbüro Marcus Schmidt Bauvorhaben Flugplatz Schleißheim

Kawasaki zrx1100 metal mulisha Jahrgang 1999 KOMPLETTUMBAU:

VPN unter Ubuntu

Liste über die in Baden-Württemberg anerkannten

Kurzfassung Büttiker Graf

Projektautomatisierung