Web Server Benchmarking Evaluation von Werkzeugen und Durchführung von Fallstudien

Größe: px
Ab Seite anzeigen:

Download "Web Server Benchmarking Evaluation von Werkzeugen und Durchführung von Fallstudien"

Transkript

1 Diplomarbeit Wirtschaftsinformatik DII Web Server Benchmarking Evaluation von Werkzeugen und Durchführung von Fallstudien Vorgelegt dem Fachbereich Wirtschaftswissenschaften der Universität Gesamthochschule Essen von: Ingo Breker Venner Str Mönchengladbach Matrikelnummer: Erstgutachter: Zweitgutachter: Prof. Dr. B. Müller Clostermann Prof. Dr. G. Neumann Sommersemester 1999, 12. Studiensemester Voraussichtlicher Studienabschluß: Sommersemester 1999

2 Inhaltsverzeichnis I Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis Formelverzeichnis I III IV V VI 1 Einleitung 1 2 Leistungsaspekte von Web Servern Begriffe Architektur von Lastgeneratoren für Web Server HTTP Performance Web Server Architektur Workload Charakterisierung Modellierungsansätze für Web Server Weitere Themen des Web Server Benchmarkings 22 3 Anforderungen an Web Server Performancetesttools Allgemeine Anforderungen an ein Performancetesttool Internetspezifische Anforderungen 27 4 Evaluation der Werkzeuge Einleitung Testfälle LoadRunner PerformanceStudio SilkPerformer WebLoad

3 Inhaltsverzeichnis II 4.7 e Load Vergleich der Werkzeuge 59 5 Vorgehensmodell Testplanung Erstellen von Testskripten Erstellen von Szenarien Erzeugen der Last und Erfassen der Meßdaten Auswerten der Ergebnisse 67 6 Fallstudien Fallstudie 1: Vergleich IIS vs. Apache Fallstudie 2: Vergleich WWW Server vs. Mapkit Server 77 7 Zusammenfassung und Ausblick 81 Literaturverzeichnis 83 Index 89 Anhang A: Beispielskripte 91 A.1 SilkPerformer 91 A.2 PerformanceStudio 92 A.3.1 LoadRunner (VUGen) 99 A.3.2 LoadRunner (Astra QuickTest) 99 A.4 WebLoad 101 Anhang B: Tuningeinstellungen des IIS und Apache Web Servers 102 B.1 Apache 102 B.2 IIS 103 Eidesstattliche Versicherung 109

4 Abbildungsverzeichnis III Abbildungsverzeichnis ABBILDUNG 1 WACHSTUM DER ANZAHL DER ONLINENUTZER NACH DATAMONITOR...1 ABBILDUNG 2 DEFINITION VON DENKZEIT, REAKTIONSZEIT UND ANTWORTZEIT ([MENA98, S. 68]).4 ABBILDUNG 3 ÜBERSICHT ÜBER LEISTUNGSBEWERTUNGSTECHNIKEN ([BMC98])...11 ABBILDUNG 4 SYMBOLE VON WARTESCHLANGENSTATIONEN...12 ABBILDUNG 5 WARTESCHLANGENMODELLE NACH GUNTHER...13 ABBILDUNG 6 WARTESCHLANGENMODELL EINES WEB SERVERS NACH SLOTHOUBER...14 ABBILDUNG 7 ANTWORTZEIT VS. ANZAHL REQUESTS PRO ZEITEINHEIT...16 ABBILDUNG 8 CLIENTSEITIGE WARTESCHLANGENMODELLE ([MENA98, S.230])...18 ABBILDUNG 9 SERVERSEITIGE WARTESCHLANGENMODELLE ([MENA98, S.240])...21 ABBILDUNG 10 SCREENSHOT DES ASTRA QUICKTESTS...34 ABBILDUNG 11 SCREENSHOT DES LOADRUNNER CONTROLLER...35 ABBILDUNG 12 SCREENSHOT DES LOADRUNNER ANALYSIS...37 ABBILDUNG 13 SCREENSHOT DES PERFORMANCESTUDIOS WÄHREND EINES LASTTESTS...41 ABBILDUNG 14 SCREENSHOT DES PERFORMANCE REPORTS DES PERFORMANCESTUDIOS...42 ABBILDUNG 15 SCREENSHOT DES RECORDERS DES SILKPERFORMERS...45 ABBILDUNG 16 SCREENSHOT DER SKRIPTING UMGEBUNG DES SILKPERFORMERS...46 ABBILDUNG 17 SCREENSHOT DES SILKPERFORMERS WÄHREND EINES LASTTESTS...47 ABBILDUNG 18 SCREENSHOT DER ANALYSEKOMPONENTE DES SILKPERFORMER...48 ABBILDUNG 19 SCREENSHOT DES AAT VON WEBLOAD...51 ABBILDUNG 20 SCREENSHOT DES WEBLOAD MASTERS WÄHREND DES LASTTESTS...52 ABBILDUNG 21 SCREENSHOT DES E TESTERS...56 ABBILDUNG 22 SCREENSHOT DER SZENARIOERSTELLUNG MIT E LOAD...57 ABBILDUNG 23 SCREENSHOT DER STATISTIKSEITE VON E LOAD...58 ABBILDUNG 24 MEßUMGEBUNG DES VERGLEICHSTESTS IIS VS. APACHE...69 ABBILDUNG 25 ANZAHL WEB ERRORS DER STATISCHEN SEITEN DES TESTS IIS VS. APACHE...72 ABBILDUNG 26 MEßERGEBNISSE DER STATISCHEN SEITEN DES TESTS IIS VS. APACHE...73 ABBILDUNG 27 GESAMTE ANTWORTZEIT DES STATISCHEN/DYNAMISCHEN TESTS IIS VS. APACHE.74 ABBILDUNG 28 AUFSCHLÜSSELUNG DER STATISCHEN UND DYNAMISCHEN ANTWORTZEIT...74 ABBILDUNG 29 CPU AUSLASTUNG BEIM STATISCHEN/DYNAMISCHEN TEST...75 ABBILDUNG 30 WEB ERRORS BEIM STATISCHEN/DYNAMISCHEN TEST...75 ABBILDUNG 31 MEßUMGEBUNG DES VERGLEICHSTESTS MAPKIT SERVER VS. WWW SERVER...77 ABBILDUNG 32 MEßERGEBNISSE DES WEBSTONE TEST VON MAPKIT UND WWW SERVER...79 ABBILDUNG 33 WEB ERRORS DES WEBSTONE TESTS VON MAPKIT UND WWW SERVER...80 ABBILDUNG 34 CPU UND NETZWERKBELASTUNG DES MAPKIT SERVERS...80 ABBILDUNG 35 SCREENSHOT DER ANWENDUNGSKONFIGURATION DES INTERNETDIENST MANAGERS ABBILDUNG 36 SCREENSHOT DER ISAPI FILTER DES INTERNETDIENST MANAGERS ABBILDUNG 37 SCREENSHOT DER WEBSITE EIGENSCHAFTEN IM INTERNETDIENST MANAGERS..107 ABBILDUNG 38 SCREENSHOT DER LEISTUNGSMERKMALE IN DEN SYSTEMEIGENSCHAFTEN ABBILDUNG 39 SCREENSHOT DER EINSTELLUNG DER SYSTEMLEISTUNG IM INTERNETDIENST MANAGERS ABBILDUNG 40 SCREENSHOT DER PROTOKOLLOPTIONEN DES INTERNETDIENST MANAGERS...108

5 Tabellenverzeichnis IV Tabellenverzeichnis TABELLE 1 ZUWACHS DER EUROPÄISCHEN INTERNET HOSTS NACH RIPE...2 TABELLE 2 ERKLÄRUNG DER PARAMETER DER KENDALL NOTATION...12 TABELLE 3 ERKLÄRUNG DER VARIABLEN IM WEB SERVERMODELL NACH SLOTHOUBER...15 TABELLE 4 ERKLÄRUNG DER VARIABLEN IM NETZWERKMODELL NACH HEIDEMANN ET AL...17 TABELLE 5 ERKLÄRUNG DER INPUT PARAMETER DER WARTESCHLANGENMODELLE ([MENA98]).20 TABELLE 6 BEISPIELRECHNUNG EINES CLIENTSEITIGEN MODELLS OHNE PROXY SERVER ([MENA98], S. 234)...20 TABELLE 7 BEISPIELRECHNUNG DES SERVERSEITIGEN MODELLS OHNE FILE SERVER ([MENA98], S. 243)...21 TABELLE 8 KATEGORISIERUNG DER VARIABLEN DER MODELLE AUS [MENA98] NACH DER QUELLE...22 TABELLE 9 HARD UND SOFTWAREANFORDERUNG AN LOADRUNNER...33 TABELLE 10 AUSWERTUNGSMÖGLICHKEITEN DES LOADRUNNERS...36 TABELLE 11 ANTWORTZEITEN DER MAPKIT TESTS MIT LOADRUNNER...37 TABELLE 12 HARD UND SOFTWAREANFORDERUNG AN DAS PERFORMANCESTUDIO...40 TABELLE 13 ANTWORTZEITEN DER MAPKIT TESTS MIT DEM PERFORMANCESTUDIO...43 TABELLE 14 HARD UND SOFTWAREANFORDERUNG AN DEN SILKPERFORMER...44 TABELLE 15 ANTWORTZEITEN DER MAPKIT TESTS MIT SILKPERFORMER...49 TABELLE 16 HARD UND SOFTWAREANFORDERUNG AN WEBLOAD...50 TABELLE 17 ANTWORTZEITEN DER MAPKIT TESTS MIT WEBLOAD...53 TABELLE 18 HARD UND SOFTWAREANFORDERUNG AN E LOAD...55 TABELLE 19 ANTWORTZEITEN DER MAPKIT TESTS MIT E LOAD...58 TABELLE 20 ERFÜLLUNG DER ANFORDERUNGEN DURCH DIE EVALUIERTEN TOOLS...59 TABELLE 21 PREISE DER TOOLS, UNTERSCHIEDEN NACH ANZAHL VIRTUELLER BENUTZER...61 TABELLE 22 ERGEBNISSE DER MAPKIT TESTS IM ÜBERBLICK...62 TABELLE 23 WORKLOADCHARAKTERISTIK DES WEBSTONE BENCHMARKS...70 TABELLE 24 UNTERSCHIEDE IN DEN VORAUSSETZUNGEN ZWISCHEN DER FALLSTUDIE 1 UND [MIND99]...76

6 Formel-/Abkürzungsverzeichnis V Abkürzungsverzeichnis Abkürzung Erklärung AAT Agenda Authoring Tool ACK Acknowledgement ADSL Asymmetric Digital Subscriber Line API Application Program Interface ASCII American Standard Code for Information Interchange ASP Active Server Pages BDL Benchmark Definition Language C/S Client/Server CGI Common Gateway Interface CICS Customer Information Control System CPU Central Processing Unit CSS Cascade Style Sheets DCOM Distributed Component Object Model DE-NIC Deutsches Network Information Center DM Deutsche Mark EIDE Enhanced Integrated Drive Electronics ERP Enterprise Resource Planning FIFO First In First Out FTP File Transfer Protocol GB Gigabyte GIF Graphics Interchange Format GUI Graphical User Interface HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS Secure Hypertext Transfer Protocol IIOP Internet Inter-ORB Protocol IIS Internet Information Server ISBN International Standard Book Number ISDN Integrated Services Digital Network ISP Internet Service Provider JPEG Joint Photographic Experts Group KB Kilobyte KBit Kilobit LAN Local Area Network LDAP Lightweight Directory Access Protocol MB Megabyte MBit Megabit MIPS Million Instructions Per Second MNG Multiple Image Network Graphics MSS Maximum Segment Size NIC Network Information Center NNTP Network News Transfer Protocol ODBC Open Database Connectivity OEM Original Equipment Manufacturer ORB Object Request Broker PCI Peripheral Component Interconnect PNG Portable Network Graphics POP3 Post Office Protocol 3 PS Processor Sharing QA Quality Assurance

7 Formel-/Abkürzungsverzeichnis VI RE RIPE RTE RTT SMTP SPEC SQL SSL TCP/IP TPS UDP URL VU WAN WWW Requirement Réseaux IP Européens Remote Terminal Emulation Round Trip Time Simple Mail Transfer Protocol Standard Performance Evaluation Corporation Structured Query Language Secure Socket Layer Transmission Control Protocol / Internet Protocol Transactions Per Second User Datagram Protocol Uniform Resource Locator Virtual User Wide Area Network World Wide Web Formelverzeichnis FORMEL 1 ANTWORTZEIT DES WEB SERVERMODELL NACH SLOTHOUBER...14 FORMEL 2 ANTWORTZEIT FÜR EINEN OPTIMALEN REQUEST NACH HEIDEMANN ET AL FORMEL 3 ANTWORTZEIT FÜR EINEN TCP REQUEST NACH HEIDEMANN ET AL...17 FORMEL 4 ZEIT FÜR EINE SERIE VON TCP REQUESTS NACH HEIDEMANN ET AL...17

8 Kapitel 1: Einleitung 1 1 Einleitung Das Internet ist momentan eines der dynamischsten Schauplätze der Informationstechnik. Es ist dabei, den Schritt vom militärischen Forschungsnetzwerk zu einem Massenmedium zu vollziehen. Nahezu monatlich werden neue Techniken oder Standards vorgestellt oder neue Schlagwörter geprägt. Die Anzahl der Nutzer und der Web Server ist seit Anfang der 90 er Jahre explodiert und wird auch in Zukunft steigen, wie folgende Studien belegen: Nach einer Studie von Datamonitor [Data99a] vom März 1999 wächst die Zahl der Internetbenutzer weltweit von 170 Millionen Benutzern 1999 auf 250 Millionen Benutzer 2003 und 300 Millionen Benutzern im Jahr Abbildung 1 Wachstum der Anzahl der Onlinenutzer nach Datamonitor Nach einer weiteren Studie von Datamonitor [Data99b] wächst der Geldbetrag, den Internetnutzer auf europäischen Web Sites ausgeben, von 770 Mio. Dollar 1999 auf Mio. Dollar 2002, was einer Steigerung um das 6,5fache entspricht. In Deutschland steigt der Betrag von 350 Mio. Dollar auf Mio. Dollar, eine Steigerung um das 5,5fache [Data99c]. Zufolge des GfK Onlinemonitors ist die Anzahl der Onlinenutzer in Deutschland von 10,3 Mio. laut [Gfk98] Anfang 1998 auf 13 Mio. laut [Gfk99] Anfang 1999 gestiegen. Das entspricht ca neuen Onlinenutzern in Deutschland pro Tag. Nach der Zählung des RIPE (Réseaux IP Européens) [Ripe99] ist die Anzahl der europäischen Hosts im Internet von Januar 1992 bis April 1999 um knapp das 60- fache gestiegen. In Tabelle 1 ist der Zuwachs der Internet Hosts vom Dezember

9 Kapitel 1: Einleitung 2 des jeweiligen Jahres zum Dezember des Vorjahres abgebildet Tabelle 1 Zuwachs der europäischen Internet Hosts nach RIPE Nach der Zählung des DE NIC (Deutsches Network Information Center) [Nic99] ist die Anzahl der Top Level Domains Deutschlands von im Dez über im Dez über Dez auf Dez gestiegen. Im April 1999 lag der Wert schon bei Top Level Domains. Aus der Tatsache, daß die Anzahl der Benutzer des Internets stark steigt, entsteht auch eine zunehmende Belastung der Web Server. Ein zweiter Grund für eine steigende Belastung eines Web Servers besteht darin, daß der Bekanntheitsgrad einer Web Site meist kontinuierlich steigt und so mehr Nutzer anzieht, wie in [Manl97b] dargestellt. Zum dritten stehen durch den kontinuierlichen Ausbau des Datennetzes größere Bandbreiten zur Verfügung, wie z.b. durch T DSL von T Online 1, so daß der Web Server zunehmend der Flaschenhals werden kann. Diese zunehmende Belastung eines Web Servers ist die Hauptmotivation für das Web Server Benchmarking. Wenn ein Web Server zum Zeitpunkt X ausreichend schnell ist, besteht keine Sicherheit, daß dies nach einem halben Jahr immer noch so ist. Nun gibt es interne Leistungsmaße für die Komponenten des Web Servers, wie MIPS für die CPU, Übertragungsrate und Positionierungszeit für die Festplatte und Bandbreite für das Netzwerk. Warum reichen diese Angaben nicht aus? Ein Web Server ist ein komplexes System, das nicht an den einzelnen internen Leistungsmaßen gemessen werden kann, sondern als eigenständiges Produkt behandelt werden muß. Es gibt hauptsächlich drei Leistungsmaße: Antwortzeit, Durchsatz und Auslastung des Web Servers. Mit Hilfe des Web Server Benchmarkings möchte man die Frage beantworten: Ist das System leistungsfähig genug für meine Ansprüche?. Warum nun aber spezielle Benchmarks für Web Server? Im Grunde ist ein Web Server auf den ersten Blick nichts anderes als ein herkömmlicher File Server in 1

10 Kapitel 1: Einleitung 3 einer C/S Umgebung. Er beinhaltet unter anderem HTML Seiten, Grafiken, evtl. Video oder Musikdateien. Trotzdem gibt es große Unterschiede, die es wert sind, einen Web Server als eigene Kategorie zu betrachten. Zum ersten kommen beim File Server nur statische Abrufe vor, er muß im Gegensatz zum Web Server keine Dateien dynamisch erzeugen, beispielsweise über CGI Skripte,. Dann wäre da noch der Unterschied in der Anzahl der potentiellen Benutzer. Im Gegensatz zu einer C/S Umgebung kann bei einem Web Server eine sinnvolle Obergrenze nicht festlegt werden. Als drittes kommt hinzu, daß bei einem Web Server sogenannte Bursts, d.h. Leistungsspitzen, auftreten können, die dadurch hervorgerufen werden, daß viele Personen gleichzeitig den Web Server benutzen. Außerdem ist die Verteilung der Dateigrößen auf den Web Servern meist eine heavy tailed distribution. Auf diese und andere Punkte, die mit den speziellen Anforderungen des Web Server Benchmarkings in Berührung stehen, wird detailliert im Kapitel 2 eingegangen. Dort werden auch kurz die Modellierungsansätze für Web Server skizziert. Das darauf folgende Kapitel stellt einen Anforderungskatalog an ein Performancetesttool für Web Server auf. Dabei wird nach generellen Anforderungen und Anforderungen, die speziell für einen Web Server gelten, unterschieden. Auf der Grundlage der Anforderungen werden im Kapitel 4 die Performancetesttools evaluiert. Die Werkzeuge werden kurz beschrieben und es werden drei kleinere Fallstudien durchgeführt. Um ein Performancetesttool sinnvoll einsetzen zu können, benötigt man ein Vorgehensmodell, welches im Kapitel 5 vorgestellt wird. Auf der Basis dieses Vorgehensmodells werden im nachfolgenden Kapitel zwei Fallstudien durchgeführt. Das Kapitel 7 faßt die Ergebnisse zusammen und gibt einen Ausblick auf die Zukunft des Web Server Benchmarkings.

11 Kapitel 2: Leistungsaspekte von Web Servern 4 2 Leistungsaspekte von Web Servern 2.1 Begriffe In diesem Unterkapitel werden nachfolgend einige wichtige Begriffe definiert. Unter einem Webobjekt wird ein Objekt, das auf einem Web Server liegt und über das Internet zugänglich ist, verstanden. Webobjekte können beispielsweise HTML Dokumente, GIF oder JPEG Grafiken oder auch Video oder Audiodateien sein. Wenn im folgenden von einem Web Server die Rede ist, ist damit nicht nur das Programm, wie z.b. Apache oder IIS, gemeint. Unter einem Web Server wird in dieser Arbeit neben dem Web Server Programm und dem Rechner, auf dem das Web Server Programm läuft, auch die Server verstanden, die das Web Server Programm benutzt. Darunter fallen beispielsweise Datenbankserver, Applikationsserver (Tuxedo, CICS) oder Mainframes. Die Definition von Denkzeit, Reaktionszeit und Antwortzeit (Response Time) wird in Abbildung 2 graphisch dargestellt. Ende der vorherigen Response t 0 Browser sendet Request t 1 Response beginnt einzutreffen t 2 Ende der Response t 3 Denkzeit Reaktionszeit Antwortzeit Abbildung 2 Definition von Denkzeit, Reaktionszeit und Antwortzeit ([Mena98, S. 68]) Ein Lastgenerator ist ein Programm, das auf einem Rechner einen oder mehrere Benutzer simuliert, welche die vom Anwender des Performancetesttools vorgegebenen Anweisungen abarbeiten. Diese simulierten Benutzer werden in dieser Arbeit virtuelle Benutzer genannt. Die vom Anwender des Performancetesttools vorgegebenen Anweisungen für einen virtuellen Benutzer werden als Testskript

12 Kapitel 2: Leistungsaspekte von Web Servern 5 bezeichnet. Der Begriff Benchmark trifft die Möglichkeiten der hier evaluierten Werkzeuge nicht genau. In [Mena98, S. 297] wird Benchmarking als Running a set of standard programs on a machine to compare it s performance with that of others bezeichnet, in [RaLT98, Glossary 1] steht zu Benchmark: In performance testing, a fixed workload that testers compare against other workloads, to determine the performance of different system configurations. Prominente Beispiele für Benchmarks sind SpecWeb96 2 von der SPEC Gruppe, WebStone 3 von Mindcraft oder WebBench 4 von dem Verlag Ziff Davis. Die Benchmarks erscheinen sinnvoll, wenn man bestimmte Hard und Softwarekonfigurationen vergleichen will, ohne diese selber zu testen. Eine Problematik bei den Benchmarks liegt jedoch darin, daß der Server durch eine festgelegte synthetische Last getestet wird. Es gibt jedoch keine Gewähr dafür, daß der Server unter den realen Bedingungen die erwartete Leistung bringt. Ein Beispiel dafür ist der SpecWeb96, der keine dynamisch erzeugten Seiten enthält und nur statische Seiten vom Server lädt. Dynamisch erzeugte Seiten stellen jedoch ganz andere Anforderungen an den Prozessor des Web Servers, da das Webobjekt vor der Antwort auf den Request noch erzeugt werden muß 5. Ein anderes Problem ist, daß die Web Server speziell für diese Tests mit einem erheblichen Aufwand getunt werden. Weil die nachfolgend evaluierten Werkzeuge aber nicht von einem fest vorgegebenen Workload ausgehen müssen, wird in der vorliegenden Arbeit der Begriff Performancetest statt des Begriffes Benchmark benutzt. Ein Performancetest benutzt keinen festen Workload, sondern einen von dem Benutzer auf seine Bedürfnisse angepaßten Workload. Desweiteren ist das Ziel eines Performancetests nicht unbedingt der Vergleich mehrerer Systeme. Im LoadRunner Handbuch werden mehrere Testziele aufgeführt [MeCo98, 24]: 2 siehe 3 siehe 4 siehe 5 Ein Beispiel für die Unterschiede zwischen dynamischer und statischer Last findet man unter Server98/numbers.html ff.

13 Kapitel 2: Leistungsaspekte von Web Servern 6 Messung der Server Antwortzeit Optimale Hardwarekonfiguration Zuverlässigkeit Testen von Software /Hardwareupgrades Evaluieren neuer Produkte Messen der Systemkapazität Flaschenhals identifizieren Ein weiteres Testziel kann noch hinzugefügt werden, der contention test [RaLT98, 1 9]. Hierbei werden Nonvisual User und Visual User kombiniert. Ein Nonvisual User ist ein simulierter Benutzer, der keine Ausgabe auf die GUI macht und so nur die Server Antwortzeit mißt, während ein Visual User die Ergebnisse mit dem zu testenden Programm ausgibt und so die Antwortzeit des Clients mißt. Im Fall des contention tests führen die Nonvisual User bestimmte Transaktionen, wie z.b. das Einfügen, Ändern und Löschen von Datensätzen in einer Tabelle auf dem Server aus. Die Visual User versuchen ihre ähnlichen Transaktionen korrekt durchzuführen. Es sollen damit Deadlock Situationen und Fehler in der Nebenläufigkeit entdeckt werden. Der contention test ist also eher unter dem Punkt funktionales Testen anzusiedeln, kann aber dennoch als ein Anwendungsgebiet der Performancetesttools angesehen werden. 2.2 Architektur von Lastgeneratoren für Web Server In [Bang97] wird eine neue Methode für das Generieren von HTTP Requests vorgestellt. Drei Probleme treten bei herkömmlichen Benchmarks auf : Es ist schwierig, Overload Situationen des Web Servers, die durch Bursts von HTTP Requests entstehen, synthetisch herzustellen. Die Verzögerungen des WAN werden nicht gut dargestellt. Wenn zuviele Clients simuliert werden müssen, kann der Lastgenerator den Flaschenhals darstellen. Um Burst Situationen zu erzeugen, sollte ein Client, der sog. S Client, aus einem connection establishing process und einem connection handling process

14 Kapitel 2: Leistungsaspekte von Web Servern 7 bestehen. Der connection establishing process hat einen Pool von nicht aktiven Verbindungen. Er stellt in konstanten Abständen eine TCP Verbindung her, sendet einen HTTP Request ab und übergibt die TCP Verbindung in einen Pool von aktiven Verbindungen. Der connection handling process empfängt die Daten von den aktiven Verbindungen aus dem Verbindungs Pool und schließt die Verbindungen nach Beendigung. Das Problem der WAN Verzögerungen wird über ein Zwischenschalten eines Routers gelöst, der die Pakete künstlich verzögert. Weitere Literatur zu diesem Thema bieten die Autoren der Benchmarks hbench:web [Manl97a] bzw. [Manl98], Surge [Crov97] und httperf [Mosb97] an. 2.3 HTTP Performance In den Aufsätzen dieses Unterkapitels liegt der Schwerpunkt auf der Untersuchung der Performanceaspekte des HTTP Protokolls. In [Sper94] wird die zeitliche Abfolge der TCP Requests, die aus einem HTTP Request entstehen, untersucht. Durch das Verhalten von HTTP/1.0, für jeden Request eine neue TCP Verbindung zu eröffnen, leidet die Performance bei kleinen Webobjekten stark. Der Grund hierfür ist beim Slowstart Algorithmus der TCP Implementationen zu suchen. Slowstart soll die Window Größe der TCP Verbindung bestimmen und verhindern, daß zuviele Pakete das Netzwerk überfluten, auch congestion avoidance genannt. Slowstart beginnt mit einer Window Größe von eins, d.h. ein Paket darf abgeschickt werden, ohne ein ACK der Gegenstelle. Wenn dieses Paket nicht verloren geht, wird die Window Größe solange erhöht, bis ein Paket verloren geht. Weil HTTP/1.0 jedoch immer nur eine TCP Verbindung nutzt, ist die Window Größe relativ klein, dadurch kommt es zu einem großen Overhead bei der Kombination TCP und HTTP/1.0. Wenn, wie in [Sper94] dargelegt, zehn Webobjekte der Größe 1668 Bytes mit zehn TCP Verbindungen angefordert werden, dauert die Übertragung 5,3 Sekunden, bei einer TCP Verbindung 1,2 Sekunden. Eine weiteres Problem von HTTP/1.0 liegt darin, daß der Web Server die TCP Verbindungsinformationen eine gewisse Zeit speichern muß. Diese Zeit wird in den TCP Implementationen von Unix über TCP_TIME gesetzt. Dadurch kann es

15 Kapitel 2: Leistungsaspekte von Web Servern 8 bei vielen TCP Verbindungen zu einem hohen Ressourcenverbrauch auf dem Web Server kommen. In [Padm94] wird wie in [Sper94] versucht, die Latenzzeiten von HTTP/1.0 zu erklären. Die Latenz wird durch die Round Trip Time (RTT) definiert. Die RTT ist die Zeit, die benötigt wird, um ein Paket von einem Ende der Verbindung zum anderen Ende und zurück zu schicken. Darüber hinaus werden Verbesserungsvorschläge für das HTTP Protokoll wie z.b. persistente und pipelined Verbindungen gemacht und Experimente mit den verbesserten Protokollen durchgeführt. In [Li97] wird die Performance von HTTP/1.0 zwischen LAN und Modem mit Hilfe der Latenz verglichen. Der Workload besteht aus drei Dateien, die 5 KB, 22 KB und 68 KB groß sind. Im LAN liegt der prozentuale Anteil der Latenzzeit an der Gesamtzeit zwischen 14% und 31%, beim Modem zwischen 1% und 1,6%. Auffällig ist, daß bei der LAN Verbindung das Öffnen der TCP Verbindung schneller wird, je größer die zu übertragende Datei ist. In [Touc96] oder [Ruba96] wird ein ähnlicher Themenkreis behandelt, wie in den drei bisher genannten Aufsätzen. In der Spezifikation von HTTP/1.1 [Fiel97, S.43] vom Januar 1997 wird auf die Forderung von [Padm94] nach einer persistenten Verbindung, dem Keep Alive Mechanismus, eingegangen. In [Frys97] wird auf die Unterschiede zwischen HTTP/1.0 und HTTP/1.1 hingewiesen. Es werden die Performance zwischen HTTP/1.0 mit vier TCP Verbindungen, HTTP/1.1 mit einer persistenten Verbindung, HTTP/1.1 mit einer pipelined Verbindung und HTTP/1.1 mit einer pipelined Verbindung mit Datenkompression gemessen. Desweiteren werden Tips gegeben, wie die Geschwindigkeit durch Verwendung von CSS und den neuen Grafikformaten PNG und MNG gesteigert werden kann.

16 Kapitel 2: Leistungsaspekte von Web Servern 9 In [Crov98a] wird die Leistung von HTTP/1.0 und von HTTP/1.1 auf einem Apache und einem IIS Web Server anhand von Durchsatz und Latenz verglichen. Dabei wird jeweils das Netzwerk, die CPU und die Festplatte als Flaschenhals angesehen. Wenn das Netzwerk der Flaschenhals ist, ist HTTP/1.1 durch die persistenten Verbindungen besser als HTTP/1.0. Dabei wird im Gegensatz zu [Frys97] festgestellt, daß pipelined connections keinen großen Einfluß auf die Latenz des Dateitransfers haben. In [Frys97] werden pro HTML Seite 43 eingebettete Webobjekte angenommen, in [Crov98a] durchschnittlich nur 3,3 Webobjekte pro HTML Seite, dadurch werden die Unterschiede der Studien erklärt. Wenn die CPU der Flaschenhals ist, besteht kein großer Unterschied zwischen HTTP/1.0 und HTTP/1.1, daß heißt, daß die neuen Features von HTTP/1.1 die CPU nicht wesentlich mehr belasten. Durch die Reduzierung des Hauptspeichers wird die Festplatte zum Flaschenhals, zum einen, weil die Webobjekte nicht mehr gecached werden können, zum anderen, weil mehr virtueller Speicher beansprucht wird. In diesem Fall ist HTTP/1.0 dem HTTP/1.1 überlegen, weil durch die persistenten Verbindungen mehr Speicher verbraucht wird. Der Grund des höheren Speicherverbrauchs liegt darin, daß HTTP/1.1 bei den persistenten Verbindungen die TCP Verbindung auch während der Ruhezeiten aufrecht erhält. 2.4 Web Server Architektur McGrath [McGr95] vergleicht mehrere HTTP Daemons mit unterschiedlicher Konfiguration miteinander. Das Ergebnis ist, daß Server mit preforking einen besseren Durchsatz, mehr connections per second, geringere RTT s, weniger CPU Belastung, weniger Speicherverbrauch und weniger Systemaufrufe haben. Preforking bedeutet, daß die Web Server Prozesse in einem Pool auf die HTTP Requests warten, im Gegensatz zum Forking, wo für jeden einkommenden HTTP Request ein neuer Web Server Prozeß gestartet wird. Einschränkend ist zur dieser Studie jedoch zu sagen, daß nur maximal acht Clients eine 100 Byte große Datei anfordern und so keine realen Lasten simuliert wurden. In einer späteren Studie [McGr96a] hat McGrath vier Plattformen miteinander

17 Kapitel 2: Leistungsaspekte von Web Servern 10 verglichen. Als Last werden hier drei statische HTML Seiten, drei Perl Skripte und drei C Programme benutzt. Im ersten Experiment wird die Performance der statischen Seiten mit der Performance der Perl und C Skripte verglichen. Als zweites vergleicht er die Performance der Requests an den Web Server direkt oder über den Unix Daemon inetd. Als letztes wurden die Performanceunterschiede zwischen forking, preforking und multithreading Web Servern verglichen. 2.5 Workload Charakterisierung In [Alme96] wird ein neuer Webmonitor vorgestellt, es werden jedoch auch kurz zwei Besonderheiten eines Web Servers charakterisiert, die heavy tailed distribution der Dateigrößen und die Kurzlebigkeit der Prozesse bei Web Servern mit forking. In [Crov95] wird die Selbstähnlichkeit des Netzwerkverkehrs bei starker Belastung des Netzwerks gezeigt. Die Entstehung der Selbstähnlichkeit liegt zum einen daran, daß die Übertragungszeiten einer heavy tailed distribution, z.b. Pareto Verteilung, genügen. Zum zweiten sind auch die silent times, die Ruhezeiten, heavy tailed distributed. In [Park96] wird gezeigt, daß die Selbstähnlichkeit des Netzwerkverkehrs bei einem zuverlässigen Transportprotokoll wie TCP stark von der heavy tailed distribution der Dateigröße abhängt. Ist die Varianz groß, so ist auch die Selbstähnlichkeit des Netzwerkverkehrs groß. Die Selbstähnlichkeit ist nicht abhängig von den Netzwerkressourcen, der Netzwerktopologie, dem traffic mixing oder der Verteilung der Zwischenankunftszeiten. Traffic mixing bedeutet, daß bei zwei oder mehr Servern die Dateigrößen einer Gruppe von Servern eine große Varianz haben, die Dateigrößen der anderen Server jedoch keine große Varianz besitzen. Große Selbstähnlichkeit hat auf die Performance einen negativen Einfluß, die package loss rate und die package retransmission rate steigen langsam bei den untersuchten Fällen bei fester Bandbreite und Buffergröße und wachsender Selbstähnlichkeit. Bei UDP ist der negative Einfluß der Selbstähnlichkeit auf die

18 Kapitel 2: Leistungsaspekte von Web Servern 11 package loss rate noch größer. Diese Aussagen wurden über eine Simulation gewonnen. Weitere Literatur zu diesem Thema findet man unter [Arli95], [Arli96a] und [Crov97]. 2.6 Modellierungsansätze für Web Server In [Ware97, Chap. 12] wie auch in [BMC98] wird zwischen drei Techniken des Bewertens der Performance bzw. Leistung von komplexen C/S Systemen unterschieden: Messung Modellierung und Lösung über Simulation Modellierung und Lösung über mathematische Verfahren Methoden zur Leistungsbewertung Messung Modellgestützte Bewertung Mathematische Verfahren Analytische Verfahren (Produktformnetze) Numerische Verfahren (Markovsche Techniken) Diskrete Simulation Abbildung 3 Übersicht über Leistungsbewertungstechniken ([BMC98]) Die Modellierung bietet einige Vorteile gegenüber der Messung. Sie ist einfacher und schneller zu modifizieren und findet unter Umständen schneller Erklärungen für das Verhalten eines Web Servers. Zudem kann die Modellierung schon eingesetzt werden, wenn die Hard und Software noch nicht zur Verfügung steht. Meist ist die Modellierung auch kostengünstiger [Schm98, S. 29]. Der Nachteil jeder Modellierung ist jedoch, daß aufgrund der zu treffenden Abstraktionen das Ergebnis bis zu einem gewissen Grad ungenau wird. Daher sind Modelle bzw. Modellergebnisse zur Erhöhung der Vertrauenswürdigkeit einer Validierungsprozedur zu unterziehen.

19 Kapitel 2: Leistungsaspekte von Web Servern 12 Die Modellierung eines Web Servers kann prinzipiell über mehrere Ansätze geschehen, z.b. über Petri Netze, Automaten oder Warteschlangenmodelle. Klassisch geschieht die Modellierung aber über Warteschlangenmodelle, die auch Warteschlangennetze genannt werden. Warteschlangennetze bestehen aus Warteschlangenstationen mit keinem oder einem Warteraum und mindestens einem Prozessor. Die Stationen sind über Routing Wege miteinander verbunden, auf denen sich die Aufträge durch das Netz bewegen. Prozessor Warteraum Abbildung 4 Symbole von Warteschlangenstationen Die Parameter einer Warteschlangenstation werden üblicherweise in der Kendall Notation (A/B/c/K/m/Z) angegeben, sie werden in der Tabelle 2 kurz erläutert [BMC98, B 13]. Bei der verkürzten Kendall Notation werden nur die ersten drei Parameter angegeben, z.b. M/M/1, wobei der Warteraum (K) unbegrenzt, die Quelle (m) unbegrenzt und die Warteschlangenstrategie (Z) FIFO ist. Parameter A B c K m Erklärung Die Verteilung der Zwischenankunftszeiten, beim Web Server die Verteilung der Zwischenankunftszeiten der einzelnen HTTP Requests. Die Verteilung der Bedienzeiten, beim Web Server die Verteilung der Zeiten, die der Web Server braucht, um einen HTTP Request zu bearbeiten. Die Anzahl der Prozessoren, beim Web Server die Anzahl der Web Server Prozesse. Die Kapazität des Warteraums, bei Web Servern die accept queue. In den meisten Unix TCP/IP Implementationen wird diese Kapazität durch die Kernelvariable somaxconn charakterisiert. Diese Variable gibt die maximale Länge des listen sockets an, unter Solaris ist sie beispielsweise auf 1000 gesetzt [Bang97, S. 2 3]. Die Auftragsanzahl der Quelle, bei einem Web Server meist nicht quantifizierbar und meist unendlich groß. Z Die Warteschlangenstrategie, bei Web Servern meist FIFO (= First In First Out) oder PS (= processor sharing). Tabelle 2 Erklärung der Parameter der Kendall Notation

20 Kapitel 2: Leistungsaspekte von Web Servern 13 Für die Warteschlangenmodelle gibt es einen analytischen, numerischen oder simulativen Lösungsweg. Der Nachteil der Simulation ist, daß detailliertere Kenntnisse über das System nötig sind und die Simulation eine längere Laufzeit aufgrund der Zustandsraumexploration hat. Auf die Lösung durch Simulation wird hier nicht weiter eingegangen Modellierung nach Gunther Bei [Gunt98] ist das Kapitel 9 speziell auf Web Server ausgerichtet. Dort gibt Gunther zuerst eine Übersicht über das WWW, seine Größe und über einige Web Server Benchmarks. Darauf folgt ein kurze Einführung in das HTTP Protokoll und ein Abschnitt über Web Performance, welcher komplett auf [Sper94] aufbaut. In dem Hauptteil dieses Kapitels wird ein Modell eines Web Servers als Warteschlangenmodell vorgestellt, welches in Abbildung 5 skizziert wird. Es wird der Unterschied zwischen Forking und Preforking mit Hilfe des Tools PDQ untersucht. Dabei stützt er sich auf die Untersuchung von [McGr95]. Preforked Web-Server Clients Fork-on-demand Web-Server Clients Master m Slaves Daemon forked processes Abbildung 5 Warteschlangenmodelle nach Gunther Modellierung nach Slothouber Slothouber modelliert in [Slot96] und [Ware97, Chap. 12] Web Server mit Hilfe eines offenen Warteschlangennetzes. Er nimmt in seinem Modell M/M/1 Warteschlangenstationen an. Die ersten beiden M stehen für Markov, daß heißt es

21 Kapitel 2: Leistungsaspekte von Web Servern 14 gilt eine negative exponentielle Verteilung der Zwischenankunftszeiten und der Bedienzeiten. Die 1 steht für einen Prozessor, die Kapazität des Warteraums und die Auftragsanzahl der Quelle ist unendlich, die Warteschlangenstrategie ist FIFO. Das Modell abstrahiert von dem Aufruf von CGI Skripten, den HTTP if modified Requests und der heavy tailed distribution der Dateigrößen. In Abbildung 6 wird der Web Server durch die Prozessoren S i und S r dargestellt. S i ist für den Verbindungsaufbau verantwortlich und S r liest eine Datei von der Festplatte und stellt sie ins Netzwerk. S s stellt die Serveranbindung an das Internet dar und S c den Anbindung des Client Browsers an das Internet. Der Knoten p stellt die Verzweigung dar, falls die Datei noch nicht komplett übertragen wurde. Web Server s i s r Internet p s c s s Abbildung 6 Warteschlangenmodell eines Web Servers nach Slothouber Unter der Annahme von Jacksons Theorem läßt sich die Antwortzeit eines HTTP Requests dann wie folgt berechnen: T F I F = C 1 A* I S A* F F*( B+ R* Y) B* R A* F*( B+ R* Y) Formel 1 Antwortzeit des Web Servermodell nach Slothouber Variable T A F Erklärung Antwortzeit Anzahl der HTTP Requests an den Web Server pro Sekunde. Durchschnittliche Dateigröße der Webobjekte in Bytes. Falls nicht anders angegeben ist F = 5275 Bytes.

22 Kapitel 2: Leistungsaspekte von Web Servern 15 B I Y R S C Größe des Datenbereichs eines Datenpaketes im Netzwerk, die maximum segment size (MSS). Falls nicht anders angegeben ist B = 2000 Bytes. Initialisierungszeit des Web Serverprozesses in Sekunden, die Zeit, die der Request am Prozessor S i verweilt. Die Zeit, die S r unabhängig von der Größe der angeforderten Datei benötigt, um den Request verarbeiten zu können. Die Rate, mit der S r die Datei bereitstellen kann in Abhängigkeit von der Größe der Datei. Die Verweildauer am Knoten S r ist somit Y+B/R. Die Netzwerkbandbreite des Servers. Die Netzwerkbandbreite des Clients. Falls nicht anders angegeben ist C = 707 KBit/sek. Tabelle 3 Erklärung der Variablen im Web Servermodell nach Slothouber In der Analyse dieses Modells werden I und Y auf 0 gesetzt. Die Servergeschwindigkeit wird nur über R dargestellt, wobei R durch die Geschwindigkeit des LAN s beschränkt wird und nicht durch die Prozessor oder Festplattengeschwindigkeit. Der Parameter C ist aus der Sicht des Web Servers nicht beeinflußbar und wird auf konstante 707 KBit/sek. gesetzt. B hat keinen großen Einfluß auf die Antwortzeit und wird konstant auf 2000 Bytes gesetzt. Die Parameter F, R und S haben den Haupteinfluß auf die Antwortzeit. Ein Ergebnis der Analyse ist, daß die maximale Kapazität des Web Servers bei Variation von F nicht linear, sondern hyperbolisch verläuft. Die Erhöhung dieses Parameters hat bei einem kleinen F somit eine größere Verschlechterung der maximalen Kapazität zur Folge als bei einem großen F. Die maximale Kapazität eines Web Servers ist die Anzahl der HTTP Requests, die der Web Server zu verarbeiten schafft, bevor die Antwortzeit asymptotisch gegen unendlich strebt, wie in Abbildung 7 zu sehen ist. Bei der Variation von S ändert sich die maximale Kapazität des Web Servers linear, d.h. wenn die Bandbreite verdoppelt wird, verdoppelt sich auch die maximale Kapazität des Servers. Mit Hilfe eines weiteren Modells wurde analysiert, inwiefern die Hinzunahme eines zweiten Web Servers die Performance steigert. Dabei wurde festgestellt, daß die Hinzunahme eines um 50% langsameren Web Servers die Performance des Gesamtsystems verschlechtert. Wenn der Server der Flaschenhals ist, bekommt man eine größere Verbesserung der Performance, wenn die Geschwin-

23 Kapitel 2: Leistungsaspekte von Web Servern 16 digkeit des Web Servers verdoppelt wird, als wenn ein zweiter gleichwertiger Web Server hinzugefügt wird. Typische Responsezeitkurve für M/M/1 Warteschlangenmodelle Responsezeit (T) T 1 = 1 A Anzahl der HTTP-Requests pro Zeiteinheit (A) Abbildung 7 Antwortzeit vs. Anzahl Requests pro Zeiteinheit Modellierung nach Heidemann, Obraczka und Touch Im Gegensatz zu Slothouber modellieren Heidemann, Obraczka und Touch in [Heid97] nicht mit Hilfe von Warteschlangenmodellen, sondern mit heuristischen Formeln. Sie fokussieren ihr Modell auf das Netzwerk und auf HTTP, und stellen ein analytisches Modell des HTTP Protokolls über die Protokolle TCP, TCP mit connection caching und UDP auf. Ziel der Untersuchung sind die Startup Effekte der Protokolle. Das Modell wird analysiert und mit Messungen validiert. Das Modell trifft folgende Annahmen: Der Netzverkehr ist fehlerfrei, d.h. keine Pakete gehen verloren. Die Zeit, die der Web Server zum Antworten braucht, ist konstant. Die Requests sind untereinander unabhängig. Es werden keine parallelen Verbindungen modelliert. Die drei folgenden Formeln werden mit Hilfe von elementaren Beziehungen hergeleitet. Formel 2 modelliert die Antwortzeit für einen optimalen Request, Formel 3 berechnet die Antwortzeit für einen Request mit TCP Overhead und Formel 4 berechnet die Zeit für eine Serie von TCP Requests ohne Berücksichtigung von Denkzeiten.

24 Kapitel 2: Leistungsaspekte von Web Servern 17 T min req = rtt + bw size reply + processing + bw size Formel 2 Antwortzeit für einen optimalen Request nach Heidemann et al. reqsize TTCP = 2* rtt + + processing + slowstarttcp + bw reply bw Formel 3 Antwortzeit für einen TCP Request nach Heidemann et al. size n STCP = rtt + ( TTCP ( i) rtt) i= 1 Formel 4 Zeit für eine Serie von TCP Requests nach Heidemann et al. Variable T TCP rtt req size bw processing slowstart TCP reply size Erklärung Die Antwortzeit eines HTTP Requests über TCP. Die Round Trip Time. Die Größe des Requests. Die Bandbreite. Die durchschnittliche Bearbeitungsdauer des Servers. Die Verzögerung durch den Slowstart von TCP. Sie ist abhängig von der Anzahl der Requests, die vorher schon durchgeführt wurden. Sie steigt monoton mit der Anzahl durchgeführter Requests, der Betrag, der pro Request hinzugezählt wird, sinkt jedoch monoton. Die Größe des Replies. Tabelle 4 Erklärung der Variablen im Netzwerkmodell nach Heidemann et al. In der Analyse werden die Parameter Bandbreite (bw), Round Trip Time (rtt) und die Maximum Segment Size (mss) für zehn typische Netzwerkarten, wie Modem, Ethernet, WAN etc. gemessen. Aufgrund dieser Daten und des Modells wurde der Overhead von TCP über T TCP / T min berechnet und dargestellt. Das Modell wird mit eigenen Messungen und mit den Messungen in [Frys97] validiert. Das Ergebnis der Studie ist, daß der Overhead von HTTP über TCP mit dem Produkt der Bandbreite und der RTT korreliert. Bei den heutigen Techniken wie Modem oder ISDN, wo die Bandbreite klein ist, bzw. Ethernet, wo die RTT klein ist, ist der Overhead nicht groß. Bei zukünftigen Technologien jedoch, wo die Bandbreite und die RTT groß ist, wie ADSL oder Satellitenanbindung, wird der Overhead eine bedeutendere Rolle spielen.

25 Kapitel 2: Leistungsaspekte von Web Servern Modellierung nach Menascé und Almeida Der Ansatz von Menascé und Almeida zur Modellierung eines Web Server geht von zwei unterschiedlichen Sichten aus, der Client und der Server Sicht. Bei der Workload Beschreibung fließen die typischen Eigenschaften des Web Traffics Burstiness und heavy tailed distributed Dateigrößen mit ein. Bei der Betrachtung der Client Seite sollen Fragen beantwortet werden wie: Was für eine Bandbreite sollte das LAN / der Internetanschluß haben? Soll ein Proxy Server benutzt werden? In Abbildung 8 sieht man zwei geschlossene Warteschlangennetze, welche dazu benutzt werden können, eine Antwort auf die beiden obigen Fragen zu finden. clients LAN 1 2 router 3 outgoing link 4 clients LAN 1 2 router 3 outgoing link 4 ISP Internet web server 6 incoming link 5 7 cpu 8 disk proxy cache server ISP Internet web server 6 incoming link 5 (a) (b) Abbildung 8 Clientseitige Warteschlangenmodelle ([Mena98, S.230]) Der Ablauf eines Requests ohne Proxy Server (Abbildung 8a) sieht so aus, daß ein Request vom Client (1) über das LAN (2), den Router (3) und dem outgoing link (4) zum ISP, Internet und dem angestrebten Web Server (5) geht. Die Response geht über den incoming link (6), den Router (3) und das LAN (2) zum Client (1). Ein Request mit Proxy Server (Abbildung 8b) beginnt wieder beim Client (1) und dem LAN (2), läuft aber über den Proxy Server (7, 8). Wenn der Proxy Server das gewünschte Webobjekt im Cache hat, gelangt es über das LAN (2) direkt zum Client (1). Falls das Webobjekt nicht im Cache vorhanden ist, geht der Request

26 Kapitel 2: Leistungsaspekte von Web Servern 19 wieder über (2), (3), (4), (5) und (6) zurück zum Proxy Server und von dort aus weiter über das LAN (2) zum Client (1). In der Tabelle 5 werden die in das Warteschlangenmodell einfließenden Input Parameter erklärt. In der ersten Sektion stehen die Parameter, die für alle Web Server Modelle benötigt werden, danach folgen die Parameter für die clientseitigen Modelle. Die nächsten vier Parameter werden nur im Falle eines Einsatzes des clientseitigen Modell mit Proxy Servers benötigt und die letzten fünf Parameter sind für das serverseitige Warteschlangenmodell relevant. Parameter für alle Modelle aus [Mena98] LANBandwidth MaxPDU FrameOvhd RouterLatency AvgSizeHTTPRequest DocumentSize r PercentSize r Parameter für die clientseitigen Modelle LinkBandwith InternetDelayRTT InternetDataRate BrowserRate NumberClients PercentActive Parameter für das clientseitige Modell mit Proxy Server P hit HitCPUTime MissCPUTime DiskTime Erklärung der Parameter Bandbreite des LAN s in MBit pro Sekunde Maximale MSS (Maximum Segment Size) im LAN in Bytes Overhead der Frames im LAN in Bytes Latenz der Router in Mikrosekunden pro Paket Durchschnittliche Größe der HTTP Requests, die der Browser absetzt Durchschnittliche Dokumentengröße der Kategorie r (r = 1,...,R) Prozent der Dokumente, die in R Kategorie r angefragt werden PercentSize r = 1 r= 1 Bandbreite des Internetzugangs in KBit pro Sekunde Durchschnittliche RTT (Round Trip Time) des Internet Datentransferrate des Internets in KB pro Sekunde Anzahl der HTTP Request pro Sekunde, die der Browser absetzt. Die Inverse der Denkzeit des Benutzers. Anzahl der Clients im LAN Prozent der im Web aktiven Clients Wahrscheinlichkeit eines Cache Hits CPU Zeit die bei einem Cache Hit benötigt wird, in Sekunden CPU Zeit die bei einem Cache Miss benötigt wird, in Sekunden Übertragungszeit der Festplatte in KB pro Millisekunden

27 Kapitel 2: Leistungsaspekte von Web Servern 20 Parameter für die serverseitigen Modelle ArrivalRate r CPUTimePerHTTP Request r DiskTime NoWebServer NoFileServerDisks CPUTimeFileServer Anzahl der HTTP Requests pro Sekunde der Kategorie r CPU Zeit, die benötigt wird, um einen Request der Kategorie r zu verarbeiten Übertragungszeit der Festplatte in KB pro Millisekunden. Anzahl der Web Server Anzahl der Festplatten im File Server CPU Zeit des File Server in KB pro Sekunde Tabelle 5 Erklärung der Input Parameter der Warteschlangenmodelle ([Mena98]) Diese Input Parameter können in ein Excel Makro, das [Mena98] auf einer CD ROM beigefügt ist, eingegeben werden. Daraus werden die Auslastung der Ressource (Utilization), die durchschnittliche Länge der Warteschlange und die durchschnittliche Wartezeit eines Request bei der Warteschlangenstation (Residence Time) berechnet. Damit können Auswertungen, wie in Tabelle 6 gezeigt, erstellt werden. Das Beispiel in Tabelle 6 zeigt, daß die Ressource 6, der Incoming Link, den Flaschenhals darstellt. Residence Time (sec.) Utilization LAN (2) 0,019 0,59% Router (3) 0,001 0,04% Outgoing Link (4) 0,042 1,31% Incoming Link (6) 43,403 99,29% Throughput: 0,3121 Requests/sec. Throughput: 55,5 Kbps Response Time: 44,7 sec. Tabelle 6 Beispielrechnung eines clientseitigen Modells ohne Proxy Server ([Mena98], S. 234) Serverseitig treten andere Fragestellungen auf, wie z.b.: Wie groß sollte die Bandbreite in Internet sein? Wieviele mirror sites werden benötigt? Sollte ein leistungsstarker oder mehrere leistungsschwächere Web Server eingesetzt werden? Soll ein Fileserver statt der lokalen Festplatte eingesetzt werden? In Abbildung 9 sind zwei offene Warteschlangennetze zu sehen, einmal eine einfache Umgebung mit einem Web Server, zum anderen eine komplexere

28 Kapitel 2: Leistungsaspekte von Web Servern 21 Umgebung mit n Web Servern und einem Fileserver mit p Festplatten. incoming link 1 router 2 LAN 3 incoming link 1 router 2 LAN 3 6 outgoing link 4 cpu 5 disk web server 6 outgoing link 4 cpu web server cpu web server n 7 cpu (a) (b) 8 disk disk p file server Abbildung 9 Serverseitige Warteschlangenmodelle ([Mena98, S.240]) Tabelle 7 zeigt eine Beispielrechnung für ein serverseitiges Modell mit einem Web Server ohne File Server. Die Abkürzung R.T. steht für Residence Time und Util. für Utilization. Die Residence Time ist in Sekunden angegeben. Die Tabelle ist mit Hilfe der auf der mit [Mena98] gelieferten Excel Dateien ClosedQN.xls und WebModels.xls berechnet worden. Filesize 5KB 10KB 38,5KB 350KB 1KB (CGI) Requests 2 pro Sek. 2,4 pro Sek. 1,52 pro Sek. 0,08 pro Sek. 2 pro Sek. R.T. Util. R.T. Util. R.T. Util. R.T. Util. R.T. Util. Incoming 0,002 1,4% 0,002 0,9% 0,002 0,2% 0,002 0,0% 0,002 0,4% Link Router 0,001 0,5% 0,001 0,4% 0,002 0,2% 0,012 0,0% 0,000 0,1% LAN 0,005 4,0% 0,010 4,9% 0,036 3,2% 0,328 0,2% 0,001 0,2% CPU 0,021 5,9% 0,026 4,7% 0,064 1,9% 0,466 0,1% 0,824 80,4% Disk 0,112 27,5% 0,223 34,6% 0,857 22,6% 7,776 1,2% 0,025 1,4% Outgoing 0,078 24,7% 0,155 30,9% 0,591 20,1% 5,369 1,1% 0,018 1,3% Link Summe 0,218 0,416 1,551 13,953 0,870 Tabelle 7 Beispielrechnung des serverseitigen Modells ohne File Server ([Mena98], S. 243) Die Performancetesttools können auch zur Gewinnung von Modellparametern genutzt werden. Manche Parameter kann man direkt aus der Spezifikation

29 Kapitel 2: Leistungsaspekte von Web Servern 22 ableiten, wie Bandbreite, Anzahl Server/Festplatten oder die Größe der Maximum Segment-Size. Manche Parameter, wie die Anzahl der Clients, der Workload oder die Wahrscheinlichkeit eines Proxy Hits, können nur geschätzt oder aus der Vergangenheit interpoliert werden. Bei vielen Zeitenmessungen, wie CPU Zeit, Router Latenz oder die Round Trip Time des Internets, können die Performancetesttools helfen, die Werte der Input Parameter mit Hilfe entsprechender Monitore zu bestimmen. So kann das Performancetesttool die entsprechende Last erzeugen und mit den geeigneten Monitoren kann die gewünschte Parameter gemessen werden. Testtools + Monitore Spezifikation Geschätzt bzw. Interpoliert CPUTimeFileServer LANBandwidth ArrivalRate r CPUTimePerHTTP Request r LinkBandwith BrowserRate HitCPUTime MaxPDU NumberClients MissCPUTime NoFileServerDisks PercentActive RouterLatency NoWebServer AvgSizeHTTPRequest InternetDataRate FrameOvhd DocumentSize r InternetDelayRTT DiskTime PercentSize r P hit Tabelle 8 Kategorisierung der Variablen der Modelle aus [Mena98] nach der Quelle 2.7 Weitere Themen des Web Server Benchmarkings Einen wichtigen Einfluß auf die Geschwindigkeit eines Web Servers hat auch die Ausführung von CGI Skripten. Mit [Cour97] und [Edwa95] kann man sich über den Einfluß von CGI Skripten auf die Web Server Performance informieren. Um die Performance eines Web Servers zu messen, gehören nicht unbedingt nur die Antwortzeiten, sondern auch die Auslastung des Web Servers zu den gewünschten Ergebnissen. Literatur zum Monitoring von Web Server steht in [Alme96], [Cock96], [Hafe97], [Wall96] und [Gior96]. Die Auswirkung von SSL Verschlüsselung bzw. die Möglichkeiten der Verbesserung der Web Server Performance hat Arthur Goldberg in [Gold98a] und [Gold98b] untersucht. Caching ist ein wichtiges Thema für die Geschwindigkeit einer Anbindung von

30 Kapitel 2: Leistungsaspekte von Web Servern 23 Clients an das Internet. Teilweise basieren komplette Kalkulationen von ISP s wie metronet oder germany.net auf Caching von Internetinhalten durch sogenannte Proxy Server 6. Literatur dazu findet man unter [Arli96b], [Crov98b], [Gold98c] und [Best95]. In den Arbeiten von [McGr96b], [Titt96], [Titt97] und [Ruba96] findet man ein Review von Web Sever Benchmarks, z.b. WebStone, SpecWeb oder Gstone. Möglichkeiten bzw. Ergebnisse der Offline Analyse von Web Server Logs werden in [Mogu95a], [Lync97] und [Manl97a] behandelt. Den Aspekt des Testens des Netzwerks behandelt Buchanan in [Buch96]. Verbesserungsvorschläge für die Betriebssysteme, unter denen die Web Server laufen, können in [Bang98] und [Mogu95b] nachgelesen werden. Den Aspekt des Load Balancing von Web Servern behandeln die Aufsätze von Aversa et al. [Aver98], [Best98] und Cisco Systems [Cisc97]. 6 Siehe c t magazin für computer technik, Verlag Heinz Heise, Ausgabe 8/97, Seite 134 und 140

31 Kapitel 3: Anforderungen 24 3 Anforderungen an Web Server Performancetesttools Um die auf Seite 5 genannten Testziele erfüllen zu können, muß das Testwerkzeug bestimmten Anforderungen genügen. Manche von diesen Anforderungen leiten sich aus den Grundsätzen des Messens der Performance ab, manche Anforderungen kommen speziell aus dem Aufgabengebiet des Messens der Web Server Performance. Die Anforderungen sind stark von der zu testenden Applikation abhängig. Wenn beispielsweise ein Online Shop getestet werden soll, dessen Datenverkehr verschlüsselt ist, dann muß das Testwerkzeug in der Lage sein, die Daten in der gewünschten Weise zu verschlüsseln und damit die Anforderung RE28 erfüllen. Die nachfolgenden Anforderungen sind innerhalb der Unterkapitel nicht sortiert. Die kursiv geschriebenen Texte sind Anmerkungen zu den Anforderungen. Viele der Anforderungen finden sich so oder in ähnlicher Form in [Pfei98], wobei diese Arbeit nicht speziell auf den Web Server als Meßobjekt fokussiert. Die Anforderung RE13 basiert auf [Dirl94]. 3.1 Allgemeine Anforderungen an ein Performancetesttool RE1 RE2 RE3 RE4 RE5 RE6 Das Testwerkzeug sollte einen Mechanismus zum Aufzeichnen von Testskripten haben. Dieses Werkzeug soll im folgenden Recorder genannt werden. Das Tool muß mehrere virtuelle Benutzer simulieren können. Die Denkzeiten der Benutzer zwischen den Requests müssen simuliert werden können. Die virtuellen Benutzer sollten sich synchronisieren können, d.h. sie warten bei einem Punkt im Testskript aufeinander, um dann gleichzeitig mit dem Abarbeiten der darauf folgenden Anweisungen im Testskript zu beginnen. Durch die Technik der Synchronisation können Bursts simuliert werden. Die Last sollte auch von mehreren Rechnern erzeugbar sein, d.h. die Lastgeneratoren sollten im Netzwerk verteilt werden können. Die Kommunikation mit den Rechnern sollte ein zentrales Steuer-

32 Kapitel 3: Anforderungen 25 programm handhaben. Dieses Steuerprogramm soll im folgenden Controller genannt werden. RE7 Der Controller sollte überprüfen, ob die am Lasttest beteiligten Rechner die gleiche Systemzeit haben. Es kann problematisch sein, die einzelnen Ergebnisse der unterschiedlichen Lastgeneratoren zusammenzufassen und zu synchronisieren, wenn die Lastgeneratoren unterschiedliche Systemzeiten haben. Die Synchronisation der Rechner wird über Betriebssystem durchgeführt. Unter Windows NT beispielsweise lautet der Befehl zur Synchronisation mit einem Server: net time \\Rechnername /SET. RE8 Die einzelnen Transaktionszeiten aller virtuellen Benutzer mit Zeitstempel sollten externen Programmen zur Verfügung stehen. Wenn die Auswertungen in der Analysekomponente des Werkzeugs nicht ausreichend sind, dann können diese benötigten Auswertungen durch externe Programme geschehen. RE9 Das Performancetesttool muß mindestens die Antwortzeit messen. RE10 Die Analyse der Antwortzeiten sollte den Minimal, Maximal, Mittelwert und die Varianz bzw. Standardabweichung sowie frei einstellbare Quantile beinhalten. RE11 Die Auswertungskomponente sollte außer der Analyse der Antwortzeiten weitere Daten anbieten, wie z.b. TPS, Fehler pro Stunde oder Bytes pro Sekunde. RE12 Neben der Antwortzeit sollten noch weitere Messungen vorgenommen bzw. andere Datenquellen ausgewertet werden können, z.b. die Messung der Serverauslastung oder der Netzwerkbelastung. RE13 Ein Meßlauf muß einen Vorlauf und einen Nachlauf haben. Es darf nur die Zeit gemessen werden, in der alle virtuellen Benutzer aktiv sind. Diese Anforderung leitet sich aus der DIN her [Dirl94, S ]. Der Vorlauf wird beispielsweise benötigt, um die Lastspitze, die auftritt, wenn alle virtuelle Benutzer gleichzeitig den ersten Request machen, nicht in die gemessenen Ergebnisse einfließen zu lassen. Der Nachlauf ist notwendig, weil die virtuellen Benutzer nicht gleichzeitig mit ihren Trans-

33 Kapitel 3: Anforderungen 26 aktionen fertig werden. Die Folge daraus ist, daß die Last auf dem Web Server, nachdem der erste virtuelle Benutzer seine Aufgaben beendet hat, sukzessive abnimmt und die gemessenen Zeiten nicht mehr repräsentativ sind. RE14 Es sollte auch von anderen Programmen der Zugriff auf die Meßdaten möglich sein. RE15 Ein Performancetest sollte auch von der Kommandozeile aus startbar sein. Dies hat den Hintergrund, daß auch ein Monitoring über ein externes Schedulerprogramm möglich sein sollte. RE16 Der Performancetest sollte ohne Aufsicht laufen können, d.h. für Fehler sollte es eine Behandlungsroutine geben, die ohne das Eingreifen eines Benutzers funktioniert. Hiermit ist gemeint, daß der Benutzer des Testtools festlegen kann, wie auf einen Fehler reagiert wird. Beispielsweise kann es sein, daß ein fehlerhafter Zugriff auf eine Grafik fatal ist, wenn es sich bei dieser Grafik um die Navigationsleiste handelt. Wenn es sich jedoch um die Hintergrundgrafik handelt, kann dieser Fehler ignoriert werden. So sollten auch mehrere Klassen festgelegt werden können, beispielsweise Fehler, die einen Abbruch des Lasttests bewirken, Fehler, bei denen der aktuelle Durchlauf neu gestartet wird und Fehler, die protokolliert oder ganz ignoriert werden. RE17 Das Testwerkzeug sollte es erlauben, bei der Testplanung Ziele anzugeben und diese nach dem Performancetest zu überprüfen. RE18 Die Lastraum Exploration, d.h. das Finden der Leistungsgrenze eines Web Servers aufgrund angegebener Ziele des Benutzers, sollte automatisch geschehen. Mit automatischer Lastraum Exploration ist hier die automatische Veränderung der Benutzerzahl in Abhängigkeit von quantifizierten Kriterien, die der Benutzer festlegt, gemeint. RE19 Wenn RE18 nicht erfüllt ist, sollte zumindest die manuelle Veränderung der Anzahl der virtuellen Benutzer einfach möglich sein. RE20 Die Auslastung der Ressourcen der Lastgeneratoren wie CPU, Festplatte und Netzwerkkarte sollte von den Lastgeneratoren selbst überwacht

34 Kapitel 3: Anforderungen 27 werden. Die Schwellenwerte sollten von dem Benutzer einstellbar sein. Wenn eine Überschreitung der Schwellenwerte auftritt, muß diese dem Benutzer gemeldet werden. 3.2 Internetspezifische Anforderungen RE21 Das TCP/IP Protokoll muß unterstützt werden. RE22 Es sollten weitere Protokolle unterstützt werden, wie z.b. HTTP, FTP, SMTP, LDAP etc. Das Anpassen der Testskripte ist einfacher, wenn das Werkzeug auch die Protokollschichten, die über der Netzwerkschicht von TCP/IP liegen, wie z.b. HTTP oder FTP, mit speziellen Befehlen unterstützt. RE23 Der HTTP Header jedes einzelnen Requests muß spezifiziert werden können. HTTP Requests bzw. Responses teilen sich auf in Header Informationen und Daten. Es ist wichtig, die Header Informationen exakt wiederzugeben, weil davon das Verhalten des Web Servers stark beeinflußt wird. So ist es beispielsweise wichtig, den Headereintrag User Agent richtig zu setzen, weil dieser Eintrag von Web Anwendungen häufig abgefragt wird. RE24 Es sollte einfach einstellbar sein, ob die TCP Verbindungen über den Keep Alive Mechanismus von HTTP/1.1 wiederverwendet werden sollen. Der Keep Alive Mechnismus kann auch über das Setzen eines HTTP Headers, wie in RE23 beschrieben, realisiert werden. Weil sich aber dieses Feature von HTTP direkt auf die Performance auswirkt, sollte es speziell herausgehoben und einfach ein bzw. abschaltbar sein. RE25 Das Performancetesttool sollte auch Seiten mit dynamischen Inhalten messen können. Darunter fallen Techniken wie CGI, Active Server Pages (ASP) und die Redirection von Webseiten. RE26 Cookies sollten automatisch empfangen, gespeichert und versendet werden können. Für das Setzen von permanenten Cookies sollte es einen speziellen Befehl geben. Permanente Cookies sind Cookies, die auf der Festplatte des Benutzers gespeichert werden. Sie werden meist dafür gebraucht, zu erkennen, ob ein

35 Kapitel 3: Anforderungen 28 Benutzer schon einmal die Website besucht hat. Über einen speziellen Befehl zum Setzen eines permanenten Cookies kann dieses Verhalten gesteuert werden. RE27 Verschlüsselter Datenverkehr sollte aufgezeichnet werden können. RE28 Verschlüsselter Datenverkehr sollte abgespielt werden können. Die Anforderungen RE27 und RE28 sind getrennt worden, weil es bei einem Web Server relativ einfach ist, die Verschlüsselung der Daten abzuschalten, das Testskript aufzuzeichnen und die Verschlüsselung wieder anzuschalten. Die Verschlüsselung wirkt sich aber stark auf die Performance aus, wie in [Gold98b] dargelegt, so daß es für einen realistischen Performancetest wichtig ist, die Verschlüsselung zu berücksichtigen. RE29 Client Zertifikate sollten benutzbar sein. RE30 Beim Laden von Webobjekten sollten mehrere Threads benutzt werden können. Viele Webbrowser arbeiten mit der Technik, mit mehreren Threads TCP Verbindungen aufzubauen, um so die Webobjekte schneller laden zu können. Die Browser von Netscape und der Internet Explorer 4.0 arbeiten beispielsweise mit maximal vier Threads. RE31 Die Daten, die zum Web Server geschickt werden, sollten leicht modifizierbar und randomisierbar sein. RE32 Basic und Digest Authentification von HTTP sollte unterstützt werden. RE33 Die Bandbreite, mit der die Daten übertragen werden, sollte einstellbar sein, z.b. ISDN, Modem 28K, Modem 56K. Durch das Verringern der Bandbreite im LAN kann die Belastung des Web Servers realistischer gestaltet werden. Bei komplexen Seiten, die viele HTTP Requests notwendig machen, würden ohne Beschränkung der Bandbreite diese Requests den Web Server sehr schnell hintereinander erreichen und unrealistisch stark beanspruchen. RE34 Ein Proxy Server zwischen dem Performancetesttool und dem Web Server sollte unterstützt werden. Ein Lastgenerator sollte, genau wie ein Browser, auch in der Lage sein, einen Proxy Server zu benutzen.

36 Kapitel 4: Evaluation der Werkzeuge 29 4 Evaluation der Werkzeuge 4.1 Einleitung In diesem Teil der Arbeit sollen Werkzeuge, welche die Performance von Web Servern messen können, evaluiert werden. Die meisten Werkzeuge können mehr als nur die Performance von Web Servern messen. Diese Fähigkeiten werden aber nicht weiter untersucht, sie werden anhand der Informationen aus der Dokumentation der Werkzeuge kurz erwähnt. Die Auswahl der Werkzeuge geschah aufgrund der geschätzten Marktanteile Anfang 1999 und ihrer Verfügbarkeit. Mercury Interactive ist Marktführer in dem Segment des Automated Software QA mit 35,4% laut IDC Studie # Segue und Rational sind zwei von den größeren Mitbewerbern, so daß auch sie in die Auswahl der Werkzeuge kamen. Die Software von RSW Software und Radview Software standen im Internet zu download bereit und war somit einfach zu beschaffen. Diese beiden Anbieter sind zudem auf das Web Server Benchmarking spezialisiert im Gegensatz zu den drei erstgenannten Anbietern. Weitere Bedeutung erlangt die Software von RSW Software, e Test Suite, durch die Tatsache, daß seit März 1998 Cyrano dieses Tool als OEM Version unter dem Namen WebTester in seine Produktpalette aufgenommen hat und vertreibt 8. Es gibt noch weitere Tools, die evaluiert werden könnten, z.b. QALoad von Compuware oder Portent von loadtesting.com, aber das würde den Umfang dieser Arbeit sprengen. Eine Liste von Performancetesttools steht unter: load.htm oder 4.2 Testfälle Für die Evaluation der Performancetesttools wurden mehrere Testfälle durchlaufen. Zwei Testfälle liefen auf der Web Site 7 siehe 8 siehe

37 Kapitel 4: Evaluation der Werkzeuge 30 essen.de, dem sogenannten Mapkit Server. Die Web Site liegt im lokalen Netzwerk, ist aber auch über das Internet erreichbar. Diese Web Site besteht aus HTML Seiten, GIF Grafiken und drei Skripten. Das erste Skript zählt einen Counter hoch, das zweite führt eine Volltextsuche durch und mit dem dritten Skript kann sich ein Benutzer authentifizieren. Das erste Skript ist in der Programmiersprache C geschrieben, die letzten beiden sind mit Perl kodiert worden. Mit diesen Fallstudien kann man die grundlegenden Fähigkeiten der Werkzeuge prüfen und den CGI Support testen. Der dritte Testfall wurde auf einem IIS Web Server, der im lokalen Netzwerk eingebunden war, installiert. Hiermit soll die Fähigkeit der Performancetesttools, Cookies und über ASP generierte SessionID s korrekt zu handhaben, geprüft werden Mapkit Search Test Der erste Testfall beinhaltet zehn Benutzer, welche die Transaktion Search 35- mal ohne Verzögerung hintereinander auf dem Mapkit Server ausführen. Die Transaktion Search beinhaltet keine Denkzeiten. Die einzelnen Webobjekte werden nacheinander geladen, d.h. erst wenn der vorhergehende Response komplett angekommen ist, wird der Request für das nächste Webobjekt abgesetzt. Dieses Vorgehen war notwendig, weil nicht alle Werkzeuge das Laden von HTML Seiten mit mehreren Threads, wie in der Anforderung RE30 beschrieben, unterstützen. Folgende Schritte führt die Transaktion Search aus: 1. Laden der Startseite Diese Seite lädt zwei HTML Seiten und drei GIF Grafiken nach. Sie beinhaltet zusätzlich ein Skript, das in C geschrieben ist und einen Counter hochzählt. 2. Laden der Service Seite Service/index.html. Diese lädt wiederum zwei HTML Seiten und 14 GIF Grafiken nach. 3. Laden der Suchen Seite search.html. 4. Durchsuchen des öffentlichen Bereichs der Website nach dem Begriff Server mit Hilfe eines in Perl implementierten Skriptes.

38 Kapitel 4: Evaluation der Werkzeuge 31 Die Implementierungen dieses Testfalls sind im Anhang B als Beispiel für die Skriptsprachen der einzelnen Werkzeuge abgedruckt. Die Summe der Responsedaten ergibt ca. 59 Kilobyte. Im folgenden wird dieser Test Mapkit Search Test genannt Mapkit Intern Test Dieser Testfall besteht aus zehn virtuellen Benutzern, welche die Transaktion Intern 20-mal hintereinander ohne Verzögerung auf dem Mapkit Server ausführen. Ebenso wie beim Mapkit Search Test werden keine Denkzeiten und nur ein Thread benutzt. Die Transaktion Intern besteht aus folgenden Schritten: 1. Jede Seite des öffentlichen Bereichs des Mapkit Servers, die direkt von der Menüleiste erreichbar ist (Information, Kontakt, Dokumente, News, Service, Suche, Intern), wird einmal mit den dazugehörigen Grafiken geladen. 2. Durchsuchen des öffentlichen Bereichs des Mapkit Servers nach dem Begriff Server mit Hilfe eines in Perl implementierten Skriptes. 3. Authentifizieren für den internen Bereich. 4. Jede Seite des internen Bereichs des Mapkit Servers, die direkt von der Menüleiste erreichbar ist (Kontakt, Dokumente, Termine, Service, Suche, Anwender), wird einmal mit den dazugehörigen Grafiken geladen. 5. Durchsuchen des internen Bereichs des Mapkit Servers nach dem Begriff Server mit Hilfe eines in Perl implementierten Skriptes. Die Responsedaten der Transaktion Intern umfassen ca. 107 Kilobyte. Dieser Testfall heißt im folgenden Mapkit Intern Test IIS Test Der dritte Testfall ist auf einem Internet Information Server mit ASP Unterstützung installiert worden und wird deswegen im folgenden IIS Test genannt. Es werden HTML Seiten, die dynamisch generiert werden und SessionID s enthalten bzw. Cookie Inhalte anzeigen, mit dem Recorder aufgezeichnet. Dann wird versucht, diese aufgezeichneten Seiten so anzupassen, daß die dynamischen Inhalte korrekt verarbeitet werden. Zusätzlich kann auf dem Server SSL Verschlüsselung aktiviert werden, so daß überprüft werden kann, ob

39 Kapitel 4: Evaluation der Werkzeuge 32 verschlüsselter Verkehr korrekt aufgezeichnet und wiedergegeben wird. Der IIS Test ist ein funktionaler Test, der zeigen soll, ob die Performancetesttools in der Lage sind, mit dynamischem Inhalt, wie Cookies und SessionID s, umzugehen.

40 Kapitel 4: Evaluation der Werkzeuge LoadRunner 5.01 Der LoadRunner von Mercury Interactive Corp. besteht aus den Komponenten VUGen, Astra QuickTest, Controller und Analysis. Zusätzlich dazu kann der TestDirector zum Verwalten bzw. zum Schedulen der Tests benutzt werden. Es gibt im LoadRunner auch die Möglichkeit, Visual User über das Programm WinRunner am Lasttest zu beteiligen. LoadRunner unterstützt: Datenbanken (Informix, Oracle, ODBC) Applikationsserver (Tuxedo, DCOM) ERP (SAP R/3, Baan, Oracle, Peoplesoft) WWW (HTTP) TCP/IP (über Winsock) Java RTE (Remote Terminal Emulation) VUGen und Astra QuickTest werden zum Aufzeichnen benötigt, der Controller ist das zentrale Steuerprogramm der Lastgeneratoren und Analysis wertet die Ergebnisse aus Ressourcenverbrauch Komponente Speicher (mind./ CPU Plattenplatz Betriebssystem empfohlen) Controller 24 MB/32 MB MB WindowsNT4.0 oder Windows95 Tabelle 9 Hard und Softwareanforderung an LoadRunner Bei dem Mapkit Search Test lag die Prozessorauslastung durchschnittlich zwischen 31% und 35%, beim Mapkit Intern Test zwischen 37% und 44%. Der Hauptspeicherverbrauch lag für den Start des Masters bei ca. 3,5 MB. Bei der Ausführung der virtuellen Benutzer als Prozeß wurde 2,6 MB bis 2,9 MB pro Benutzer verbraucht, bei der Ausführung als Thread wurden zwischen 1 MB und 1,1 MB pro Benutzer verbraucht.

41 Kapitel 4: Evaluation der Werkzeuge Aufzeichnen Zum Aufzeichnen von den Testskripten stehen zwei Werkzeuge zur Verfügung, VUGen und Astra QuickTest. Abbildung 10 zeigt einen Screenshot aus Astra QuickTest. VUGen steht für Virtual User Generator und kann Aktionen von einem Benutzer aufzeichnen. Die Möglichkeiten des VUGen beschränken sich jedoch nicht nur auf den HTTP Verkehr, mit diesem Tool ist es auch möglich, Skripte für Datenbanken oder ERP Systeme aufzuzeichnen. Es ist jedoch nicht in der Lage, SSL verschlüsselten Verkehr aufzuzeichnen. Für diesen Fall und für den Fall des Web Server Performancetest empfiehlt Mercury den Astra QuickTest. Diese Komponente ist spezialisiert auf das Testen von Web Servern. Der VUGen zeichnet die Aktionen auf der Basis von Winsock auf, während Astra QuickTest als Proxy fungiert, der die Aktionen aufzeichnet. Astra QuickTest hat nicht nur die Möglichkeit, Skripte aufzuzeichnen, sondern kann diese auch in einem eigenen Browserfenster wiedergeben. Es kann eingestellt werden, ob Grafiken mit aufgezeichnet werden sollen. Abbildung 10 Screenshot des Astra QuickTests

42 Kapitel 4: Evaluation der Werkzeuge 35 Astra QuickTest ist komplett iconbasiert, d.h. jedes aufgezeichnete Webobjekt wird als Icon repräsentiert, die Verknüpfungen zwischen diesen Webobjekten wird als Linie dargestellt. Es ist jedoch auch möglich, sich ein Skript anzeigen zu lassen. Ein Beispiel hierfür findet sich im Anhang A.3.2. Astra QuickTest ist nicht unabhängig vom Browser, die mitgelieferte Version beispielsweise arbeitete nicht mit dem Netscape Navigator 4.5 zusammen. In Abbildung 10 ist das dreigeteilte Fenster von Astra QuickTest zu sehen, im ersten Abschnitt sieht man die aufgezeichneten Dokumente mit ihren Links, im mittleren Teil stehen die Icons für jedes aufgezeichnete Webobjekt und im unteren Teil steht das Protokoll des letzten Testlaufs Lastgenerator Die Szenarienerstellung wird durch einen Wizard unterstützt. Das Szenario wird in sechs Fenstern abgebildet, dem Scripts, Hosts, Vusers, Rendezvous Output und dem Transactions Fenster. Abbildung 11 Screenshot des LoadRunner Controller

43 Kapitel 4: Evaluation der Werkzeuge 36 Während des Lasttests ist es möglich, virtuelle Benutzer nach Belieben anzuhalten und wieder laufen zu lassen. Der Lastgenerator läuft unter den Betriebssystemen Windows NT4.0, HP UX ab Version 10.01, AIX ab Version 4.1 und Sun Solaris ab Version Analyse Während des Lasttests wird der Benutzer weder über Ergebnisse noch über einen Tätigkeitsfortschritt automatisch informiert. Es kann jedoch die Belastung des Web Servers, der unter Unix oder Windows NT laufen muß, angezeigt werden. Dafür ist es unter Unix notwendig, den rstat Daemon laufen zu lassen. Nach dem Lasttest steht ein Network Delay Monitor und speziell für Oracle Datenbanken ein Transaction Breakdown Monitor zur Verfügung. Der Network Delay Monitor mißt die Verzögerung des Netzwerks einmal vor dem Lasttest und dann während des Lasttests und kann so ermitteln, ob das Netzwerk der Flaschenhals ist. Die Analysekomponente des LoadRunner ist sehr umfangreich und enthält 13 Performance Graphen und 9 Performance Reports. Tabelle 10 gibt die Namen aller zur Verfügung stehenden Auswertungsmöglichkeiten an. Weil die einzelnen Transaktionszeiten in der Analyse noch zur Verfügung stehen, ist es auch möglich, nur einen Ausschnitt des Lasttests zu analysieren. Kategorie Activity Graphs Performance Graphs Web Graphs Activity Reports Performance Reports Namen der Auswertungen Running Virtual Users / Rendezvous / TPS (Passed) / TPS (Failed) Data Point / Percentile / Performance under Load (Running Users) / Transaction Performance / Transaction Performance Summary / Transaction Performance Summary by User / Transaction Distribution) Connection per Second / Throughput Scenario Execution / Failed Transactions / Failed Vuser / Rendezvous Data Point / Detailed Transaction / Transaction Performance Summary / Transaction Performance by User / Performance under Load Tabelle 10 Auswertungsmöglichkeiten des LoadRunners

44 Kapitel 4: Evaluation der Werkzeuge 37 In der Abbildung 12 sieht man als Beispiel den Percentile Graph, über den die Quantile ermittelt werden können. Abbildung 12 Screenshot des LoadRunner Analysis Ergebnisse der Tests Die Antwortzeiten des Mapkit Search Tests und des Mapkit Intern Test sind aus der Tabelle 11 zu entnehmen. Die verschiedenen Messungen der durchschnittlichen Antwortzeit wichen bei den Mapkit Search Tests um maximal 3% bzw. 5%, bei den Mapkit Intern Tests um maximal 3% ab. Mapkit Search Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 12,85 Sek. 12,59 Sek. 13,43 Sek. Minimale Antwortzeit 4,88 Sek. 3,81 Sek. 7,41 Sek. Maximale Antwortzeit 20,43 Sek. 19,62 Sek. 29,35 Sek. Mapkit Intern Thread Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 36,33 Sek. 35,85 Sek. 37,29 Sek. Minimale Antwortzeit 16,82 Sek. 12,92 Sek. 21,20 Sek. Maximale Antwortzeit 50,56 Sek. 47,88 Sek. 54,16 Sek. Mapkit Intern Prozeß Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 34,16 Sek. 33,08 Sek. 34,67 Sek. Minimale Antwortzeit 19,05 Sek. 14,89 Sek. 21,58 Sek. Maximale Antwortzeit 48,41 Sek. 46,93 Sek. 50,44 Sek. Tabelle 11 Antwortzeiten der Mapkit Tests mit LoadRunner Auffällig beim Mapkit Search Test war, daß bei einer bestimmten Einstellung in den Runtime Settings die mittlere Antwortzeit bei 15,83 Sekunden, also ca. 23% höher als die anderen gemessenen Werte, lag. Diese Messungen konnten aber nicht reproduziert werden.

45 Kapitel 4: Evaluation der Werkzeuge 38 Leider war es mit LoadRunner nicht möglich, genau die Requests abzusetzen, die auch der Browser abgesetzt hatte. Beim Mapkit Search Test beispielsweise wurden vier HTML Seiten doppelt aufgerufen, d.h. es wurden 30 statt der gewünschten 26 Requests abgesetzt. Beim Mapkit Intern Test war ein Unterschied zu sehen, ob der virtuelle Benutzer als Thread oder als Prozeß gestartet wurde. Der Mittelwert bei der Prozeßausführung lag bei 34,16 Sekunden, als Thread bei 36,33 Sekunden, also eine Erhöhung der Antwortzeit von ca. 6,4%. Dieser Unterschied ist nicht durch begrenzte Systemressourcen zu erklären, die CPU Belastung lag, wie in Abschnitt beschreiben, zwischen 37% und 43%. Beim IIS Test hatte LoadRunner keine Probleme, sowohl die Cookies als auch die SessionID s und die SSL Verschlüsselung wurden einwandfrei unterstützt.

46 Kapitel 4: Evaluation der Werkzeuge PerformanceStudio Das PerformanceStudio von Rational ist eine Weiterentwicklung des Produkts Performix. Die Produkte SQA Suite für die GUI User und PreVUE für die Web User gingen darin ein. Es kann GUI User und Web User bzw. Datenbank User testen, RTE User wie bei LoadRunner können nicht simuliert werden. PerformanceStudio unterstützt folgende Protokolle bzw. Anwendungen: Datenbank (MS SQL Server, Oracle, Sybase) Internet (HTTP) Applikationsserver (Tuxedo) Socket Calls Das PerformanceStudio besteht aus den Komponenten Robot zum Aufzeichnen von Skripten und Loadtest zum Anpassen der Skripte, Aufbau der Szenarien, Ablauf der Simulation und Auswertung der Ergebnisse. Zusätzlich gibt es noch den Administrator, den Testmanager und SiteCheck. PerformanceStudio ist das einzige unter den hier evaluierten Produkten, bei dem es eine Benutzerverwaltung gibt. Hierfür und für die Projektverwaltung ist der Administrator zuständig. Mit dem Testmanager wird die Testplanung durchgeführt und es werden die Tests verwaltet. Das Tool SiteCheck prüft die Links von HTML Seiten von einer bestimmten Seite aus, indem er die zu der Web Site gehörigen Links weiterverfolgt und die externen Links testet Ressourcenverbrauch Die Programme Robot, Master und GUI Agent laufen auf Windows NT4.0, der Virtual User Agent läuft auf Windows NT4.0, Solaris 2.6, AIX4.X und HP UX 10.X und 11.X. Die Hardwareanforderungen von Rational an die Komponenten des PerformanceStudio sind in Tabelle 12 aufgelistet.

47 Kapitel 4: Evaluation der Werkzeuge 40 Komponente Speicher (mind./ CPU Plattenplatz Betriebssystem empfohlen) Robot 64/128 MB MB Windows NT4.0 Master 64MB MB Pentium- 71 MB Windows NT4.0 pro virt. User 166 VU Agent 64MB MB Pentium- 26 MB Windows NT4.0 pro virt. User 166 VU Agent 32MB + 0,5 1,5 MB pro virt. User k.a. 40 MB Solaris2.6, AIX4.X und HP UX10.X/11.X Tabelle 12 Hard und Softwareanforderung an das PerformanceStudio Bei den Mapkit Search Tests lag die Prozessorauslastung durchschnittlich zwischen 43% und 47%, bei den Mapkit Intern Tests zwischen 52% und 64%. Der Hauptspeicherverbrauch lag für den Start des Masters bei ca. 13 MB. Bei der Ausführung des Testskripts wurden beim Beginn des Test 2,3 MB pro virtuellem Benutzer verbraucht. Je nach Länge des Tests stieg der Verbrauch auf bis zu 7 MB pro virtuellem Benutzer beim Mapkit Intern Test an. Dieses Verhalten zeigt sich nicht, wenn Denkzeiten in den Skripten benutzt werden Aufzeichnen Der Robot hat drei Möglichkeiten, die Testskripte automatisiert zu erstellen. Die erste Möglichkeit ist, daß er sich als Proxy zwischen den Browser und den Web Server hängt. Bei der zweiten Möglichkeit hängt sich der Robot in die Winsock API und horcht dort die Requests ab. Bei der dritten Möglichkeit zeichnet es den Netzwerkverkehr über die Netzwerkkarte auf. Es ist nicht möglich, SSL verschlüsselten HTTP Verkehr aufzeichnen, dies soll aber ab der Version 7.1 realisiert sein Lastgenerator Szenarien, bei PerformanceStudio Schedules genannt, werden über einen Baum definiert, in dem die Benutzergruppen den Testskripten zugeordnet werden. In Abbildung 13 im mittleren Fenster ist ein einfacher Schedule zu sehen. Falls mehrere Testskripte einer Benutzergruppe zugeordnet werden sollen, kann das über einen Selector geschehen. Damit kann festgelegt werden, auf welche Weise das nächste auszuführende Testskript ausgewählt wird, z.b. sequentiell, durch eine

48 Kapitel 4: Evaluation der Werkzeuge 41 Zufallsauswahl mit vorgegebenen Gewichtungen oder gewichtet nach der Zeit, die das Testskript verbraucht. Die Testskripte vom PerformanceStudio werden im Vergleich zu den Testskripten anderer Performancetesttools sehr lang. Im Anhang A.2 ist ein Beispiel eines Testskripts vom PerformanceStudio abgedruckt. Für jeden HTTP Request werden alle HTTP Headereinträge komplett im Testskript wiedergegeben. Diese Maßnahme kann zwar die Qualität des Simulation erhöhen, macht die Testskripte aber auch unübersichtlicher und damit schwerer wartbar. PerformanceStudio unterstützt außer HTTP keine anderen Internet Protokolle wie FTP oder SMTP mit speziellen Befehlen. Abbildung 13 Screenshot des PerformanceStudios während eines Lasttests Analyse Während des Lasttests kann die Tätigkeit der virtuellen Benutzer über Summary Graphen, welche die kumulierten Tätigkeiten der virtuellen Benutzer darstellen, und User Views, welche die Tätigkeiten der einzelnen virtuellen Benutzer

49 Kapitel 4: Evaluation der Werkzeuge 42 darstellen, beobachtet werden. Die Analysekomponente des PerformanceStudios besteht aus sieben Reports: LogViewer (zeigt das Log des Testlaufs und evtl. vorhandene Fehler) Analog (Fehler Log) Response (zeigt die einzelnen Antwortzeiten graphisch an) Performance (Abbildung 14) Status (Fehlerübersicht über die einzelnen Requests) Trace (einzelne Transaktionszeiten und Fehler) Usage (Durchsatz und kumulative Statistiken) Abbildung 14 Screenshot des Performance Reports des PerformanceStudios Ergebnisse der Tests PerformanceStudio setzt genau die gleichen HTTP Requests ab wie der Browser. Hier kommt dem Tool das Prinzip zugute, jeden Request aufzuzeichnen und wieder abzuspielen In der Tabelle 13 stehen die Antwortzeiten des Mapkit Search Tests und des

50 Kapitel 4: Evaluation der Werkzeuge 43 Mapkit Intern Tests. Die Einzelwerte weichen beim Mapkit Search Test um maximal 4%, beim Mapkit Intern Test um maximal 3% davon ab. Mapkit Search Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 10,67 Sek. 10,28 Sek. 10,95 Sek. Minimale Antwortzeit 2,83 Sek. 2,59 Sek. 3,30 Sek. Maximale Antwortzeit 21,65 Sek. 19,66 Sek. 24,75 Sek. Mapkit Intern Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 32,28 Sek. 31,62 Sek. 33,34 Sek. Minimale Antwortzeit 17,63 Sek. 11,30 Sek. 23,29 Sek. Maximale Antwortzeit 45,66 Sek. 43,30 Sek. 49,33 Sek. Tabelle 13 Antwortzeiten der Mapkit Tests mit dem PerformanceStudio Ebenso wie LoadRunner bereitete der IIS Test dem PerformanceStudio keine Probleme.

51 Kapitel 4: Evaluation der Werkzeuge SilkPerformer 2.6 Der SilkPerformer ist eine Weiterentwicklung des Programms SQLbench von der damals gleichnamigen Firma, welches Performancetests auf ODBC Datenbanken durchführen kann. Seit der Version 3.0 beherrscht SilkPerformer neben dem HTTP Protokoll auch das IIOP und Tuxedo Protokoll und ist somit in der Lage, auch Corba Komponenten und Tuxedo Applikationsserver zu testen. Beim SilkPerformer kann kein GUI oder RTE User getestet werden. Für den GUI User gibt es das Produkt SilkTest von der Firma Segue, welches über das Produkt SilkRealizer mit dem SilkPerformer zusammen gesteuert werden kann. SilkTest und SilkRealizer müssen allerdings gesondert erworben werden. Der SilkPerformer besteht aus den Komponenten Recorder, Performer und Reporter. Der Recorder ist für das Aufzeichnen der Testskripte verantwortlich, im Performer findet die Anpassung der Skripte, die Szenarioerstellung und die Durchführung der Lasttests statt. Mit dem Reporter werden die Lasttests ausgewertet Ressourcenverbrauch Komponente Speicher (mind./ CPU Plattenplatz Betriebssystem empfohlen) Controller/ 64 MB plus 1 MB Pentium k.a. Windows NT4.0 Agent pro virt. Benutzer Recorder 16 MB/32 MB k.a. Windows95 oder Windows NT4.0 Tabelle 14 Hard und Softwareanforderung an den SilkPerformer Die Prozessorauslastung lag bei den Mapkit Search Tests zwischen 13% und 15%, bei den Mapkit Intern Tests zwischen 20% und 21%. Der Hauptspeicherverbrauch für den Start des SilkPerformers liegt bei ca. 2,3 MB, beim Lasttest werden pro virtuellen Benutzer ca. 1,4 MB bis 1,8 MB benötigt Aufzeichnen Der Recorder von SilkPerformer verhält sich wie ein Proxy. Er zeichnet jeden HTTP Request auf, sowohl HTML Seiten wie auch Grafiken. SSL Verschlüsselung wird ab der Version 2.6 unterstützt, wobei dort nicht mehr ein einfacher

52 Kapitel 4: Evaluation der Werkzeuge 45 Proxy, der die Requests aufzeichnet und an den Web Server weitergibt, implementiert wurde. Der Recorder gibt sich dem Browser gegenüber als Web Server aus, mit dem eine SSL Verbindung aufgebaut wird. Dem zu testenden Web Server gibt der Recorder sich als Browser aus, mit dem er auch eine SSL Verbindung initiiert. Abbildung 15 zeigt den Recorder während des Aufzeichnens von HTTP Requests. Abbildung 15 Screenshot des Recorders des SilkPerformers Das Testskript des SilkPerformers vermengt die Requests mit der Szenarioerstellung. So werden im Skript die Benutzergruppen und deren auszuführenden Transaktionen definiert. Die Anzahl der Benutzer und die Auswahl der Lastgeneratoren wird jedoch später im Controller festgelegt. So ist eine klare Trennung zwischen dem Testskript und dem Szenario, in welches das Testskript eingebettet ist, nicht gegeben. Die Synchronisation der virtuellen Benutzer und das Einbinden von Datenquellen für die Eingaben der virtuellen Benutzer muß per Hand codiert werden. Diese Angaben können nicht, wie in LoadRunner oder PerformanceStudio, graphisch erstellt werden. In Abbildung 16 ist die Skripting Umgebung des SilkPerformers abgebildet. Der Baum auf den linken Bildschirmhälfte ist hauptsächlich zur Navigation im Skript gedacht, dort werden alle Teile des Skripts als Icon abgebildet. Das rechte Teilfenster stellt den Editor dar und im unteren Teilfenster werden die Compilermeldungen ausgegeben.

53 Kapitel 4: Evaluation der Werkzeuge 46 Abbildung 16 Screenshot der Skripting Umgebung des SilkPerformers Lastgenerator Die Kommunikation geschieht über ein Windows NT Netzwerk. Die Kommunikation zwischen dem Controller und den Lastgeneratoren geschieht über DCOM, die Testskripte und die gemessenen Daten werden über ein Shared Directory ausgetauscht. SilkPerformer kann, wie auch LoadRunner, verschiedene Netzwerkgeschwindigkeiten, wie z.b bps simulieren. Ein Timeout, wie lange ein Request maximal dauern darf, kann nicht festgelegt werden. SilkPerformer kann über die Kommandozeile aufgerufen werden, wodurch ein Monitoring möglich ist. Die Protokolle HTTP, HTTPS, SMTP, POP3, FTP, NNTP und LDAP werden explizit unterstützt Analyse Während des Lasttests werden, wie in Abbildung 17 zu sehen ist, umfangreiche Angaben zu jedem virtuellen Benutzer gemacht, sie werden aber nicht graphisch aufbereitet. Die gemessenen Performancedaten können jedoch dem NT Performancemonitor übergeben und so angezeigt werden.

54 Kapitel 4: Evaluation der Werkzeuge 47 Abbildung 17 Screenshot des SilkPerformers während eines Lasttests Es wird pro Lasttest und virtuellem Benutzer ein Resultfile erzeugt, das aber beim folgenden Lasttest wieder überschrieben wird. Auf Benutzergruppen verdichtete Informationen werden in eine ODBC Datenbank geschrieben. Für jede Transaktion bekommt man pro Benutzergruppe nur die Angaben minimale, maximale und durchschnittliche Antwortzeit. Quantile oder Varianzen werden in der Analyse nicht berechnet. Abbildung 18 zeigt die tabellarische Auswertung der Analysekomponente. Die einzelnen Zeiten der Transaktionen können nur durch Programmierung mit der Skriptsprache BDL (Benchmark Definition Language) gewonnen werden. Folgenden Kennzahlen können jeweils als Summe und als Durchsatz pro Sekunde, Minute und Stunde ausgegeben werden: Transactions SQL Commands SQL / Web Errors Data received / sent Requests sent / received Successful / Failed connects URL Redirection Successful sessions / Session failures Authentication failures Session time Cookies sent / received

55 Kapitel 4: Evaluation der Werkzeuge 48 Abbildung 18 Screenshot der Analysekomponente des SilkPerformer Neben dieser Analysekomponente gibt es noch die Auswertung von Zeitserien Daten, also Daten, die im Zeitverlauf gesammelt werden. Die Daten über Die Anzahl der Transaktionen Die empfangen / gesendet Daten Die erfolgreichen / fehlgeschlagenen Connects Die Anzahl der HTTP Redirections Die Anzahl der aktiven SilkPerformer Threads können im Zehn Sekundentakt gesammelt und ausgewertet werden Ergebnisse der Tests In Tabelle 15 sind die Antwortzeiten der Mapkit Tests aufgeführt. Die von SilkPerformer aufgezeichneten HTTP Requests wichen wie beim Performance- Studio nicht von den HTTP Requests des Browsers ab. Beim Mapkit Search Test wichen die einzelnen durchschnittlichen Antwortzeiten um maximal 3% von der gemittelten durchschnittlichen Antwortzeit ab, beim Mapkit Intern Test lag die Abweichung bei maximal 2%.

56 Kapitel 4: Evaluation der Werkzeuge 49 Mapkit Search Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 10,10 Sek. 9,82 Sek. 10,33 Sek. Minimale Antwortzeit 3,19 Sek. 1,40 Sek. 3,73 Sek. Maximale Antwortzeit 18,94 Sek. 17,01 Sek. 22,39 Sek. Mapkit Intern Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 30,09 Sek. 29,89 Sek. 30,62 Sek. Minimale Antwortzeit 9,72 Sek. 5,10 Sek. 17,92 Sek. Maximale Antwortzeit 47,02 Sek. 45,17 Sek. 49,37 Sek. Tabelle 15 Antwortzeiten der Mapkit Tests mit SilkPerformer Mit dem Lieferumfang der SilkPerformers konnte die SSL Verschlüsselung zunächst nicht getestet werden, es gibt aber einen SSL Recorder auf der Web Site von Segue, den man downloaden kann. Damit war der IIS Test für den SilkPerformer problemlos durchführbar.

57 Kapitel 4: Evaluation der Werkzeuge WebLoad 3.0 WebLoad von der Firma Radview Software, das von der Firma Platinum technology inc. unter dem Namen Final Exam Webload 9 vermarktet wird, besteht aus fünf Komponenten: dem Agenda Authoring Tool (AAT), dem WebLoad Monitor Test Controller, kurz Monitor, der Load Generator Software, auch Load Server, der Probing Client Software und dem TestTalk. Die Aufgabe des Agenda Authoring Tools besteht im Aufzeichnen von Testskripten. Der Monitor ist die Zentrale von WebLoad. Er startet und überwacht die Lasttests, kommuniziert mit den Probing Clients und Load Servern und zeigt die Ergebnisse an. Der Load Server bekommt das Testskript, generiert die virtuellen Benutzer, führt den Test durch und liefert seine Meßergebnisse an den Monitor. Der Probing Client simuliert im Gegensatz zum Load Server nur einen virtuellen Benutzer. TestTalk ist der Netzwerk Agent, der für die Kommunikation zwischen dem Monitor und den Load Servern bzw. den Probing Clients verantwortlich ist. Nach [Veer99], einem Artikel der Patricia Seybold Group, soll WebLoad die Nische zwischen den einfachen Web Server Performancetesttools wie InetLoad auf der einen Seite und großen, unternehmensweiten Performancetesttools wie LoadRunner oder PerformanceStudio auf der anderen Seite, ausfüllen Ressourcenverbrauch Komponente Speicher (mind./ CPU Plattenplatz Betriebssystem empfohlen) Monitor/ Probing Client 32 MB Pentium 20 MB Windows 95 oder Windows NT4.0 LoadServer 64 MB Pentium MB Windows NT3.51 oder Windows NT4.0 Tabelle 16 Hard und Softwareanforderung an WebLoad 9 siehe

58 Kapitel 4: Evaluation der Werkzeuge 51 Bei den Mapkit Search Tests lag die Prozessorauslastung zwischen 11% und 13%, bei den Mapkit Intern Tests zwischen 17% und 19%. Der Hauptspeicherverbrauch lag für den Start des Monitors bei ca. 9,5 MB, pro virtuellem Benutzer wurden ca. 560 KB verbraucht Aufzeichnen Das Agenda Authoring Tool (AAT) gibt es in zwei Versionen, als Universal AAT und AAT for Explorer. Der Universal AAT arbeitet wie der Recorder von SilkPerformer mit allen Browsern auf Proxy Basis zusammen, kann aber keine SSL verschlüsselte HTTP Requests aufzeichnen. Für diesen Fall ist der AAT for Explorer gedacht, er kann verschlüsselte HTTP Requests aufzeichnen, arbeitet aber nur mit dem Internet Explorer 3.01 oder 4.0 zusammen. Der AAT for Explorer arbeitet nicht als Proxy. Beide AAT s laufen unter Windows NT oder Windows 95. Die Skiptsprache ist seit der Version 3.0 JavaScript. Abbildung 19 Screenshot des AAT von WebLoad Lastgenerator Die Szenarioerstellung ist ebenso wie bei LoadRunner über einen Wizard möglich. Das Szenario wird wie ein Baum aufgebaut, in Abbildung 20 auf der linken Bildhälfte zu erkennen. Eine Load Session kann mehrere Hosts haben, auf denen Load Generatoren oder Probing Clients laufen. Ein Probing Client kann nur ein Testskript ausführen, dem Load Generator können mehrere Testskripte zugewiesen werden.

59 Kapitel 4: Evaluation der Werkzeuge 52 Die Testskripte können entweder zu den einzelnen Hosts geschickt werden oder die Hosts holen sie sich über ein shared directory. Die Dauer der Simulation kann nur über die Angabe eines Zeitraums festgelegt werden. Es kann keine Anzahl von Iterationen angegeben werden. Eine automatische Lastraumexploration ist möglich, indem Ziele quantifiziert werden und ein Inkrement angegeben wird. Es werden jedoch nur Benutzer hinzugenommen, d.h. nach Erreichen des Ziels wird nicht versucht, die Benutzeranzahl genauer zu bestimmen, sondern man beläßt es bei der erreichten Benutzeranzahl. Abbildung 20 Screenshot des WebLoad Masters während des Lasttests Analyse Während des Lasttest können über einen Servermonitor die Leistungsdaten eines Windows NT Servers auf dem Monitor Computer angezeigt werden. Alle Statistiken, die nach dem Test abgerufen werden können, sind auch während des Lasttests verfügbar. Die Statistiken geben Auskunft über:

60 Kapitel 4: Evaluation der Werkzeuge 53 Load Size Transactions Per Second / Successful Transactions Per Second Rounds Per Second / Successful Rounds Per Second / Failed Rounds Per Second Throughput (Bytes Per Second) Response Data Size Round / Transaction / Connect / Send / Response / Process Time Rounds / Successful Rounds / Failed Rounds Transactions/Successful Transactions Attempted Connections/Successful Connections Responses HTTP Response Status 200 In der WebLoad Terminologie ist eine Round ein kompletter Durchlauf eines Testskripts Ergebnisse der Tests In Tabelle 17 werden die über alle mit WebLoad durchgeführten Tests gemittelten Antwortzeiten des Mapkit Search Test und des Mapkit Intern Test dargestellt. Die Ergebnisse der durchschnittlichen Antwortzeit schwankten beim Mapkit Search Test um maximal drei Prozent und beim Mapkit Intern Test um maximal zwei Prozent. Mapkit Search Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 9,90 Sek. 9,57 Sek. 10,22 Sek. Minimale Antwortzeit 8,20 Sek. 6,79 Sek. 8,93 Sek. Maximale Antwortzeit 11,17 Sek. 10,47 Sek. 12,27 Sek. Mapkit Intern Mittelwert Minimum Maximum Durchschnittl. Antwortzeit 28,91 Sek. 28,31 Sek. 29,41 Sek. Minimale Antwortzeit 18,50 Sek. 14,61 Sek Sek. Maximale Antwortzeit 35,59 Sek. 33,31 Sek. 40,16 Sek. Tabelle 17 Antwortzeiten der Mapkit Tests mit WebLoad Bei dem Durchlauf des Mapkit Search Tests setzte WebLoad 36 statt der geforderten 26 Requests ab. Dies läßt sich dadurch erklären, daß in der HTML Seite /oeffentl/service/service.html die Grafik space2.gif elfmal verwendet wird. Der Browser holt sich diese Datei einmal und befriedigt die restlichen zehn

61 Kapitel 4: Evaluation der Werkzeuge 54 Requests durch seinen Cache. WebLoad jedoch setzt elf Requests statt des gewünschten einen Requests ab. HTTP Requests, die einen 4XX Code von HTTP, also einen Fehler, verursachen, führt WebLoad nicht durch und kommentiert sie im Skript aus. Beispiele für solche Fehler sind broken links oder unauthorisierte Zugriffe. Falls doch ein Fehler auftreten sollte, bricht WebLoad das Skript ab und startet es erneut. Das führt bei dem Mapkit Search Test dazu, daß ein Request an eine fehlende GIF Datei nicht gestellt wird, was aber das Ergebnis nicht stark verfälscht. Beim Mapkit Intern Test werden jedoch neben diesem GIF noch vier weitere Requests, die unauthorisiert sind, nicht gestellt, was die Ergebnisse deutlich verfälscht. Die Ergebnisse der Mapkit Tests sind etwas überraschend, weil die Differenz zwischen der maximalen und minimalen Antwortzeit sehr gering ist. Bei den anderen Werkzeugen lag beispielsweise die Differenz beim Mapkit Search Test zwischen 12,36 und 18,82 Sekunden, bei WebLoad bei 2,97 Sekunden. Die zweite Auffälligkeit war, daß WebLoad beim Mapkit Search Test trotz der oben genannten 36 statt der geforderten 26 Requests die kürzeste durchschnittliche Antwortzeit aller Performancetesttools hatte. Beim IIS Test konnte die Wiedergabe nicht SSL verschlüsselt werden, weil diese Funktion bei der evaluierten Evaluation Copy gesperrt war. Der Test ließ sich aber mit dem AAT for Explorer verschlüsselt aufzeichnen. Mit Cookies oder der SessionID gab es keine Probleme.

62 Kapitel 4: Evaluation der Werkzeuge e Load Das Werkzeug e Load von RSW Software ist eingebettet in die e Test Suite, welche aus den Werkzeugen e Tester, e Load, e Spider und e Monitor besteht. E Tester ist ein Werkzeug zum funktionalen Test von webbasierten Applikationen, es ist speziell für die Produkte Net Dynamics, Web Objects, Cold Fusion von Allaire und ASP von Microsoft ausgerichtet. Mit e Tester werden die Skripts für e Load aufgezeichnet. E Spider folgt jedem Link auf der Website und erstellt so eine Karte der zu testenden Website. Daraus kann automatisch ein Skript generiert werden. Die Komponente e Monitor ist für das Monitoring einer Website gedacht. E Monitor kann e Tester Skripte nutzen, bringt aber auch 50 eigene Monitoring Skripte mit. Bei einem Fehler kann es eine Nachricht über E Mail schicken oder über CA Unicenter oder Tivoli den Administrator benachrichtigen Ressourcenverbrauch Komponente Speicher CPU (mind./ Plattenplatz Betriebssystem (mind.) empf.) e Test Suite 32 MB 486 / Pentium 20 MB Windows NT4.0 oder Windows 95 Tabelle 18 Hard und Softwareanforderung an e Load Zusätzlich zu den in Tabelle 18 spezifizierten Anforderungen muß der Internet Explorer 4.01 installiert sein. Beim Ressourcenverbrauch konnten nur die Werte des Mapkit Search Tests berücksichtigt werden, weil der Mapkit Intern Test nicht aufgezeichnet werden konnte. Die CPU Belastung lag bei der Ausführung eines virtuellen Benutzers als Thread zwischen 39% und 41%, bei Ausführung als Prozeß zwischen 59% und 61%. Hierbei ist jedoch anzumerken, daß e Load eine permanente Ausgabe von Online Informationen hat, die nicht abgeschaltet werden kann. Bei den anderen Performancetesttools wurde diese, falls vorhanden, auf ein Minimum reduziert. Der Hauptspeicherverbrauch lag bei ca. 3,5 MB für den Controller, zwischen 1,1 MB und 1,3 MB pro virtuellem Benutzer bei Ausführung als Thread und zwischen 2,8 MB und 3,2 MB bei Ausführung als Prozeß.

63 Kapitel 4: Evaluation der Werkzeuge Aufzeichnen E Load kann die Skripte von e Tester, einem funktionalen Testwerkzeug, verwenden. Mit dem e Tester werden die Skripts für beide Testarten, funktional und Lasttest, aufgezeichnet. Leider war es nicht möglich, den Mapkit Intern Test mit e Tester so aufzuzeichnen, weil e Tester Probleme mit der Authentifizierung für den internen Bereich des Mapkit Servers hatte. Aufgezeichnet wird über einen im e Tester eingebetteten Browser. Über diesen können auch, wie beim Astra QuickTest, die einzelnen Schritte wiedergegeben werden, wenn es gewünscht wird. Abbildung 21 Screenshot des e Testers Lastgenerator Die Szenarioerstellung geht mit e Load recht schnell von der Hand. Profile bestehen aus mehreren Skripten und Synchronisationspunkten, diese werden bei der Szenarioerstellung der Benutzeranzahl und weiteren Parametern, die in Abbildung 22 gezeigt werden, zugewiesen und dann in den sogenannten Autopiloten kopiert. Dort wird der Ablauf des Tests festgelegt, z.b. ob alle Benutzer gleichzeitig starten, wann der Test endet oder ob eine Pause zwischen den Iterationen eingefügt wird.

64 Kapitel 4: Evaluation der Werkzeuge 57 Abbildung 22 Screenshot der Szenarioerstellung mit e Load Analyse Während des Lasttests werden für jeden Benutzer das Skript, die Anzahl der Wiederholungen, die Seite, die gerade geladen wird und die Fehler angezeigt. Es gibt auch umfangreiche Online Auswertungen. Performance vs. User Graph Errors vs. Users Graph Performance vs. Time Graph Errors vs. Time Graph Users vs. Time Graph Statistics vs. Time Graph Die Abbildung 23 zeigt die weiteren Auswertungen, die e Load zur Verfügung stellt.

Simulation von Computer- und Kommunikationssystemen

Simulation von Computer- und Kommunikationssystemen Computer und Kommunikationssysteme Nachbildung der Verarbeitung in Rechnern und Kommunikation in Netzwerken Belegung und Auslastung von Systemressourcen Analyse von Systemverhalten Systemleistung in der

Mehr

Internet und WWW Übungen

Internet und WWW Übungen Internet und WWW Übungen 6 Rechnernetze und Datenübertragung [WEB6] Rolf Dornberger 1 06-11-07 6 Rechnernetze und Datenübertragung Aufgaben: 1. Begriffe 2. IP-Adressen 3. Rechnernetze und Datenübertragung

Mehr

Intrusion Detection & Response

Intrusion Detection & Response Intrusion Detection & Response Seminararbeit im SS 2002 (4. Semester Bachelor) von Uwe Hoffmeister 900 1840 Christian Klie 900 1882 Tobias Schmidt 900 1883 Seite 1 von 132 Version vom 17.04.2002 1. Verzeichnisse

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

Internet Information Services v6.0

Internet Information Services v6.0 Internet Information Services v6.0 IIS History Evolution von IIS: V1.0 kostenlos auf der CeBit 1996 verteilt V2.0 Teil von Windows NT 4.0 V3.0 Als Update in SP3 von NT4.0 integriert V4.0 Windows NT 4.0

Mehr

Lasttestbericht BL Bankrechner

Lasttestbericht BL Bankrechner Lasttestbericht BL Bankrechner Business-Logics GmbH Inhaltsverzeichnis 1 Testumgebung 2 1.1 Hardwareversionen........................ 2 1.2 Softwareversionen........................ 3 1.3 Datenbestand..........................

Mehr

Netzwerkperformance 2.0

Netzwerkperformance 2.0 Netzwerkperformance 2.0 Die KPI`s als Schlüsselfaktoren der Netzwerke Andreas Dobesch, Product Manager DataCenter Forum 2014, Trafo Baden ISATEL Electronic AG Hinterbergstrasse 9 CH 6330 Cham Tel. 041

Mehr

Ein kleines Computer-Lexikon

Ein kleines Computer-Lexikon Stefan Edelmann 10b NIS-Klasse Ein kleines Computer-Lexikon Mainboard Die Hauptplatine! Sie wird auch Motherboard genannt. An ihr wird das gesamte Computerzubehör angeschlossen: z.b. Grafikkarte Soundkarte

Mehr

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung Methoden und Werkzeuge zur Softwareproduktion WS 2003/04 Karsten Beyer Dennis Dietrich Überblick Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung 2 Motivation Funktionstest

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Technische Grundlagen von Internetzugängen

Technische Grundlagen von Internetzugängen Technische Grundlagen von Internetzugängen 2 Was ist das Internet? Ein weltumspannendes Peer-to-Peer-Netzwerk von Servern und Clients mit TCP/IP als Netzwerk-Protokoll Server stellen Dienste zur Verfügung

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr

Application Performance Management. Auch eine Frage des Netzwerkes?

Application Performance Management. Auch eine Frage des Netzwerkes? Application Performance Management Auch eine Frage des Netzwerkes? Agenda Architektur von Webanwendungen Lange Applikationsantwortzeiten Application Performance Management (APM) Netzwerkbasiertes APM Serverbasiertes

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Internet - Grundzüge der Funktionsweise. Kira Duwe

Internet - Grundzüge der Funktionsweise. Kira Duwe Internet - Grundzüge der Funktionsweise Kira Duwe Gliederung Historische Entwicklung Funktionsweise: -Anwendungen -Rechnernetze -Netzwerkschichten -Datenkapselung -RFC -Verschiedene Protokolle (Ethernet,

Mehr

Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux

Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux Jan H. Bartels XXX XXX XXX XXX XXX Einführung Leistungskennzahlen & Komponenten Methoden der Leistungsanalyse Zusammenfassung XXX XXX 23.06.2011

Mehr

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1 Telekommunikationsnetze 2 Breitband ISDN Lokale Netze Internet Martin Werner WS 2009/10 Martin Werner, November 09 1 Breitband-ISDN Ziele Flexibler Netzzugang Dynamische Bitratenzuteilung Effiziente Vermittlung

Mehr

Web Services. Einlußfaktoren der Performance Bottleneck Analyse

Web Services. Einlußfaktoren der Performance Bottleneck Analyse Web Services Einlußfaktoren der Performance Bottleneck Analyse Beispiel: Intranet Performance Help Desk Applikation Web Server mit DB für FAQs über verbreitete Hard- oder Softwareprobleme und Lösungen

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Makologa Touré Damian Gawenda

Makologa Touré Damian Gawenda Vortrag von Makologa Touré Damian Gawenda im ITT am 08. August 2006 07.08.06 Makologa Touré Damian Gawenda 1 Übersicht Was ist ein WMS? Web-Technologien Wie installiere ich einen Web-Map-Server? 07.08.06

Mehr

Vorwort... 5. Vorwort zur deutschen Übersetzung... 11

Vorwort... 5. Vorwort zur deutschen Übersetzung... 11 Vorwort.................................................... 5 Vorwort zur deutschen Übersetzung........................... 11 1 Einführung................................................ 23 1.1 Einführung................................................

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Diplomarbeit. Planung eines Webauftritts. Ein Leitfaden für kleine und mittelständische Unternehmen. Daniel Jurischka. Bachelor + Master Publishing

Diplomarbeit. Planung eines Webauftritts. Ein Leitfaden für kleine und mittelständische Unternehmen. Daniel Jurischka. Bachelor + Master Publishing Diplomarbeit Daniel Jurischka Planung eines Webauftritts Ein Leitfaden für kleine und mittelständische Unternehmen Bachelor + Master Publishing Daniel Jurischka Planung eines Webauftritts: Ein Leitfaden

Mehr

KN 20.04.2015. Das Internet

KN 20.04.2015. Das Internet Das Internet Internet = Weltweiter Verbund von Rechnernetzen Das " Netz der Netze " Prinzipien des Internet: Jeder Rechner kann Information bereitstellen. Client / Server Architektur: Server bietet Dienste

Mehr

Daniel Heß. Donnerstag, den 16. November 2006. Verein zur Förderung der privaten Internet Nutzung e.v. Wie funktioniert das Internet? dh@ping.

Daniel Heß. Donnerstag, den 16. November 2006. Verein zur Förderung der privaten Internet Nutzung e.v. Wie funktioniert das Internet? dh@ping. Daniel Heß Verein zur Förderung der privaten Internet Nutzung e.v. Donnerstag, den 16. November 2006 Was ist Ein globales Netzwerk von Computern und Kommunikationsgeräten Quelle für eine fast unendliche

Mehr

Chapter 11 TCP. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von

Chapter 11 TCP. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Chapter 11 TCP CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Einführung: Lasttests mit JMeter. Sitestress.eu Jesuitenmauer 24 33098 Paderborn www.sitestress.eu - karl@sitestress.eu - 05251 / 687060

Einführung: Lasttests mit JMeter. Sitestress.eu Jesuitenmauer 24 33098 Paderborn www.sitestress.eu - karl@sitestress.eu - 05251 / 687060 Einführung: Lasttests mit JMeter Agenda Über SITESTRESS.EU Tests planen Warum Lasttests? Testen Was ist JMeter? Ergebnisse analysieren Wie arbeitet JMeter? Beispiel JMeter-GUI Skripte für JMeter über SITESTRESS.EU

Mehr

Protokollanalyse bei VoIP

Protokollanalyse bei VoIP Protokollanalyse bei VoIP 1. Einführung 2. Protokoll Stack H.323 3. Protokollanalyse in VoIP-Umgebung Funktionelle Analyse Paketanalyse 4. Dimensionierungsaspekte bei VoIP Jitter-Theorie Bandbreite bei

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Performance Report OXID eshop 5.0 Enterprise Edition

Performance Report OXID eshop 5.0 Enterprise Edition Performance Report OXID eshop 5.0 Enterprise Edition supported by SysEleven September 2013 OXID esales AG www.oxid-esales.com info@oxid-esales.com 1/14 Copyright Kontakt OXID esales AG www.oxid-esales.com

Mehr

Wie funktioniert ein Internetprovider. Michael Stiller

Wie funktioniert ein Internetprovider. Michael Stiller Wie funktioniert ein Internetprovider Michael Stiller Donnerstag 20.01.2000 Ping e.v. Weiterbildung, Wie funktioniert ein Internetprovider 1 Anforderungen an einen Internetprovider oder was die Nutzer

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Internet Briefing. Developer Konferenz. Clientseitige Last- & Performancetesting. Namics.

Internet Briefing. Developer Konferenz. Clientseitige Last- & Performancetesting. Namics. Internet Briefing. Developer Konferenz. Clientseitige Last- & Performancetesting. Jürg Stuker. CEO. Partner. 8. Dezember 2011 Thema 1 Verstehen was zwischen User Agent und Server geschwatzt wird... 8.

Mehr

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen 2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen Dienste des Internets Das Internet bietet als riesiges Rechnernetz viele Nutzungsmöglichkeiten, wie etwa das World

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr

7 TCP/IP-Dienste konfigurieren

7 TCP/IP-Dienste konfigurieren 7 TCP/IP-Dienste konfigurieren In diesem Kapitel lernen Sie die Begriffe Ports,Sockets und Connections kennen (LPI 1: 109.1). den Zusammenhang der Ports von TCP/IP-Diensten mit der Datei /etc/services

Mehr

UDP-, MTU- und IP- Fragmentierung

UDP-, MTU- und IP- Fragmentierung UDP-, MTU- und IP- Fragmentierung Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung

Mehr

Klausur - Computernetzwerke

Klausur - Computernetzwerke Klausur - Computernetzwerke Márk Félegyházi Zeit: 1.5 Stunden, keine Hilfmaterialien Gesamtpuntke: 50 2011.04.12 Name der/den Studenten(innen): NEPTUN: ===================================================

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Apache JMeter. Arbeit von Bundi Beat, 6Ie. Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C.

Apache JMeter. Arbeit von Bundi Beat, 6Ie. Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C. Apache JMeter Arbeit von Bundi Beat, 6Ie Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: D. Gruntz, C.Nicola Windisch, 3. Juli 2003 Inhaltsverzeichnis 1. Was ist JMeter?...3

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 6: 14.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

SolarWinds Engineer s Toolset

SolarWinds Engineer s Toolset SolarWinds Engineer s Toolset Monitoring Tools Das Engineer s Toolset ist eine Sammlung von 49 wertvoller und sinnvoller Netzwerktools. Die Nr. 1 Suite für jeden Administrator! Die Schwerpunkte liegen

Mehr

Dokumentation für den IPCop-VPN Zugang mit Mac OS X

Dokumentation für den IPCop-VPN Zugang mit Mac OS X Dokumentation für den IPCop-VPN Zugang mit Mac OS X Mirco Schmidt 7. Januar 2006 Inhaltsverzeichnis 1. Mac OS X als Roadwarrior 5 1.1. Vorraussetzungen................................ 5 1.2. Konfiguration

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Messung des Online-Erfolges / Optimierung einer Website

Messung des Online-Erfolges / Optimierung einer Website Messung des Online-Erfolges / Optimierung einer Website Stuttgart, Mai 2001 Guido Hartmann Senior Project Manager Talstrasse 41 Stuttgart phone: +49.711.90717-177 guido.hartmann@pixelpark.com http://www.pixelpark.com

Mehr

Kapitel 6 Internet 1

Kapitel 6 Internet 1 Kapitel 6 Internet 1 Kapitel 6 Internet 1. Geschichte des Internets 2. Datenübertragung mit TCP/IP 3. Internetadressen 4. Dynamische Zuteilung von Internetadressen 5. Domain-Namen 6. Internetdienste 2

Mehr

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht TCP/IP Datenübertragungsschicht Netzwerkschicht Anwendungsschicht 1 Schichtenmodell Schichtenmodell der Internet- Protokollsuite Ziel: Kommunikation unterschiedlicher Rechner mit verschiedenen Betriebssystemen

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Internet. Werkzeuge und Dienste. Martin Scheller Klaus-Peter Boden Andreas Geenen Joachim Kampermann. Von Archie" bis World Wide Web"

Internet. Werkzeuge und Dienste. Martin Scheller Klaus-Peter Boden Andreas Geenen Joachim Kampermann. Von Archie bis World Wide Web Martin Scheller Klaus-Peter Boden Andreas Geenen Joachim Kampermann Internet Werkzeuge und Dienste Von Archie" bis World Wide Web" Herausgegeben von der Akademischen Software Kooperation Mit 130 Abbildungen

Mehr

VPN Tracker für Mac OS X

VPN Tracker für Mac OS X VPN Tracker für Mac OS X How-to: Kompatibilität mit DrayTek Vigor Routern Rev. 1.0 Copyright 2003 equinux USA Inc. Alle Rechte vorbehalten. 1. Einführung 1. Einführung Diese Anleitung beschreibt, wie eine

Mehr

Aufbau einer Testumgebung mit VMware Server

Aufbau einer Testumgebung mit VMware Server Aufbau einer Testumgebung mit VMware Server 1. Download des kostenlosen VMware Servers / Registrierung... 2 2. Installation der Software... 2 2.1 VMware Server Windows client package... 3 3. Einrichten

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Graphing - SNMP DATA - MRTG II

Graphing - SNMP DATA - MRTG II Graphing - SNMP DATA - MRTG II Netzwerkmanagement Software hat sich in den letzten Jahren vom hilfreichen Produkt zur integralen Grundlage für den professionellen IT Betrieb gewandelt. Grosse und leistungsfähige

Mehr

Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken

Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken Einleitungsvortrag zur Diplomarbeit: Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken --- Bernd Wollersheim --- --- wollersh@informatik.uni-bonn.de

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Vordefinierte Elemente (CI)

Vordefinierte Elemente (CI) 1 IIS Name 1.1 IIS Scans Scandatum, Direktes Bearbeiten der Metabasis ermöglichen, Version 1.1.1 Websites Name, Ausführberechtigung Dateien, Lesen, Nur Skripts ausführen, Skriptzugriff, Schreiben, Sicheren

Mehr

Windows Server 2012 R2

Windows Server 2012 R2 Windows Server 2012 R2 Eine Übersicht Raúl B. Heiduk (rh@pobox.com) www.digicomp.ch 1 Inhalt der Präsentation Die wichtigsten Neuerungen Active Directory PowerShell 4.0 Hyper-V Demos Fragen und Antworten

Mehr

Einführung. Übersicht

Einführung. Übersicht Einführung Erik Wilde TIK ETH Zürich Sommersemester 2001 Übersicht Durchführung der Veranstaltung Termine (Vorlesung und Übung) Bereitstellung von Informationen Einführung Internet Internet als Transportinfrastruktur

Mehr

Internetanbindung von Datenbanken

Internetanbindung von Datenbanken Internetanbindung von Datenbanken Oracle Application Server Oracle Application Server - 1 Gliederung Einführung Oracle Application Server (OAS) Praxis- und Diplomarbeitenverwaltung LiveHTML Kritik Becker,

Mehr

Microsoft Server 2012 Hyper-V Replica für Oracle Database

Microsoft Server 2012 Hyper-V Replica für Oracle Database Microsoft Server 2012 Hyper-V Replica für Oracle Database Seite 1 Inhalt 1 Executive Summary... 3 2 Windows Server 2012 R2 Hyper- V Replica Technologie- Review... 3 2.1 Begriffe... 3 2.2 Konfigurationsoptionen:...

Mehr

Konfigurationsanleitung Quality of Service (QoS) Funkwerk. Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.1.

Konfigurationsanleitung Quality of Service (QoS) Funkwerk. Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.1. Konfigurationsanleitung Quality of Service (QoS) Funkwerk Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.1 Seite - 1 - 1. Konfiguration von Quality of Service 1.1 Einleitung Im Folgenden

Mehr

RDS und Azure RemoteApp

RDS und Azure RemoteApp RDS und Azure RemoteApp Inhalt Remote Desktop Services Ein kurzer Überblick RD Session Host und RD Virtualization Host RDS auf Azure Desktop Remoting in der Cloud RD RemoteApp Was ist das und wie funktioniert

Mehr

Steigern Sie die Effizienz Ihrer IT. Das Instrument für ein vollständiges IT-System Management. Proaktiv, zentral und zuverlässig

Steigern Sie die Effizienz Ihrer IT. Das Instrument für ein vollständiges IT-System Management. Proaktiv, zentral und zuverlässig Steigern Sie die Effizienz Ihrer IT Das Instrument für ein vollständiges IT-System Management. Proaktiv, zentral und zuverlässig Über Würth Phoenix IT und Beratungsunternehmen der Würth-Gruppe Headquarter

Mehr

D r e ISP S P i m K l K as a s s e s n e r n au a m H.Funk, BBS II Leer

D r e ISP S P i m K l K as a s s e s n e r n au a m H.Funk, BBS II Leer Der ISP im Klassenraum H.Funk, BBS II Leer Überblick Agenda: Ziel des Workshops Grundlagen PPPoE Realisierung eines lokalen PPPoE Servers Port-Forwarding DNS / DDNS Ziel des Workshops Ein Netzwerk vergleichbar

Mehr

Realistische und aussagekräftige Lasttests mit loadit

Realistische und aussagekräftige Lasttests mit loadit Realistische und aussagekräftige Lasttests mit loadit 5. Juli 2012 Jens Müller NovaTec Ingenieure für neue Informationstechnologien GmbH Leinfelden-Echterdingen, München, Frankfurt am Main, Jeddah / Saudi-Arabien

Mehr

IT-Symposium 2008 04.06.2008. HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime 6/9/2008 1

IT-Symposium 2008 04.06.2008. HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime 6/9/2008 1 HOB RD VPN HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime Joachim Gietl Vertriebsleiter Central Europe 6/9/2008 1 HOB RD VPN Eine branchenunabhängige Lösung für alle Unternehmen die Ihren Außendienst

Mehr

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Software zur Annahme und Verarbeitung von HTTP/HTTPs- Requests (Port 80/443) benutzerdefinierte

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

Mehr

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Das Problem Die Abkündigungen seitens Microsoft von Forefront Threat Management Gateway (TMG) und

Mehr

Herzlich willkommen! 25.4. Bad Homburg 27.4. Hamburg 04.5. München

Herzlich willkommen! 25.4. Bad Homburg 27.4. Hamburg 04.5. München Herzlich willkommen! 25.4. Bad Homburg 27.4. Hamburg 04.5. München Storage over Ethernet NAS, iscsi, File Services Comeback des?! Agenda: Überblick Network Storage Hot for 2006 File Services WAFS / Acceleration

Mehr

Apache. O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo. Das umfassende Handbuch. Ben Laurie und Peter Laurie 2.

Apache. O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo. Das umfassende Handbuch. Ben Laurie und Peter Laurie 2. 2.AUFLAGE Apache Das umfassende Handbuch Ben Laurie und Peter Laurie Deutsche Übersetzung von Peter Klicman, Jochen Wiedmann & Jörgen W. Lang O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Service Delivery. erfolgreich einführen und betreiben

Service Delivery. erfolgreich einführen und betreiben Service Delivery erfolgreich einführen und betreiben Einführung und Betrieb eines neuen Service Nicht immer läuft bei der Einführung eines neuen Service oder einer Anwendung alles wie geplant! Keine termingerechte

Mehr

eytron VMS Webanwendung Fehlersuche und -Behebung

eytron VMS Webanwendung Fehlersuche und -Behebung eytron VMS Webanwendung Fehlersuche und -Behebung 2009 ABUS Security-Center GmbH & Co. KG, Alle Rechte vorbehalten Diese Anleitung soll Ihnen Unterstützung für den Fall geben, dass die Webanwendung nach

Mehr

Themen des Kapitels. 2 Übersicht XenDesktop

Themen des Kapitels. 2 Übersicht XenDesktop 2 Übersicht XenDesktop Übersicht XenDesktop Funktionen und Komponenten. 2.1 Übersicht Themen des Kapitels Übersicht XenDesktop Themen des Kapitels Aufbau der XenDesktop Infrastruktur Funktionen von XenDesktop

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

1. Interface. Wireshark (Ehtereal)

1. Interface. Wireshark (Ehtereal) Wireshark (Ehtereal) Das Programm Wireshark Network Protocol Analyzer dient dazu, wie der Name schon sagt, ersichtlich zu machen, welche Datenpakete die Netzwerkkarte empfängt bzw. sendet. In Form von

Mehr

Design von skalierbaren Websystemen und Test auf ihre Leistungsbeschränkungen Basiert auf der Veröffentlichung Design and testing of scalable Web-based systems with performance constraints von Mauro Andrelini,

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München Time CGI Version 1.5 Stand 04.12.2013 TimeMachine Dokument: time.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor Version Datum Kommentar

Mehr

Behandlung von Performance Problemen

Behandlung von Performance Problemen Behandlung von Performance Problemen DFN Betriebstagung, Forum IP über WiN 27.10.2010 Robert Stoy Überblick Was sind Performance Probleme? Unterschiede zur Behandlung bei Leitungsunterbrechungen Strategie

Mehr

Computernetze In Brief

Computernetze In Brief Computernetze In Brief Inhaltsverzeichnis: Computernetze...1 In Brief...1 Inhaltsverzeichnis:...2 Routing...3 1. Load Balancing / Load Sharing...3 2. IP ROUTE Befehl...3 3. Classful / Classless...4 4.

Mehr

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke VMware Server Agenda Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture Virtuelle Netzwerke 2 Einleitung Virtualisierung: Abstrakte Ebene Physikalische Hardware

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Anwendungen des Matlab-Webservers als Simulationstool für virtuelle Laborumgebungen

Anwendungen des Matlab-Webservers als Simulationstool für virtuelle Laborumgebungen Anwendungen des Matlab-Webservers als Simulationstool für virtuelle Laborumgebungen Michael E. Auer / Andreas Pester Carinthia Tech Institute, University of Applied Sciences Richard-Wagner-Strasse 19,

Mehr

Herzlich willkommen im Modul Web-Engineering

Herzlich willkommen im Modul Web-Engineering Herbst 2014 Herzlich willkommen im Modul Web-Engineering Wirtschaftsinformatik: 5. Semester Dozenten: Rainer Telesko / Martin Hüsler Fachhochschule Nordwestschweiz FHNW / Martin Hüsler und Rainer Telesko

Mehr

www.uni-math.gwdg.de/linuxuebung

www.uni-math.gwdg.de/linuxuebung 14 Netzwerküberwachung und -steuerung Überblick SNMP Simple Network Management Protocol Datendefinitionen SNMP Implementierungen unter Linux Kommandos zur Datenbeschaffung Konfiguration des Net-SNMP Agenten

Mehr

Webtest-Leistungen. der ARGE Rundfunk-Betriebstechnik (RBT) Stand 2012

Webtest-Leistungen. der ARGE Rundfunk-Betriebstechnik (RBT) Stand 2012 eine Arbeitsgemeinschaft von ARD und ZDF Webtest-Leistungen der ARGE Rundfunk-Betriebstechnik (RBT) Stand 2012 Mit der zunehmenden Anzahl und Bedeutung web-basierender Angebote und Anwendungen im Rundfunk

Mehr

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.4 SIP 1 SIP (1) SIP (Session Initiation Protocol), dient als reines Steuerungsprotokoll (RFC 3261-3265) für MM-Kommunikation Weiterentwicklung des MBONE-SIP.

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

Cluster und Load Balancer

Cluster und Load Balancer Cluster und Load Balancer Hochverfügbare Systeme... vermindern das Risiko eines Totalausfalls durch Redundante und ausfallsichere Serverkonfiguration Redundante und ausfallsicher Netzwerkkonfiguration

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS

opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS Agenda opensm2 Überblick INSPECTOR ANALYZER 1 opensm2 bietet eine einheitliche Lösung für das unternehmensweite Performance

Mehr