Lasttests für Online-Auftritte

Transkript

1 Lasttests für Online-Auftritte Claus-Georg Pleyer Sachgebiet IT Fachbereich Informations- und Hochfrequenztechnik 1

2 Kritische Fragen zum Online-Auftritt Antwortzeit Wie lange müssen Benutzer auf angeforderte Seiten warten? Durchsatz Wie viele Benutzer können gleichzeitig zugreifen? Lastspitzen Was passiert bei einem sehr schnellen Anstieg der Benutzer? Flaschenhals Welche Komponenten sind als erstes ausgelastet? Fehler Gibt es systematische Fehler beim Zugriff? Seitenweiterentwicklung Wie entwickelt sich die Performance bei Änderungen (Inhalt, Design) im Online-Auftritt? HW/SW-Updates Wie ändert sich die Performance bei neuen SW- und HW-Komponenten im Back-End? 2

3 Welche Benutzer-Zugriffe kann die RBT testen? Seiten-Zugriff / Download: HTTP(S) 1.0/1.1 Get -Text: HTML - Bilder: JPEG, GIF - Steuerinformationen: CSS, JavaScript (.js), PHP, XML-Dateien, Flash (.swf), etc. - Dokumente und anderer Content:.pdf,.wav,.mp4, etc. (z.b. Podcast) Formular-Eingabe: HTTP(S) 1.0/1.1 Form Get/Post - wechselnder Inhalt (z.b. Suche, Umfrage, Registrierung) Login, Postings, Messaging: HTTP(S) 1.0/1.1 Form Get/Post und Jabber - wechselnder Inhalt (z.b. Chats, Foren) - Cookies Streaming über RTSP: RTSP-Play (ab Mai 2010 auch RTMP) - Start- und End-Zeit sowie Dauer variabel Spezielle Test-Seiten mit unterschiedlicher Back-End-Tiefe - Eingrenzung von möglichen Engpässen - Untersuchung bestimmter Komponenten 3

4 Welche Testvarianten bietet die RBT an? Zeitpunkt Häufigkeit Testart Tests Tag Nacht einmalig zyklisch funktional Last Streß Stichpunkt Vor Freischaltung des Online-Auftritts Nach Freischaltung des Online-Auftritts 4

5 Welche Lastwege testet die RBT? Test 1: Von der RBT aus auf den Provider oder den Betreiber des Webauftritts Test 2: Vom RBT-Provider aus auf den Provider oder den Betreiber des Webauftritts Test 3: Vor Ort auf mehrere oder einzelne Komponenten des Betreibers Test 1 Test 3 Test 2 beliebige Zugangsraten Mögliche Last- u. Meßpunkte: Rundfunk-Betriebstechnik GmbH

6 Welche Web-Test-Tools gibt es? Große Vielfalt Von einfach bis komplex und von alt bis neu Linux- oder Windows-basierend oder beides Open Source oder proprietär Von frei bis über allein für SW Freeware (nur SW) - kommandozeilenorientiert, Linux: Apache flood, ApacheBench (ab), HP httperf - mit GUI: MS Web Application Stress (WAS), Apache JMeter, Cyrano/Quotium/GNU OpenSTA Kommerzielle Tools -SW: Zott s_aturn, Paessler Webserver Stress Tool, Borland SilkPerformer, David Fischer Proxysniffer, HP/Mercury Loadrunner, Verysoft/Quotium QTest, Kay H. Fluhr Edirector, Minq PureLoad, Compuware QALoad, Empirix e-load, Neotys NeoLoad -HW + SW: Shenick diverifeye, Spirent Avalance, Ixia IXLoad, Agilent NetworkTester 6

7 Was ist das Testumfeld der RBT? Know How - RFCs, HTTP-Parameter, Testkonzepte, Labortests Meßmittel - NeoLoad (Fa. Neotys) umfangreiche, realitätskonforme Webtest-SW, mit beliebigen eigenen HW-Clients - Open System Testing Architecture (OpenSTA) Browser-Rekorder, clusterfähig, leicht abrufbare URL-Statistiken - NetworkTester (Fa. Agilent Technologies) hardware-basierend, 2 x 2 GE, Reporting-Tool, Tcl/Tk-skriptfähig, seit `05 bei der RBT im Einsatz - ergänzende oder andere Tools möglich Erfahrung - Web-Tests bei BR, ZDF, IVZ, MDR und RBT - Realitätsnähe - Meßmitteleinsatz beim Internet-Provider (derzeit 3 Lastrechner mit je 100 Mbit/s) Flexibilität und Unabhängigkeit - rundfunkspezifische Ausrichtung - individuelle Auswertung und Aufbereitung - Objektivität durch freie Wahl der Test-Tools 7

8 Was leisten die von der RBT eingesetzten Tools? Simulation eines realen Online-Nutzerverhaltens - beliebige parallele und sequenzielle URL-Zugriffe - beliebige feste oder zufällige Pausen ( Denkzeiten ) - beliebig gewichtete, wechselnde Benutzer-Eingaben Skalierung der Zugriffe bis auf mehrere tausend Benutzer - unterschiedliche zeitliche Last-Profile - Nachbildung von im Rundfunk üblichen Spitzenlasten, z.b. bei Großereignissen - Individuelle IP- und MAC-Adressen für die Last-Client-Instanzen Monitoring beteiligter Komponenten - für sämtliche Client-Instanzen stichpunktartig gut möglich, durchgängig eher aufwendig - Ergänzende Überwachung von Netz- und Server-Kapazitäten Ziel: Verifizierbare realistische Lastsituationen, um Performancegrenzen, Engpässe und Auswirkungen von Änderungen zu erkennen Automatisierte Abläufe möglich Zusammenarbeit mit Ihren Mitarbeitern (z.b. Monitoring und Web-Design) erwünscht 8

9 Wie werden die Tests von der RBT aufbereitet? Testbeschreibung - Welche Last wurde eingesetzt? Ergebnis-Graphiken - durchschnittliche und maximale Antwortzeiten und Server-Reaktionszeiten (TTFB) (Differenzierung nach HTTP-Response, TCP-Session-Setup und DNS möglich) - lastkonformer Durchsatz, Transaktionsraten (HTTP-Code 200 OK) - Fehlerhäufigkeit und -art bei Antworten des SUT - Auslastung des Lastsystems Vergleiche - zeitlich (chronologisch) - örtlich (Meßpunkte) - zielbezogen (Portale) - lastbezogen (Meßläufe) Bewertungen - Seiten- und URL-Ladezeiten aus Anwendersicht - Bestimmung der Performancegrenze - Engpaß-Eingrenzung (Loadbalancer, Webserver, DB, etc.) - Fehleranalyse auf Netzwerk- und Anwendungsebene 9

10 Beispiel: Streßtest des Webservers im RBT-Labor Zugriffe auf HTML-Seite mit JPEG-Bildern bei 4s - 50s Denkpause Normalbetrieb 8 neue Benutzer/s Leistungsgrenze ab ca Benutzern Ursache: 100 % GE-Durchsatz in Richtung Client 2 Überlast-Effekte ab ca Benutzern - Transaktionsrate sinkt auf 450 Requests/s - Durchsatz verringert sich auf 60 MByte/s - Antwortzeiten, Offene Sessions und Time-Outs steigen an Ursache: 100 % CPU-Auslastung des Web-Servers 10

11 Über Ihre Kontaktaufnahme freuen sich Jürgen Wehner (Sachgebietsleiter IT) Tel.: (0911) Claus-Georg Pleyer (insb. Rückfragen zu dieser Präsentation) Tel.: (0911)