Torsten Schlautmann OPITZ CONSULTING Essen GmbH Nürnberg, 19.11.2009 OPITZ CONSULTING GmbH 2009 Seite 1
Agenda 1. Warum Lasttests? 2. Vorgehensmodell für Lasttests 3. Auswahl geeigneter Lasttest-Tools 4. Beispielszenarien OPITZ CONSULTING GmbH 2009 Seite 2
1 Warum Lasttests? OPITZ CONSULTING GmbH 2009 Seite 3
Warum Lasttests? Absicherung vor der Einführung neuer IT-Systeme Absicherung vor größeren Änderungen in der IT- Infrastruktur oder in der Applikation Migration auf ein neues Release (DB, Middleware, Applikation) Storage-Austausch Migration auf ein neues Betriebssystem Änderungen in der Gesamtarchitektur (Netz, Cluster-Technologien, etc.) usw. Absicherung eines Sizings Aufdecken von Problemen, bevor diese in der Produktion auftreten! OPITZ CONSULTING GmbH 2009 Seite 4
Warum Lasttests? Client Netzwerk Application-Server Netzwerk Datenbank Storage OPITZ CONSULTING GmbH 2009 Seite 5
2 Vorgehensmodell für Lasttests OPITZ CONSULTING GmbH 2009 Seite 6
Vorgehensmodell bei Lasttests 1 2 3 4 5 Anforderungsprofil erstellen Tool-Auswahl Operationalisierung Ausführung und Messung Auswertung und Berechnung 6 Optimierung In Anlehnung an DIN 66273 / ISO 144576 OPITZ CONSULTING GmbH 2009 Seite 7
Anforderungsprofil erstellen Wie viele Benutzer arbeiten später mit dem System und müssen simuliert werden? Welche Bandbreiten müssen simuliert werden? Gibt es Spitzenlasten (z.b. Jahresabschlussarbeiten) die simuliert werden müssen? Welche Programmabläufe werden wie häufig und mit welchen Parametern aufgerufen? Welche Denkzeiten sind zu berücksichtigen? Welcher Anteil der Benutzer ist als aktiv, welcher als passiv zu bewerten? Wie soll das Antwortzeitverhalten sein? (!!!!) OPITZ CONSULTING GmbH 2009 Seite 8
3 Auswahl geeigneter Lasttest-Tools OPITZ CONSULTING GmbH 2009 Seite 9
Auswahl eines geeigneten Lastgenerators Kriterien für die Auswahl: Welche Schichten der Architektur müssen einbezogen werden? Welche Netzwerkprotokolle müssen unterstützt werden? Wie soll die Messung der Performance vorgenommen werden? (Korrelation beachten) Werden die Kriterien des Anforderungsprofiles abgedeckt? Synthetischer vs. natürlicher Lasttest Kosten (Lizenzen + Projekt) OPITZ CONSULTING GmbH 2009 Seite 10
Auswahl eines geeigneten Lastgenerators Lasttest-Tool / Lasterzeugung Testinfrastruktur Lasttreiber (Nutzer-Simulation) Steuerung/ Messung Application- Server Database- Server OPITZ CONSULTING GmbH 2009 Seite 11
Übersicht gängiger Lasttest-Tools IBM Rational Performance Tester HP (Mercury) Loadrunner Borland (Segue) SilkPerformer Compuware QALoad Quest Benchmark Factory Hammerora Swingbench OPITZ CONSULTING GmbH 2009 Seite 12
4 Beispielszenarien OPITZ CONSULTING GmbH 2009 Seite 13
Bsp.: Quest Benchmark Factory Szenario: Direkte Migration von 9.2.0.6 (HP-UX, Single Instance) auf 11.1.0.7 (Linux, RAC) Ziele: Probleme vor der Produktivstellung erkennen und beheben Lastverhalten unter realistischen Bedingungen prüfen Parametrisierung vor Produktivstellung optimieren Leistungsfähigkeit des System prüfen Zusammenspiel aller Komponenten testen OPITZ CONSULTING GmbH 2009 Seite 14
Ausgangssituation Heterogene IT-Umgebung: Diverse datenbankbetriebene Applikationen, teils hochkritisch Verschiedene Lieferanten für die Applikationen Große Anzahl an Oracle Datenbanken im Einsatz Dynamisches Umfeld mit häufigen Änderungen am Quellcode Zu berücksichtigende Änderungen: Datenbank Upgrade Anwendungsänderung Architekturwechsel und Plattformwechsel OPITZ CONSULTING GmbH 2009 Seite 15
Motivation: Datenbank Upgrade Ausgangslage: Datenbank zentrale Komponente Applikation für DB optimiert Datenbank Parameter optimiert Herausforderung: Support für DB-Version läuft aus Änderung: Datenbank Upgrade 9.2.0.6 Upgrade? 11.1.0.7 Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 16
Motivation: Anwendungsänderung Ausgangslage: Applikation durchläuft QS Datenbank Parameter optimiert Herausforderung: Redesign der Anwendung Massive Änderungen Änderung: Codeänderung Release 1.0 Codeänderung? Release 1.1 Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 17
Motivation: Architekturwechsel Ausgangslage: System Sizing für SLAs ausreichend Herausforderung: Neue Verfügbarkeitsanforderung Zukunftssichere Architektur Wachstum d. Benutzeranzahl Änderung: Architekturwechsel Betriebssystemwechsel Single Instance Architekturwechsel Betriebssystemwechsel? Knoten 2 Knoten 1 Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 18
Werkzeuge Quest Benchmark Factory Testet Performance und Skalierbarkeit Simuliert Benutzer und Transaktionen Abspielen eines Produktions-Workload Entwickler / DBAs / QA Teams können überprüfen, ob die Datenbank für Produktionsbetrieb skaliert Bei steigender Benutzerlast Vor Einspielen eines neuen Anwendungs-Release Vor Änderungen an Hardware / OS / Oracle-Version OPITZ CONSULTING GmbH 2009 Seite 19
Werkzeuge Quest Oracle Performance Analysis Abweichungen vom normalen Lastprofil erkennen Die Art des Problems eingrenzen CPU, I/O, Locking etc. Die Verursacher eingrenzen Anwendung, User, Client, SQL-Kommando Change Tracking Analyse (Ausführungspläne) Flashback-Einsatz: Als Verfahren zur Datenrückgewinnung wird Flashback für den Lasttest implementiert. OPITZ CONSULTING GmbH 2009 Seite 20
Mögliche Vorgehensweise im Projekt 1. Implementierung von Monitoring im Altsystem Aufzeichnung TOP-Statements Definition / Durchführung von kritischen Geschäftsprozessen Messung von Metriken Aufzeichnung Geschäftsprozesse (SQL Trace Level 12) 2. Implementierung eines Systems zur Lastgenierung und Messung Installation Clients für BF Einrichtung Repository Parametrisierung der TOP-Statements Database Replay Import SQL-Trace 3. Durchführung Performance Tests Erstellung von Testplänen Erstellung von Testszenarien auf Basis von SQL-Trace und TOP-Statements Messung von Metriken Auswertung / Vergleich / Abweichungen 4. Reaktion auf Abweichungen Änderung an der Applikation Änderung an der DB-Konfiguration Änderung Sizing Lastverteilung OPITZ CONSULTING GmbH 2009 Seite 21
1. Monitoring und Aufzeichnen des SQL (Trace) OPITZ CONSULTING GmbH 2009 Seite 22
2. Import Trace-Files und BM-Skripte OPITZ CONSULTING GmbH 2009 Seite 23
3. Durchführung d. Tests und Monitoring OPITZ CONSULTING GmbH 2009 Seite 24
4. Auswertung der Ergebnisse OPITZ CONSULTING GmbH 2009 Seite 25
Anmerkungen zum Vorgehen Definition des Ablaufes vor der Durchführung Gewährleistung von Vergleichbarkeit Einhalten des genauen Ablaufs! Ausschluss von weiteren Einflüssen Wiederholung sämtlicher Tests Sicherstellung der Messergebnisse Optimierung der Parameter / Konfiguration Dokumentation der Messparameter was muss z.b. bei den Wiederholungen berücksichtigt werden? OPITZ CONSULTING GmbH 2009 Seite 26
Bsp.: Real Application Testing (RAT) Szenario: Direkte Migration von 10.2.0.4 (Windows, Single Instance, Failsafe) auf 11.1.0.7 (Linux, RAC) Ziele: Probleme vor der Produktivstellung erkennen und beheben Lastverhalten unter realistischen Bedingungen prüfen Parametrisierung vor Produktivstellung optimieren Leistungsfähigkeit des System prüfen Zusammenspiel aller Komponenten testen OPITZ CONSULTING GmbH 2009 Seite 27
Ausgangssituation Zentrale Datenbankinfrastruktur: Mehrere Applikationen auf einer DB Dynamisches Umfeld mit häufigen Änderungen am Quellcode Zu berücksichtigende Änderungen: Datenbank Upgrade Architekturwechsel und Plattformwechsel Weitere Rahmenbedingungen: Lasttests sollen so realitätsnah wie möglich sein Kurzfristige Umsetzung aufgrund nicht beeinflussbarer Parameter zwingend notwendig (kurze Projektlaufzeit erforderlich) OPITZ CONSULTING GmbH 2009 Seite 28
Werkzeug: Real Application Testing: Capture 10.2.0.4 Windows OPITZ CONSULTING GmbH 2009 Seite 29
Werkzeug: Real Application Testing: Replay 11.1.0.7 Linux RAC OPITZ CONSULTING GmbH 2009 Seite 30
Hinweise zur Benutzung Was wird alles unterstützt? Jede Art von SQL (DML, DDL, PL/SQL) Volle LOB-Unterstützung Login / Logoff Wo sind die Grenzen? Direct path load (imp/exp) Streams, nicht PL/SQL-basiertes AQ Verteilte Transaktionen Flashback Shared Server OPITZ CONSULTING GmbH 2009 Seite 31
Hinweise zur Benutzung Was sollte bei der Planung berücksichtigt werden? Ausreichend Platz für die Aufzeichnung (und das Abspielen!) der Transaktionen muss vorhanden sein. Die Datenbank sollte auf jeden Fall bei Beginn der Aufzeichnung der Transaktionen durchgestartet werden (!!!) Das Zieldatenbank-System muss inhaltlich auf den Status zum Beginn der Aufzeichnung hergestellt werden. Über Filter können nach verschiedenen Kriterien nur bestimmte Transaktionen aufgezeichnet werden (User, Programm, Module, Action, Service, Session ID). Es werden SYSDBA-Rechte benötigt. Performance-Overhead ist abhängig von der Applikation Bedienung ist über Enterprise Manager & PL/SQL-Packages (DBMS_WORKLOAD_%) möglich. OPITZ CONSULTING GmbH 2009 Seite 32
Fazit Beide Tools haben ihre Stärken, die je nach Projektsituation gezielt eingesetzt werden sollten. Real Application Testing kann enorm Zeit sparen, sollte jedoch intensiv unter realistischen Rahmenbedingungen getestet werden (Einfluss auf Produktionssystem). Im direkten Vergleich ist die Nutzung von Benchmark Factory deutlich flexibler, setzt aber eine intensive Beschäftigung mit den wichtigsten Geschäftsprozessen voraus und verursacht Aufwände für das Skripting. OPITZ CONSULTING GmbH 2009 Seite 33
Fragen und Antworten OPITZ CONSULTING GmbH 2009 Seite 34
Kontakt Torsten Schlautmann OPITZ CONSULTING Essen GmbH torsten.schlautmann@opitz-consulting.com Telefon +49 201 89 29 94-1775 Mobil +49 173 7252409 OPITZ CONSULTING GmbH 2009 Seite 35