George W. Anderson, Michael Mißbach. Projekthandbuch Last-Testing und Performance-Tuning

Transkript

1 George W. Anderson, Michael Mißbach Projekthandbuch Last-Testing und Performance-Tuning

2 Inhalt Vorwort zur deutschen Ausgabe 15 Vorwort zur englischen Ausgabe 17 1 Einführung Warum haben wir dieses Buch geschrieben? Besonderheiten von SAP-Systemen Vorbehalte gegen Last-Testing und Performance-Tuning Wie haben wir dieses Buch geschrieben? Für wen haben wir dieses Buch geschrieben? Der Wasserfall Die Kunst, ein Boot jederzeit flott zu halten Reaktionszeit und Durchsatz Wie ist dieses Buch zu lesen? Aufbau dieses Buches Der SAP-Tuning-Werkzeugkoffer Last-Testing und Performance-Tuning Besonderheiten im Umgang mit SAP-Systemen Gründe für Änderungen an mysap-lösungen Erarbeiten von Performance-Tuning-Zielen Last-Testing Argumente für Last-Tests Was genau sind Last-Tests? Weitere Formen von Last-Tests Vergleichbarkeit von Last-Tests Alternative Verfahren für Last-Tests Performance-Tuning Statische Systeme vs. Adaptive Computing Anwendungsübergreifende Geschäftsprozesse Erkennung und Behebung von Engpässen Benchmarking System-Baselining Return on Investment vs. Return on Information Inhalt 5

3 3 Testen von SAP-Lösungen SAP-Technologie SAP-Basis SAP Web Application Server als neue Basis SAP Exchange Infrastructure und SAP Master Data Management SAP NetWeaver und mysap-lösungen Last-Tests von SAP-Lösungen und -Produkten R/3-System und SAP ERP Central Component SAP Enterprise Portal SAP Business Information Warehouse SAP Strategic Enterprise Management mysap Customer Relationship Management mysap Product Lifecycle Management mysap Supply Chain Management mysap Supplier Relationship Management SAP Exchange Infrastructure SAP xapps SAP Internet Transaction Server SAP-Systemlandschaften Typische Landschaften für mysap-lösungen Empfehlung Konkrete Ziele als Erfolgskriterien Ziele, Geschäftsprozesse und Daten im Detail Ermittlung von Lösungsmerkmalen Ermittlung relevanter Geschäftsprozesse Ermittlung relevanter Daten Entwicklung einer Projektplanvorlage Verschiedene Last-Test-Methoden Testen einzelner Hardwarekomponenten (Stufe 1) Standard-Benchmark-Tests für SAP-Systeme (Stufe 2) Kundenspezifische Stress-Tests (Stufe 3) Entwicklung von Erfolgskriterien Messungen mit der Stoppuhr Reaktionszeiten von Transaktionen und Geschäftsprozessen Messung von Systemleistung und -durchsatz Leistung des Plattensubsystems Inhalt

4 5 Zusammensetzung des Test- und Tuning-Teams Technologie trifft Business Best Practices für die Teamzusammenstellung Taktische Überlegungen für einzelne Projekte Langfristige und strategische Überlegungen Zusammenhang zwischen Werkzeugen und Teams Einsatz externer Ressourcen Methoden zum schnellen Lernerfolg Herausforderungen durch neue Lösungen und Systeme Unterstützung des Change-Management-Teams Taktisches Change-Management Strategisches Change-Management Auswahl der Testwerkzeuge Bewertung von Testwerkzeugen Kriterien für Testwerkzeuge Beschaffung von Pilotsoftware Test von Testwerkzeugen Betriebssystemspezifische Werkzeuge CheckIt von Smith Micro Werkzeuge von Hardwareherstellern Werkzeuge für Webserver NetBench und WebBench von VeriTest Benchmark Factory von Quest OpenSTA von CYRANO Chariot und QCheck von NetIQ Windows Media Player von Microsoft Norton AntiVirus LoadSim von Symantec Test-Werkzeuge für Plattensubsysteme SQLIO von Microsoft SQLIOStress von Microsoft NTiogen von Symbios Iometer Nbench Performance Assessment Tool von Hewlett-Packard SQL Profiler von Microsoft Generische Scripting-Werkzeuge Perl, Visual Test und andere ältere Scripting-Werkzeuge AutoIT von HiddenSoft PrimalScript von Sapien TxShuttle von WinShuttle SAP API-fähige Scripting-Werkzeuge AutoTester ONE von AutoTester Inhalt 7

5 6.5.2 TestPartner von Compuware QALoad von Compuware WinRunner for R/3 und QuickTest Professional von Mercury Interactive LoadRunner von Mercury Interactive Werkzeuge und Ansätze von SAP SAP ecatt Lasterzeugung mit SAP CCMS Anwendungsübergreifende Last-Tests Last-Tests von SAP BW und SAP SEM Last-Tests von SAP EP und mysap SRM Weitere Überlegungen Tipps und Tricks Überwachungswerkzeuge Überwachungswerkzeuge von SAP SAP CCMS Central Monitoring System SAP Solution Manager Tools zur Dokumentation der Konfigurationsdaten WinMSD von Microsoft Systems Insight Manager von Hewlett-Packard CheckIt von Smith Micro MonitorIT von Breakout Software Configuration Auditor von Ecora Patch Manager von Ecora Survey von Hewlett-Packard GetConfig von Hewlett-Packard AssetDB von Compulsion Software Windows Management Instrumentation von Microsoft Monitor-Utilities und Betriebssystem-Applets Tools für Plattensubsysteme UNIX-Betriebssystem-Tools Betriebssystem-Tools für Microsoft Windows Management-Tools für Oracle und Microsoft SQL Server IBM Insight für SAP und Oracle Überwachungs-Tools für periphere Geräte Lab-Utilities PsTools von Sysinternals EventComb von Microsoft Administrator's Pak von Winternals Weitere Lab-Utilities Anwendungen zum Enterprise-Management Patrol for SAP Solutions Suite von BMC Unicenter Application Management von Computer Associates OpenView Operations von Hewlett-Packard Inhalt

6 7.5.4 Tivoli Monitoring for Applications von IBM AppManager für das R/3-System von NetIQ Vorbereitung für einen guten Start Hardwareressourcen für Test und Tuning Sandbox-Systeme Capacity-on-Demand-Systeme Hilfssysteme der Testinfrastruktur Erfassen der Baseline Dokumentationstiefe der Baseline-Konfiguration Einfrieren der Baseline Vorbereitung des Testsystems Festlegung einer Testkombination Ermittlung eines repräsentativen Testmix Charakterisierung der Arbeitslast Ermittlung der am häufigsten ausgeführten Transaktionen Definition von Lastpaketen Baselines für Testkombinationen Weitere Überlegungen zu Input-Daten Testkombinationen für technische Komponenten Serverhardware Plattensubsysteme Betriebssysteme Datenbanken Test durchschnittlicher Systemlasten Test von Spitzenlasten Datengrundlage und Datenbeschaffung Zusammenstellung des Last-Mixes Einschränkungen im Hinblick auf End-to-End-Tests Spezifische Herausforderungen der verschiedenen SAP-Komponenten Automatisierung von Last-Tests Grundlagen im Überblick Praxistaugliche Ansätze SAP-Benchmark-Kits als Vorlagen Top-10-Ansatz Nutzung des SAP Batch Schedulers Skripte für das Grundrauschen Mandantenkopien Inhalt 9

7 10.3 Vorbereitung von Skripten Tests mit realen Benutzern Tests mit virtuellen Benutzern Infrastruktur für die Entwicklung von Last-Test-Skripten Praxistipps für die Skripterstellung Skripte testen und bearbeiten Skript für die Erfassung der Daten und Statistiken Skript für das SAPLOGIN Zeitversetzte Anmeldung am SAP GUI Weitere Tipps und Tricks Regelmäßige Kommunikation Utility-Skripte Standard-Subroutinen für Last-Tests Variablen und Eingabedaten Tuning virtueller Benutzer Andere nützliche Subroutinen Abschließende Vorbereitungen und letzte Korrekturen Implementierung der simulierten Benutzer Installation der Support-Infrastruktur für die Client-Emulation Installation des SAP GUI Softwareinstallation für die Client-Emulation Konfiguration der Werkzeuge für die Client-Emulation Testen von Testpaketen Aspekte in Hinblick auf die Arbeitslast Einfrieren der Testplattform Überlegungen zur Überwachung des Last-Tests Überwachung der Testläufe Automatisierte Prozesse, Dienstprogramme und Transaktionsskripte Ende der Testwoche Ausführung von Last-Tests Sicherstellung der Wiederholbarkeit Mehr als ein Test Änderungen immer nacheinander vornehmen Praxistipps für Testläufe Checklisten Zeit zwischen Testläufen reduzieren Zurücksetzen der Datenbank Neustart aller Systeme Systemprüfung vor dem Test Inhalt

8 12.3 Start des Last-Tests Überwachung des Testlaufs Automatisierte Datensammlung Überwachung durch SAP-Monitoring-Transaktionen Überwachung durch den SAP CCMS Alert Monitor Transaktion STAD Weitere SAP CCMS-Transaktionen Überwachung durch betriebssystembasierte Tools Beenden von Testläufen Ordnungsgemäßes Ende eines Testlaufs Beenden durch Schleifenzähler Harter Abbruch Analyse von Last-Tests Überblick über die wichtigsten Leistungsdaten Einsatz von SAP CCMS Performance-Log der SAP-Anwendung Performance der Datenbank Updates, Sperren und die Leistung des Plattensubsystems Speicherverwaltung Tabellenpuffer Betriebssystemmonitor Detailanalysen der Antwortzeit und Arbeitslast Aufbereitung der Messdaten Datentransfer mit Transaktion ST Datenexport aus dem SAP GUI Aufbereiten der Ausgabeprotokolle Import der Ausgabedaten in Excel Darstellung der Ergebnisse Zielgruppen Daten in Informationen umwandeln Iteratives Testen und Tunen Postrun-Analyse Bewertung von Änderungen während eines Testzyklus Methodenwechsel während des Last-Tests Änderungen an Clients Änderungen der Testplattform Änderungen der Arbeitslast Tuning von SAP-Systemen Tuning des Plattensubsystems und des SAN Datenbank-Tuning Inhalt 11

9 SAP-Anwendungs-Tuning SAP-Frontend-Tuning Erfahrungen aus der Praxis Windows Server-Konsolidierung für SAP SAN-Konsolidierung und Plattensubsystem-Upgrades Release-Upgrades Besondere Nutzenfaktoren Verfügbarkeit Zusammenhang von Konsistenz und Verfügbarkeit eines SAP-Systems Single Points of Failure Failover-Tests Wartungsfenster und Hochverfügbarkeit Test von Desaster-Recovery-Lösungen Schutz gegen Inkonsistenz der Datenbank Skalierbarkeit Scale-up- und Scale-out-Skalierbarkeit Ermittlung der tatsächlichen Belastbarkeit Smoke-Tests Einfluss von Last-Tests auf die SAP-Systemadministration Proaktives Testen Von der Transaktion zum anwendungsübergreifenden Geschäftsprozess Charakterisierung der Zusammensetzung der Systemlast Neue Technologien und Ausführungsfenster Ein guter Rat zum Schluss A Musterskripte 333 A.1 Zeitversetztes Anmelden A.2 Systemabmeldung A.3 Grundrauschen A.4 Daten aus Textfile einlesen A.5 Daten aus Microsoft Excel einlesen A.6 Seriennummern-Generator A.7 Zufallszahlen-Generator A.8 Logische Verzweigung A.9 SAP GUI-Meldungen erfassen A.10 ST03-Monitoring A.11 Aufzeichnung von Messdaten Inhalt

10 B Tools-Matrix 349 Die Autoren 355 Index 357 Inhalt 13

11 Vorwort zur deutschen Ausgabe»If you can t measure it you can t manage it.«unternehmen sind aus guten Gründen bestrebt, die von ihnen betriebenen EDV-Systeme möglichst unverändert zu betreiben. Auf diese Weise ist die Stabilität der Systeme am einfachsten gewährleistet und die Kosten bleiben unter Kontrolle. Der globale Wettbewerb macht es jedoch notwendig, Geschäftsprozesse schnell an die sich ständig wandelnden Bedingungen des Marktes anzupassen. Damit müssen sich aber auch die Softwaresysteme ständig verändern, die diese Prozesse in vielen Fällen erst ermöglicht haben. Die»Agilität«der EDV-Systeme wird damit zum Wettbewerbsfaktor. Auf der anderen Seite legt der zum Sprichwort gewordene Rat,»Never touch a running system«, nahe, dass jede Veränderung ein Risiko für die immer komplexer werdenden Systemlandschaften birgt. Die zunehmende Durchdringung der Geschäftsprozesse durch SAP-Lösungen macht Unternehmen immer abhängiger von diesen Systemen, eine ausreichende Systemleistung und Verfügbarkeit auch und gerade unter Last werden zunehmend wichtiger. In Systemlandschaften im Umfeld von SAP NetWeaver erstrecken sich Geschäftsprozesse über mehrere SAP-Systeme. Mit der Enterprise Services Architecture (ESA) können in kürzester Zeit Funktionalitäten von mehreren Systemen zu einem übergeordneten Geschäftsprozess zusammengeführt werden. Wenn aber nur eines der beteiligten Systeme ausgerechnet während der Hauptsaison oder zum Jahreshauptabschluss eine völlig ungenügende Leistung zeigt oder gar zum Stehen kommt, ist guter Rat im wahrsten Sinne des Wortes sehr teuer wenn er überhaupt auf die Schnelle zu erhalten ist. Der Betrieb von SAP-Infrastrukturen erfordert daher den konsequenten Einsatz von Best Practices und Verfahren, wie sie z.b. in der Information Technology Infrastructure Library (ITIL) niedergelegt wurden, sowie in ihrer Weiterentwicklung, dem IT Service Management Reference Model (ITSM). Heute gilt ITSM als Industriestandard für den professionellen Betrieb verteilter Rechnerumgebungen und seine Bedeutung für den Betrieb von SAP-Umgebungen steht außer Frage. Vorwort zur deutschen Ausgabe 15

12 Allerdings beschreiben ITIL und ITSM nur den groben Rahmen, ohne auf die praktische Implementierung einzugehen. In vielen Gesprächen habe ich von Kunden immer wieder gehört, dass vor allem für den zum Change- und Performance-Management gehörenden Bereich»Testen und Tunen von SAP-Systemen«Bedarf nach einem praxisrelevanten Leitfaden besteht. In Ergänzung zu meinen Büchern über Adaptive Hardware-Infrastrukturen und den Systembetrieb für SAP, die in den letzten Jahren bei SAP PRESS veröffentlicht wurden, habe ich daher dem Verlag eine Übersetzung des Buches mysap Tool Bag for Performance Tuning and Stress Testing meines US-amerikanischen Kollegen George W. Anderson vorgeschlagen. Das übersetzte, deutschte Manuskript habe ich in enger Abstimmung mit ihm aktualisiert, teilweise umgeschrieben und Besonderheiten gekürzt, die nur den amerikanischen Markt betreffen. Ich hoffe, dass Sie in diesem Buch Konzepte sowie Tipps und Tricks finden, die Ihnen helfen, die SAP-Systeme Ihres Unternehmens immer fehlerfrei und performant zu halten. Die deutsche Bearbeitung dieses Buches ist in vielen Nacht- und Wochenendstunden während meiner Freizeit entstanden. Darum ist dieses Buch meiner Frau Sabine und meinem Sohn Richard gewidmet, die viel Zeit ohne meine ungeteilte Aufmerksamkeit verbringen mussten. Bedanken möchte ich mich auch bei Florian Zimniak und Stefan Proksch sowie dem ganzen SAP PRESS-Team, die dieses Buch in gewohnt professioneller Weise realisiert haben. Dr.-Ing. Michael Mißbach, im Mai 2005 SAP HP Competence Center, Walldorf 16 Vorwort zur deutschen Ausgabe

13 Vorwort zur englischen Ausgabe»This book is about a whole lot more than performance tuning and testing.«in diesem Buch geht darum, Geld zu sparen und Geld zu verdienen in Bezug auf das Kapital Ihres Unternehmens, das Budget Ihrer Kunden und sogar Ihre persönlichen Mittel. Zwei Faktoren sind dazu entscheidend: Die Anfangsinvestitionen in eine SAP-Systemlandschaft müssen möglichst schnell wieder zurückfließen und das System muss wie eine gut geölte Maschine funktionieren, damit es auch langfristig Gewinn abwirft. Das geht im Prinzip ganz einfach, indem Sie dafür sorgen, dass die Benutzer des SAP Business Information Warehouse stets mit aktuellen Informationen versorgt sind, Ihr Customer-Relationship-Management-Team produktiv bleibt und Ihre R/3-User immer beschäftigt sind. Im Gegenzug profitiert Ihr Unternehmen von den Vorteilen eines schnellen Informationszugriffs, besseren Vertriebszahlen und vielem mehr positive Auswirkungen im Hinblick auf Finanzen, Job und Karriere. Dieses Buch beschäftigt sich auch mit den Gefahren, die dem wohl wichtigsten Faktor der heutigen Geschäftswelt innewohnen und die ein sorgfältiges Last-Testing und Performance-Tuning so unabdingbar machen: Veränderung. Die Art und Weise, in der Veränderungen gehandhabt werden oder anders gesagt: wie ein Unternehmen sicherstellt, dass Veränderungen sich nicht negativ auf die Leistung oder Verfügbarkeit unternehmenskritischer SAP-Systeme auswirken, macht den Unterschied zwischen einem durchschnittlichen und einem wirklich erfolgreichen Unternehmen aus. Im Umkehrschluss gilt natürlich auch: Ein jahrzehntelang vernachlässigtes Change-Management kann eine Lawine auslösen, die auch erfolgreiche Organisationen mit sich reißt und nur diejenigen verschont, die genügend Anpassungsfähigkeit zeigen. Schon häufig sind große Unternehmen und Institutionen über scheinbare Kleinigkeiten ins Stolpern geraten. Die Vergangenheit zeigt, dass die Erfolgsaussichten für ein gutes Change- Management viel versprechend sind. Ein Blick auf die Liste der größten Unternehmen weltweit belegt, dass die Anpassungsfähigkeit an Veränderungen das Überleben selbst in Zeiten einer schlechten globalen Weltwirtschaftslage sichern kann. Die erfolgreichsten Unternehmen in dieser Liste setzen Testverfahren und Tuning-Methoden ein, die den hier Vorwort zur englischen Ausgabe 17

14 vorgestellten ähneln sie betrachten ihre SAP- und Unternehmenssysteme als Ganzes, um die Leistung zu steigern, Ausfälle zu verringern und die Risiken zu minimieren, die Veränderungen mit sich bringen. Aus genau diesem Grund habe ich dieses Buch geschrieben: Ich möchte Ihnen verschiedene Ansätze vorstellen, mit denen Sie den Veränderungen der heutigen Geschäftswelt begegnen können, damit Ihr Unternehmen nicht nur überlebt, sondern auch wachsen kann. Danksagung Das Wort Veränderung lässt mich an die Durchführung von System- Upgrades, das Verwalten und Installieren von SAP Support-Packages und an das Aufspielen von Patches und Fixes denken. Ich denke darüber nach, was auf dem Spiel steht die Leistung und Verfügbarkeit eines Systems, von dem die Arbeit tausender Menschen abhängt, und ich erkenne die Tragweite meiner Arbeit und der meines Teams. Gleichzeitig ruft das Wort Veränderung jedoch auch andere, persönliche Gefühle hervor. Dieses Wort beinhaltet auch die tief greifenden Veränderungen, die ein Mensch durch Gott erfahren kann. Verstehen Sie mich nicht falsch: Ich bin kein Geistlicher oder Prediger, sondern ich habe einfach nur meinen Weg im Glauben gefunden und versuche seither, mein Leben nach christlichem Vorbild zu gestalten. Dies vorausgeschickt muss ich nicht betonen, dass ich für meine Familie und meinen Arbeitsplatz dankbar bin, sowie für meine Kunden, die mit ihrer Erfahrung ebenfalls zu diesem Buch beigetragen haben. Von Herzen danken möchte ich meiner Familie meinen Kindern Phillip, Ashley und Meagan und ganz besonders meiner Frau und besten Freundin Michelle. Ein großes Dankeschön gilt außerdem meinen vielen Kunden in Nordamerika, speziell in Houston, Cleveland, Austin, Cranston und Rochester vielen Dank für die gute Zusammenarbeit und die Möglichkeit, voneinander zu lernen. Meinen SAP-Kollegen bei HP, SAP, Microsoft, Oracle, Capgemini und anderen Unternehmen danke ich für die langjährige und uneingeschränkte Unterstützung und Freundschaft. Ein herzlicher Dank für ihre großartige Hilfe geht auch an meine Testkollegen bei AutoTester, Compuware, Mercury Interactive, SAP, Microsoft und vielen weiteren. Schließlich möchte ich mich bei meinen engsten Freunden und allen anderen bedanken, mit denen ich tagtäglich zusammenarbeite. Für eure Unterstützung, Zuverlässigkeit und Freundschaft werde ich euch immer dankbar sein. George W. Anderson, im Juni 2004 Hewlett-Packard, Houston 18 Vorwort zur englischen Ausgabe

15 10 Automatisierung von Last-Tests Die Automatisierung der Systembelastung betrifft die Dateneingabe und -verarbeitung. Die Emulation der Arbeitslast durch die Simulation der Eingabe von Daten und Abfragen ist der eigentliche Kern jedes Last-Tests. Ohne ein Verfahren zur Automatisierung dieser Eingaben, sodass sie weitgehend ohne ständige Überwachung, aber kontrolliert selbstständig ablaufen, sind Stress-Tests kaum realisierbar. Dieses Kapitel ist der Automatisierung der Lasterzeugung gewidmet. Basierend auf unseren praktischen Erfahrungen werden u.a. Verfahren für die Automatisierung beschrieben und Tipps vermittelt, damit Sie möglichst schnell funktionsfähige Skripte erstellen können. Ferner werden die Alternativen für die Automatisierung der Testlast genannt, die Ihnen helfen werden, wenn Sie Ihrem Team oder Ihren Vorgesetzten gegenüber Automatisierungsmethoden rechtfertigen und schmackhaft machen müssen Grundlagen im Überblick Bei der Automatisierung der Systemlast durch einen Last-Mix, dessen Zusammenstellung detailliert in Kapitel 9 beschrieben wurde, geht es nicht nur um die optimale Nutzung der vorhandenen Ressourcen, also Personaleinsparungen, sondern auch darum, wiederholbare und konsistente Testläufe zu gewährleisten. Automatisierte Testverfahren ermöglichen: die Simulation von hunderten oder tausenden von Benutzern durch einige wenige Mitarbeiter die Simulation von hunderten oder tausenden von PCs und Laptops durch eine kleine Zahl von Servern zur Lastgenerierung die Automatisierung der Ausführung komplexer Geschäftsprozesse die Ermittlung einiger weniger Input-Datensätze, anhand derer hunderte gültige Datenkombinationen generiert werden können die Wiederverwendung der Skripte für Last-Tests, z.b. für Funktionsoder Regressions-Tests Wiederholbarkeit und Konsistenz Möglichkeiten automatisierter Testverfahren Grundlagen im Überblick 215

16 Last-Tests mit SAP NetWeaver SAP-Last-Tests neuerer Generation müssen jedoch mehr als nur durch Benutzer generierte Transaktionen umfassen. Neben Transaktionen, die durch ALE (Application Link Enabling) oder EDI (Electronic Data Interchange) von anderen Systemen generiert werden, tritt mit SAP NetWeaver die SAP Exchange Infrastructure als»vermittler«. Die Automatisierung der Systemlast muss daher auch dafür eingesetzt werden können, sicherzustellen, dass auch verknüpfte und unternehmenskritische Systeme miteinander arbeiten. Glücklicherweise müssen Sie hierfür kein Experte für Internetprotokolle sein. Es genügt festzulegen, welche Geschäftsprozesse getestet werden sollen, und die Geschäftsprozesse mit Daten im richtigen Format zu versorgen. Manuelle Ausführung von Transaktionen Die Alternative zur Automatisierung von Testläufen ist die manuelle Ausführung von Transaktionen; für funktionale und Regressionstests ist dies sogar die normale Methode. Für Last-Tests ist die manuelle Eingabe von Transaktionen dagegen keine realistische Option. Abgesehen von der Unmöglichkeit, hunderte oder tausende von Mitarbeitern dafür einsetzen zu können, bestünde eine weitere Herausforderung darin, dass die Benutzer»auf Kommando«die verschiedenen Geschäftsprozesse reproduzierbar ausführen müssten. Eine weitere Methode, die hier nur der Vollständigkeit halber erwähnt werden soll, ist die Simulation von Usern auf ihren PCs außerhalb der normalen Arbeitszeit mithilfe von Tools, die nicht über eine SAP API verfügen. Praxisbeispiel So haben wir z.b. einmal auf Wunsch eines Kunden für einen Last-Test auf R/3-Systemen auf 300 PCs Transaktionen mit Windows Visual Test 4.0 ausführen lassen. Dieser Ansatz hatte folgende Nachteile: Auf jedem dieser PCs musste ein SAP GUI installiert werden, wozu jeder PC die GUI-Standards erfüllen musste, um das erfolgreiche Ausführen der Skripte zu gewährleisten. Die Skriptsprache selbst führte bei der Ausführung zu Fehlern Desktops wurden unerwartet gesperrt, Skriptfenster wurden unterbrochen usw. Auch das Starten der Tests stellte eine große Herausforderung dar, da meist ein Neustart des Rechners notwendig war, und zwar zum Leeren des Cache, Herstellen von SAP-Client-Verbindungen und Aktivieren abgestürzter/blockierter Desktops. 216 Automatisierung von Last-Tests

17 Auch die Auswertung der Daten war äußerst schwierig letztendlich musste eine Batch-Datei erstellt werden, um die Inhalte aller Protokolldateien auf den lokalen Festplatten der einzelnen Desktops in einer einzigen Datei zu speichern. Eine weitere Methode beinhaltet die Verwendung eines SAP-Benchmark- Kits zur Simulation der Anwendungslast (siehe Abschnitt ). Allerdings können mit einem Standardtest eben auch nur Standardlasten auf Standardsystemen erzeugt werden; schon das individuelle Customizing eines Systems kann zu erheblichen Problemen führen. Zudem haben diese Benchmark-Kits eine nicht zu unterschätzende Lernkurve, z.b. inklusive handgestrickter Perl-Codes und AutoIT-Skripts. Standard- Benchmark-Kits können daher in der betrieblichen Realität nur dafür genutzt werden, die vom Hersteller versprochene Leistung eines neuen Systems vor Beginn des Customizings in einem Abnahmetest nachzuweisen (siehe Abschnitt 4.2.2). IDES und SAP- Benchmark-Kits Für die Nutzung eines Internet Demonstration and Evaluation Systems (IDES) für Testzwecke gilt prinzipiell das Gleiche. Für den Test von kundenindividuellen Geschäftsprozessen und Systemen sind diese Ansätze ungeeignet Praxistaugliche Ansätze Die folgenden Ansätze für die Automatisierung von Last-Tests haben sich in der Praxis bewährt. Für diese Verfahren werden die wesentlichen SAP- Geschäftsprozesse berücksichtigt SAP-Benchmark-Kits als Vorlagen Auch wenn sich die SAP-Benchmark-Kits nicht für kundenindividuelle Last-Tests eignen, so können sie doch als Vorlage zum Erstellen eigener Skripte verwendet werden. Der Vorteil der Benchmark-Kits liegt darin, dass sie bereits die Verknüpfung einer Reihe wichtiger komponentenspezifischer Transaktionen enthalten, sodass ein ganzheitlicher Geschäftsprozess abgebildet wird. Abbildung 10.1 zeigt das Beispiel der Transaktionsabfolge eines typischen Geschäftsprozesses, wie er im Benchmark-Kit des mysap CRM Customer Interaction Centers simuliert wird. Ganzheitlicher Geschäftsprozess Praxistaugliche Ansätze 217

18 mysap CRM Interaction Center Benchmark 4.0 CIC-Bildschirm laden Aufruf beantworten Histor. Geschäftsprozess-Daten abrufen Geschäftsprozess bestätigen Material usw. bestätigen Performance-Testing-Ausgabe (Reaktionszeiten, Durchsatz, Bestätigungen, Probleme usw.) Abbildung 10.1 Mögliche Transaktionsabfolge im mysap CRM Interaction Center Dabei müssen jedoch einige Punkte berücksichtigt werden: Weder die Skripte noch die Daten des SAP-Benchmark-Kits können direkt verwendet werden. Beide müssen an Ihr individuelles SAP-System angepasst werden. Benchmark-Kits sind nur für eine relativ beschränkte Anzahl von Lösungen und Transaktionen verfügbar. Bei diesem Ansatz wird immer nur eine SAP-Lösung getestet. Für anwendungsübergreifende Geschäftsprozesse stehen keine SAP- Benchmark-Kits zur Verfügung Top-10-Ansatz Am häufigsten ausgeführte Transaktionen Wie in Abschnitt beschrieben, können mit Transaktion ST03 im CCMS auf einfache Weise die häufigsten Online-, Batch- und RFC-Transaktionen ermittelt werden. Auf dieser Basis können dann Skripte zur Simulation der zehn wichtigsten Geschäftsvorgänge erstellt werden. Beißen Sie sich dabei nicht an der Zahl zehn fest, dieser Wert dient hier lediglich als Richtlinie, vielleicht wird der Großteil Ihrer Systemlast auch von 15 Transaktionen oder nur acht oder neun verursacht. Erfahrungsgemäß umfassen die wichtigsten Transaktionen 70 bis 80 % an Online- Transaktionen und 20 bis 30 % an Batch-Jobs. Es ist klar, dass dieser Ansatz nicht für die Simulation des kompletten Geschäftsprozesses und Lastspektrums geeignet ist, da ja lediglich die am häufigsten ausgeführten Transaktionen berücksichtigt werden (siehe Abbildung 10.2). So wird zum Beispiel die Verarbeitung eines Kundenauftrags mit Kommissionierung, Versand, Fakturierung und Zahlungseingang 218 Automatisierung von Last-Tests

19 nicht vollständig simuliert. Trotzdem ist in der Praxis die Simulation der Transaktionen mit dem größten Aktivitätsvolumen (bei Sortierung nach Dialogschritten) oder der größten Systemlast (bei Sortierung nach Datenbank- oder CPU-Zeit) eine einfache und effektive Methode, um eine erforderliche realistische Verarbeitungslast zu generieren. Abbildung 10.2 CCMS-Anzeige der Last auf einem SAP-Datenbankserver Nutzung des SAP Batch Schedulers Eine Möglichkeit, mit SAP-Bordmitteln realitätsnahe Lastprofile zu generieren, bietet der SAP Batch Scheduler. Dabei dienen die Transaktionen SM36 und SM37 zum Definieren und Freigeben von Batch-Jobs, Transaktion SM64 zum Definieren von Triggern und SE38 zum Ausführen mehrerer Reports. Zum Steuern der Ausführung der Testläufe kann das Programm sapevt wie ein normaler ABAP-Report genutzt werden. Die Ausführung externer Befehle ist mit sapxpg möglich. Auf diese Weise lässt sich ein komplexer Last-Test mithilfe weniger Skripte steuern, wobei jeder abgearbeitete Job bzw. jedes Skript den nächsten auslöst. Mit dieser Methode können relativ einfach realitätsnahe komplexe Lastszenarien reproduzierbar generiert werden, bei denen Batch-Jobs bei bestimmten externen Ereignissen ausgelöst werden. Eines nach dem anderen Mit geeigneten Skripten kann der Statuscode überprüft und damit zum Beispiel festgelegt werden, dass ein Batch-Job so lange gestartet wird, bis ein vollständiger Satz Testskripte ausgeführt wurde. Für das Scripting ist lediglich Transaktion SM37 erforderlich. Praxistaugliche Ansätze 219

20 Skripte für das Grundrauschen Anzeige von Informationen Auch die Verwendung von Noise-Skripten (siehe Abschnitt 9.1.3) ist eine hervorragende Testmethode. Am besten eignen sich hierfür Transaktionen, bei denen keine Eingabe von Daten notwendig ist, sondern lediglich die Anzeige von Informationen vom System angefordert wird, wie zum Beispiel Transaktion VA03 (Anzeige von Aufträgen), Transaktion MM03 (Anzeige von Materialien), Transaktion PA03 (Anzeige von Mitarbeiterinformationen), Transaktion MB03 (Anzeige von Material belegen), Transaktion ME53 (Anzeige von Bestellanforderungen), Transaktion ME23 (Anzeige von Bestellungen) und Transaktion XD03 (Anzeige von Kundeninformationen). Eine weitere Methode ist zum Beispiel die wiederholte Ausführung von Transaktion VA01 (Auftragserstellung). Dabei müssen nur beim ersten Durchgang Daten (per Skript) eingegeben werden. Bei erneuter Ausführung der Transaktion mit dem Parameter»/n«wird die Systemlast in regelmäßigen Schritten reproduzierbar erhöht Mandantenkopien Systemressourcen beanspruchen Leistung der Netzwerkinfrastruktur Das Erstellen von Mandantenkopien via Transaktion SCCL oder Mandantenexporten über Transaktion SCC8 hat zwar nichts mit dem Ausführen eines Geschäftsprozesses zu tun, kann aber ebenfalls zur Erzeugung einer Testlast»missbraucht«werden, da dabei die Systemressourcen vor allem des Plattensubsystems massiv beansprucht werden. Da der Speicherbedarf eines SAP-Mandanten in der Regel die Größe des Schreib-Caches des Plattensubsystems überschreitet, führt die Ausführung einer Mandantenkopie zu ressourcenintensiven Lese- und Schreibvorgängen. Damit sind eine Mandantenkopie zum Messen der Leistung eines Plattensubsystems und ein Mandantenexport zum Messen der Leistung der Netzwerkinfrastruktur hervorragend geeignet. Auch die Erstellung eines leeren Mandanten kann eine hohe Last mit einer geringen Menge Eingabedaten generieren. Mandantenkopien sind dementsprechend eine gute Möglichkeit, ein System unter eine reproduzierbare Last zu setzen. Allerdings hat diese Last nur wenig mit der tatsächlichen Nutzung eines SAP-Systems zu tun Vorbereitung von Skripten Keine leichte Sache Wie das Programmieren umfasst auch das Erstellen von Skripten zur Automatisierung von Last-Tests eine Reihe von Schritten, zu denen z.b. 220 Automatisierung von Last-Tests