Home

Performance-Modellierung und Simulation eines SAP

1. Anhang 205 7 Anhang Portaloperationen der Fallstudie ID Funktion Duplikat Fremd von funktion Tag 1 Vorbereitungen 1 0 Portal Seite ffnen 1 1 Logon Admin 1 2 User anlegen 1 3 Gruppe anlegen 1 4 User zu Gruppen Administrator hinzuf gen 1 5 Ordner anlegen 1 6 Rolle anlegen 1 7 Objekt Rolle ffnen 1 8 Einstiegspunkt aktivieren 1 9 Rolle zu Gruppe zuordnen 1 10 Rolle anpasse 1 11 Leserechte f r Portal Content vergeben 1 12 Schreibrechte f r Ordner anlegen 1 13 Kurskonfiguration pr fen 1 14 Logout Tag 2 Login Navigation Personalisierung Men 2 0 Benutzer anmelden 1 1 2 1 Initiales Passwort ndern 2 2 Benutzer abmelden 1 14 2 3 Benutzer wieder anmelden 1 1 2 4 Zur Startseite wechseln 2 5 Personalisieren Darstellungsschema ndern 2 6 Personalisieren Darstellungsschema speichern 2 7 User Mapping f r R 3 Verbindungen einrichten X 2 8 Detaillierte Benutzerinformationen eintragen 2 9 Top Level Navigation Unterpunkte aufrufen 2 10 Startseite Portal Information abrufen 2 11 Content Management Direct Links zu Komponenten 2 12 Kollaboration Grundlage f r asynchrone Zusammenarbeit 2 13 Curriculum Congress Personalisierter Inhalt 2 14 Wechseln zur Inhaltsverwaltung 2 4 2 15 History Funktion Wechseln zu Curriculum Congress 2 16
2. Jee Date Date Date Size Free Resets einstals Tables Objects mrequests Iris Loadqueuesize m wed Nov wea NOV Wed e st Zeg i true 16 28 54 16 28 54 SE 2 Table Buffer Administratio y e Kar es m Bit En ci C portalsim2 informatiktu muenchen de enSQLI t erviet vy Ze gy K Show Buffered Objects G gt GHISEBRINGHE 233227250 MADENE portalsim2 F33 SAPP33DB Remove Single Object Table E Type Status Records NotFounds DataSize TotalSize ReloadCounter FixingCounte l Reset Buffer j CAF_GP_TEXDEF null Tenueckam Ip been bas Is llo Refresh CAF_GP_USRHSH null ui am 2 0 718 si Jb 0 Refresh lt m hn lt m 1 U SS Abbildung 3 9 Anzeige der Tabellen Puffer Quelle eigene Darstellung Systemarchitektur und Monitoring 76 Die wichtigsten zur Verf gung stehenden Daten der einzelnen Eintr ge sind in Tabelle 3 8 aufgelistet Feld Beschreibung Puffer Details Size Gr e des Tabellenpuffers Displacements Anzahl an Verdr ngungen Requests Anzahl der Anfragen Hits Anzahl der Treffer DisplData Verdr ngte Datenobjekte der letzten Verdr ngung DisplObjects Verdr ngte Pufferobjekte der letzten Verdr ngung DisplTables Verdr ngte Tabellen der letzten Verdr ngung TraceOn Flag ob Buffer Trace aktiviert ist Objekt
3. 1400 Stichprobenumfang 3000 on u 577 814 E o 47 276 1000 op E 800 2 h amp 600 400 7 T T T T T 1 0 500 1000 1500 2000 2500 3000 Lastschritt Aufrufe Abbildung 4 15 Bearbeitungszeiten eines Lastschritts Quelle eigene Darstellung Parametrisierung Die Parametrisierung der logischen GC Komponenten wurde bereits angesprochen und hat folgende Merkmale Das durchschnittliche GC Intervall wird ber eine Denkzeit der GC Client Entries spezifiziert Die durchschnittliche GC Dauer wird ber die mittlere Bearbeitungszeit u der GC Sim Entry angegeben 4 3 Gesamtbetrachtung des Modells Die Modellierung des SAP Netweaver Portal Systems beruht grunds tzlich auf der 3 Schicht Architektur des SAP Netweaver Stacks siehe Kapitel 2 1 1 1 und entspricht somit dem Mo dellierungsprinzip der LQNs Die einzelnen Modellkomponenten konnen den Architektur schichten wie folgt zugeordnet werden LON Modell 132 Prasentationsschicht Benutzer Applikationsschicht Java Server Tabellenpuffer Sperrverwaltung GC Persistenzschicht Datenbank Aufgrund der geschichteten Modellierungsweise von LQNs existieren verschiedene Ebenen in der die Tasks platziert werden k nnen Somit entstehen Nachrichtenpfade die von der Ausgangsebene bis zur untersten Ebene vordringen k nnen und dabei nicht streng hierar chisch verlaufen m ssen Die Dauer vom Senden einer synchronen Anfrage bis hin zum Emp
4. IMacrosPortalHandle Lab 1 CaseStudyLabs Abbildung 5 4 Schematische Darstellung des internen Testtreiber Aufbaus Ouelle Jehle 2010 126 Testtreiber_Executer Die Klasse Testtreiber _Executer bergibt die ben tigten Pa rameter des Testtreibers und steuert dessen Ausf hrung Simulation und Evaluation 144 iMacrosTestDriver Diese Klasse ist ein Singleton Gamma et al 1995 und stellt die zentrale Komponente des Testtreibers dar Sie steuert die Ausfiihrung des Lastsze narios und erstellt die notwendige Anzahl an Benutzern mittels Instantiierung der Klasse UserBot Zudem wird sie ber den Verlauf der durchgef hrten Aktionen ber die Klasse ObserverAgent benachrichtigt und leitet gegebenenfalls die nach folgenden Schritte ein CourseConfiguration Wie bereits bei der Beschreibung der Fallstudie in Kapitel 5 1 dargestellt sind Vorbereitungen n tig die der Dozent vor den eigentlichen bungs einheiten vornimmt Dazu z hlen unter anderem die Erstellung der Schulungsordner sowie das Anlegen der Benutzer die von den Schulungsteilnehmern verwendet wer den Die Klasse CourseConfiguration bernimmt die Initialisierung der ben tigten Objekte f r die Durchf hrung der bungseinheiten und verwendet f r die Kommuni kation mit dem Portalsystem die ausgelagerte Klasse iMacrosPortalHandle iMacrosPortalHandle In dieser Klasse sind alle grundlegenden Interaktion
5. Theoretische Grundlagen 39 Die wichtigsten strukturellen Eigenschaften von Markov Ketten sind wie folgt Homogen Eine homogene Markov Kette besitzt zu jedem Zeitpunkt dieselben Wahr scheinlichkeiten somit sind die bergangswahrscheinlichkeiten zeitunabh ngig Domschke Drexl 2007 218 Gedd chtnislos Die Ged chtnislosigkeit nimmt Einfluss auf die Markov Eigenschaft da f r k nftige Systembewertungen lediglich der aktuelle Zustand wichtig ist und kei ne vorhergehenden Zust nde im Ged chtnis bleiben Lunze 2006 347 Absorbierend Wenn eine Markov Kette mindestens einen absorbierenden Zustand be sitzt hei t sie absorbierend Ein Zustand i S wird genau dann ein absorbierender Zustand genannt wenn kein anderer Zustand der zeitdiskreten Markov Kette von ihm erreicht werden kann Bolch et al 2006 62 Irreduzibel Eine Markov Kette wird irreduzibel genannt wenn alle Zust nde in der Kette paarweise untereinander erreichbar sind Erreichbarkeit ist gegeben wenn es m glich ist von Zustand i zu Zustand j in einer endlichen Anzahl von Schritten zu ge langen Bolch et al 2006 62 Reduzibel Bei einer reduzierbaren Markov Kette kann die Zustandsmenge Z in dis junkte Teilmengen Z von untereinander stark zusammenh ngenden Zust nden zerlegt werden Zwei Zust nde i und j sind stark zusammenh ngend wenn es einen Pfad so wohl von i nach j als auch umgekehrt gibt Lunze 2006 357 F r die
6. IBM 2011j topasrec erstellt w hrend der Aufzeichnung eine Bin rdatei mit den lokalen System Metriken Cross Eletronic Circuit Metriken CEC Metriken und Cluster Metriken Bei der Verwendung von topasrec wurden folgende Parameter verwendet topasrec C c lt Anzahl gt s lt Intervall gt o lt Ausgabedatei gt Systemarchitektur und Monitoring 96 Der Parameter C gibt an dass auch die CEC Metriken aufgezeichnet werden c spezifi ziert die Anzahl der Aufzeichnungen s definiert das Intervall zwischen den Aufzeichnun gen und anhand des Parameters o wird die Ausgabedatei festgelegt Die aufgezeichnete Bin rdatei kann im Anschluss mit dem Hilfsmittel topasout zu einer CSV Datei konvertiert bzw kopiert werden Dabei wurden die Parameter c f r die Ausga be in eine CSV Datei und R lt Typ gt zum Spezifizieren der gew nschten Daten verwendet Tabelle 3 12 stellt die verf gbaren Leistungsdaten dar lt Typ gt Beschreibung summary Gibt eine bersicht zur Ressourcenverwendung wieder detailed Gibt einen detaillierten Bericht zur Ressourcenverwendung aus lan Gibt an wieviele Daten ber das Netzwerk gesendet bzw empfangen wurden disk Gibt an wieviele Daten auf Disks geschrieben bzw gelesen wurden poolinfo Gibt Informationen ber den geteilten Prozessor Pool des CEC wieder mempool Stellt Informationen zu den Hauptspeicher Pools der lo
7. Inhaltsverzeichnis Zusammenfassung nissen I Abbildungsverzeichns a REINER VI ET Zen CHAS ic scdissticissssacatasccsacepecanataccadtescssesccolsaseamerycosQoesscesavasvoovegsseaads A A e E E XI We TE 1 1 1 Problemstellung und Motivation der Arbeit ssssssssonssssosnssssnnesnnnnennnnnennnnnnnnnnnnnnen 2 1 2 Ke TE 4 1 3 Forschette sees ee Eet 6 1 4 H GSO ESTO E 8 1 5 Forschungsbereich am Lehrstuhl f r Wirtschaftsinformatik sscsccsssesees 11 1 6 Aufbau der Arbeit sense 12 2 Theoretische Grundlagen nes eegeg 15 2 1 Enterprise Resource Planning am Fallbeispiel SAP ccsssssosssssonsesnossennonsennnnnne 15 SH WE EE 17 2 1 2 SAP NetWweav r Portal EEN 23 2 2 Messtheoretische Grundlagen ssesssesssesssocssoosssoesssesssesssoossoossoossssssssesssoessoossosssose 24 2 2 1 Statistisch Eu SE EE 26 2 2 23 leet 29 2 3 Performance Evaluation von Rechnersystemen scccssccscsscsccsscscsecsscessesseseees 30 2 3 1 Berformanece Metriken eebe 31 23 2 HNN orkloal EE 33 2 3 3 Methoden der Performance Evaluation cccecccecsseceseceseceeeceeseeceeeceeeeeeeeeeneees 34 2 4 Warteschlanpennetze jsessassscsssesscceoussssevessoupncsoonssscodsnspiecssenssccavespscatosseanceespsesvasseeuac eh 44 2 5 Layered Queueing Networks scsscccsesssecssscssacsoesseceesssoudsscotsecssnstsccavovabacscsussacensvavenscsess 47 2 5 1 Komponenten von EON Modellen ox is dsussscesrsedniasatedatsestesdasbavitiaatan
8. Den Entries der Lastschritte Tasks werden die Service Zeiten und Varianzen zugewie sen Die Anfragen die von den Lastschritte Tasks gesendet werden werden spezifiziert Im gew hlten Beispiel werden im ersten Interaktionsschritt Lese und Schreibsperren Anfragen gesendet im zweiten Lastschritt Anfragen an den Tabellenpuffer Den Datenbank Entries der SQL Abfragen werden entsprechende Service Zeiten und Varianzen zugewiesen Bei der Tabellenpuffer Entry der lesenden SQL Abfrage wird eine Weiterleitungs wahrscheinlichkeit zur entsprechenden Entry des Datenbank Tasks definiert Der Enqueue Server leitet beide SQL Abfragen an die entsprechenden Tasks des Sperrmanagements Lese Schreibsperre weiter Sowohl der Lesesperren als auch der Schreibsperren Task wird ber einen Aktivit ts graphen definiert Die entsprechenden Entries verweisen auf die jeweilige Start Aktivit t des Aktivit tsgraphen Die Check Entry des Schreibsperren Tasks wird spezifiziert Die Entries des Semaphors werden als Wait bzw Signal Entry deklariert Simulation und Evaluation 163 Die Entry des Schreibsperren Pseudotasks wird definiert indem auf die entsprechende Aktivit t verwiesen wird 28 Entry Deklarationen A Aktivitat 29 E23 30 A U1E1 U1A1 Interaktionsschritte sind Uber Aktivitat U1A1 definiert 31 s W1E1 2 731 1 Lastschritt 1 Service Zeit 32 c W1E1 0 00438 1 Lastschritt 1 quadrierter Variatio
9. Markup Validation Service In http validator w3 org zugegriffen am 29 12 2011 2011 Wallace T F Kremzar M H 2001 ERP Make It Happen The Implementers Guide to Success with Enterprise Resource Planning 1 Aufl Wiley Hoboken NJ 2001 Wannenwetsch H H Nicolai S 2004 E Supply Chain Management 2 Aufl Vieweg Wiesbaden 2004 Wassermann G Yu D Chander A Dhurjati D Inamura H Su Z 2008 Dynamic Test Input Generation for Web Applications In International Symposium on Software Testing and Analysis Hrsg Seattle WA 2008 S 249 260 Weicker R P 1990 An Overview of Common Benchmarks In IEEE Computer Vol 23 1990 Nr 12 S 65 75 Weiss H P 1993 Benchmarking Learning from the Best In CPA Journal Online Vol 63 1993 Nr 10 S 81 Wilhelm K 2001 Capacity Planning for SAP Concepts and Tools for Performance Monitoring and Modelling Essen 2001 Winkler S 2010 Monitoring Kritische Prozess und Projektaktivit ten mithilfe pers nlicher Assistenten 1 Aufl Josef Eul Verlag Gmbh Erlangen N rnberg 2010 Winter R 2009 Interview mit Alan R Hevner zum Thema Design Science In Wirtschaftsinformatik Vol 51 2009 Nr 1 S 148 151 Literaturverzeichnis 204 Wohe G 2005 Allgemeine Betriebswirtschaftrslehre Vahlens M nchen 2005 Woodside C M 1989 Throughput Calculation for Basic Stochastic Rendezvous Networks In Performance Evaluation Vol 9
10. N gt N Cluster KORG Pr sentations Schicht Applikations Datenbank Schicht Schicht Abbildung 2 4 3 Schicht Architektur und Installationsvarianten Quelle eigene Darstellung 2 1 1 3 Ressourcennutzung Eine von Jehle 2010 15f durchgef hrte Erhebung der Ressourcennutzung l sst bereits eine grunds tzliche Einordnung der einzelnen Schichten bzw Technologien eines SAP ERP Systems hinsichtlich der CPU Hauptspeicher und I O Nutzung zu Die Einordnung dient lediglich als grobe bersicht welche Ressource von welchen Komponenten besonders stark beansprucht wird Datenbankschicht Pr sentationsschicht HTTP Edel E CPU Pr sentationsschicht SAP GUI Applikationsschicht ABAP Applikationsschicht J2EE gering mittel hoch Abbildung 2 5 Ressourcenbedarf nach Schichten Quelle eigene Darstellung in Anlehnung an Jehle 2010 Wie man in Abbildung 2 5 erkennen kann ist der Ressourcenbedarf bei der Applikations schicht im Java Umfeld besonders hoch Die I O Ressourcen werden allerdings nur dann stark beansprucht wenn die entsprechende Portal Applikation viele Zugriffe auf die Datenba sis aufweist In vielen Fallen aber beispielsweise bei den in dieser Arbeit modellierten portal internen Funktionen kann von einem hauptspeicher und CPU intensiven Lastmuster ausge gangen werden Theoretische Grundlagen 23 2 1 2 SAP Netweaver Portal Das in dieser Arbeit betrachtete SAP Netweaver Porta
11. Systeme PEER F r eine ausf hrliche Darstellung der Architektur sowie Validierung der funktionalen Aspekte sei auf die entsprechende Arbeit verwiesen Zusammenfassend lassen sich die Eigenschaften von PEER wie folgt beschreiben Grafische Benutzeroberfl che PEER bietet eine grafische Benutzeroberfl che von der aus die Tests geplant konfiguriert und ausgef hrt werden k nnen Lasterzeugung PEER verwendet das von iOpus entwickelte Werkzeug iMacros iOpus 2012 zur Wiedergabe von den im Web Browser aufgezeichneten Benutzerak tionen Darstellung der Ergebnisse Neben der Lasterzeugung dient PEER auch der Auf zeichnung von Leistungsdaten Dabei werden im Black Box Ansatz die Antwortzeiten der einzelnen Interaktionsschritte festgehalten und aggregiert dargestellt Einheitliche Schnittstellen Aufgrund der modularen Architektur und der Verwendung von einheitlichen Schnittstellen ist es problemlos m glich eigene Lastmodule einzu binden Die modulare Architektur von PEER wird durch die Trennung der grafischen Oberfl che GUI der Ausf hrungseinheit und dem Konfigurator realisiert Da die Aufzeichnung von Black Box Messdaten und die Darstellung der Ergebnisse f r diese Arbeit nicht genutzt wer den sind lediglich die bereitgestellten Lastmodule relevant auf denen aufbauend der f r diese Arbeit verwendete Workload umgesetzt werden kann Nichtsdestotrotz soll der Testtreiber die Kompatibilit t zur Verwaltungseinhei
12. aufrufen 5 6 Eigenen Meeting Room aufrufen 5 7 Eigenen Task anlegen Single Step 5 8 Collaboration Launch Pad CLP aufrufen 5 9 User zum CLP hinzuf gen 5 10 E Mail an CLP Benutzer verschicken X 5 11 Instant Messaging mit CLP Benutzer X 5 12 Application Sharing mit CLP Benutzer X 5 13 Benutzer abmelden 1 14 Tag 6 ffentliche Dokumente Versionierung 6 0 Benutzer anmelden 1 1 6 1 Ordner f r ffentliche Dokumente erstellen 1 5 6 2 ffentliches Dokument erstellen Anhang 207 6 3 Inhalt f r ffentliches Dokument eingeben 6 4 ffentliches Dokument versionieren 6 5 ffentlichen Ordner ffnen 6 6 Benutzer abmelden 1 14 Tag 7 Benutzerverwaltung und Sicherheit 7 0 Benutzer anmelden 1 1 7 1 Benutzer anlegen 1 2 7 2 Benutzerdaten eintragen 2 8 7 3 Benutzer zu Gruppen hinzuf gen Administrator 1 4 7 4 Benutzerprofil speichern 2 6 7 5 Ordner anlegen 1 5 7 6 Rolle anlegen 1 6 7 7 Portal Content Objekt ffnen 1 7 7 8 Einstiegspunkt aktivieren 1 8 7 9 Rolle einer Gruppe zuordnen 1 9 7 10 Benutzerpasswort ndern 7 11 Bneutzer abmelden 1 14 Tag 8 Developer Studio Visual Composer 8 0 Benutzer anmelden 1 1 8 1 Startseite zu Composer navigieren 8 2 Visual Composer ffnen 8 3 Benutzer abmelden 1 14 X Nachbereitungen X 0 Benutz
13. 4 Demonstration Die Zweckm igkeit des entwickelten Artefakts wird in der vierten Phase berpr ft indem ein geeignetes Anwendungsszenario gew hlt und eine Instanz des Artefakts eingesetzt wird 5 Evaluation In der Evaluationsphase werden die erreichten Ergebnisse in Bezug auf die formulierten Ziele bewertet ber die Auswahl einer Evaluationsmethode vgl Hevner et al 2004 83 wird die Effizienz und Effektivit t des entwickelten Artefakts berpr ft und f hrt gegebenenfalls zu einem neuen Entwicklungszyklus 6 Kommunikation Schlie lich werden die gewonnenen Erkenntnisse Beschreibung des Problemraumes Signifikanz L sungsansatz erwarteter und evtl nachgewiesener Bei trag sowie Stringenz des Designprozesses an die Wissensbasis zur ckgef hrt Einleitung 11 1 5 Forschungsbereich am Lehrstuhl f r Wirtschaftsinformatik Die vorliegende Arbeit ist Teil einer Reihe von Forschungsarbeiten im Bereich der Perfor mance Evaluation von SAP ERP Systemen die am Lehrstuhl f r Wirtschaftsinformatik von Prof Dr Helmut Kremar an der Technischen Universit t M nchen TUM durchgef hrt wer den Aufgrund der beiden Technologieplattformen eines SAP ERP Systems ABAP Advan ced Business Application Programming und J2EE Java 2 Enterprise Edition unterteilen sich die Arbeiten vertikal in die jeweilige technologische Basis In horizontaler Hinsicht ge hen aus den Erkenntnissen der durchgef hrten Performance Messungen die Untersuchu
14. 585 598 Hower R 2009 Web Site Test Tools and Site Management Tools 420 Tools Listed In http www softwareqatest com qatweb1 html zugegriffen am 28 12 2011 2011 Hu L Gorton I 1997 Performance Evaluation for Parallel Systems A Survey 9707 University of New South Wales Sydney Australia 1997 IBM 201 1a IBM Active Memory Expansion In https www ibm com developerworks wikis display WikiPtype IBM Active Memor y Expansion zugegriffen am 10 07 2011 2011 Literaturverzeichnis 196 IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM livari iOpus 2011b IBM AIX Unix on Power Systems In http www 03 ibm com systems power software aix index html zugegriffen am 11 07 2011 2011 2011c IBM Support Assistant Tool Add Ons List In http www 01 ibm com support docview wss uid swg27013116 IBM 20Monitoring 20and 2 ODiagnostic zugegriffen am 19 09 2011 2011 20114 IBM XIV Storage System In http www 03 ibm com systems de storage disk xiv zugegriffen am 07 07 2011 2011 201 1e iostat Command In http publib boulder ibm com infocenter aix v6rl index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopasout htm zugegriffen am 08 07 2011 2011 2011f mpstat Command In http publib boulder ibm com infocenter aix v6rl index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopasout htm zugegriffen am 08 07 2011 2011 2011g Pattern Modeling and Analysis Tool
15. Aufgabe gewartet und erst im Anschluss der n chste Interaktionsschritt eingeleitet wird Die Anzahl der synchronen Anfragen wird ber den Parameter lt rendezvous gt angegeben Da im Normalfall jeder Lastschritt einmal ausgef hrt wird wird der Para meter auf den deterministischen Wert 1 gesetzt 4 2 2 Lastschritt Die Abarbeitung einer Benutzeranfrage siehe Kapitel 3 1 1 soll aus der Sicht des Servers als Lastschritt bezeichnet werden W hrend der Abarbeitung des Programmcodes kann ein Last LQN Modell 110 schritt lesend oder schreibend auf die Datenbank zugreifen Falls die Daten im Tabellenpuffer vorgehalten werden kann ein vergleichsweise langsamer Zugriff auf die Datenbank umgan gen werden siehe Kapitel 3 1 4 Bei einem Datenbankzugriff k nnen zudem Sperren gesetzt werden die ber den Enqueue Server verwaltet werden siehe Kapitel 3 1 3 LQN Modellierung Ein LQN Task reprasentiert wie in Kapitel 2 5 1 dargelegt Ressourcen eines Systems bei spielsweise Systemprozesse Benutzer Hardware Einheiten oder Lastschritte Ein LQN Task hat eine eigene Warteschlange f r die eingehenden Anfragen und ist mit ei nem Prozessor Task der CPU Ressource verbunden Die Abarbeitung der Anfragen kann nach den folgenden Scheduling Mechanismen erfolgen FIFO First In First Out Der Standardmechanismus bei dem die Anfragen in der Reihenfolge abgearbeitet werden wie sie eingetroffen sind PPR Priority Preemptive Resu
16. B Fraser K Hand S Harris T Ho A Neugebauery R Pratt I Warfield A 2003 Xen and the Art of Virtualization In 19th ACM Symposium on Operationg Systems Principles Hrsg Bolton Landing NY 2003 S 164 177 Baumgarten U Siegert H J 2007 Betriebssysteme Eine Einf hrung M nchen Oldenbourg Wissenschaftsverlag 2007 Bause F 1993 Queueing Petri Nets A Formalism for the Combined Qualitative and Quantitative Analysis of Systems In 5th International Workshop on Petri Nets and Performance Models IEEE Hrsg IEEE Computer Society Toulouse Frankreich 1993 S 14 23 Bause F Beilner H 1989 Eine Modellwelt zur Integration von Warteschlangen und Petri Netz Modellen In 5 GI ITG Fachtagung Messung Modellierung und Bewertung von Rechensystemen und Netzen Hrsg Braunschweig 1989 S 190 204 Berman S 2008 Streuung und Streuungsma e In http homepage ruhr uni bochum de stephen berman Statistik Streuung html zugegriffen am 19 10 2011 2011 Bichler M 2006 Design science in information systems research In Wirtschaftsinformatik Vol 48 2006 Nr 2 S 133 135 Bl ttel B Koch V Mosel U 1993 Transport Theoretical Analysis of Relativistic Heavy Ion Collisions In Reports on Progress in Physics Vol 56 1993 Nr 1 Literaturverzeichnis 193 Boegelsack A 2012 Performance und Skalierung von SAP ERP Systemen in virtualisierten Umgebungen Technische Universit t M nchen
17. Eine genauere Betrachtung dieser Verfahren erfolgt in Kapitel 2 3 3 Abbil dung 2 8 veranschaulicht die Gleichwertigkeit von System Performance Metriken und Work load Performance Metriken worklead Methode der Performance Evaluation System Abbildung 2 8 Aspekte der Leistungsbewertung Quelle eigene Darstellung in Anlehnung an Rechenberg Pomberger Pirklbauer 2006 454 2 3 1 Performance Metriken F r die Bewertung der Leistungsfahigkeit eines Systems m ssen Performance Metriken defi niert werden Die Auswahl passender Metriken ist dabei stark problemorientiert So ist bei spielsweise f r Service Anfragen eines Benutzers an ein System die Antwortzeit von gro er Bedeutung wogegen bei der Analyse von Computernetzwerken dem Durchsatz eine gr ere Bedeutung zugeschrieben wird Es existieren eine Vielzahl von verschiedenen Metriken aber keine offiziellen Standards Risse 2006 Metriken von Standard Benchmarks beispielsweise von dem Transaction Processing Council betreffen nur bestimmte Applikationsszenarios und k nnen nicht generell eingesetzt werden siehe auch Kapitel 2 3 3 Nach Ray Jain 1991 sind folgende Eigenschaften f r Performance Metriken gefordert Geringe Variabilit t Redundanzfreiheit Vollst ndigkeit Neben einer geringen Variabilit t die f r eine h here statistische Konfidenz sorgt fordert die Redundanzfreiheit dass nicht mehrere Metriken f r abh ngige Variablen def
18. F r den vorgestellten L sungsansatz wer den existierende Erkenntnisse aus der Wissensbasis verwendet Applicable Knowledge und in Kapitel 2 und 3 diskutiert Kapitel 4 stellt das entwickelte Artefakt vor Eine Instanz des Artefakts wird in Kapitel 5 praktisch angewendet Application in the Appropriate En vironment und evaluiert Die Erkenntnisse der Evaluation aus Kapitel 5 sowie die Interpre tation der Ergebnisse in Kapitel 6 f hren das erlangte Wissen an die Wissensbasis zur ck Additions to the Knowledge Base Obwohl in der Arbeit von Hevner et al 2004 neben dem vorgestellten Rahmenwerk diverse Handlungsempfehlungen gegeben werden wird kein Forschungsprozess beschrieben der eine ordnungsgem e Durchf hrung der Designwissenschaft definiert Daher wird in dieser Arbeit der von Pfeffers et al 2006 89ff vorgeschlagene Designprozess angewendet Dieser wird in sechs Phasen unterteilt l Problemidentifikation und Motivation Ziel dieser Phase ist die Definition der Prob lemstellung und der Motivation der Arbeit Neben dem Problemverst ndnis sollen be stehende L sungen analysiert und das Verbesserungspotential aufgezeigt werden 2 Zieldefinition Aus dem Problemverst ndnis der ersten Phase werden die Ziele quanti tativer oder qualitativer Art abgeleitet 3 Konzeption und Entwicklung In dieser Phase wird unter Zuhilfenahme der Erkennt nisse aus der Wissensbasis das eigentliche Artefakt entwickelt
19. F r die gesamte Abbildung der Portalfallstudie werden s mtliche Labs hinzugef gt setAlignedRun Es besteht die M glichkeit nach jedem Interaktionsschritt die Benut zer zu synchronisieren und damit den Verlauf einer bungseinheit zu simulieren bei der der Dozent nach jedem Schritt wartet bis die Teilnehmer die Aufgaben durchge f hrt haben F r die in dieser Arbeit durchgef hrten Messungen wird diese Funktion nicht verwendet und daher auf false gesetzt setThinkTimeFlag PEER sieht f r die Benutzerdenkzeiten auf der Ebene des Testtrei bers keine entsprechende Konfigurationsm glichkeit vor Die vorgeschlagene Umset zung erfolgt lediglich auf der Ebene der Testlaufkomposition bei der ein Pseudo Testtreiber zwischen den einzelnen Testtreibern die Denkzeit des Benutzers simuliert vgl Jehle 2010 143 Daher musste der Portalfallstudien Testtreiber um eine Denk zeitkomponente erweitert werden Mit diesem Methodenaufruf kann die Verwendung von Denkzeiten zwischen den Interaktionsschritten aktiviert werden die ber die be reitgestellte Methode Thread sleep realisiert wird doStart Sobald alle Parameter durch die soeben vorgestellten Methodenaufrufe ge setzt wurden kann der Testlauf mit dieser Methode gestartet werden Mit den genannten Erweiterungen des Lastmoduls sowie den notwendigen Anpassungen f r die verwendete Portal Version kann das Portal mit dem vorgestellten Workload unter Last gesetzt wer
20. Layered Queueing Networks LQN ein Im Zuge der Mo dellerstellung werden spezielle Architekturmerkmale eines SAP Netweaver Portal Systems ber cksichtigt und bestehende Ans tze entsprechend erweitert Methode Die Arbeit basiert auf einem gestaltungsorientierten Ansatz Ausgehend von den bestehenden Erkenntnissen aus der Wissensbasis und dem in einer Online Umfrage festge stellten Bedarf in der Praxis werden systeminh rente Einflussfaktoren auf die Leistung des Systems analysiert und in einem LQN Modell dem zentralen Artefakt dieser Arbeit abgebil det Die Gestaltung des Artefakts wird neben der Mess und Warteschlangentheorie von den ermittelbaren Daten aus der Leistungsmessung geleitet F r die Bewertung der Tragf higkeit des Ansatzes wird das Modell unter Verwendung eines Lastmusters aus der Praxis instanzi iert Anschlie end werden die erzielten Simulationsergebnisse sowie die ermittelten Messwer te zum Vergleich herangezogen und die Ursachen f r auftretende Differenzen analysiert Resultate Durch die Ber cksichtigung und Umsetzung spezieller Architekturmerkmale eines SAP Netweaver Portal Systems konnten vielversprechende Simulationsergebnisse in Bezug auf das Antwortzeitverhalten erzielt werden Auftretende Wartezeiten aufgrund von Re chenengp ssen sowie ausgelasteten Applikations Threads werden dem tats chlichen Verhal ten entsprechend ber cksichtigt Ebenso konnten durch die Modellierung des Sperrmanage ments und der Tabe
21. Mainframe Systemen vollzogene Paradigmenwechsel erm glichte eine signifikante Redukti on der Kosten sodass ERP Systeme auch f r den gehobenen Mittelstand interessant wurden Technische Notwendigkeiten wie zum Beispiel das Jahr 2000 Problem oder die europ ische W hrungsunion f rderten zudem den Umstieg von Individuall sungen zu Standardsoftware Gadatsch 2002 210 Ende der neunziger Jahre sowie Anfang dieses Jahrhunderts wurden nicht zuletzt durch tech nische Fortschritte und steigende Leistungsf higkeit von Computersystemen ERP Systeme auch f r den mittleren sowie unteren Bereich des Mittelstandes wirtschaftlich Gadatsch 2002 210f Das Werben um die Gunst des Mittelstandes dauert bis heute an da sich im Ge gensatz zu Gro unternehmen und dem oberen Segment der Mittelstandsunternehmen bei SAP Webseite http www sap com germany index epx Theoretische Grundlagen 17 denen SAP die Marktf hrerrolle seit Jahren bernommen hat kein eindeutiger Marktf hrer herausbilden konnte Jiingste Bestrebungen von SAP kleine und mittlere Unternehmen KMUs zu erreichen stellt sich in Form der Softwarel sung Business by Design ByD dar die als Software as a Service SaaS angeboten wird Dabei wird die Software von SAP als Application Service Provider ASP zur Verf gung gestellt und von den Kunden angemietet Der Unterschied zu dem klassischen ASP Konzept liegt dabei vor allem bei der Entkopplung zwischen Servicekonsument und Applika
22. Programm oder Datenstrukturen zu ver bessern Alpar et al 2008 55 Die unterschiedlichen Messgr en die mit einem Monitor erfasst und ausgewertet werden k nnen m ssen definiert sein Mit den erhobenen Daten kann man anschlie end Aussagen ber den Betriebszustand des berwachten Systems t tigen das Leistungsverhalten der Funk tionseinheiten analysieren und Leistungsengp sse aufdecken Die verrichtete berwa chungst tigkeit wird wie bereits in Kapitel 1 2 erw hnt Monitoring genannt Winkler 2010 27 Rechenberg Pomberger Pirklbauer 2006 460 F r die Leistungsmessung k nnen unterschiedliche Monitoring Methoden verwendet werden Ausgehend von der Implementierungsebene unterteilt man Monitore in Hardware Software und Hybrid Monitore Hardware Monitore Ein Hardwaremonitor ist ein eigenst ndiges komplexes elekt ronisches Messinstrument welches mit Messf hlern die Leistung der Hardwarekom ponenten erfassen kann Durch die Messung elektrischer Signale in der Hardware ei nes Systems k nnen dessen Zust nde ermittelt werden wie zum Beispiel dessen CPU Die Datenerfassung untergliedert sich in Aufnahme Verkn pfung und Verarbeitung der mit Hilfe der Messf hler erfassten Signale Alpar et al 2008 55 Haas Zorn 1995 209 Ein gro er Vorteil von Hardwaremonitoren ist dass sie sehr kurze Vorg nge korrekt erfassen k nnen und keinen Messaufwand im System erzeugen was f r Echt zeitsysteme wesentlich ist Nachte
23. S 40 61 Obaidat M S Boudriga N 2010 Fundamentals of performance evaluation of computer and telecommunication systems John Wiley amp Sons Hoboken N J 2010 Oed W Mertens B 1981 Characterization of computer system workload In Computer Performance Vol 2 1981 Nr 2 S 77 83 Oracle 2011 Java SE HotSpot at a Glance In http www oracle com technetwork java javase tech index jsp 136373 html zugegriffen am 08 12 2011 2011 Orth B 1974 Einf hrung in die Theorie des Messens Kohlhammer Stuttgart 1974 Park A Becker J C 1990 IOStone A Synthetic File System Benchmark In Computer Architecture News Vol 18 1990 Nr 2 S 45 52 Parupudi M Winograd J 1972 Interactive Task Behavior in a Time Sharing Environment In ACM Annual Conference Hrsg Boston MA 1972 S 680 692 Peterson J L 1977 Petri Nets In ACM Computing Surveys Vol 9 1977 Nr 3 S 223 252 Literaturverzeichnis 200 Petri C A 1962 Kommunikation mit Automaten Institut f r Instrumentelle Mathematik Universit t Bonn 1962 Petriu D 1994 Approximate Mean Value Analysis of Client Server Systems with Multi Class Requests In ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems Hrsg Nashville TN 1994 S 77 86 Petriu D Amer H Majumdar S Al Fatah I 2000 Using Analytic Models for Predicting Middleware Performance In Second International Workshop on Software and Perf
24. Speicherverwaltung System Overhead wird nicht ausreichend Rechnung getragen Die in diesem Zusammenhang geltenden Limitationen bei der LQN Modellierung wurden bereits in den Kapiteln 4 2 6 so wie 5 8 dargestellt Zur weiteren Bewertung soll eine Betrachtung der einzelnen Komponenten bzw Einflussfak toren erfolgen die in Kapitel 4 1 2 identifiziert wurden Eine grunds tzliche Einsch tzung der Umsetzung sowie der erzielten Ergebnisse wird in Tabelle 6 1 vorgenommen wobei die Ten denz anhand der Pfeilrichtung veranschaulicht werden soll Fazit 185 Komponente Einflussfaktor Modellierungsart Bewertung Client Anzahl Denkzeit Parameter ch Referenz Komponente die die Last schritte aufruft Einflussfaktoren sind parametrisierbar Lastschritt Dispatching Zeit und Implizit ch Wartezeiten Dispatching und Wartezeiten werden implizit tiber die Warteschlangen des Modells erfasst Bearbeitungszeit Parameter a Angabe erfolgt tiber den Mittelwert und die Streuung Abbr che Parameter 7 max_service time Gut geeignet zur berpr fung von SLAs Datenbankaufrufe Synch Aufrufe a ggf Datenbanktask Gut abbildbar inkl Sperrmanagement Tabellenpuffer und Pufferung Allerdings aufw ndig Sperrmanagement bei der Modellierung Datenbank Bearbeitungszeit Parameter gt Black Box Die Datenbank wird lediglich als Blackbox betrachtet Tabellenpuffer Verdr ngungen Weiterleitungs A Invalidierung
25. Springer Gabler 2012 Boegelsack A Wittges H Kremar H 2010 Scalability and Performance of a Virtualized SAP System In Proceedings of the 16th American Conference on Information Systems Hrsg Lima Peru 2010 S Paper 13 Boegelsack A Wittges H Kremar H Kuehnemund H 2011 Zachmanntest A Synthetic Memory Benchmark for SAP ERP Systems In Zhang R Cordeiro J Li X Zhang Z Zhang J Eds CEIS 1 S 348 355 SciTePress Bolch G Greiner S de Meer H Trivedi K S 2006 Queueing Networks and Markov Chains Modeling and Performance Evaluation with Computer Science Applications John Wiley and Sons Hoboken NJ USA 2006 Bond B Genovese Y Miklovic D Wood N B 2000 ERP is dead Long live ERP II In Strategic Planning SPA Vol 12 2000 S 12 15 B nnen C Herger M 2007 SAP Netweaver Visual Composer Galileo Press Bonn Boston 2007 Bortz J D ring N 1995 Forschungsmethoden und Evaluation F r Sozialwissenschaftler 2 vollst berarb Aufl Springer Verlag GmbH Berlin Heidelberg 1995 Buchholz P 1992 A Hierarchical View of GCSPNs and its Impact on Qualitative and Quantitative Analysis In Journal of Parallel and Distributed Computing Vol 15 1992 Nr 3 S 207 224 Chamberlin D D Boyce R F 1974 SEQUEL A structured English Query Language In ACM SIGFIDET jetzt SIGMOD Workshop on Data Description Access and Control Hrsg Ann Harbor Michiga
26. Trace List of Traces Trace Status Refresh 46250 Output limited to 5000 records in total portalsim informatik tu muenchen de c d Ze A No Result Statement SQLTrace Record Detail trace id sat_sqltrace node 2246250 Connection setAutoCommit boolean 5 bAutoCommit setAutoCommit false Attribute Value s EE Location com sap sql jdbc direct DirectPreparedStatement executeQue ss PreparedStatement executeQuery x p sql j p Query REENEN SELECT NAME CHANGE FROM KMC Time Wed Feb 22 14 41 03 CET 2012 Re m SES ond 1 false next Duration 530 sap comfrji RS 880096373 microseconds Guest ResultSet close 1 dose Statement SELECT sap comfrj RS 880096373 5 NAME CHANGE Guest PreparedStatement clearBatch r n U sap comfr STMT 1324437233 e Guest PreparedStatement clearBatch Kaes SE 1 sap com ri STMT 860631884 1 dearBatch CHANGE gt 3 1 So Weber 1 dearBatchO J2EE sap com irj Guest Connection commit Application 217 Sap com rj commit i J2EE user Guest t J2EE Session 0 Thread Thread com sapportals wcm service cache ClusterCacheTable Refresher Bind 2 1314373186585 Parameters ResultSetld 1195394880 Table names KMC_CMCC_TABLE Prepared 682371244 Statement Id VendorSQL 381163192 statement Id DSR 540bea945bee11e18df300000022466a Transaction Id Unique log 0E1EB1D4DE03007E0001E1CC003C01120004B98DADC47717 record
27. fang der Antwort wird als Antwortzeit interpretiert Aufbauend auf die grunds tzliche Modellierung der einzelnen Schichten Pr sentationsschicht mittels Benutzer Task Applikationsschicht mittels Lastschritte Task und Persistenzschicht mittels Datenbank Task wurden f r die Datenbankanfragen die Sperrverwaltung sowie die applikationsseitige Tabellenpufferung explizit modelliert Dies hat den Vorteil dass zus tzli che Wartezeiten aufgrund des wechselseitigen Zugriffs auf die Datenbasis sowie der Leis tungsgewinn mittels zwischengespeicherter Daten im Tabellenpuffer nicht nur implizit in der Service Zeit der Datenbankkomponente enthalten ist Betrachtet man nun das Schichtprinzip des LQN Modells werden Anfragen von dem Benut zer Task initiiert und an die darunterliegende Ebene dem Lastschritte Task gesendet Die Lastschritte wiederum k nnen Datenbankaufrufe erfordern die abh ngig von der optional verwendeten Sperrverwaltung und der potentiellen Verwendung des Tabellenpuffers ber verschiedene Wege realisiert werden und in Kapitel 4 2 5 dargestellt wurden Zus tzlich wurde zur Analyse der Auswirkungen des Garbage Collectors die M glichkeit geschaffen die Aktivit tsintensit t ber die N herungswerte der beiden Parameter durch schnittliche GC Dauer und durchschnittliches GC Intervall zu justieren Die logischen GC Komponenten des Modells betreffen das Speichermanagement der Applikationsschicht Abbildung 4 16 zeigt ein
28. nenne 145 Abbildung 5 6 Ressourcenzuweisung im ersten Test azenarto 147 Abbildung 5 7 Ressourcenzuweisung im zweiten Test Raenaro sese 148 Abbildung 5 8 Einschwingverhalten am Beispiel einer Men Navigation ssssssseseesesse0 149 Abbildung 5 9 Oszillierende Messwerte 150 Abbildung 5 10 Kumulierte Antwortzeiten in Sekunden Szenario 1 151 Abbildung 5 11 Trefferrate der Pufferzugriffe in Prozent Szenario 1 152 Abbildung 5 12 Durchschnittliche Datenbankzeit pro DB Anfrage in Millisekunden Ben E ER 153 Abbildung 5 13 Durchschnittliche Enqueue Zeit pro Sperrobjekt in Millisekunden Szenario I TEE 154 Abbildung 5 14 CPU Zeit eines EJB Requests sowie durchschnittliche CPU Nutzung CS ZCI ALIOAL D EEEE T E AE E E E EEN 155 Abbildung 5 15 Trefferrate der Pufferzugriffe in Prozent Szenario 21 156 Abbildung 5 16 CPU Zeit eines EJB Requests sowie durchschnittliche CPU Nutzung ESYA E EE 157 Abbildung 5 17 Kumulierte Antwortzeiten in Sekunden Szenario 21 158 Abbildung 5 18 Zusammensetzung der Service Zeit in der Ausgabedatei Beispiel 167 Abbildung 5 19 Vergleich der Simulations und Messwerte Szenario In 171 Abbildung 5 20 Vergleich der Simulations und Messwerte Szenario 2 173 Abbildung 5 21 Dauer der Garbage Collector L ufe Szenario 2 80 Benutzer 177 Abbildungsverzeichnis Ix Abbildung 5 22 Intervall zwischen den Garbage Collector Laufen Szenario 2 80 Benutzer Vase heet Ee
29. t Mcpy 40 verwendet Dies stellt sicherlich eine idealisierte Sicht dar da in der Praxis eben solche Messdaten meist nicht zur Verf gung stehen Nichtsdestotrotz h tte eine angenommene maximale Nutzlast von 75 bis 80 Prozent zu einer Parametrisie rung von ca Mcpy 37 gef hrt und die Simulationsergebnisse nur leicht verschoben Der Hauptspeicher ist zwar immer noch ausreichend f r die Speicherallokation der JVM allerdings sorgt die Verknappung zu erh hten GC Aktivit ten im Hochlastbe reich Die Gr e des Tabellenpuffers wurde reduziert sodass nicht alle gepufferten Objekte im Tabellenpuffer Platz finden und es folglich zu Verdr ngungen kommt Simulation und Evaluation 174 Im Bereich zwischen 1 bis 40 Benutzern ist auch in diesem Szenario ein leichter Anstieg des Antwortzeitenzuwachses zu verzeichnen der sich analog zu dem ersten Szenario ber zu nehmende Sperrsituationen erkl ren l sst Hinzu kommt die mit steigender Benutzeranzahl abnehmende Trefferrate des Tabellenpuffers Die erh hte Grundantwortzeit bei einem Benut zer ist ebenfalls auf den Tabellenpuffer zur ckzuf hren da die Trefferquote bereits bei einem Benutzer bei gut 80 Prozent liegt und somit geringer ist als im ersten Szenario Ab 40 simultanen Benutzern wirkt sich die erw hnte Begrenzung der CPU Ressourcen auf die Antwortzeiten aus Von nun an treten Wartezeiten am Prozessor auf die sich auch in den Simulationsergebnissen im entsprechenden Abschnitt be
30. ter bergabe zur Umsetzung der Portalfallstudie Der Aufruf der Methoden erfolgt ber den bergeordneten Testdriver Executer der aufgrund des Verzichts der PEER GUI auch die Einstiegskomponente darstellt Die umzusetzenden Methoden sind in Abbildung 5 5 darge stellt und werden im Folgenden kurz erl utert Simulation und Evaluation 145 lt lt interface gt gt iMacrosTestDriver_Interface setAdminLoginData adminUn String adminPwd String void setUserLoginData userPre String userPass String void setHostName hostName String void setRunEnvironment runEnv RunEnvironment void setNumberOfUser numUser int void setNumberOfLoadRuns numLoadRuns int void setBrowserRunMode runMode runMode int setRunCourseConfiguration runCourseConfigurations boolean void addLabsToRun labToAdd UserJob void setAlignedRun alignedRun boolean void setThinkTimeFlag thinkTimeFlag boolean void doStart void Abbildung 5 5 Testtreiber Interface fiir die Portalfallstudie Quelle eigene Darstellung in Anlehnung an Jehle 2010 124 setAdminLoginData Hiermit wird das Administratorkennwort bergeben das den Testtreiber erlaubt die n tigen administrativen Aufgaben durchzuf hren wie zum Beispiel die Erstellung von Fallstudien Benutzern setUserLoginData Das mit dieser Methode bergebene Pr fix wird allen Benutzern und erstellten Objekten vorangestellt Dadurch ist es m glich
31. 0 0_22462 Services Performance Tracing Connect View Tools Help e m ele ODEO amp Key Storage Fr um gt Iw limit 100 4 Leak Detector ZA Licensing Adapte ZA Locking Adapter 4 Log Configurator 4 Log Viewer ZM Memory Info Zen Message Info ZM Migration Service Z Monitoring 4 NZDM Service 4 P4 Provider 4 PDF Manipulation A 4 Performance Trad PRI DC po tent com sap pct admin t ZM PMI S S ifyAttriputes 4 prtbridge 4 Remote Object C ZA Runtime Info Pro Zo SAML 4 SDIC Service 4 Secure Storage 4 Security Provider e J 4 Session Failover P PRT_init com sap portal appdesigner framework tabc PRT_render pcd portal_content administrator super_ EP PRT_render pcd portal_content every_user general EP PRT_init pcd portal_content every_user general defa Connected to portalsim informatik tu muenchen de Abbildung 3 15 Komponentenansicht der JARM Daten Quelle eigene Darstellung 3 2 2 Single Activity Trace Der Single Activity Trace SAT verwendet die von JARM zur Verf gung gestellten Daten allerdings werden hierbei alle erfassten Leistungsdaten aufgezeichnet Es k nnen somit die Benutzeranfragen einzeln analysiert und die logischen Abarbeitungsschritte Komponenten f r jede Anfrage zusammen mit ihren Performance Daten erfasst werden Der Trace wird ber die Logging API des SAP Systems automatisch in eine Da
32. 03 33 57 ider Web Request Administrator 22 B 03 33 58 Detailansicht 4 eR Web Request Administrator 13 el Ge See h emer Speicher und Prozessinfo Systeme Aktionen U hwender Text Text Gi SAPI2ENode port Name der Komponente fray i oo E Een Detatansicht Ji Aktons Typ SF EL EL amp Darstellun Prozess Id geg da Se Thread Id BIE eR J E i W iste max Speiherverbrauch Zeiten 210O2 2012105755 ee ie Dela Name der Komponente Wert Einhe Iesse ID men 3837 ms CPU Zeit 338 ms Aufruf Rol Wartezeit ms 0 ms Ladezeit ms 0 ms Generierzeit 0 ms Wartezeit des Schrittes ms 787 ms Netzwerkzeit 0 ms SAJ P98 1 101 portalccms OVR Abbildung 3 20 Anzeige des funktionalen Trace Quelle eigene Darstellung Zeiten CPU Ladezeit Wartezeit Netzwerkzeit etc Speicher und Prozessinformationen bei denen unter anderem die Transaktions ID GUID festgehalten wird Datenbank Prozeduren Request Typ Anzahl der Aufrufe Datenbankzeit etc In der Client Info Detailansicht ist der Cert Subrecord zu finden der Informationen zur Quelle der LUW dem Beginn der Benutzeraktion bereitstellt F r die Auswertung der Einzeldatens tze k nnen die Performance Daten exportiert und bei spielsweise in Excel grafisch analysiert werden siehe Abbildung 3 21 Systemarchitektur und Monitoring 90 Reste JA a SP EE ER DSB JE e Statistikeinzels tze
33. 126358 HH 10 2 8 2 875 0 128808 D LATE FR TR EN 11 2 875 2 95 0 147248 0 068986 re h 12 2 95 3 025 0 142279 0 098897 Fr nr 13 3 025 3 1 0 122559 0 107793 FF HERE FTRERE 14 3 1 3 175 0 098469 0 114087 RRR EES 15 3 175 3 25 0 075110 0 122356 16 3 25 3 325 0 055729 0 048624 17 3 325 3 4 0 039102 0 076470 18 3 4 3 475 0 026734 0 082474 19 3 475 3 55 0 017975 0 078640 20 3 55 3 625 0 011830 0 062569 21 3 625 3 7 0 007924 0 033113 22 3 7 3 775 0 004894 0 036135 23 3 775 3 85 0 003016 0 035690 24 3 85 3 925 0 001948 0 013682 25 3 925 4 0 001192 0 041501 26 overflow 0 001735 0 051717 Listing 5 11 Service Zeit Verteilung des ersten Lastschritts Beispiel Quelle eigene Darstellung Die Histogrammfunktion ist mit Version 5 6 des Simulators nicht mehr lauff hig Daher musste f r die Analy se der Service Zeit Verteilungen auf die Vorg ngerversion 5 5 ausgewichen werden Simulation und Evaluation 170 Mit einer Parametrisierung der Service Zeit von 2 731 und der Verteilung von 0 00438 bei dem ersten Lastschritt des Beispielmodells ergibt sich die erwartete Gammaverteilung die vom Simulator bei einem quadrierten Variationskoeffizienten von 0 lt c2 lt 1 angewendet wird vgl Kapitel 4 2 2 Im vorletzten Abschnitt der Ausgabedatei werden Informationen zu dem Durchsatz und der Nutzung der einzelnen Entries und Aktivit ten wiedergegeben Zus tz
34. 1989 Nr 2 S 143 160 Woodside C M Neilson J E Petriu D C Majumdar S 1995 The Stochastic Rendezvous Network Model for Performance of Synchronous Client Server like Distributed Software In IEEE Transactions on Computers Vol 44 1995 Nr 1 S 20 34 Woodside C M Neron E Ho E D S Mondoux B 1986 An Active Server Model for the Performance of Parallel Programms Written Using Rendezvous In Journal of Systems and Software Vol 6 1986 Nr 1 2 S 125 131 Woodside M 2002 Tutorial Introduction to Layered Modeling of Software Performance Carleton University Ottawa Canada 2002 Xu J Oufimtsev A Woodside M Murphy L 2005 Performance modeling and prediction of enterprise JavaBeans with layered queuing network templates In SIGSOFT Softw Eng Notes Vol 31 2005 Nr 2 S 5 Zieher M 1989 Kopplung von Rechnernetzen Techniken zu Planung Entwurf Vermessung und Leistungsoptimierung Universitat Karlsruhe 1989 Zitterbart M 1990 Monitoring and debugging transputer networks with NETMON II Proceedings of the joint international conference on Vector and parallel processing S 200 209 Zurich Switzerland Springer Verlag New York Inc Zuse H 1998 A Framework of Software Measurement Walter de Gruyter amp Co Berlin 1998 Zwerenz K 2009 Statistik Einf hrung in die computergest tzte Datenanalyse Oldenbourg Wissensch Vlg M nchen 2009
35. 2010 131 148 Wenngleich die implementierten Funktionen zur Erfassung der Leistungsdaten in der vorlie genden Arbeit nicht ausreichen da lediglich die Zeit aus Benutzersicht zwischen dem Absen den der Anfrage und dem Erhalt der Antwort festgehalten wird kann das PEER Rahmenwerk f r die Lasterzeugung verwendet werden vgl Applicable Knowledge in Abbildung 1 1 Einleitung 12 1 6 Aufbau der Arbeit Mit der Integration der Dienste und Anwendungen auf einer einheitlichen Plattform dem Un ternehmensportal ist die Sicherstellung ausreichender Ressourcen von zentraler Bedeutung Die Bewertung der Leistungsfahigkeit des Systems mittels Ex Post Analysen soll daher durch den Einsatz von Ex Ante Simulation erg nzt werden um zukiinftige Lastmuster und Lastin tensit ten einsch tzen und gegebenenfalls fr hzeitig darauf reagieren zu k nnen Die vorlie gende Arbeit hat das Ziel mittels LQN ein Simulationsmodell f r die Leistungsanalyse eines SAP Netweaver Portal Systems zu erstellen das hei t ein geeignetes Artefakt f r die Unter st tzung eines fr hzeitigen Analyseprozesses bereitzustellen Unter Anwendung des vorge stellten Design Science Prozesses von Pfeffers et al 2006 ist diese Arbeit den einzelnen Phasen entsprechend strukturiert um die in Kapitel 1 3 beschriebenen Forschungsfragen zu beantworten Abbildung 1 3 stellt den Zusammenhang zwischen den sechs Kapiteln dieser Arbeit die Bearbeitung der drei Forschungsfragen und de
36. 25 031 26 039 28 592 26 039 25 017 32 734 30 857 N Cx 0 072 0 075 0 080 0 075 0 073 0 092 0 086 z Median 341 633 340 163 350 139 341 163 339 372 347 544 349 438 Q1 25 330 605 324 479 332 918 325 479 324 304 328 567 332 887 Q3 75 356 382 359 847 371 754 360 847 358 285 377 804 378 765 D 1 001 1 840 2 657 2 776 2 759 2 494 2 326 o 0 017 0 018 0 038 0 030 0 034 0 038 0 023 z Cx 0 017 0 010 0 014 0 011 0 012 0 015 0 010 Median 1 001 1 839 2 657 2 781 2 763 2 499 2 331 5 oi 25 0 986 1 824 2 624 2 767 2 729 2 461 2 306 03 75 1 012 1 852 2 683 2 794 2 781 2 519 2 343 Abbildung 5 16 CPU Zeit eines EJB Requests sowie durchschnittliche CPU Nutzung Szenario 2 Ouelle eigene Darstellung In Abbildung 5 16 sind erneut die CPU Zeiten des beispielhaften EJB Requests sowie die aufgezeichnete CPU Nutzung auf Betriebssystemebene ersichtlich Die Grenze von drei verf gbaren Kernen wird zwischen 40 und 60 simultanen Benutzern er reicht Ab diesem Zeitpunkt sind die CPU Ressourcen des Systems ersch pft Ab 80 Benut zern ist dann ein Einbruch der CPU Nutzung System CPU Zeit plus Benutzer CPU Zeit zu erkennen Wie die Aufzeichnungen des Betriebssystem Hilfsmittels topas_nmon zeigen bricht die CPU Nutzung nach bestimmten Intervallen immer wieder ein und gilt als Indiz f r eine Garbage Collector Aktivit t in diesen Zeitr umen Dieser Sachverhalt wird in Kapi tel 5 8 n her untersucht Die Bearbeitungszeiten des EJB Requests z
37. 5 D Os T T T T T T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer Sim 1 267 508 276 934 293 339 447 584 604 324 773 128 954 559 Q1 25 260 603 271 829 290 012 423 087 594 802 922 119 1329 207 Q3 75 270 573 280 985 300 730 439 529 620 379 986 671 1431 516 Abbildung 5 20 Vergleich der Simulations und Messwerte Szenario 2 Quelle eigene Darstellung Das zweite Szenario besch ftigt sich mit dem Fall dass diverse Systemressourcen verknap pen Dies betrifft folgende Einflussgr en Die CPU Ressourcen werden auf drei Kerne gekappt Den Messungen zufolge ent sprechen diese Ressourcen dem Bedarf der von 40 simultanen Benutzern bei der Aus f hrung des modellierten Workloads ben tigt wird Wie bereits in Kapitel 5 5 5 2 dargestellt wurde liegt der Maximalwert an erreichter CPU Nutzlast bei ca 85 bis 90 Prozent Unter einer idealisierten Annahme w rde der lineare Anstieg der CPU Auslastung erst bei 44 Benutzern die Volllast und somit 100 Prozent erreichen die auch von den Grundannahmen der Warteschlangennetze gefordert werden siehe Kapitel 4 1 Eine exakte Parametrisierung der Prozessor Multiplizit t im LON Modell kann somit nur dann erfolgen wenn Messdaten zur Ver f gung stehen Ansonsten kann diese nur durch eine Absch tzung erfolgen und w rde der Literatur entsprechend bei 75 bis 80 Prozent angesetzt werden F r die Simulation dieses Szenarios wurde der gemessene Wert parametrisiert und somit eine Multiplizi t
38. 6 ffentliche Dokumente Versionierung 6 2 ffentliches Dokument erstellen X X 6 3 Inhalt f r ffentliches Dokument eingeben X X 6 4 ffentliches Dokument versionieren X 6 5 ffentlichen Ordner ffnen X X Tag 7 Benutzerverwaltung und Sicherheit 7 10 Benutzerpasswort ndern X X X Nachbereitungen X 1 Benutzer l schen X X 2 Gruppen l schen X X 3 Ordner l schen X Tabelle 5 1 Konsolidierte Liste der modellierten Portalfunktionen Quelle eigene Darstellung in Anlehnung an Jehle 2010 66f Die aufgef hrten Portalfunktionen bilden den Zustand des Portalsystems im Schulungsbetrieb ausreichend ab Jehle 2010 68 Da sich die nicht parallel durchf hrbaren Operationen sich auf zwei Funktionen beschr nken ID 3 12 sowie 3 13 wurde bei der Lasterzeugung sowie der Workload Modellierung auf diese Funktionen verzichtet da zum einen eine m gliche zeitliche Verf lschung zwischen der sequentiellen Abarbeitung am System und der sema phorgesteuerten Abarbeitung bei der Simulation analysiert werden m sste zum anderen die Integration dieser Funktionen keinen Mehrwert bei der Analyse des Antwortzeitverhaltens mit sich bringen w rde Simulation und Evaluation 141 5 3 Lasterzeugung Fir die Erhebung der Leistungsdaten ist es notwendig die gewiinschte Last am Portalsystem zu erzeugen Durch den Einsatz eines Programmes zur automatischen Lastgenerierung kann zum einen eine deterministische Ausf hrung gew hrleistet werd
39. Analyse von Markov Prozessen existieren verschiedene Methoden wie zum Beispiel die Berechnung der Wahrscheinlichkeit einen bestimmten Zustand zu erreichen Allerdings kann die Anzahl an Zust nden bei komplexer werdenden Systemen sehr stark ansteigen Sta te Space Explosion sodass eine automatische Generierung des Zustandsraumes und effizi ente L sungswege der zugrundeliegenden Gleichungen notwendig werden Bolch et al 2006 Daraus haben sich spezielle Notationen basierend auf Petri Netzen und Warteschlan genmodellen welche in den folgenden Kapiteln vorgestellt werden sowie Anwendungen zur automatischen Generierung des Zustandsraumes entwickelt Petri Netze Anfang der sechziger Jahre beschrieb Carl Adam Petri in seiner Dissertation Kommunikati on mit Automaten Petri 1962 eine Theorie die in den darauffolgenden Jahren unter der Bezeichnung Petri Netze weltweit bekannt wurde Peterson 1977 Petri Netze k nnen als grafischer Formalismus zur Beschreibung von Prozessstrukturen verstanden werden Ein gro Der Vorteil der Systemmodellierung mit Petri Netzen ist dass durch die grafische Notation ein hoher Grad an Anschaulichkeit erreicht wird Petri Netze werden in vielen Anwendungsgebieten zur Systemmodellierung verwendet wie zum Beispiel bei der Modellierung von Gesch ftsprozessen oder Workflow Systemen Bei der Modellierung von Rechensystemen eignen sich Petri Netze vor allem f r die Untersu chung funktionaler Aspekte glo
40. Anfragen ebenfalls nicht vom Tabellenpuffer bedient wer den Allerdings wurde im Vorfeld von der Java Applikation eine Sperranfrage an den Enqueue Server gesendet 3 Im dritten Fall werden keine Lesesperren gesetzt und die Select Statements vom Puf fer bedient 4 Im vierten Fall werden sowohl Lesesperren gesetzt als auch Select Statements vom Puffer bedient All die vier m glichen Fallkonstellationen m ssen vom LQN Modell abgedeckt werden Be trachtet man die Modellierung der Tabellenpufferung sowie der Sperr Objekte in den voran gegangenen Kapiteln ergeben sich folgende Wege vom Lastschritte Task zum Datenbank Task 1 Lastschritt gt Datenbank 2 Lastschritt gt Sperrverwaltung gt Datenbank 3 Lastschritt gt Tabellenpuffer gt ggf Datenbank 4 Lastschritt gt Sperrverwaltung Lesesperre gt Tabellenpuffer gt ggf Datenbank Da die im Workload auftretenden SQL Abfragen einzeln als Entry in den jeweiligen Kompo nenten modelliert werden ist der jeweilige Weg vom Lastschritt zur Datenquelle eindeutig abbildbar Lediglich die Frage ob vom Tabellenpuffer oder von der Datenbank gelesen wird wird ber eine Weiterleitungswahrscheinlichkeit festgelegt Abbildung 4 12 stellt die geschil derten Szenarien anhand beispielhafter Pfade grafisch dar LQN Modell 127 Lastschritt Lastschritt Lastschritte Tabellenpuffer Sperrverwaltung SQL Select Query 1 a SQL Select Lese
41. Bei einer Schreibsperrenanfrage die aufgrund der Multiplizit t von 1 erst bedient werden kann sobald alle fr her angekommenen Schreibsperrenanfrage desselben Sperrbereichs abgearbeitet wurden durchl uft die Entry eine Sequenz von Aktivit ten im Aktivit tsgraph Die erste Aktivit t sendet eine synchrone Anfrage an den Sema phor und bleibt solange blockiert bis die Sperre gesetzt werden konnte Dies stellt si cher dass keine fr her eingetroffenen Leseoperationen derzeit durchgef hrt werden oder anstehen Sobald die Sperre gesetzt werden konnte kann in den folgenden Akti vit ten die Datenbankoperation durchgef hrt die Antwort an die Lastschritt Entry ge sendet und die Sperre wieder freigegeben werden Solange eine Schreibsperrenanfrage durch den Schreibsperren Task bedient wird k nnen keine sp ter ankommenden Le seanfragen Datenbankoperationen durchf hren da der vorhin beschriebene Aufruf der Check Entry nicht bedient werden kann Neben dem genannten Sperrprinzip von Sperrbereichen wird der Enqueue Server im Modell abgebildet siehe Abbildung 4 10 Der Enqueue Server nimmt Sperranfragen der Lastschritte entgegen Dazu werden die einzelnen Datenbankoperationen als Entry des Enqueue Servers abgebildet Da der Enqueue Server die Anfragen sequentiell abarbeitet wird ihm eine Multip lizit t von 1 zugewiesen Dadurch wird verhindert dass zwei Sperranfragen zeitgleich bei den Sperranfrage Tasks eintreffen und f r eine ungewollte Ne
42. Create Inquiry VA11 R 3 System einbinden X 2 17 Navigation berblick ber field areas 2 18 Benutzer abmelden 1 14 Tag 3 Inhaltsverwaltung 3 0 Benutzer anmelden 1 1 Anhang 206 3 1 Vorschau SAP iViews 3 2 Ordner anlegen 1 5 3 3 iView in neuen Ordner kopieren 3 4 Neues iView anlegen 3 5 Neues iView konfigurieren 3 6 Portal Webseite erstellen 3 7 Portal Webseite konfigurieren 3 8 neues Workset erstellen 3 9 neues Workset konfigurieren 3 10 Webseite mit Workset verlinken Delta Link 3 11 Objekt Rolle class role ffnen 1 7 3 12 Workset mit Rolle verlinken Delta Link 3 13 Workset schlie en 3 14 Rolle Class role aktualisieren 3 15 Erstellte Webseite ffnen 3 1 3 16 Benutzer abmelden 1 14 Tag 4 Forgeschrittene Inhaltsverwaltung 4 0 Benutzer anmelden 1 1 4 1 Neues iView anlegen Transaktion iView 3 4 4 2 Neues iView konfigurieren 3 5 4 3 Neues iView aufrufen X 4 4 Neues View anlegen RSS Feed iView X 4 5 Neues iView konfigurieren 3 5 4 6 Neues View aufrufen 4 3 4 7 Benutzer abmelden 1 14 Tag 5 Kollaboration 5 0 Benutzer anmelden 1 1 5 1 SAP Meeting Room erstellen 5 2 SAP Meeting Room konfigurieren 5 3 Benutzer Gruppen zum SAP Meeting Room hinzuf gen 5 4 nderungen abspeichern 5 5 Room Directory
43. Datenbanksystems von dem Performance Modell nicht erfasst werden Es wurde zudem vorausgesetzt dass gen gend Hauptspeicher f r die Allokation des Heap Speichers zur Verf gung steht Diese Annahme schlie t den Abbruch der Programmausf h rung bei unzureichendem Speicher aus Die Freisetzung von nicht mehr ben tigtem Spei cherinhalt ist Aufgabe des Garbage Collectors dessen Aktivit ten sich ebenfalls auf die Per formance des Portalsystems auswirken Eine detaillierte Modellierung des GC Verhaltens ist wenn berhaupt m glich nicht nur m hsam sondern auch bei der Parametrisierung schwierig umzusetzen da die GC Zeiten in den aufgezeichneten Bearbeitungszeiten der Performance Traces enthalten sind und somit ausgeklammert werden m ssten Der in dieser Arbeit vorge stellte Modellierungsansatz zur Angabe der Aktivit tsintensit t des Garbage Collectors dient lediglich speziellen Analysezwecken Der Einfluss des Betriebssystems System Overhead und die Defizite in der Abbildung des Speichermanagements f hren im berlastbereich zu ungenauen Simulationsergebnissen Die Einsatzm glichkeiten des Performance Modells in diesem Lastbereich sind somit sehr be grenzt Dies erkl rt sich durch die fehlende Modellierung des zugrundeliegenden Systems Hardware Betriebssystem Neben der rein technischen Betrachtung des Leistungsverhaltens eines SAP Netweaver Portal Systems kann der vorgestellte Ansatz zur Performance Modellierung und Perfor
44. Deeg ck Sek Lads Sa heeded ES 177 Abbildung 5 23 Dauer der Garbage Collector Laufe Szenario 2 100 Benutzer 178 Abbildung 5 24 Intervall zwischen den Garbage Collector L ufen Szenario 2 100 Benulze Beeren 178 Abbildung 5 25 Vergleich zwischen Benutzer und System CPU Zeit Szenario 2 80 Behulzer E 179 Abbildung 5 26 Vergleich zwischen Benutzer und System CPU Zeit Szenario 2 100 lB Tali DEE 180 Abbildung 6 1 Bewertung der Ergebnisse nach dem Antwortzeitverhalten 184 Abbildung 6 2 Bewertung der Ergebnisse nach der Lastmntens t ee eeeeseeeteereeeeeees 187 Tabellenverzeichnis X Tabellenverzeichnis Tabelle KE ee DE 26 Tabelle 22 4 Felder Tafel TT 38 Tabelle 2 3 G ngige Verteilungen bei Warteschlangensystemen esceecceeeceteeeeeeneeeeeees 46 Tabelle 3 1 Wichtige Monitore des Connections Manipulator resesssssnesneesnenseennennn 66 Tabelle 3 2 Wichtige Monitore des System Thread Manage s cccccsceesseceteceseeeeeeeeneees 67 Tabelle 3 3 Wichtige Monitore des http Provider Services im Dispatcher 67 Tabelle 3 4 Wichtige Monitore des Chuster Managerg 68 Tabelle 3 5 Wichtige Monitore des http Provider Services im Server 69 Tabelle 3 6 Wichtige Monitore des Application Thread Managers eee 69 Tabelle 327 8permodi na eis 72 Tabelle 3 8 Auswahl relevanter Daten im Tabellenpufter Monitor 76 Tabelle 3 9 Ja
45. Details Table Name der gepufferten Tabelle Status Status valide invalide Type Art der Pufferung voll generisch Einzelsatz Generic Key Anzahl der Schl sselfelder bei generischer Pufferung DataSize Gr e der Puffereintr ge in Bytes TotalSize Gr e der gesamten Tabelle im Tabellenpuffer in Bytes Used Anzahl der Zugriffe Inval Anzahl der durchgef hrten Invalidierungen Tabelle 3 8 Auswahl relevanter Daten im Tabellenpuffer Monitor Quelle eigene Darstellung F r den Anwendungsentwickler ist es m glich den Puffer zu umgehen indem im SQL Statement die Angabe SAP BYPASSING BUFFER nach dem Select Statement angegeben wird Fiir die Workload Modellierung ist es wichtig zu sehen ob die Datenbankoperationen eines Lastschrittes den Puffer verwenden oder nicht Da her miissen die SQL Statements des SQL Traces siehe Kapitel 3 2 4 ausgewertet werden und Datenbankoperationen die explizit keinen Puffer verwenden entsprechend modelliert werden Eine gute Pufferkonfiguration ist Voraussetzung fir ein leistungsfahiges Portalsystem Auf der einen Seite sollte gen gend Platz zur Verf gung gestellt werden um Verdr ngungen zu vermeiden auf der anderen Seite sollte unn tig bereitgestellter Platz vermieden werden Da man jedoch die zuk nftig angesto enen Portaloperationen nur absch tzen kann l sst sich der ben tigten Platz nicht genau vorhersagen Die Anpassungen der Konfiguration die man zur Leistungsverbesserung von T
46. Entries des Daten bank Tasks spiegeln die im Workload durchgef hrten Datenbankabfragen wider Die durch schnittliche Service Zeit sowie das Streuungsma werden ber die gesammelten Daten des funktionalen Traces ermittelt Umsetzung Wie bereits in Kapitel 4 2 2 dargestellt ist es ausreichend die Multiplizit t des Lastschritte Tasks ber die Summe der zur Verf gung stehenden Threads in den Java Server Instanzen zu spezifizieren n m Anzahl Threads ServerInstanz k 1 Die SQL Abfragen werden ber die Entries des Datenbank Tasks abgebildet wobei die Ser vice Zeit dem Wert entspricht der im funktionalen Trace als Datenbank Zeit gekennzeich net ist Die Wartezeit bis eine Datenbankverbindung hergestellt werden kann ist darin nicht enthalten Unabh ngig davon ist die angegebene Service Zeit ein Bruttowert da diese Zeit nicht zwingend aus der reinen Bearbeitungszeit innerhalb der Datenbank bestehen muss War tezeiten innerhalb des Datenbanksystems w rden ebenso in diesem Wert enthalten sein Somit LQN Modell 126 spiegelt diese Angabe lediglich die Zeit wieder die f r die Abarbeitung au erhalb der Java Server Instanz ben tigt wurde Betrachtet man die eingehenden Anfragen zum Datenbanksystem sind verschiedene Wege m glich 1 Der einfachste Fall ist ein direkter Datenbankaufruf bei dem keine Tabellenpufferung erfolgt und keine vorangegangenen Sperranfragen gesendet wurden 2 Im zweiten Fall k nnen die
47. Gr e des Heap Speichers reduziert sodass der erh hte F llgrad verst rkte Aktivit ten des Speichermanagements bewirkt Schlie lich wurde die Gr e des Tabellenpuffers reduziert sodass es zu Verdr ngungen und Invalidierungen der Pufferobjekte kommt die zu einer erh hten Anzahl an Datenbankaufrufen f hren Simulation und Evaluation 181 Anschlie end wurde der Fokus auf u ere Einflussgr en gelegt Dies betrifft auf der einen Seite den von Jehle 2010 festgestellten Overhead des Betriebssystems auf der anderen Seite den zunehmenden Einfluss des Speichermanagements der aufgrund der Stop the World Pause zu Einbr chen der CPU Nutzung f hrt Aufgrund der in der LQN Literatur fehlenden Betrachtung des Garbage Collectors wurde eine Modellierung der identifizierten GC Einflussgr en GC Dauer und GC Intervall angestrebt Der Modellierungsansatz stellt eine M glichkeit dar die Aktivit tsintensit t des Garbage Collectors statisch festzulegen statt sie wie in der Literatur blich impliziten ber die Bearbeitungszeit der Lastschritte zu erfassen Es sei an dieser Stelle erneut darauf hingewiesen dass dieser Ansatz keine allgemeine Abbil dung des dynamischen GC Verhaltens darstellt sondern lediglich die M glichkeit bietet ber die beiden Parameter GC Dauer und GC Intervall die Aktivit tsintensit t des Garbage Collectors zu parametrisieren Dies ist vor allem dann hilfreich wenn Erfahrungswerte exis tieren und die Simulation
48. Menge aller potentiellen Untersuchungsobjekte einer Fragestellung zu untersuchen Die Stichprobe soll repr sentativ f r die Grundgesamt heit sein Ein Parameter stellt eine Eigenschaft der Grundgesamtheit dar die der Beschreibung der Verteilung der Einheiten dient Beispielsweise ist der Mittelwert ein Parameter 2 2 1 1 Ma e der zentralen Tendenz Mittelwerte k nnen als Ma e der zentralen Tendenz bezeichnet werden da sie den typischen zentralen oder durchschnittlichen Wert der Beobachtungswerte Stichprobe beschreiben Schulze 2007 35 F r die quantitative Erfassung existieren verschiedene Ma e Arithmetisches Mittel Das arithmetische Mittel x bildet den Durchschnitt der Be obachtungswerte x4 Xn n H i 1 1 x n Theoretische Grundlagen 27 Neben dem arithmetischen Mittel sind das geometrische und harmonische Mittel wei tere Durchschnittsparameter Median Der Median auch als Zentralwert bezeichnet stellt die mittlere Zahl in einer sortierten Liste der erhobenen Werte dar Ist die Anzahl der Werte gerade so wird aus den beiden zentralen Elementen der Durchschnitt gebildet Modus oder Modalwert Der Modus oder Modalwert ist der Wert der am h ufigsten vorkommt 2 2 1 2 Streuungsma e Ma e der zentralen Tendenz verm gen zwar Informationen ber das Zentrum zu geben ent halten aber keine Informationen dar ber wie weit die Beobachtungswerte von diesem Zent rum entfernt sind Sch
49. Mexico 1998 S 1 6 Siebert G Kempf S Ma alski O 2008 Benchmarking Leitfaden f r die Praxis Hanser M nchen 2008 Simon H A 1996 The Sciences of the Artificial 3 Aufl MIT Press Cambridge MA 1996 Simon H A 1970 Administrative Behavior A Study of Decision Making Process in Administrative Organization Macmillan New York NY 1970 Snodgrass R 1988 A Relational Approach to Monitoring Complex Systems In ACM Transactions on Computer Science Vol 6 1988 Nr 2 S 157 195 S bbing T 2006 Handbuch IT Outsourcing 3 v llig neu bearb Aufl C F M ller Heidelberg M nchen Landsberg Berlin 2006 Staples E 1987 The Tower of Hanoi Problem with Arbitrary Start and End Positions In ACM SIGACT News Vol 18 1987 Nr 3 S 61 64 Tanenbaum A S 2006 Moderne Betriebssysteme Pearson Studium M nchen 2006 Tertilt D Kremar H 2011 Generic Performance Prediction for ERP and SOA Applications In 19th European Conference on Information Systems Hrsg Helsinki Finnland 2011 Literaturverzeichnis 203 Tertilt D Leimeister S Gradl S Mayer M Kremar H 2010 Towards an evolutionary model generation for ERP performance simulation International Conference on Intelligent Systems and Agents Freiburg Teuffel M Vaupel R 2010 Das Betriebssystem z OS und die zSeries Die Darstellung eines modernen GroBrechnersystems Oldenbourg Miinchen 2010 Thompson W 1884
50. Sekunden Intervall erkennen W hrend der Ausf hrung der Garbage Collection f llt die CPU Auslastung auf bis zu 25 bis 30 Prozent Der System Overhead bel uft sich auf ca 10 Prozent Bei 100 Benutzern steigt der Overhead deutlich an siehe Abbildung 5 26 Auch hier fallen die GC Zyklen sofort ins Auge die in einem Intervall von ca 20 Sekunden f r einen Ein bruch der CPU Auslastung sorgen Simulation und Evaluation 180 100 u Gesamt 83 26 80 a u Benutzer 63 09 60 m CPU System 40 CPU Benutzer 20 0 Os 300s 600s Abbildung 5 26 Vergleich zwischen Benutzer und System CPU Zeit Szenario 2 100 Benutzer Quelle eigene Darstellung 5 9 Zusammenfassung Kapitel 5 besch ftigte sich mit der Simulation und Evaluation des LQN Modells anhand der am SAP UCC der TU M nchen eingesetzten Portalfallstudie und dient somit der Beantwor tung von Forschungsfrage 3 Dazu wurden zu Beginn die Schulungsinhalte vorgestellt und daraus der modellierte Workload abgeleitet Mit der Eingrenzung auf interne Portaloperatio nen haben sich die in Tabelle 5 1 aufgelisteten Portalfunktionen ergeben die nach ihrer Ser vice Zeit Varianz sowie den durchgefiihrten Datenbankaufrufen modelliert und parametrisiert wurden Fiir die Lasterzeugung wurde der von Jehle 2010 entwickelte Lastgenerator ver wendet Bereits in den Telefongespr chen mit einem SAP Mit
51. Tabellenkakulation Name ID der Komponente Startzeit Endzeit Ausgef hrte Aktion Textverarbeitung portalsim2_P33_333227250 03 31 53 03 31 53 Appl ij com sap portal LOkale Datei portalsim2_P33_333227250 03 31 56 03 31 56 Appl ij com sap portal i Senden portalsim2_P33_333227250 03 32 00 03 32 00 Appl ij com sap portal i Office portalsim2_P33_333227250 03 32 00 03 32 00 Appl in com sap portal i ABC Analyse 41 gt HTML Download amp SB GS E Be Di di e e E IA E URL in Clipboard ablegen TRACE Daten Trace Datum Uhrzeit Langtext der Trace Meldung Langtext der Trace Meldung ID einer Transaktion GUID 4 gt d gt v Abbildung 3 21 Export der Performance Daten zur externen Analyse Quelle eigene Darstellung F r die in dieser Arbeit durchgef hrten Performance Analysen spielt der funktionale Trace eine zentrale Bedeutung da die Leistungsdaten der einzelnen Komponenten zur Verf gung gestellt werden 32 4 SQL Trace Der SQL Trace protokolliert alle Datenbankaufrufe mit Open und Native SQL Statements Neben seinem Einsatz bei der Entwicklung von Java Programmen wird der SQL Trace auch f r die Performance Analyse verwendet Nicht zuletzt ist der SQL Trace wichtig f r die Er kennung von Tabellenpuffer Operationen die beispielsweise bei der Verdr ngung oder Inva lidierung siehe Kapitel 3 1 4 auftreten und somit nicht Inhalt der eigentlichen Aufgabe bzw Benutzeraktion sind F r die korrekte Parametrisie
52. X Wartezeiten X Datenbankzeiten Da die J2EE Engine f r die DSRs nicht transparent ist werden neben den DSR Daten noch zus tzliche Performance Traces geschrieben und somit eine noch detailliertere Erfassung der Performance Daten erreicht siehe Abbildung 3 19 Systemarchitektur und Monitoring 88 J2EE Engine Client HTTP Service EJB Container Datenbank DSRs Performance Traces Abbildung 3 19 Granularit t der DSR Datens tze und Performance Traces Quelle eigene Darstellung ber die SAP Transaktion STATTRACE kann der funktionale Trace Statistikrohdaten und Traces angezeigt werden Der funktionale Trace ist eine Erweiterung der Datenselektions transaktion STAD die Statistikrohdaten nur f r ein lokales ABAP System wiedergeben kann Zudem wird der globale Systemlastmonitor SAP Transaktion ST03G erg nzt der nur ag gregierte Daten anzeigt Zur Auswahl sowie Darstellung der Daten werden folgende Funktio nen bereitgestellt ber die Systemauswahl k nnen die Systeme ausgew hlt werden f r die die Statis tikdatens tze und Traces analysiert werden sollen Mittels Datenselektion k nnen die zu analysierenden Daten ausgew hlt werden Dabei kann nach folgenden Kriterien gefiltert werden Startdatum Startzeit Lesezeitraum Transaktions ID GUID Die gefilterten Statistiks tze und Traces werden anschlie end in der Analysesicht an gezeigt Die Darstellung der Analysesicht kann hierarchi
53. basierenden Layered Queueing Networks LQNs sowie ein an der Carleton University entwickelter LQN Simulator LQsim 2011 eingesetzt LQNs sind eine Erweiterung der klassischen Warteschlangennetze um komplexe Software Systeme tiber logische Software Ressourcen die eine vertikal geschichte te Struktur bilden zu beschreiben Sie entstammen den Arbeiten ber Active Servers Woodside et al 1986 dem Lazy Boss Model Rolia 1988 den Rendezvous Networks Woodside et al 1995 sowie der Method of Layers Rolia Sevcik 1995 Neben der hierar chischen Struktur bietet die Unterst tzung von replizierten Entit ten geteilten Warteschlan gen und synchronen Aufrufen um nur einige zu nennen eine sehr gute Grundlage zur Model lierung der komponentenbasierten geschichteten Architektur eines SAP Netweaver Portal Systems Neben der Aufarbeitung der theoretischen Grundlagen werden die Hilfsmittel zur berwa chung der Leistungsdaten Monitoring Hilfsmittel eines SAP Netweaver Portal Systems untersucht Ziel ist es die in der SAP Netweaver Dokumentation genannten Performance Einflussgr en und ermittelbare Leistungswerte zu identifizieren Dazu ist es notwendig die Architektur eines SAP Netweaver Portal Systems zu analysieren und f r die einzelnen Kom ponenten entsprechende Monitoring Hilfsmittel zu ermitteln Zudem werden Analyse Werkzeuge auf Betriebssystemebene zur Erfassung von grunds tzlichen Leistungsdaten CPU Haupt
54. bedient bis eine Anfrage an die Signal Entry gesendet wird Ein Semaphor Task bildet grunds tzlich einen Bin rsemaphor ab F r einen Z hlsemaphor kann ein Multi Server siehe Abbildung 4 4 verwendet werden Dabei gibt die Multiplizit t die Anzahl der Token an Da ein regul rer LQN Task mit einer Multiplizit t gt 1 Multi Server eine einzige Warteschlange teilt wurde dieses Verhalten bei den Semaphor Tasks ver ndert da bei einem Z hlsemaphor jede Instanz des Multi Servers eine eigene Warte schlange ben tigt siehe Abbildung 4 7 Anfrage Antwort freigeben Multiplizitat gt 1 Z hlsemaphor IT Abbildung 4 7 Funktionsprinzip eines Semaphor Tasks Ouelle eigene Darstellung F r die Umsetzung der Sperr und L seanfragen ist es nicht zwingend notwendig Aktivit ten zu modellieren da diese ber die verschiedenen Phasen einer Entry abgebildet werden k n nen Sobald eine Anfrage eine Entry erreicht wird die Service Phase Phase 1 gestartet Auf grund des in dieser Phase notwendigen Datenbankaufrufs wird eine Sperre gesetzt die ber eine Anfrage an die Wait Entry des Semaphors realisiert wird Sobald die Anfrage von dem Server Task abgearbeitet wurde wird eine Antwort an den aufrufenden Task gesendet Die anschlie end initiierte zweite Phase des Server Tasks sendet daraufhin eine Anfrage an die Signal Entry des Semaphors und gibt somit das Objekt welches durch den Semaphor gesperrt wurde wieder
55. der Praxis erreichten und in der Literatur f r ein gut konfiguriertes System vorgeschlagenen Wert Da sich die Trefferrate nicht ver ndert hat eine steigende Anzahl an Benutzern keinen Einfluss auf die Antwortzeit Die Datenbank wird als Black Box betrachtet Daher wurden gen gend Systemressourcen f r den Datenbank Host zur Verf gung gestellt Die Service Zeiten der einzelnen SQL Abfragen bleiben konstant und haben folglich keinen Einfluss auf die Antwortzeit Ein m glicher limi tierender Faktor ist die Anzahl der zur Verf gung gestellten Datenbankverbindungen Aller dings zeigt die Nutzung dass die vorhandenen 20 Verbindungen f r diesen Workload ausrei chen Dieses Szenario zeigt dass sowohl der modellierte Sperrmechanismus als auch die Multipli zit t des Lastschritte Tasks die realen Systemkomponenten Sperrkonzept des SAP Netweaver Portal Systems Anzahl der Applikations Threads entsprechend abbilden Es zeichnet sich durch den geringen aber stetigen Anstieg der Antwortzeiten aufgrund von zu nehmenden Sperrsituationen und dem Knick bei 80 simultanen Benutzern der die erreichte maximale Parallelit t der Applikations Threads darstellt aus Simulation und Evaluation 173 5 7 2 Szenario 2 Knappe Systemressourcen 1500s 5 Messwerte Q1 25 CG A 3 4 Messwerte Q3 75 2 u 12005 Simulation 1 Max Messwerte Ausrei er 900s lt A L 5 H 2 600s E l o 2 300s 4 a E d
56. des Aktivit tsgraphen Sequenz Und Gabelung zus tzliche Und Gabelung Pseudo Aktivit t RSpseudo amp RSlock gt RSrelease Und Vereinigung Antwort Listing 5 7 Aktivit tsdeklaration der Lesesperre Beispiel Ouelle eigene Darstellung Die Aktivit tsdeklaration der Schreibsperre ist in Listing 5 8 dargestellt Auch hier muss im Gegensatz zur schematischen Darstellung in Kapitel 4 2 3 eine Und Gabelung eingef hrt werden die die Antwort an die aufrufende Entry sowie die Anfrage an die Signal Entry des Semaphors parallel durchf hrt Die initialen Definitionen verhalten sich analog zu den voran gegangenen Aktivit tsgraphen 99 Aktivit ts Deklarationen 100 AWS1 101 s WSA1 0 0 102 s WSlock 0 0 103 s WSdb 0 0 104 s WSreply 0 0 105 s WSrelease 0 0 106 f WSlock 1 107 f WSdb 0 108 f WSreply 1 109 y WSlock S1W 1 0 110 y WSdb D1E2 1 0 111 y WSrelease S1S 1 0 Startaktivitat Schreibsperre keine Service Zeiten Aktivitat WSlock sendet Anfrage an Wait Entry Aktivitat WSdb sendet Anfrage an Datenbank Entry Aktivitat WSreply sendet die Antwort Aktivitat WSrelease sendet Anfrage an Signal Entry deterministsche Anzahl an Anfragen stochastische Anzahl an Anfragen deterministsche Anzahl an Anfragen Anfrage an Wait Entry des Semaphors Anfrage an Datenbank Anfrage an Signal Entry des Semaphors Simulation und Evaluation 166 112 113 WSA1 gt WSlock Definition
57. des GC Einflusses dar Da die Aktivit tsintensit t jedoch lediglich ex ante festgelegt werden kann bietet es sich an die Modellierung der Java Speicherverwaltung zum Gegen stand weiterer Untersuchungen zu machen Fazit 187 Die CPU Ressourcen werden in dem LQN Modell als spezieller Task Typ als Prozessor Task modelliert Die Parametrisierung erfolgt tiber die Multiplizitat und somit die Anzahl an simultan berechneten Lastschritten ohne Wartezeiten am Prozessor Unter der aus der Warte schlangentheorie abgeleiteten Annahme einer linear ansteigenden CPU Nutzung bis zum Er reichen der Vollauslastung vgl Kapitel 4 1 1 werden die Rechenkapazit ten vom LQN Modell akkurat nachgebildet Die Ergebnisse haben allerdings gezeigt dass die CPU auf grund des System Overheads und des Speichermanagements von den Benutzerprozessen nicht voll ausgelastet werden kann Dieser Sachverhalt muss ber die Multiplizit t des Pro zessor Tasks entsprechend parametrisiert werden bildet aber nicht den wachsenden Anteil der Systemprozessorzeit im berlastbereich ab und f hrt folglich zu divergierenden Ergebnissen zwischen gemessenen und simulierten Antwortzeiten Die Abbildung der CPU Ressource im LQN Modell kann im Normallastbereich als sehr gut bewertet werden im Hochlastbereich wird den u eren Einfl ssen jedoch nicht ausreichend Rechnung getragen F hrt man die Bewertung der Ergebnisse nach dem Antwortzeitverhalten und nach den mo dellierten Komp
58. die ausgef hrten Funktionen sowie deren Reihenfolge und zus tzliche Parameter wie zum Beispiel Denkzeiten der anfragesendenden Benutzer nicht konfiguriert werden k nnen F r individuell gestaltete Lastszenarien verweist SAP auf die Verwendung von Werkzeugen von Drittherstellern Jehle 2010 45f Infolgedessen ist bei der Entscheidung ber das zu verwendende Lastmuster f r die Evaluation des LQN Modells die Wahl auf die bereits bei Jehle 2010 eingesetzte Portalfallstudie gefallen 2 7 Kapazit tsplanung Der in dieser Arbeit vorgestellte Ansatz zur Modellierung und Simulation eines SAP Netweaver Portal Systems kann f r die Kapazit tsplanung in Hinblick auf das ben tigte Per formance Modell und die daraus resultierende Performance Vorhersage verwendet werden Der Ansatz liefert somit einen Beitrag f r die technische Komponente der Kapazit tsplanung Mit der Erstellung eines Kostenmodells kann eine Kosten Performance Analyse durchgef hrt werden die als Grundlage f r einen Konfigurations Investment und Personalplan dienen kann Obwohl die Kapazit tsplanung in dieser Arbeit nicht detailliert behandelt wird werden im folgenden Abschnitt die wesentlichen Merkmale kurz dargestellt Die Kapazit tsplanung besch ftigt sich mit der Frage wann die Systemauslastung ges ttigt ist und welche kosteng nstigen Methoden den S ttigungspunkt am l ngsten hinausz gern Menasc Almeida 2002 Bei der Kapazit tsplanung versucht man somit Har
59. einer erh hten Benutzeranzahl m gliche Engp sse aufdecken soll Allgemein l sst sich festhalten dass bei einem gut konfigurierten Portalsystem unter norma len Lastbedingungen die Simulation vielversprechende Resultate liefert Dies zeigen die Er gebnisse des Vergleichs der Mess und Simulationswerte aus Szenario 1 In Szenario 2 wird deutlich dass erschwerte Bedingungen wie knappe Systemressourcen oder eine mangelhafte Portalkonfiguration wie z B eine nicht ausreichende Tabellenpuffergr e die Simulations genauigkeit stark beeintr chtigen Dies erkl rt sich nicht zuletzt direkt aus den betrachteten Modellkomponenten und den Grundannahmen der Warteschlangennetze siehe Kapitel 4 1 Die Ergebnisse der Evaluation zeigen jedoch auch dass die eintretenden Engp sse ab einer bestimmten Lastintensit t hervorgerufen durch eine bestimmte Anzahl von simultan agieren den Benutzern von der Simulation erkannt werden Im ersten Szenario wurde dies beispiels weise durch die Begrenzung der parallelen Applikations Threads hervorgerufen im zweiten Szenario konnten die Auswirkungen der begrenzten CPU Ressourcen erfasst werden Nicht zuletzt wurde der Einfluss des Sperrmanagements abgebildet sodass der Anstieg der Ant wortzeiten durch zunehmende Sperrsituationen ebenfalls in den Simulationsergebnissen wi dergespiegelt wird Fazit 182 6 Fazit Vor dem Hintergrund die Leistungsf higkeit von Computersystemen zu bewerten haben sich im wissensc
60. f r den L sungsansatz von neuar tigen Problemen oder bekannten Problemen in neuen Dom nen dienen k nnen Hevner et al 2004 76 Die kreierten Artefakte entspringen somit weniger zugrundeliegenden Theorien viel mehr entwickeln sich theoretische Modelle aus der Anwendung und Evaluation der Arte fakte da diese f r ein besseres Verst ndnis des Problems und der inh renten Mechanismen sorgen Nunamaker et al 1991 Environment Relevance IS Research Knowledge Base Foundations Theories Frameworks Instruments Constructs Models Methods Instantiations People e Roles e Capabilities e Characteristics Develop Build e Theories e Artifacts Organizations e Strategy e Structure amp Culture e Processes Business Needs Applicable Knowledge Assess Refine Methodologies Data Analysis Technology Techniques Justify Evaluate Infrastructure Applkications Communications Architecture Development Analytical Case Study Experimental Field Study Simulation Formalisms Measures Validation Criteria Capabilities Additions to the Knowledge Base Application in the Appropriate Environment Abbildung 1 1 Design Science Framework Quelle Hevner et al 2004 80 Konzeptionelle Rahmenbedingungen sowie Handlungsempfehlungen zum Designprozess k nnen der Arbeit von Hevner et al 2004 entnommen werden Wie dem in Abbildung 1 1 dargestellten Rahmenwerk zu entnehmen ist bezieht die der angewandt
61. for Java Garbage Collector In https www ibm com developerworks community groups service html communityvie w communityUuid 22d56091 3a7b 4497 b36e 634b51838ell zugegriffen am 03 08 2011 2011 2011h Topas In http publib boulder ibm com infocenter aix v6r l index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopas htm zugegriffen am 08 08 2011 2011 2011j topas CEC Analyser In https www ibm com developerworks wikis display WikiPtype topas CEC Analyser zugegriffen am 08 07 2011 2011 2011j topasout Command In http publib boulder ibm com infocenter aix v6rl index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopasout htm zugegriffen am 08 07 2011 2011 2011k topasrec Command In http publib boulder ibm com infocenter aix v6rl index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopasrec htm zugegriffen am 07 08 2011 2011 20111 Understanding the IBM JVM In http publib boulder ibm com infocenter javasdk v 1r4m2 index jsp topic 2Fcom ib m java doc diagnostics 142 2Fhtml 2Funderthejvm html zugegriffen am 04 12 2011 2011 2011m vmstat Command In http publib boulder ibm com infocenter aix v6r l index jsp topic 2Fcom ibm aix c mds 2Fdoc 2Faixcmds5 2Ftopasout htm zugegriffen am 09 07 2011 2011 J 2007 A Paradigmatic Analysis of Information Systems as a Design Science In Scandinavian Journal of Information Systems Vol 19 2007 Nr 2 S 39 64 2012 iOpus iMarcros In http
62. here bertragbarkeit werden die Performance Messungen an einem Portalsystem mit einer Standardkonfiguration durchgef hrt In den folgenden Abschnitten werden nun die verschiedenen Benchmark Typen und ihre wesentlichen Merkmale vorgestellt Theoretische Grundlagen 57 Der Begriff Benchmark ist in vielen verschiedenen Wissenschaftsbereichen verbreitet W he 2005 In der Informatik dient er der Messung von Systemen Hardware und Softwarekom ponenten und erlaubt durch einen Vergleich der Ergebnisse eine Aussage ber deren Perfor mance zu geben Nach Prechelt 2001 43 ist ein Benchmark ein genau definierter An wendungsfall f r ein Programm oder eine Methode der eine Vorschrift einschlie t wie das Ergebnis der Anwendung quantifiziert werden kann Die resultierende beliebig reproduzier bare Gr e hei t Benchmark Ergebnis Benchmark Werte spiegeln somit die Leistungsf higkeit des Systems wieder Der Unterschied zu Performance Messungen im Allgemeinen liegt darin dass Benchmarks standardisierten Kriterien unterliegen Benchmark Ergebnisse werden haupts chlich dazu verwendet den eigenen Fortschritt zu messen und einen Vergleich mit der Konkurrenz durchzuf hren vgl Hoetzel et al 1998 Der Begriff des Benchmarking kommt urspr nglich aus der Landvermessung bei der mittels Benchmarking ein Festpunkt gesetzt wird der als Ausgangs und Bezugspunkt f r weitere Messungen dienen soll In der IT Branche wurde der Begriff berei
63. identisch Anfragen an Servern niedriger Ebenen sind geometrisch verteilt Bei stochastischen Phasen wird dabei der Durchschnitt als Parameter angegeben bei deterministischen Phasen eine bestimmte Anzahl von Aufrufen Parameter in LQN Modellen Folgende Parameter sind in einem LQN Modell angegeben 2 5 3 Arten von Clients sowie deren Populationsgr e und Ankunftsrate Die Anzahl an Prozessorknoten sowie Task Zuweisungen Die Multiplizit t der einzelnen Task oder Prozessorknoten Bedienstrategien der einzelnen Software und Hardware Server Die durchschnittliche Bedienzeit f r jede Aktivit t sowie Phasen der Entries Die durchschnittliche Anzahl an synchronen asynchronen und weitergeleiteten Aufru fen welche von den verschiedenen Phasen einer Entry oder Aktivit t gesendet wer den Transformationsregeln In vielen Software Systemen existieren Zyklen beispielsweise bei einem asynchronen Aufruf einer Anfrage die der Server nach deren Abarbeitung beantwortet LQN Modelle fordern aber einen azyklischen Graphen sodass eine Transformation notwendig wird welche durch Semaphore erreicht wird Shousha et al 1998 Die Semaphore erm glichen einen exklusiven Lese oder Schreibzugriff indem ein zus tzlicher Task mit einfacher Multiplizit t und einer Bedienzeitdauer von Null modelliert wird der den asynchronen Aufruf als synchronen Aufruf Theoretische Grundlagen 53 an die entsprechende Entry weitergibt Dadurch bleibt der Se
64. kann Jackson 1964 Gordon Newell 1967 zeigten dass auch geschlossene Netzwerke unter denselben Annahmen eine solche Produktforml sung besitzen Mit dem Auftreten von Computern und Computernetzwerken erkannte man die Warteschlangentheorie als leistungsstarkes Design und Analyseinstrument Theoretische Grundlagen 45 i Populations prozess gr e i O O Verteilung der Bedienzeiten d Warteschlangen Ankunfts kapazit t Anzahl der Bedieneinheiten Abbildung 2 13 Schematische Darstellung eines Warteschlangensystems Quelle eigene Darstellung Die Elemente eines Warteschlangensystems werden in Abbildung 2 13 dargestellt l Seien t t2 Ankunftszeiten dann sind T t tj 1 die Ankunftszeitenabstan de Der g ngigste Ankunftsprozess ist der Poisson Prozess bei dem die Ankunftszei tenabst nde stochastisch unabh ngige identisch verteilte Zufallsvariablen sowie ex ponentialverteilt sind Die Bedienzeit auch Service Zeit genannt ist jene Zeit die ein Element in der Bedie neinheit verbringt Genauso wie bei den Ankunftszeitenabst nden sind auch die Bedi enzeiten eine Folge von stochastisch unabh ngigen identisch verteilten Zufallsvariab len Auch hier ist die g ngigste Verteilung die Exponentialverteilung Die Anzahl der Bedieneinheiten legt fest wie viele Bedieneinheiten f r jeden angebo tenen Dienst zur Verf gung stehen Jeder angebotene Dienst ist wiederum f r sich ein eig
65. kann abh ngig von der verwendeten JVM sowie GC LQN Modell 128 Implementierung variieren Libic Tuma Buley 2009 Beispielsweise unterscheiden sich die Algorithmen bei der Verwaltung der Young und der Tenured Generation siehe auch Kapi tel 3 1 5 Unabh ngig von der verwendeten Implementierung werden bei einem GC Lauf die Applika tions Threads gestoppt Dieser Zeitabschnitt wird auch als Stop the World Pause bezeichnet Daher kann eine berm ige Aktivit t des Garbage Collectors zu hohen Antwortzeiten inef fizienter CPU Nutzung und Speicherauslagerung Paging f hren Daraus resultieren zwei Leistungsindikatoren die die Aktivit tsintensit t des Garbage Collectors beschreiben zum einen die durchschnittliche Dauer in der die Applikations Threads blockiert sind zum ande ren das durchschnittliche Intervall von einem bis zum n chsten GC Lauf vgl Cheng Morrison 2007 Die aufgezeichneten Messwerte des funktionalen Traces im SAP System geben keinen Auf schluss ber die GC Zeiten Daher ist in den angegebenen Zeiten implizit die Zeit enthalten in der der Applikations Thread aufgrund eines GC Laufes nicht fortgesetzt werden konnte Diese Tatsache f hrt bei der Modellentwicklung dazu dass in der ersten Iteration auf eine explizite Modellierung des Garbage Collectors verzichtet wird Zudem ist es mit den Mitteln der LQNs nicht m glich das Verhalten des Garbage Collectors identisch nachzubilden Dies liegt zum einen an der
66. muenchen de PuTTY Transaktions ID Abbildung 3 16 Single Activity Trace Quelle eigene Darstellung 3 2 3 Funktionaler Trace Der funktionale Trace greift auf die von JARM zur Verf gung gestellten Daten und Distri buted Statistical Records DSRs zu DSR ist ein Konzept das urspr nglich f r den ABAP Stack entwickelt und sp ter auf J2EE Systeme erweitert wurde Statistiken und Trace Daten die von dem DSR Dienst innerhalb der J2EE Engine generiert werden werden ber einen speziellen Agenten des Computing Center Management Systems CCMS an ein zentrales Monitoring System Central Monitoring System CEN gesendet Abbildung 3 17 zeigt den Ablauf wie die Statistikdatens tze und die Rohdaten in das zentrale Monitoring System gelangen Dieser l sst sich wie folgt beschreiben 1 In der J2EE Engine ist der DSR Dienst f r die erhobenen Leistungsdaten verantwort lich und kommuniziert mit der Java DSR API einer Java Bibliothek die f r die Ver waltung der DSR Datens tze verantwortlich ist 2 Die Datens tze werden mittels der Write API vom Hauptspeicher in das Dateisystem unter dem Pfad lt J2EE Installationsverzeichnis gt prfclog dsr geschrieben 3 Der CCMS Agent liest die Trace Dateien und gibt sie an das Monitoring System wei ter Dabei werden aggregierte Statistikdaten und Einzeldatens tze Statistikrohdaten unterschieden Systemarchitektur und Monitoring 86 Die Statisti
67. nnen werden sie zuerst in einer Socket Warteschlange festgehalten Sollte auch diese voll sein die Warte schlange hat standardm ig eine Gr e von 200 Anfragen wird eine Fehlermeldung zur ck gegeben Vor allem bei Lasttests die im oberen Lastbereich arbeiten kann dies immer wieder vorkommen und wird von entsprechenden Log Dateien festgehalten Wird die Anfrage akzeptiert wird sie an den Connections Manipulator weitergeleitet Die ser f hrt eine protokollspezifische Liste der eingehenden Anfragen Entsprechende Monitore siehe Tabelle 3 1 geben Auskunft ber die Anzahl an Verbindungen Monitor Beschreibung CurrentPoolSize Anzahl der Verbindungen im Verbindungspool HTTPConnectionsCount Anzahl aktueller http Verbindungen Tabelle 3 1 Wichtige Monitore des Connections Manipulator Quelle eigene Darstellung in Anlehnung an SAP 201 1a Jede Anfrage im Verbindungs Pool wird einem System Thread im System Thread Manager zugeordnet Der System Thread Manager hat standardm ig eine Kapazit t von 100 System Threads allerdings dienen die einzelnen System Threads nicht nur Benutzeranfragen sondern auch der internen Kommunikation Die WaitingTasksQueue beinhaltet Anfragen die nicht sofort einem System Thread zugeordnet werden konnten Eine Auswahl wichtiger Monitore des System Thread Managers ist in Tabelle 3 2 aufgelistet Monitor Beschreibung CurrentThreadPoolSize Derzeitige Gr e de
68. s mtlichen generierten Inhalt einem Durchlauf zuzuordnen und gegebenenfalls zu l schen setHostName Wie sich bereits aus dem Namen der Methode erschlie t wird hiermit die Adresse des Servers festgelegt setRunEnvironment Ein Testtreiber kann diverse Konfigurationen bereitstellen die unterschiedliche Systemeigenschaften und Lastszenarien abdecken Mit diesem Para meter wird die zu verwendende Konfiguration ausgew hlt setNumberOfUser Damit wird die Anzahl der Benutzer festgelegt die die definierten Lastschritte parallel durchf hren setNumberOfLoadRuns Hintereinander geschaltete Durchl ufe k nnen mit diesem Pa rameter auch auf der Ebene des Testtreibers definiert werden Dies ist vor allem dann sinnvoll wenn ein vorausgehender Durchlauf das System einpegeln siehe auch Ein schwingverhalten in Kapitel 5 5 1 soll setBrowserRunMode Die Ausf hrung des iMacros Browser kann sichtbar oder im so genannten Tray Modus erfolgen Da bei der Lasterzeugung der Browser nicht sichtbar sein soll um Ressourcen zu schonen wird ber diesen Methodenaufruf der Tray Modus aktiviert setRunCourseConfiguration Die bereits angesprochene Vorkonfiguration zur Durch f hrung der Fallstudie kann hiermit aktiviert werden Simulation und Evaluation 146 addLabsToRun Aufgrund des modularen Aufbaus der Fallstudienumsetzung in ein zelne Labs k nnen hiermit die zu verwendenden bungseinheiten definiert werden
69. sich ein Objekt bei einem Zugriff nicht im Puffer befindet und die Anfrage somit an die Datenbank weitergeleitet wird ergibt sich Pweiterleitung ES Prwa 1 Ppuffer W i Sobald die Weiterleitungswahrscheinlichkeit ermittelt wurde kann das Pufferobjekt spezifi ziert werden siehe Abbildung 4 11 F r den Tabellenpuffer wird ein Task modelliert der f r jede Entry die durchgef hrte SQL Select Abfrage abbildet Die Multiplizit t wird auf infinit gesetzt da die Anzahl an simultanen Lesezugriffen nicht beschr nkt ist Da die Bearbeitungszeit des Lesezugriffs auf den Puffer unerheblich ist und infolgedessen nicht in den Trace Dateien protokolliert wird wird die Service Zeit der Tabellenpuffer LON Modell 124 Entries auf 0 gesetzt Dadurch wirkt sich die Anfrage an den Tabellenpuffer Task nicht auf die Antwortzeit aus es sei denn sie wird vom Tabellenpuffertask mit der Wahrscheinlichkeit Prwa an den Datenbank Task weitergeleitet Neben der Bearbeitungszeit der Datenbank Entry konnen auch Wartezeiten auftreten da die Multiplizitat des Datenbank Tasks der Anzahl an Datenbank Verbindungen entspricht wogegen die Multiplizit t des Tabellenpuffers unbe grenzt ist Ein Pufferobjekt deckt oft verschiedene SQL Select Statements ab Allerdings haben ver schiedene SQL Abfragen unterschiedliche Bearbeitungszeiten in der Datenbank sodass sie einzeln modelliert werden m ssen Daher wird ein Pufferobjekt implizit ber die Summe der
70. t die Frage wie LON Modell 134 die in Forschungsfrage 1 identifizierten Systemkomponenten zur Leistungsanalyse eines SAP Netweaver Portal Systems mittels LQN modelliert und parametrisiert werden k nnen Simulation und Evaluation 135 5 Simulation und Evaluation In diesem Kapitel soll das vorgestellte Konzept der LQN Modellierung eines SAP Netweaver Portal Systems anhand einer Fallstudie des SAP University Competence Centers der Technischen Universit t M nchen evaluiert werden Dazu wird zun chst die verwendete Fallstudie beschrieben und auf die Eigenschaften des Workloads eingegangen Im Anschluss hieran wird der Lastgenerator beschrieben der f r die im darauf folgenden Abschnitt darge stellten Messungen verwendet wird Auf die Schilderung der verschiedenen Messszenarien und ergebnisse folgt sodann die Erl uterung der Simulationsdurchf hrung Der anschlie en de Vergleich der Mess und Simulationsresultate beschreibt das Antwortzeitverhalten sowie m gliche Ursachen f r die Diskrepanz zwischen den gemessenen und den simulierten Werten im Hochlastbereich Vertiefend hierzu wird schlie lich eine Analyse des GC Verhaltens pr sentiert 5 1 Fallstudie Die im SAP University Alliances Programm SAP UA 2012 entwickelten Schulungsunter lagen im Folgenden Fallstudie genannt zum SAP Netweaver Portal umfassen acht Kapitel die die einzelnen Schulungstage repr sentieren und wie folgt gegliedert sind siehe Abbil dung 5 1 e Vorb
71. tskontrolle der Messwerte einer automatisierten Elimination von Ausrei ern vorzuziehen ist da neben tat s chlichen Messfehlern auch architekturbedingte Einfl sse zu untypischen Werten f hren k nnen Im Abschnitt zur Performance Evaluation von Rechnersystemen wurde die Gleichwertigkeit von System Performance Metriken und Workload in Bezug auf die Auswahl der Perfor mance Evaluations Methode dargestellt und im Anschluss die verschiedenen Ans tze vorge stellt Die in dieser Arbeit eingesetzten LQNs basieren auf den Warteschlangennetzen Hierbei wur den die verschiedenen Elemente vorgestellt die bei der Modellierung in Kapitel 4 Verwen dung finden sowie der eingesetzte Simulator beschrieben Die Abschnitte zu den Benchmarks und der Kapazit tsplanung die den Abschluss dieses Ka pitels bilden konnten einen Einblick in die Bereiche der vergleichenden Leistungsanalyse sowie der Frage wann die Systemauslastung ges ttigt ist geben Die Kapazit tsplanung er weitert die technische Leistungsanalyse um den Kostenaspekt zu einer Kosten Performance Analyse und tr gt somit der konomischen Betrachtung des Leistungsverhaltens Rechnung Systemarchitektur und Monitoring 65 3 Systemarchitektur und Monitoring In diesem Kapitel wird zun chst die Architektur des SAP Netweaver Portal Systems darge stellt Dabei wird der Abarbeitungsablauf von Benutzeranfragen die am System ankommen erl utert und auf verschiedene Komponenten eingegangen d
72. von Rechnernetzen Die Warteschlangentheo rie ist daher ein wertvolles Werkzeug f r die Analyse von Rechnersystemen Als Vater der Warteschlangentheorie kann der D ne Agner K Erlang angesehen werden der sich als erster an die mathematische Behandlung von Telefongespr chen wagte Den Start schuss setzte er mit seiner 1909 ver ffentlichten Arbeit The Theory of Probabilities and Te lephone Conversations Erlang 1909 In den drei iger Jahren wurde der n chste Meilenstein im Zusammenhang mit der Warteschlangentheorie gelegt die Pollaczek Khintchine Formel Pollaczek 1930 Khintchine 1932 Diese von Felix Pollaczek entwickelte Formel erm glich te erstmals eine stark vereinfachte Berechnung der Kunden in einem Wartesystem mit allge meinen Annahmen Im Jahr 1951 ver ffentlichte David G Kendall seine Arbeit ber das Konzept der eingebetteten Markov Ketten Kendall 1951 Von ihm stammt auch die noch heute g ltige Notation f r Warteschlangensysteme Fast zur gleichen Zeit entwickelte Dennis V Lindley eine Gleichung zur Berechnung der mittleren Wartezeit in einem System mit sehr allgemeinen Annahmen Lindley 1952 Bis zum Jahr 1957 lag das Hauptaugenmerk auf ein zelnen Bedienstationen James R Jackson besch ftigte sich als erster eingehend mit Warte schlangennetzen und fand heraus dass man die L sung eines offenen Warteschlangennetzes unter bestimmten Bedingungen aus den L sungen der einzelnen Warteschlangenknoten zu sammensetzen
73. wird In Bezug auf die Leistungsverbesserung sowie analyse werden Funktionen wie Tabellenpufferung Wiederverwendbarkeit von h u Theoretische Grundlagen 21 fig benutzten SQL Anweisungen Statement Pooling und datenbankunabh ngige Monitor und SQL Trace Unterstiitzung geboten Damit die zugrundeliegende Datenbank ohne Probleme ausgetauscht werden kann verwendet ein SAP System nur Basisfunktionen der unterstiitzten relationalen Daten banksysteme Beispielsweise werden keine Bedingungen zur referenziellen Integritat eingerichtet Somit wird die Datenbank haupts chlich als ein leistungsf higer Hinter grundspeicher verwendet Die Ressourcennutzung ist infolgedessen stark V O lastig Der Einfluss der Datenbankschicht sollte daher getrennt von der Leistungsf higkeit eines SAP Systems betrachtet werden Jehle 2010 14 Neben den relationalen Datenbanken wird inzwischen vermehrt mit In Memory Technologien experimentiert wo die Daten im Hauptspeicher vorgehalten werden und somit einen wesentlich schnelleren Zugriff erlauben Die von SAP entwickelte In Memory Datenbank SAP HANA High Performance Analytic Appliance SAP 2012 wurde im Fr hjahr 2010 vorgestellt und soll Echtzeitberechnungen auch im Be reich von ERP Systemen erm glichen Die Leistungsanalyse von In Memory Datenbanken ist nicht Teil dieser Arbeit der modulare bzw geschichtete Aufbau des Warteschlangenmodells erm glicht es jedoch lediglich die Datenbankschicht gegen
74. www iopus com de imacros zugegriffen am 12 02 2012 2012 Jackson J R 1964 Jobshop Like Queueing Systems In Management Science Vol 10 1964 S 131 142 Jaenecke P 1982 Grundz ge einer Me theorie In Journal for General Philosophy of Science Vol 13 1982 Nr 2 S 234 279 Jain R 1991 The Art of Computer Systems Performance Analysis Techniques for Experimental Design Measurement Simulation and Modeling Wiley Interscience New York NY USA 1991 Literaturverzeichnis 197 Janssen S Marquard U 2007 Sizing SAP Systems SAP Press 2007 Jay R 2008 SAP NetWeaver Portal Technology McGraw Hill Professional 2008 Jehle H 2010 Performance Measurement of an SAP Enterprise Portal System in a Virtualized Environment Technische Universitat Miinchen 2010 Jianyi N Zhengqiu Y 2008 An Automated Test Tool of Web Application Based on Struts In IEEE Computer Society Vol 1 2008 Nr 2008 S 488 490 John L K Eeckhout L 2006 Performance Evaluation and Benchmarking CRC Press Boca Raton 2006 Jonkers H 1994 Queueing models of parallel applications the Glamis methodology In Proceedings of the 7th International Conference on Computer Performance Evaluation Hrsg Springer Verlag New York Inc Secaucus NJ USA 1994 S 123 138 Joslin E O 1965 Evaluation and performance of computers application benchmarks the key to meaningful computer evaluations Proceedings of the
75. zunehmender Systemlast untersucht Im sechsten und letzten Kapitel dieser Arbeit werden die Ergebnisse der Performance Modellierung und Simulation eines SAP Netweaver Portal Systems zusammengefasst und interpretiert Die identifizierten Einflussgr en auf die Antwortzeit werden den Resultaten der Leistungsbewertung gegen bergestellt und eine Einsch tzung ber die Akkuratesse der Per formance Evaluation mittels Modellierung und Simulation abgegeben Dabei werden sowohl die Interessensgruppen aus der Praxis als auch aus der Wissenschaft adressiert Abschlie end werden die Limitationen dieser Arbeit diskutiert und ein Ausblick auf weitergehende For schungsm glichkeiten gegeben Theoretische Grundlagen 15 2 Theoretische Grundlagen In diesem Kapitel werden die theoretischen Grundlagen die in dieser Arbeit zum Einsatz kommen vorgestellt Die Beschreibung der einzelnen Themen und Terminologien beschr nkt sich dabei nicht nur auf die in dieser Arbeit eingesetzten Methoden sondern soll einen kurzen berblick ber die relevanten Themengebiete geben 2 1 Enterprise Resource Planning am Fallbeispiel SAP Ein Enterprise Resource Planning System ERP System stellt ein unternehmensweites und Unternehmensfunktionen integrierendes System Kremar 2010 236 dar das auf Basis standardisierter Module alle oder wesentliche Teile der Gesch ftsprozesse eines Unterneh mens aus betriebswirtschaftlicher Sicht informationstechnisch unterst tz
76. 0 Benutzern Szenario 2 Quelle eigene Darstellung Von nun an steigen die Antwortzeiten in den Simulationsergebnissen ziemlich linear der leichte zus tzliche Anstieg ist den Sperrsituationen und der abnehmenden Trefferquote des Tabellenpuffers geschuldet Im Gegensatz dazu zeigen die Messwerte vor allem ab ca 70 bis 80 Benutzern einen beginnenden Anstieg des Antwortzeitenzuwachses Sobald mehr als 100 Benutzer gleichzeitig agieren ist der stark exponentielle Anstieg deutlich zu erkennen Ebenso schwanken die Messergebnisse zunehmend sodass die Maximalwerte gemessener Antwortzeiten obere Ausrei er bei 120 Benutzern einen Wert bis zu 2 240 Sekunden an nehmen und folglich beinahe dem Doppelten des Mittelwertes entsprechen In diesem Bereich liegen die Simulationsergebnisse deutlich unterhalb der gemessenen Zeiten Der Unterschied l sst sich mit einem starken System Overhead erkl ren vgl Jehle 2010 185f der von dem Simulation und Evaluation 175 Simulationsmodell nicht erfasst wird Des Weiteren weisen die GC Traces einen starken Zu wachs der GC Aktivit ten auf die ebenso nicht vom LQN Modell erfasst werden da entspre chende GC Pausen als konstanter Faktor nur in den Service Zeiten enthalten sind vgl Kapi tel 4 2 6 Die im folgenden Kapitel durchgef hrte Analyse der GC Aktivit ten besch ftigt sich ausf hrlich mit diesem Sachverhalt Zusammenfassend zeigt sich dass bei knappen Systemressourcen die Simulationswerte im Hochla
77. 1 1 a Aufruf Abbildung 2 22 LQNS Meta Modell Quelle Franks 2011 2 5 4 2 Layered Queueing Simulator LQsim Der Layered Queueing Simulator LQsim der auch in dieser Arbeit zur Simulation des LQN Modells verwendet wird greift auf vordefinierte Schablonen zur ck die den Elementen des LQNS Meta Modells siehe Abbildung 2 22 entsprechen Das daraus resultierende Si mulationsmodell entspricht dem eingegebenen LQN Modell Die verwendeten Templates greifen auf Elemente des Parasol Simulators Neilson 1991 zur ck Parasol ist ein ereignisdiskreter Simulator zur Simulation von komplexen verteilten Systemen zur Leistungsanalyse sowie zur Emulation der Ausf hrung von Programmen in nebenl ufigen Systemen Neilson 1991 Damit verteilte Systeme einfach modelliert werden k nnen stellt Parasol eine virtuelle Maschine zur Verf gung die Komponenten wie Hardware Locks Sys tem Busse oder Prozessoren anbietet Die von LQsim verwendeten Elemente von Parasol sind in Abbildung 2 23 dargestellt und lassen sich wie folgt beschreiben Theoretische Grundlagen 55 Parasol Modell Abbildung 2 23 Metamodell von Parasol Quelle Li Franks 2009 Knoten Ein Knoten ist eine Sammlung von einen oder mehreren Hosts die durch Busse oder Links verkn pft sind Es k nnen entweder einzelne CPUs oder Multi Prozessoren modelliert werden Bus Ein Bus ist ein Kommunikationskanal zur Verkn pfung von einen oder mehreren Knoten Die Kommun
78. 1965 20th national conference S 27 37 Cleveland Ohio United States ACM Kay W 2001 Capacity Planning for SAP Concepts and tools for performance monitoring and modelling Kemper A Eickler A 2011 Datenbanksysteme Eine Einf hrung 8 aktual u erw Aufl Oldenbourg M nchen 2011 Kendall D G 1951 Some Problems in the Theory of Queues In Royal Statistic Society Vol 13B 1951 S 151 182 Khintchine A Y 1932 Mathematical Theory of a Stationary Queue In Matematicheskii Sbornik Vol 39 1932 Nr 4 S 73 84 Kippenhahn R Weigert A 1991 Stellar Structure and Evolution Springer Berlin 1991 Klein J M 2000 Building Enhanced HTML Help with Dhtml and CSS Prentice Hall PTR Upper Saddle River NJ 2000 Knuth D E 1970 Von Neumann s First Computer Program In ACM Computer Surveys Vol 2 1970 Nr 4 S 247 260 Kolonko M 2008 Stochastische Simulation 1 Aufl Vieweg Teubner Verlag Wiesbaden 2008 Konradin 2011 Einsatz von ERP L sungen in der Industrie Konradin ERP Studie 2011 Konradin Business GmbH Leinfelden Echterdingen 2011 Kounev S Buchmann A 2003 Performance modelling of distributed e business applications using Queuing Petri Nets In Proceedings of the 2003 IEEE International Symposium on Performance Analysis of Systems and Software Hrsg IEEE Computer Society Washington DC USA 2003 S 143 155 Kounev S Weis B Buchmann A P 2004 Performance Tu
79. 3 0 022 5 Median 0 975 1 886 2 788 3 838 4 618 4 811 4 901 Si Q1 25 0 966 1 872 2 760 3 803 4 566 4 752 4 842 Q3 75 0 987 1 905 2 822 3 880 4 684 4 882 4 972 Abbildung 5 14 CPU Zeit eines EJB Requests sowie durchschnittliche CPU Nutzung Szenario 1 Quelle eigene Darstellung Wie in Kapitel 4 1 1 dargestellt leiten sich aus der Theorie der Warteschlangennetze zwei Annahmen bez glich der CPU Ressource ab Zum einen ist die CPU Zeit eines Lastschrittes unabh ngig von der Anzahl simultan agierender Benutzer zum anderen steigt die CPU Nutzung linear zur Benutzeranzahl Zur berpr fung der ersten Annahme CPU Zeit soll als Beispiel der EJB Request aus Kapi tel 3 2 3 Abbildung 3 20 herangezogen werden Wie man in Abbildung 5 14 erkennen kann bleiben die durchschnittlichen CPU Zeiten bei einer steigenden Anzahl von Benutzern nahezu konstant wenngleich bei 100 und 120 simultanen Benutzern eine leicht erh hte Streuung aus den Messdaten abzulesen ist Die zweite Annahme CPU Nutzung wird mittels verwendeter Kerne Cores berpr ft Die virtuellen Prozessoreinheiten werden der logischen Partition LPAR ber die Management konsole des IBM Power Servers zugewiesen und ihre Nutzung ber Betriebssystemmittel vgl Kapitel 3 3 aufgezeichnet Auch hier ist bei einer Benutzerzahl gr er 80 ein Einbruch des nahezu linearen Anstiegs zu erkennen der ebenso auf die maximale Parallelit t der Ap plikations Threads zur ckzuf hren ist Ni
80. 4 bytes Wed Nov 16 14 15 24 2011 e Average Tenured Area usage 238 529 882 bytes e Number of Explicit Garbage Collection 0 Maximum Allocation Request 97 160 bytes Wed Nov 16 13 52 23 2011 There is no object request larger than 10 M bytes Java Heap Activity Analysis and Recommendations report Garbage collection start Analysis Recommendations finish 1 Wed Nov 16 13 52 14 2011 No Java heap Wed Nov 16 exhaustion found 14 15 24 2011 There seems to be a steady increase in Java heap usage ratio 154 76021 with percentage error amp 2 2532756 Open Open verbose garbage collection logs Abbildung 3 24 Pattern Modeling and Analysis Tool Quelle eigene Darstellung Garbage Collector and Memory Analyzer Der Garbage Collector and Memory Analyzer IBM 2011c ist ebenfalls ein Analysewerk zeug das von IBM bereitgestellt wird Es liest die GC Logs aus und stellt diverse grafischen Ausgaben zur Verfiigung die das GC Verhalten tiber eine gewisse Zeitspanne darstellen sie he Abbildung 3 25 a IBM Support Assistant Workbench Data set 1 a Datei VGC heap VGC pause VGC Administration Aktualisieren Views Fenster Hilfe Support Assis A Start E Fehler analysieren 18M Monitoring and Diagnostic Tools x ca Templates 23 F E ONC Dataset1 3 _ bk e EN LA 23 Ei Zoom E Compaction pauses X Axis 0 Fragmentation GC count 2
81. 6 totalbytes 1728053248 percent 99 gt lt soa freebytes 1637134288 totalbytes 1641651200 percent 99 gt VM zu erhalten lt loa freebytes 86402048 totalbytes 86402048 percent 100 gt lt tenured gt lt gc type scavenger id 2 totalid 2 intervalms 2742 862 gt lt flipped objectcount 353673 bytes 26161824 gt Daten zur Heap Speicher lt tenured objectcount 0 bytes 0 gt lt refs_cleared soft 728 weak 0 phantom 0 gt belegung vor dem Garbage lt finalization objectsqueued 1035 gt Collector Lauf lt scavenger tiltratio 50 gt lt nursery freebytes 182463312 totalbytes 209715200 percent 87 tenureage 11 gt lt tenured freebytes 1723536336 totalbytes 1728053248 percent 99 gt lt soa freebytes 1637134288 totalbytes 1641651200 percent 99 gt lt loa freebytes 86402048 totalbytes 86402048 percent 100 gt lt tenured gt lt time totalms 27 882 gt lt ge gt Informationen zu dem Scavenger Durchlauf lt nursery freebytes 182461264 totalbytes 209715200 percent 87 gt lt tenured freebytes 1723536336 totalbytes 1728053248 percent 99 gt Daten zur Heap Speicher lt soa freebytes 1637134288 totalbytes 1641651200 percent 99 gt belegung nach dem Garbage lt loa freebytes 86402048 totalbytes 86402048 percent 100 gt Collector Lauf lt tenured gt lt time totalms 29 007 gt lt af gt Abbildung 3 12 Beispi
82. 797600000portalsim2 333227250 service ejb sap com caf runtime ear BOChangedTopicBean lt internal gt 2011111616285797600000portalsim2 222200 333227250 service ejb sap com caf runtime ear CrawlerBean lt internal gt 2011111616285797600000portalsim2 333227250 service ejb H Abbildung 3 6 Anzeige der Sperreintr ge mittels SAP Konsole Quelle eigene Darstellung Zum Aktivieren bzw Deaktivieren der Aufzeichnungen sind folgende Befehle verf gbar ENABLE SERVER LOGGING Sperreintrag Logging aktivieren DISABLE SERVER LOGGING Sperreintrag Logging deaktivieren ENABLE LOCKINGSTAT Lock Statistiken aktivieren DISABLE LOCKINGSTAT Lock Statistiken deaktivieren 3 1 4 Tabellenpuffer Wie bereits zu Beginn des Kapitels erw hnt besitzt jeder Java Server Prozess seinen eigenen Tabellenpuffer allerdings teilen sich die einzelnen Java Server Threads den Puffer Nicht zu verwechseln ist der Tabellenpuffer in einer Java Instanz mit der Pufferung im Datenbanksys tem siehe Abbildung 3 7 Wichtig ist dieser Unterschied auch f r die Performance Modellierung da der jeweilige Puffer unterschiedliche Ressourcen belastet Da in dieser Ar beit die Datenbank als Black Box betrachtet wird wird nur auf den Tabellenpuffer der Java Instanz eingegangen 74 Systemarchitektur und Monitoring Java Server Server Server CPU Ressource des T
83. 9 Under Relaxiation Koeffizient 9 1 Listing 5 2 Allgemeine Inforationen zur Simulator Eingabedatei Beispiel Quelle eigene Darstellung Prozessordeklarationen An die drei Schichten vgl Kapitel 2 1 1 1 werden entsprechende CPU Ressourcen verge ben Die Prozessoren der Benutzer und Persistenzschicht haben eine unendliche Kapazitat da lediglich die Kapazit tsengp sse der Applikationslogik betrachtet werden sollen 10 Prozessordeklarationen 11 P3 12 p Processor_User fi Prozessorressource Benutzer unendliche Kapazit t i 13 p Processor_Server s1 0 m40 Prozessorressource Server Prozessor Sharing 14 p Processor_DBfi Prozessorressource DB FCFS infinite 15 1 Listing 5 3 Prozessordeklarationen Beispiel Quelle eigene Darstellung Task Deklarationen Im Bereich der Task Deklarationen werden die Tasks der einzelnen Komponenten des Mo dells spezifiziert Benutzertyp Die Multiplizit t m 20 des Tasks gibt an dass 20 Benutzer dieses Be nutzertyps modelliert werden 7 kennzeichnet den Task als Referenztask Lastschritte Der Lastschritte Task hat eine Multiplizit t von 40 da 40 Applikations Threads fiir die Java Server Instanz konfiguriert werden Datenbank Die 10 Datenbankverbindungen der Java Server Instanz werden ber die entsprechende Multiplizitat des Datenbank Tasks modelliert Tabellenpuffer Der Tabellenpuffer Task hat eine unendliche Multiplizitat Sperrman
84. Anwendungssysteme Wannenwetsch Nicolai 2004 73 In Abbildung 2 1 ist der grunds tzliche Aufbau von ERP Systemen dargestellt Materialwirtschaft Logistik Finanz Rechnungswesen Datenbasis Controlling Querschnittsanwendungen z B Workflow Archivierung Reporting Produktion Personalwirtschaft Vertrieb Abbildung 2 1 Prinzipieller Aufbau eines ERP Systems Quelle Schwarzer Krcmar 2004 Die Entwicklung von ERP Systemen in ihrer heutigen Form war in den neunziger Jahren stark von der Erfolgsgeschichte von SAP gepr gt Die Abk rzung SAP steht f r Systeme Anwendungen Produkte in der Datenverarbeitung SAP wurde 1976 von den ehemaligen IBM Mitarbeitern Dietmar Hopp Hans Werner Hector Hasso Plattner Klaus Tschira und Claus Wellenreuther gegr ndet und ist weltweiter Marktf hrer f r betriebswirtschaftliche Standardsoftware Meissner 1999 So listet eine in 2011 durchgef hrte ERP Studie ber die Marktanteile von ERP Software in deutschen Industriebetrieben ab 50 Mitarbeiter Konradin 2011 23 SAP mit 48 1 Microsoft Dynamics NAV AX mit 21 5 Infor ERP mit 9 0 Oracle Enterprise One World mit 6 1 und noch einige kleinere Anbieter Das von SAP entwickelte System SAP R 2 fand vorwiegend in Gro unternehmen eine hohe Verbreitung Zu Beginn der neunziger Jahre als sich die Client Server Architektur durchsetz te l ste SAP R 3 seinen gro rechnerbasierten Vorg nger ab Der durch die Abkehr von
85. Aufruf Ein synchroner Aufruf stellt eine Anfrage des Clients an einen Server dar bei dem der Client blockiert bleibt bis er von dem Anbieter des Dienstes eine Antwort erh lt Sollte der Server gerade besch ftigt sein wird die Anfrage in die Theoretische Grundlagen 51 Warteschlange des Servers gestellt Sobald die Anfrage bearbeitet wird werden ein oder mehrere Phasen bei der Server Entry gestartet Phase 1 stellt dabei die Phase dar in der der Client blockiert ist Am Ende von Phase wird die Antwort an den Client geschickt und nachfolgende Phasen werden gestartet Diese sind dazu da eventuelle Nacharbeiten und deren Ressourcenverbrauch abzubilden Sobald die letzte Phase be endet ist wird die n chste Anfrage sofern vorhanden in der Warteschlange des Ser vers bedient W hrend s mtlicher Phasen k nnen Anfragen an weitere Server gesendet werden sodass der Server auch als Client fungiert aktiver Server Abbildung 2 19 stellt den Verlauf eines synchron bearbeiteten Aufrufs dar Client besch ftigt i Leerlauf Phase 2 Weiterer Serviceaufruf Zeit Abbildung 2 19 Ablauf eines synchronen Aufrufs Quelle eigene Darstellung 2 Asynchroner Aufruf Bei einem asynchronen Aufruf ist der Client nach dem Senden der Anfrage nicht blockiert und der Server sendet nach Abschluss von Phase 1 keine Antwort an den Client Diese Aufrufart ist vergleichbar mit dem parallelen Ansto en von mehreren Java Threads Abbildung 2 20
86. Count Summe der Anfragen die einen Response Code error erhal SxxResponsesCount ten haben POST Summe der Anfragen die ber POST gesendet wurden GET Summe der Anfragen die ber GET gesendet wurden Tabelle 3 5 Wichtige Monitore des http Provider Services im Server Quelle eigene Darstellung in Anlehnung an SAP 201 1a Im Anschluss wird die Anfrage an einen Applikations Thread bergeben hnlich wie der System Thread Manager besitzt auch der Application Thread Manager einen Pool an Threads sowie eine Warteschlange WaitingTasksQueue Der Unterschied zu den System Threads liegt darin dass hier nur die Benutzeranfragen verwaltet werden Daher ist auch die Gr e des Pools kleiner und standardm ig auf 40 simultane Threads angelegt Die Gr e ist zwar kon figurierbar sollte aber im Regelfall nicht h her gesetzt werden Vielmehr sollte bei Bedarf die Konfiguration eines weiteren Java Server Prozesses vorgezogen werden Tschense 2004 26f Die wichtigsten Monitore des Application Thread Managers sind in Tabelle 3 6 darge stellt Monitor Beschreibung CurrentThreadPoolSize Derzeitige Gr e des Thread Pools Die Gr e wird dyna misch an den momentanen Bedarf angepasst InitialThreadPoolSize Initiale Pool Gr e des Application Thread Pools MinimumThreadPoolS ize Minimale Pool Gr e des Application Thread Pools MaximumThreadPoolSize Maximale Pool Gr e des Application Thread Pools WaitingTasksC
87. Daten erfolgt analog zu mpstat und vmstat Somit kann die Nutzung der fundamentalen Systemressourcen aus Betriebssystemsicht festgehalten und analysiert werden 3 4 Zusammenfassung In diesem Kapitel wurden die notwendigen Informationen und Hilfsmittel f r die Messung und Modellierung eines SAP Portal Systems dargestellt und beantworten somit die in For schungsfrage 1 gestellte Frage wie ein SAP Netweaver Portal System f r die Performance Modellierung und Simulation charakterisiert werden kann und welche Analyseinstrumente die ben tigten Informationen bereitstellen Im ersten Teil dieses Kapitels wurde die Architektur des SAP Netweaver Portal Systems ana lysiert Dabei wurden neben dem Aufbau einer Java Server Instanz einzelne Komponenten des Systems betrachtet die in der Systemdokumentation bspw SAP Help 2011 sowie in den Schulungsunterlagen f r SAP Basis Administratoren SAP Education 2011 ausf hrlich be schrieben sind ber die Analyse dieser Materialien den theoretischen Grundlagen aus Kapi tel 2 und den Erfahrungen am SAP UCC der TU M nchen konnten die Bestandteile der Sys temarchitektur identifiziert werden die das Leistungsverhalten wesentlich beeinflussen Im zweiten Teil dieses Kapitels wurde die Monitoring Architektur des SAP Netweaver AS Java vorgestellt und die Hilfsmittel f r die Datenaufzeichnung der einzelnen Komponenten dargelegt In diesem Zusammenhang wurde ebenso auf die M glichkeit des Black B
88. FS Network File Sys tem oder IOStone Park Becker 1990 einem I O Benchmark Der Hauptvorteil von synthetischen Benchmarks liegt vor allem in der schnellen Implemen tierung und schnellen Anpassbarkeit sodass ein gro es Spektrum von realen Lastszenarien mittels einer Menge von Kontrollparametern abgedeckt werden k nnen Allerdings stellen sie Theoretische Grundlagen 60 oft ein sehr einfaches Abbild des realen Lastmusters dar und konnen somit nicht immer die gegebenen Systemeigenschaften darstellen wie zum Beispiel die akkurate Abbildung von Festplatten Caches Hu Gorton 1997 Jain 1991 Eine Ubertragbarkeit der Ergebnisse in den Alltagsbetrieb wird vom synthetischen Benchmark daher nicht erwartet Jehle 2010 Kernel Benchmarks Zeitgleich mit den synthetischen Benchmarks wurden Kernel Benchmarks entwickelt Dabei werden die rechenintensiven Teile des Quellcodes extrahiert und lauffahig gemacht Periphere Zus tze wie zum Beispiel die Benutzerinteraktion werden au en vorgelassen Anstelle der Benutzerschnittstellen werden zur Reproduzierbarkeit definierte Parameter bergeben Jehle 2010 Vertreter von Kernel Benchmarks sind beispielsweise der Tower of Hanoi Staples 1987 Livermore Loops McMahon 1986 oder LinPack Dongarra et al 1979 Lin Pack wird heute noch verwendet um die Leistungsf higkeit von Supercomputern zu messen Die Ergebnisse werden halbj hrlich in einer Top 500 Liste ver ffentlic
89. Intuition und Daumenregeln herangezogen da eine methodische Analyse entweder nicht verf gbar oder zu aufw ndig in der Durchf hrung ist Kounev Buchmann 2003 Daher besch ftigt sich die vorliegende Ar beit mit der Frage wie ein Modell zur technischen Performance Evaluation und Simulation eines SAP Netweaver Portal Systems charakterisiert und parametrisiert werden kann Einleitung 3 Online Umfrage zur Performance Evaluation von ERP Systemen In diesem Zusammenhang wurde 2010 eine Online Umfrage zur Performance Evaluation von ERP Systemen durchgef hrt Mayer et al 2011 die unter anderem dar ber Aufschluss ge ben sollte ob und auf welche Art und Weise Leistungsanalysen durchgef hrt werden zu wel chem Zweck diese durchgef hrt werden und welche Anforderungen an die eingesetzten Hilfsmittel gestellt werden Die Online Umfrage wurde im Dezember 2010 auf zwei gro en Internetplattformen initiiert und zwar der Deutschsprachigen SAP Anwendergruppe DSAG und dem SAP Developer Network SDN Die Befragung beschr nkte sich auf den deutschen Raum wobei die am meisten vertretenen Branchen IT Dienstleistungen 25 die ffentliche Verwaltung 19 44 sowie Banken und Versicherungen 11 11 waren 97 Prozent der Befragten die fast ausschlie lich eine langj hrige Erfahrung im Bereich von SAP Systemen aufweisen und haupts chlich Positionen als IT Berater 33 33 oder IT Projektleiter 27 78 bekleiden treten dem Thema Performance Eva
90. J E Generational heap Maximum X Value ip Memory 20 T f cig LOA and SOA sizes 140 r H hs Native memory clo NUMA 1 90 18447 bo Object sizes 120 Minimum X Value Performance 710 Unpaused time ZS i E Key Te o 5 100 N PD JA i Variants A K L 2 S Ru IB SEI Y Axis S 80 d t N A heap z std_serverd out oc GR e S 60 D Reset Axes Data Heap size ES Tenure age Ka Ve i Nursery size Wm Free nursery heap ofte 20 VS d Ey Free tenured heap afte i T red hi op El Tenured heap size H 200 4000 600 8 000 10 000 12 000 14 000 16 000 18 00 TEE Free heap after collect collection GC count z ji Report Table data Line plot Structured data std_serverl out 4 i p Abbildung 3 25 Garbage Collector and Memory Analyzer Quelle eigene Darstellung Systemarchitektur und Monitoring 95 3 3 Monitoring auf Betriebssystemebene Neben der Uberwachung des SAP System Verhaltens ist ein weiterer ebenso wichtiger As pekt das Performance Verhalten auf Betriebssystemebene Es wird zwischen drei fundamen talen Systemressourcen unterschieden die aus der Von Neumann Architektur folgen Eilert et al 2003 16 CPU Hauptspeicher J O Subsystem Im Folgenden wird ein kurzer berblick ber die verschiedenen Betriebssystem Hilfsmittel zur berwachung der Systemressourcen gegeben Dabei bezieht sich die Beschreibung auf das in dieser Arbeit eingesetzte Betriebssyste
91. Jain 1991 94 Zeitbasiertes Monitoring Das zeitbasierte bzw passive Monitoring muss die ge w nschten Informationen selbst abfragen da das Objektsystem von sich aus keine Da ten zur Verf gung stellt ber eine periodische Abfrage kann die gesamte Statusin formation des zu messenden Systems ermittelt werden Da man keine Informationen ber Zustands nderungen hat wird ein zeitbasierter Monitor in festen Zeitabst nden aktiviert Diese Aktivierung nennt man Ereignis Ein Ereignis ist eine atomare mo mentane Aktion Passive Monitore sind ideal f r die Beobachtung h ufiger Ereignisse und f r die berpr fung von lang laufenden Prozessen in verh ltnism ig gro en In tervallen Zudem muss die Anwendung nicht angepasst oder ver ndert werden Aller dings ist aufgrund der hohen Daten bertragung der Zeitaufwand f r die periodischen Abfragen sehr aufwendig Nissen Petsch Schorcht 2008 208 Ereignisbasiertes Monitoring Ereignisbasiertes Monitoring stellt das dynamische Verhalten eines Programms durch eine Abfolge von Ereignissen dar Im Gegensatz zum zeitbasierten Monitoring ist ereignisbasiertes Monitoring f r effiziente Pro grammanalysen geeignet da es darauf abzielt Einblick in das dynamische Verhalten eines parallelen Programms zu bekommen Hofmann et al 1994 Damit die Informa tionen bereitgestellt werden werden entsprechende Anweisungen im Anwendungs Theoretische Grundlagen 37 code eingef gt Durch diese
92. Knowledge soll zudem die Wiederverwendbarkeit von Informationen und Services erh ht werden indem diese an zentraler Stelle gespeichert und somit Entwicklungs und nderungsaufwand redu ziert werden Heilig Karch 2007 68 Die Architektur der SAP Netweaver Plattform ist in sechs Module unterteilt und in Abbildung 2 3 dargestellt Theoretische Grundlagen 18 SAP Netweaver SAP Netweaver People Integration People Integration Multi Channel Access Mobile Infrastructure A SAP Netweaver SAP Netweaver Portal Collaboration Portal Portal Information Integration Information Integration Business Knowledge SAP Business SAP Netweaver Intelligence Management Intelligence Portal Master Data Management SAP Master Data Management Process Integration Process Integration Integration Business Process SAP Exchange SAP Exchange Broker Management Infrastructure Infrastructure Life Cycle Management Composite Application Framework Life Cycle Management x fe z a E D D u c fe ZS Ei 2 lt v ZS Ka e 2 E fe O Application Platform Application Platform SAP Netweaver SAP Netweaver DB and OS Abstraction SAP Netweaver Application Server Komponentenansicht Produktansicht Abbildung 2 3 SAP Netweaver Komponentenansicht links und Produktansicht rechts Quelle Bonnen Herger 2007 27 Die Application Platform beinhaltet die Kernanwendungen auf die die aufbauenden Modu le zur c
93. Miami FL 2008 S 91 100 Rechenberg P Pomberger G Pirklbauer K 2006 Informatik Handbuch 4 aktual u erw Aufl Hanser Fachbuchverlag M nchen 2006 Risse T 2006 Design and Configuration of Distributed Job Processing Systems Thesis PhD Technische Universit t Darmstadt 2006 Robertazzi T G 2000 Computer Networks and Systems Queueing Theory and Performance Evaluation Springer New York New York USA 2000 Rolia J Casale G Krishnamurthy D Dawson S Kraft S 2009 Predictive modelling of SAP ERP applications challenges and solutions Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools S 1 9 Pisa Italy ICST Institute for Computer Sciences Social Informatics and Telecommunications Engineering Rolia J A 1988 Performance Estimates for Systems with Software Servers The Lazy Boss Method In VII SCCC International Conference on Computer Science Hrsg 1988 S 25 43 Rolia J A Servcik K C 1995 The Method of Layers In IEEE Transactions on Software Engineering Vol 21 1995 Nr 8 S 689 700 Literaturverzeichnis 201 Rolia J A Sevcik K C 1995 The Method of Layers In IEEE Trans on Software Engineering Vol 21 1995 Nr 8 S 689 700 Rubinstein R Y Kroese D P 2008 Simulation and the Monte Carlo Method 2 Aufl Wiley Interscience Hoboken NJ 2008 SAP 2012 SAP In Memory Computing In http ww
94. Modelling and Simulation of SAP Enterprsie Resource Planning Systems In 10th International Conference on Modeling and Applied Simulation Hrsg Rom 2011 S 347 352 McMahon F H 1986 Livermore Fortran Kernels A Computer Test of Numerical Performance Range Lawrence Livermore National Laboratory Livermore CA 1986 Meissner G 1999 SAP die heimliche Software Macht Wilhelm Heyne Verlag Miinchen 1999 Melzer I 2010 Service orientierte Architekturen mit Web Services 4 Aufl Spektrum Akademischer Verlag Heidelberg Neckar 2010 Menasc D A Almeida V A F 2002 Capacity Planning for Web Services Metrics Models and Methods Prentice Hall Englewood Cliffs NJ 2002 Merlin PM Farber D J 1976 Recoverability of Communication Protocols Implications of a Theoretical Study In IEEE Transactions on Communications Vol 24 1976 Nr 9 S 1036 1043 Literaturverzeichnis 199 Mertens P 2001 Integrierte Informationsverarbeitung 1 13 Aufl Gabler Wiesbaden 2001 Meyer E Guicking D 1974 Schwingungslehre Vieweg Verlag Braunschweig 1974 Michel D 2010 Active Memory Expansion Performance 2010 Microsoft 2011 MSDN WebBrowser Control Reference for C C Developers In http msdn microsoft com en us library aa752040 v vs 85 aspx zugegriffen am 30 12 2011 2011 Mohr M Simon T Kremar H 2005 Building an Adaptive Infrastructure for Education Service Providing In Tagung Wir
95. Modells werden mittels unterschiedlicher Nachrichtentypen modelliert Dies ist in dem Programmablauf in Zeile 5 und 6 bei dem Entry Attribut der Eingangsnach richt ersichtlich Uber dieses Attribut wird unter anderem auch die Bedienzeit fiir diese Nach richt gesetzt Die Schleife in dem Programmablauf bedient alle drei Typen von Aufrufen synchron asynchron weitergeleitet Bei asynchronen Aufrufen wird beispielsweise Zeile 12 der Empfang der Antwort sowie Zeile 17 eine optionale Antwort bersprungen vgl Franks 2011 Als Eingabedatei dient dem LQsim ebenso wie dem LQNS eine Textdatei die sowohl die einzelnen Komponentendefinitionen als auch deren Parametrisierung enth lt Die einzelnen Elemente folgen einer vordefinierten Reihenfolge und zwar beginnt die Datei mit einem all gemeinen Informationsabschnitt gefolgt von den einzelnen Komponenten Prozessoren Tasks Entries und Aktivit ten 2 6 Benchmarks In dieser Arbeit wird die Annahme geteilt dass Applikations Benchmarks Werte mit einer hohen bertragbarkeit und Praxisrelevanz liefern Lilja 2000 116 Die Anforderungen an den verwendeten Workload bei der Evaluation des zu entwickelnden LQN Modells sollen daher von Applikations Benchmarks abgeleitet werden F r einen Workload aus der Praxis der f r einen Applikations Benchmark erforderlich ist sorgt eine am SAP UCC angebotene Fallstudie die von den Dozenten im SAP UA Programm verwendet wird siehe Kapitel 5 1 F r eine h
96. Neilson 1991 F r die Syntax der Eingabedatei stehen zwei verschiedene Formate zur Verf gung Traditionelle Grammatik XML Schema Obwohl beide Formate gleich m chtig sind ist ein Trend zum XML Schema erkennbar Dies ergibt sich aus der Benutzeranleitung Franks et al 2012 in der die traditionelle Grammatik seit der Aktualisierung vom Februar 2011 nur noch im letzten Kapitel beschrieben wird Dennoch wird im folgenden Abschnitt lediglich auf die traditionelle Grammatik eingegangen da die durchgef hrten Untersuchungen dieser Arbeit zum Zeitpunkt dieser j ngsten Entwick lung zu weit fortgeschritten waren als dass der Aufwand eines Wechsels zum XML Schema gerechtfertigt gewesen w re Es sei jedoch angemerkt dass f r zuk nftige Arbeiten mit LQsim das XML Schema bevorzugt werden sollte Der Simulator wird auf Kommandozeilenebene ausgef hrt und stellt verschiedene Optionen zur Verf gung Die bei den Versuchen und Testl ufen dieser Arbeit verwendeten Parameter seien an dieser Stelle kurz dargestellt A run time precision skip Die Dauer eines Simulationsdurchlaufs Bl cke wird ber den Wert run time angegeben Die Anzahl der Simulationsblocks wird automa tisch ermittelt Die Pr zision mit anderen Worten die Definition des Konfidenzinter valls kann ber den zweiten Wert angegeben werden Skip stellt eine Einschwing phase dar das mit diesem Wert definierte Zeitintervall flie t nicht in das Ergebni
97. Notes of Lectures on Molecular Dynamics and the Wave Theory of Light Baltimore 1884 TPC 1990 TPC Benchmark B Standard Specification Transaction Processing Performance Council San Jose CA 1990 TPC 1989 TPC Benchmark A Standard Specification Transaction Processing Performance Council San Jose CA 1989 Trivedi K S Haverkort B R Rindos A Mainkar V 1994 Techniques and tools for reliability and performance evaluation problems and perspectives In Proceedings of the 7th International Conference on Computer Performance Evaluation Hrsg Springer Verlag New York Inc Secaucus NJ USA 1994 S 1 24 Tschense A 2004 Java Monitoring Infrastruktur in SAP NetWeaver 04 Galileo Press Bonn 2004 Ufimtsev A 2006 Vertical Performance Modelling and Evaluation of Component Based Software Systems National University of Ireland 2006 Ufimtsev A Murphy L 2006 Performance modeling of a JavaEE component application using layered queuing networks revised approach and a case study Proceedings of the 2006 conference on Specification and verification of component based systems S 11 18 Portland Oregon ACM Versick D 2010 Verfahren und Werkzeuge zur Leistungsmessung analyse und bewertung der Ein Ausgabeeinheiten von Rechensystemen Universit t Rostock 2010 Vogel Heuser B 2003 Systems Software Engineering angewandte Methoden des Systementwurfs fiir Ingenieure Oldenbourg Miinchen 2003 W3C 2011
98. Petri Netzen Quelle eigene Darstellung in Anlehnung an M ller 2005 87 Eine M glichkeit die vielen verschiedenen Petri Netz Typen zu klassifizieren ist die Unter teilung in Low Level und High Level Petri Netze Low Level nennt man alle Petri Netz Typen in denen es nur eine Markierungsart gibt Bei High Level Petri Netzen werden indivi duelle Markierungen verwendet Mit diesen individuellen Markierungen auch Pr dikate ge nannt ist es m glich komplexe Zust nde abzubilden Die Schaltregeln werden erweitert und den Transitionen werden Schaltbedingungen mit Variablen zugeordnet Zur Leistungsbewertung quantitativen Analyse eines Systems eignen sich Petri Netze nicht da sie den Begriff der Zeit nicht beinhalten Daher entstanden Anfang der siebziger Jahre so genannte zeitbehaftete Petri Netze Time d Petri Nets TPN Merlin Farber 1976 Durch die M glichkeit Zeitpunkte und Intervalle abbilden zu k nnen kann die Reihenfolge des Markierungsverbrauches und des Schaltens gesteuert werden Ein weiterer g ngiger Vertreter von High Level Petri Netzen sind beispielsweise gef rbte Petri Netze Coloured Petri Nets CPN Buchholz 1992 Stochastische Petri Netze sind ein spezieller Zweig der zeitbehafteten Petri Netze wobei je der Transition eine exponentiell verteilte Schaltrate zugewiesen wird F r die analytische Mo dellierung ist die Exponentialverteilung die wichtigste und auch die am leichtesten handhab bare Verteilung da si
99. S DS ME y N CPU Datenbank 7 E ll L 4 Vas Hauptspeicher Tabellenpuffer Abbildung 5 6 Ressourcenzuweisung im ersten Test Szenario Quelle eigene Darstellung 5 4 2 Szenario 2 Knappe Systemressourcen Im zweiten Szenario werden gezielt Systemressourcen reduziert und somit zus tzliche Ein fl sse auf die Antwortzeit gepr ft siehe Abbildung 5 7 Der Hauptspeicher ist ausreichend da unzureichender Hauptspeicher zu einem Out of Memory Fehler oder zumindest zur Speicherauslagerung und somit zu erheblichen Performance Verlusten f hrt die im Java Umfeld grunds tzlich vermieden werden m ssen Allerdings erreicht die Hauptspeicherauslastung einen hohen Wert sodass der Garbage Collector in zunehmendem Ma e f r freie Speicherbereiche sorgen muss Die Datenbank Ressourcen werden auf einem hohen Niveau belassen sodass keine zus tzlichen Nebeneffekte eintreten da die Datenbank Komponente im LQN Modell lediglich als Black Box betrachtet wird Simulation und Evaluation 148 Die CPU Ressourcen werden unterhalb des im ersten Szenario gemessenen maxima len Verbrauchs gesetzt Dadurch k nnen die modellierten CPU Ressourcen und deren Einfluss auf die Antwortzeit intensiver gepr ft werden Auch wird die Gr e des Tabellenpuffers reduziert sodass es zu Verdr ngungen kommt deren Einfluss mit den Ergebnissen der Simulation verglichen werden kann Testsystem Szenario 2 ff Va Datenb
100. SQL Statements abgebildet die beim Aufruf auf den Tabellenbereich des Pufferobjektes zu greifen Demzufolge haben s mtliche SQL Abfragen die von demselben Pufferobjekt gekap selt werden dieselbe Weiterleitungswahrscheinlichkeit Bei weitergeleiteten Aufrufen wird die Anfrage von dem Task beantwortet der die Anfrage bearbeitet hat Somit wird im Falle einer Weiterleitung die Antwort direkt von der Entry des Datenbank Tasks an die Entry des Lastschrittes gesendet ee m A N Pwa B SE Sen l m db_threads SQL Select SQL Select SQL Select Datenbank Query n 5 EE SR 2 RN Legende 7 A Task A Entry gt Weitergeleiteter Aufruf Abbildung 4 11 LQN Modellierung der Tabellenpuffer Quelle eigene Darstellung Parametrisierung Die Punkte zur Parametrisierung beziehen sich auch hier wieder auf die diskutierten Aspekte der Tabellenpufferung Die Anfragen an den Tabellenpuffer werden mit einer gewissen Wahrscheinlichkeit an die Datenbank weitergeleitet Dazu wird die Entry Notation mit der Option F ver wendet Die Weiterleitungswahrscheinlichkeit die sich ber das beschriebene Verfahren ab sch tzen l sst wird als Flie kommazahl angegeben LQN Modell 125 Die Service Zeit der Tabellenpuffer Entries betr gt 0 da die Zugriffszeiten auf den Puffer zum einen unbedeutend gering sind zum anderen nicht in den Trace Dateien aufgezeichnet werden In Bezug auf den Einfluss auf die Antwortzeit w
101. Set Computer Collaboration Launch Pad Continuous Time Markov Chains Coloured Petri Nets Central Processing Unit Customer Relationship Management Comma Separated Value Dynamic Hypertext Markup Language Dynamic Information and Action Gateway Deutschsprachige SAP Anwendergruppe Distributed Statistical Records Document Type Definition Discrete Time Markov Chains Enterprise Java Beans Enterprise Ressource Planning First Come First Served First In First Out Floating Point Operations per Second Garbage Collector Generic Request and Message Generator Abk rzungsverzeichnis XI GUI Graphical User Interface GUID Global Unique Identifier HANA High Performance Analytic Appliance HOL Head of Line Priority HTML Hypertext Markup Language HTTP Hyper Text Transport Protocol VO Input Output IBM International Business Machines ID Identifier IS Information Systems ISR Information Systems Research IT Information Technology J2EE Java 2 Enterprise Edition JARM Java Application Respones Time Measurement JDBC Java Database Connectivity JNDI Java Naming and Directory Provider JTA Java Transaction API JTS Java Transaction Service JVM Java Virtual Machine KMU Kleine und mittelst ndische Unternehmen LCFS Last Come First Served LCFS PR Last Come First Served with Preempt and Resume LOA Large Object Area LPAR Logical Partition LQN Layered Queueing Networks LONS Layered Queueing Network Solver LQsim Layered Queueing Networ
102. Technische Universitat M nchen Fakultat ftir Informatik Lehrstuhl fiir Wirtschaftsinformatik I 17 Univ Prof Dr Helmut Kremar Performance Modellierung und Simulation eines SAP Netweaver Portal Systems Manuel Mayer Vollstandiger Abdruck der von der Fakultat fiir Informatik der Technischen Universitat Miin chen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften Dr rer nat genehmigten Dissertation Vorsitzender Univ Prof Dr Martin Bichler Pr fer der Dissertation 1 Univ Prof Dr Helmut Kremar 2 Univ Prof Dr Hans Michael Gerndt Die Dissertation wurde am 14 Januar 2013 bei der Technischen Universit t M nchen einge reicht und durch die Fakult t f r Informatik am 24 April 2013 angenommen Zusammenfassung I Zusammenfassung Ziel Im Rahmen dieser Dissertation soll ein Ansatz fiir die Modellierung und diskrete Ereig nissimulation eines SAP Netweaver Portal Systems entwickelt werden Dabei werden unter Verwendung eines definierten Lastmusters sowie einer steigenden Anzahl von Benutzern Leistungsdaten ermittelt Die Komponenten die als wesentliche Einflussfaktoren fiir das Leis tungsverhalten gelten werden aus der Literatur abgeleitet modelliert und mithilfe der erfass ten Leistungskennzahlen parametrisiert Der zu entwickelnde Ansatz konzentriert sich auf die Applikationsschicht der Portalinfrastruktur und setzt fiir die Modellierung die auf der Warte schlangentheorie basierenden
103. Treffer Hits ablesen und folglich eine Trefferrate Hits Tref ferrate _ II Requests errechnen In einem gut konfigurierten SAP Netweaver System gilt eine Trefferrate von 95 oder h her als befriedigend Heiss Veirich Gratzl 2005 355 oft werden in der Praxis sogar Werte um die 98 bis 99 erreicht Aufgrund der ausreichend dimensionierten Tabellenpuffergr e in diesem Szenario konnte eine Trefferrate von knapp 99 erreicht werden siehe Abbildung 5 11 und folglich die An zahl der n tigen Datenbankzugriffe auf ein Minimum reduziert werden Es ist zudem ersicht lich dass die Anzahl simultaner Benutzer keinen Einfluss auf die Trefferrate nimmt und es somit nicht zu einer erh hten Anzahl an Invalidierungen und Verdr ngungen kommt Simulation und Evaluation 153 5 5 4 3 Datenbankanfragen 50ms Pe o 40ms Ss ZS SZ E S 30ms ow AE E sa z a 20ms a Eo L EE ENEE ENEE sa lt 2 10ms gt a Oms T T T T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer H 16 962 17 138 16 822 17 159 16 930 17 114 17 307 oO 0 577 0 707 0 883 0 612 0 795 0 971 1 060 Cx 0 034 0 041 0 052 0 036 0 047 0 057 0 061 Median 16 974 17 171 16 863 17 216 16 967 17 160 17 356 Q1 25 16 576 16 716 16 295 16 716 16 455 16 534 16 674 Q3 75 17 265 17 503 17 279 17 503 17 341 17 616 17 854 Abbildung 5 12 Durchschnittliche Datenbankzeit pro DB Anfrage in Millisekunden Szenario 1 Quelle ei
104. Zyklen ist Abh ngig von dem Workload und GC Konfiguration sowie den genannten GC Indikatoren nimmt der Garbage Collector einen wesentlichen Einfluss auf die System Performance und somit die Antwortzeit einzelner Benutzer Tasks 3 2 Monitoring des SAP Netweaver AS Java Im vorherigen Kapitel 3 1 wurden die Architektur des AS Java dargestellt und dabei die einzelnen Komponenten sowie leistungsbeeinflussende Elemente Sperrobjekte Speicherma nagement Pufferung beschrieben In diesem Kapitel wird die Monitoring Infrastruktur eines AS Java Systems aufgezeigt Dabei wird das Hauptaugenmerk auf die f r diese Arbeit rele vanten Leistungsdaten gelegt Systemarchitektur und Monitoring 81 Grunds tzlich sollte unterschieden werden zu welchem Zweck die berwachung bestimmter Systemeigenschaften dient Dem Entdecken von Problemen wie zum Beispiel durch Verf gbarkeits berwachung oder dem Aufdecken von Ressourcen Engp ssen Die Datensammlung ist dabei meist unvollst ndig da nur kritische Werte aufgenommen werden Der allgemeinen Systemanalyse beispielsweise hinsichtlich Antwortzeiten der einzel nen Komponenten oder Ressourcen Verbrauch einer bestimmten Applikation Die Da tensammlung erfolgt dabei laufend und ist unabh ngig von einer speziellen Problem betrachtung F r die in dieser Arbeit durchgef hrten Performance Messungen zum einen f r die Para metrisierung des Warteschlangenmodells zum anderen f r die Bewert
105. abellenpuffern durchf hrt sind somit ein iterativer Prozess 3 1 5 Garbage Collector Die folgende Beschreibung des Speichermanagements richtet sich nach der Funktionsweise der Java Virtual Machine JVM von IBM 20111 da die in dieser Arbeit verwendeten Systemarchitektur und Monitoring 77 Systeme f r die Leistungsanalysen auf einer IBM Infrastruktur basieren Die JVMs von SUN und SAP weisen jedoch hnliche Funktionsweisen auf Zudem wird speziell auf die von SAP f r ERP Systeme und Portale empfohlene Garbage Collector Konfiguration eingegangen Grunds tzlich kann einer J2EE Engine nicht mehr Speicher zur Verf gung gestellt werden als auf dem System freier physikalischer Speicher vorhanden ist Der Speicherbereich in dem die Objekte eingelagert werden wird als Heap bezeichnet Dieser wird in einen Young Generation Bereich auch Nursery Generation genannt und einen Old Generation Bereich auch Tenured Generation genannt unterteilt siehe Abbildung 3 10 Heap Gr e Heap Limit Nursery Young Generation Old Tenured Generation Ll IBM IBM Xmn Xmns Xmnx Xmo Xmos Xmox SUN SUN XX NewSize nn XX NewRatio n XX MaxNewSize nn _ Besetzter Speicher Xmn lt size gt L Freier Speicher Abbildung 3 10 Aufbau des Heap Speichers Quelle eigene Darstellung Sobald kein Speicher mehr allokiert werden kann f hrt ein Allokationsfehler zu einem Garbage Collector Lauf Der Garbage Collector GC identifizi
106. agement Das Sperrmanagement besteht aus einem Task fiir den Enqueue Server sowie drei Tasks ftir jeden Sperrbereich Lesesperre Schreibsperre Sema phor Zus tzlich wird ein Pseudo Task definiert der f r die Aktivit tsdefinition be n tigt wird Simulation und Evaluation 162 16 Task Deklarationen U Usertype W Workloadstep D DB P Puffer E Enqueue xxE Entry 17 RS Lesesperre WS Schreibsperre S Semaphor WSP WS Pseudotask 18 T8 19 t U1 r U1E1 1 Processor_User m 20 20 t W1 f W1E1 W1E2 1 Processor_Server m 40 40 Threads 1 Java Instanz 21 t D1 f D1E1 D1E2 1 Processor_DB m 10 2 SQL Queries 10 DB Verbindungen 22 t P1 f P1E1 1 Processor_Server i Tabellenpuffer unendliche Multiplizitat 23 t E1 f E1E1 E1E2 1 Processor_Server Enqueue Server 2 SQL Queries 24 t RS1 f RS1E1 1 Processor_Server Lesesperre Sperrbereich 1 25 t WS1 f WSICHK WS1E1 1 Processor_Server Schreibsperre Sperrbereich 1 inkl Checkentry 26 t S1 S S1W S1S 1 Processor_Server Bin rsemaphor Wait und Signal Entries 27 1 Listing 5 4 Task Deklarationen Beispiel Quelle eigene Darstellung Entry Deklarationen Im Abschnitt der Entry Deklaration werden wie bereits erw hnt die Entries der einzelnen Tasks spezifiziert Im vorgestellten Beispiel wurden die folgenden Deklarationen durchge f hrt Die Entry des Benutzertyp Tasks verweist auf die Aktivit t die die einzelnen Interak tionsschritte durchl uft
107. aktiv das im bertragenen Sinne einem GC Lauf ent spricht Dadurch entstehen Wartezeiten die den GC Einfluss nachahmen 2 Nach Erhalt der Antwort wird mit den eigentlichen Lastschrittaufgaben in Aktivit t 2 fortgesetzt 3 Nachdem die modellierten Lastschrittvorg nge durchgef hrt wurden wird schlie lich die Antwort an die aufrufende Entry gesendet Mit der Einf hrung dieser logischen Garbage Collector Komponenten k nnen somit 2 Para meter angegeben werden das Intervall zwischen den GC Client Anfragen ber die Denkzei ten der Entries und die Dauer der Bearbeitung ber die Service Zeit der GC Sim Entry Na t rlich sind auch diese Parameter nur Ann herungen da zum Beispiel Lastschritte die gerade ausgef hrt werden nicht von dem GC Sim Task gestoppt werden Eine Modellierung der Stop the World Pause bei der laufende Lastschritt Aktivit ten gestoppt werden ist ber die LQN Modellierung nicht ohne weiteres m glich Dennoch sei an dieser Stelle betont dass diese Ann herung ausreicht da die M glichkeit geschaffen wird ber zwei Parameter den GC Einfluss auf die Antwortzeit zu justieren Dies erm glicht Analysen des Antwortzeitver haltens bei erh hter bzw berm iger GC Aktivit t die bei impliziter Darstellung der GC Zeiten als konstanter Faktor der Service Zeit nicht einfach m glich gewesen w re da s mtli che Service Zeiten der Lastschritte angepasst werden m ssten Das Funktionsprinzip der logischen GC Komp
108. al 2005 Die genannten Gr nde die es schwer oder sogar unm glich machen ein akkurates Model zu erstellen beziehen sich auf die Komplexit t der JVM die fehlende Quellcode Offenheit der GC Implementierungen sowie fehlende Messdaten Ein gro er Nachteil der impliziten Parametrisierung d h die Service Zeit entspricht der Aus f hrungszeit inklusive GC Anteil ist der konstante GC Anteil Es ist allerdings gerade im Hochlastbereich eine berproportionale Aktivit tszunahme des Garbage Collectors zu erwar ten da der Heap Speicher an seine Grenzen gelangt und immer h ufiger Speicherbereiche von nicht mehr ben tigten Objekten freigegeben werden m ssen Nach Libic Tuma Buley 2009 kann der GC Overhead sogar um ein Vielfaches bis auf einen zweistelligen Prozentbereich ansteigen Wie bereits erw hnt lassen auch die erhobenen Messwerte die noch in Kapitel 5 5 dargestellt werden eine hnliche Schlussfolgerung zu Damit das LQN Modell in der Lage ist verschie dene GC Aktivit tsmuster und deren Auswirkung auf die Antwortzeit zu testen muss also der Garbage Collector bzw die vorgestellten GC Parameter Ausf hrungsdauer und Intervall in das Modell integriert werden Dies dient der in der zweiten Iteration durchgef hrten Analyse des Hochlastbereichs Umsetzung Damit die zwei Parameter GC Dauer und GC Intervall umgesetzt werden k nnen werden zwei logische Komponenten in das Modell integriert GC Client Der GC Client ist m
109. allgemeiner System Overhead auf die Antwortzeiten auswirken Diese u eren Einfl sse werden vom Simulationsmodell nicht hinreichend genau erfasst Flaschenhalsanalyse Die Bewertung der Simulationsergebnisse kann ebenfalls der Analyse von potentiellen Fla schenh lsen dienen Aus Sicht der LQN Modellierung stellt ein voll ausgelasteter Task einer bergeordneten Ebene dessen genutzte Ressourcen untergeordneter Ebenen nicht voll ausge lastet sind einen Flaschenhals dar vgl Neilson et al 1995 Der Ausgabedatei des Simulators k nnen Informationen zur Auslastung der einzelnen Entries und Aktivit ten entnommen werden Der wiedergegebene Wert der Nutzung liegt im Bereich 0 lt Nutzung lt m wobei m die Multiplizit t der Komponente spezifiziert und somit die durchschnittliche Anzahl an verwendeten Threads darstellt Zeigt zum Beispiel der Daten bank Task eine sehr hohe Nutzung der Threads bei einer durchschnittlichen Systemlast kann eine Erh hung der Datenbankverbindungen den Flaschenhals beseitigen Ebenso k nnen hohe Sperrzeiten einzelne Applikations Threads blockieren Sollten noch Systemressourcen vor handen sein jedoch keine freien Applikations Threads mehr zur Verf gung stehen liegen diese brach Damit ein potentieller Flaschenhals bei der konfigurierten Anzahl an Applikations Threads verhindert werden kann muss die Anzahl f r das zugrundeliegende System optimiert werden In Szenario 1 konnten wenngleich bewusst durchgef h
110. ank Hauptspeicher Tabellenpuffer Abbildung 5 7 Ressourcenzuweisung im zweiten Test Szenario Quelle eigene Darstellung Das zweite Szenario erm glicht somit die Untersuchung des Performance Verhaltens im Hochlastbereich bei dem sowohl das SAP Portal System als auch die Systemressourcen CPU an ihre Grenzen gelangen Aus den beiden Szenarien ergeben sich folglich verschiedene Lastsituationen l 2 3 Niedriglastbereich Sowohl das SAP Portal System als auch die Systemressourcen verf gen ber Reserven Hohe Auslastung des SAP Portal Systems in Szenario 1 Das Portalsystem wird ber eine hohe Anzahl an simultan agierenden Benutzern und einer Einschr nkung der Ja va Server Instanzen bzw Applikations Threads unter Last gesetzt Hohe Auslastung des SAP Portal Systems und der Systemressourcen in Szenario 2 Hierbei werden neben der Auslastung der Java Server Instanzen und der Verminde rung der Tabellenpuffergr e die zu einer zunehmenden Anzahl an Datenbankanfra gen f hrt auch die CPU Ressourcen begrenzt und infolgedessen sowohl das SAP Portal System als auch der virtuelle Host unter Last gesetzt 5 5 Messung In diesem Kapitel werden zun chst das Einschwingverhalten sowie oszillierende Messwerte des Netweaver Portal Systems erl utert und anschlie end die Messwiederholungen sowie Messergebnisse der beiden ersten Szenarien beschrieben Simulation und Evaluation 149 5 5 1 Einschwingverhalten Bei de
111. ankabfragen resultieren Ab ca 40 bis 50 Benutzern sind die CPU Ressourcen voll ausgelastet und m ssen folglich von einer zunehmenden Anzahl an Benutzern geteilt werden Dies f hrt hn lich zu der Begrenzung der Applikations Threads im ersten Szenario zu einem we sentlichen Anstieg der Antwortzeiten Deutlich sichtbar ist ein weiterer Zuwachs ab 80 Benutzern der mit einem zuneh menden System Overhead zusammenh ngt vgl Jehle 2010 185f Aber auch der soeben erw hnte Anstieg der GC Aktivit ten wirkt sich auf die Antwortzeiten aus und wird in Kapitel 5 8 weiter analysiert Zusammenfassend wird ein Hochlastbereich erreicht in dem sowohl das SAP Portal System als auch die Systemressourcen ausgelastet sind Der Mangel an zus tzlichen CPU Ressourcen bewirkt einen deutlichen Zuwachs der Antwortzeiten und versch rft sich durch erh hte Sys temaktivit ten au erhalb des SAP Portal Systems Simulation und Evaluation 159 5 6 Simulation Nachdem das Modell ber die erhobenen Messdaten parametrisiert werden konnte wird in diesem Kapitel die Durchf hrung der Simulation beschrieben Dabei werden zuerst die ver schiedenen Modellkomponenten in der Eingabedatei erl utert und im Anschluss die Informa tionen die vom Simulator in die Ausgabedatei geschrieben werden dargestellt Der verwendete Simulator LQsim LQsim 2011 der bereits in Kapitel 2 5 4 vorgestellt wur de basiert auf den ereignisgesteuerten PARASOL Simulator
112. arbage Collector Szenario 2 80 Benutzer Quelle eigene Darstellung Simulation und Evaluation 177 Die Entwicklung der GC Dauer kann in Abbildung 5 21 betrachtet werden z 45 Legende v Pause Mark Sweep 2 0 40 60 80 10 0 120 140 160 180 20 0 collection GC count Abbildung 5 21 Dauer der Garbage Collector L ufe Szenario 2 80 Benutzer Ouelle eigene Darstellung Das Intervall zwischen den GC L ufen bleibt relativ konstant zwischen 25 und 34 Sekunden siehe Abbildung 5 22 Legende 35 0 Intervall 30 0 25 0 20 0 15 0 10 0 5 0 00 time seconds 20 40 6 0 80 100 120 140 160 18 0 20 0 collection GC count Abbildung 5 22 Intervall zwischen den Garbage Collector L ufen Szenario 2 80 Benutzer Quelle eigene Darstellung Szenario 2 100 Benutzer Bei 100 simultanen Benutzern nehmen die GC Aktivit ten deutlich zu Im Schnitt wird nach ca 19 6 Sekunden ein GC Lauf mit einer mittleren Dauer von ca 1 4 Sekunden gestartet sie he Tabelle 5 3 Dauer s Mark s Sweep s Intervall s u 1 423 1 198 0 225 19 603 o 1 372 1 324 0 128 1 980 Min 0 158 0 077 0 055 15 420 Max 5 470 5 277 0 616 23 895 Tabelle 5 3 Statistische Daten zum Garbage Collector Szenario 2 100 Benutzer Quelle eigene Darstellung Simulation und Evaluation 178 In Abbildung 5 23 kann die Entwicklung der GC Dauer betrachtet werden Im Vergleich zur D
113. arbeiter der Java Performance Gruppe konnte das zu erwartende Verhaltensmuster des Portals skizziert werden Wenngleich keine LQN Simulationen durchgef hrt wurden wurden Key Performance Indikatoren ermittelt Cheng 2008 die in dieser Arbeit als Grundlage f r die Auswahl der zu modellierenden Komponenten dienten vgl Kapitel 4 1 2 Die Leistungsanalyse des Portalsystems sowie die Simulation des Modells wurden f r zwei unterschiedliche Szenarien durchgef hrt die den Schwerpunkt auf unterschiedliche Untersu chungsgegenst nde setzen Das erste Szenario kann als grundlegende Evaluation des Leis tungsverhaltens des Portalsystems sowie der Simulationsergebnisse verstanden werden da sich die zu untersuchende Systemumgebung auf ein gut konfiguriertes Portalsystem mit aus reichenden Systemressourcen bezieht Dazu wurden gen gend CPU Ressourcen und eine ausreichende Tabellenpuffergr e zur Verf gung gestellt damit zus tzliche Einflussfaktoren vermieden werden Das zweite Szenario besch ftigt sich mit der Frage wie sich das Portalsystem bei knappen Systemressourcen verh lt und welchen Einfluss dies auf die Simulationsgenauigkeit nimmt F r die Untersuchung wurden daher zum einen die CPU Ressourcen stark eingegrenzt Dies ist mit der verwendeten virtualisierten Systemumgebung von IBM ohne nennenswerten Auf wand m glich da die Systemressourcen eines virtuellen Hosts dynamisch zur Laufzeit ver n dert werden k nnen Des Weiteren wurde die
114. arios eine Multip lizit t m zugewiesen die die Anzahl der Benutzer pro Benutzertyp festlegt Die Summe aller Benutzertypen B B unter Ber cksichtigung ihrer Multiplizit t m repr sentiert die modellierte Lastintensit t L LON Modell 108 n L X Pm EN l LQN Modellierung Bei den LQNs werden Benutzer als Task dargestellt Da ein Benutzertask jedoch immer einen Ausgangspunkt darstellt und somit keine Anfrage erhalten sondern lediglich senden kann wird von einem Referenz Task gesprochen In geschlossenen Warteschlangensystemen wer den von den Referenz Tasks synchrone Anfragen gesendet und somit die Last am System erzeugt Bei offenen Warteschlangensystemen werden asynchrone Anfragen gesendet deren Ankunftsrate ber einen entsprechenden Parameter definiert wird Da Referenz Tasks in LQN Modellen Benutzer darstellen sollen definiert ein eigens daf r eingerichtete Parameter die Denkzeit des Benutzers Umsetzung Wie bereits erw hnt f hrt ein Benutzer eine Reihe von Interaktionsschritten aus deren Ab folge durch Denkzeiten zwischen den einzelnen Schritten gebremst wird Jeder durchgef hrte Interaktionsschritt i i entspricht dabei einer Aktivit t Die Anzahl der Benutzer die diese Folge von Interaktionsschritten durchf hrt wird ber die Multiplizit t des Referenz Tasks angegeben Diese Modellierungsweise reicht im Prinzip aus um die in Kapitel 5 durchgef hr te Fallstudie zu modellieren da s mtliche Stu
115. auer bei 80 Benutzern ist die durchschnittliche Dauer nur geringf gig erh ht 60 Legende S 50 Pause F 40 Mark 3 Sweep 3 0 N 2 0 1 0 0 0 5 0 10 0 15 0 20 0 25 0 30 0 35 0 400 450 collection GC count Abbildung 5 23 Dauer der Garbage Collector L ufe Szenario 2 100 Benutzer Ouelle eigene Darstellung Allerdings ist das Intervall zwischen den GC L ufen um ca 10 Sekunden gesunken und stellt somit einen berproportionalen Anstieg der GC Aktivit ten dar siehe Abbildung 5 24 Legende Intervall time seconds Di o N N vo um m o o o o 2 5 0 100 150 20 0 25 0 30 0 35 0 400 450 collection GC count Abbildung 5 24 Intervall zwischen den Garbage Collector L ufen Szenario 2 100 Benutzer Ouelle eigene Darstellung Vergleicht man die Aktivit tsintensit t der GC L ufe ist ein berproportionaler Anstieg zu erkennen 1 2 1 4 TE x 80 Dieser Anstieg f hrt zu dem Schluss dass der implizite GC Einfluss in den Bearbeitungszei ten nicht ausreicht Daher werden die N herungsparameter GC Dauer und Intervall zur Spe zifikation der Aktivit tsintensit t wie in Kapitel 4 2 6 dargestellt im LQN Modell integriert Es wird auf eine Darstellung der damit erreichten Antwortzeiterh hung verzichtet da sich dieser Effekt direkt von der Struktur sowie den verwendeten Parameterwerten der bereits vor Simulation und Evaluation 179 gestellten GC Modellierung ableitet D
116. bale Funktionalit t Korrektheit F r die quantitative Ana lyse wie sie bei der Leistungsbewertung eines Systems ben tigt wird eignen sich klassische Petri Netze nur bedingt Diesen Mangel versuchte man durch zus tzliche Funktionen zeitbe Theoretische Grundlagen 40 haftete Petri Netze stochastische Petri Netze aufzuheben die im weiteren Verlauf dieses Kapitel vorgestellt werden Kurz gesagt ist ein Petri Netz ein Graph der mit graphentheoretischen Verfahren analysiert werden kann In der Literatur findet sich eine Vielzahl von Petri Netz Typen Sie unterschei den sich beispielsweise dadurch dass sie eine andere Beschriftung nutzen unterschiedliche Marken verwenden etc Dennoch liegt bei der Definition immer ein Petri Netz Graph zu grunde Dieser kann je nach Petri Netz Typ um weitere Funktionen und Abbildungen erwei tert werden Die einfachste Form eines Petri Netzes wird durch Stellen Transitionen und Kanten be schrieben und mittels eines 5 Tupels dargestellt Bause Beilner 1989 PN S T W Wt M Folgende Aussagen gelten S ist eine endliche nichtleere Menge von Stellen T ist eine endliche nichtleere Menge von Transitionen SnT W W sind Funktionen aus S x T gt No W7 hei t R ckw rtsinzidenzfunktion W Vorw rtsinzidenzfunktion Mp ist eine Funktion aus S gt No und stellt die Anfangsmarkierung dar Petri Netz Modelle bestehen aus zwei wesentlichen Teilen Netzstruktur und Ma
117. bbildung 4 6 LQN Modellierung der Lastschritte 0 0 0 0 ccc ecceceseceeeceeeeeeeeeeseceteeeeeeenseees 113 Abbildung 4 7 Funktionsprinzip eines Semaphor TaskS cceseeseeseeeeeeeceeeceaeceeeaeeeeeees 115 Abbildungsverzeichnis VII Abbildung 4 8 Beispiel zweier sich blockierender LLeseoperattonen 116 Abbildung 4 9 Aktivit ten der Sperrobjekte oo ecccecccesceesceenceceseceeeceeeeeeseeenaeceeeneeeenseees 117 Abbildung 4 10 LQN Modellierung der Sperrverwaltung 0 cceceeceeceeseesteceteeeeeeeeseees 119 Abbildung 4 11 LQN Modellierung der Tabellenpuffer neen 124 Abbildung 4 12 LQN Modellierung der Datenbank 127 Abbildung 4 13 Zweiter Zyklus der Modellbldung eee ee cecceeceeeceeteecneeceteeeeeeenseees 128 Abbildung 4 14 LQN Modellierung der Garbage Collector Parametrisierung 130 Abbildung 4 15 Bearbeitungszeiten eines Lastschtts eeceseeeseeseeeeeeeeceecesecneeeneeeneess 131 Abbildung 4 16 Schematische Darstellung des LON Modells ce eeceesceeceeseceteeeeeeeeeeeees 133 Abbildung 5 1 Schulungsinhalte der SAP Netweaver Portal Fallstudie 135 Abbildung 5 2 Ermittlung des modellierten Workloads A 137 Abbildung 5 3 Sequentielle Abarbeitung bestimmter Lastschritte nenne 138 Abbildung 5 4 Schematische Darstellung des internen Testtreiber Aufbaus 143 Abbildung 5 5 Testtreiber Interface f r die Portalfallstudie
118. benl ufigkeit sorgen Die eingehen den Sperranfragen werden dann von der jeweiligen Entry ber eine weitergeleitete Anfrage an den Sperr Task des betreffenden Sperrbereichs weitergeleitet Sperrbereiche kapseln die Menge an Datenbankoperationen die sich gegenseitig ausschlie en m ssen Die Zeit die f r die Weiterleitung der Sperranfrage beansprucht wird setzt sich aus der War tezeit am Enqueue Server und der Bedienzeit zusammen Die Bedienzeit wird ber die be kannten Ma e u durchschnittliche Service Zeit und CS quadrierter Variationskoeffizient spezifiziert Dies kann aus den Eintr gen des Enqueue Server Traces berechnet werden Das vorgestellte Sperrkonzept f hrt anschlie end die Sperrung des Sperrbereichs durch Die Wartezeiten die aufgrund einer bestehenden Sperre entstehen entsprechen den Wartezeiten die auch im realen System auftreten LQN Modell 119 Der Aufruf der Datenbankoperation innerhalb des Aktivit tsgraphs sendet eine synchrone Anfrage an die entsprechende Entry des Datenbank Tasks Die Multiplizit t des Datenbank Tasks wird dabei auf die Anzahl der Datenbankverbindungen gesetzt die die Java Instanz en am Datenbankserver aufbauen Da die Datenbank nicht im Detail modelliert wird und als Black Box betrachtet wird werden die durchschnittlichen Service Zeiten der einzelnen Da tenbankoperationen spezifiziert Die Datenbankkomponente wird noch im Detail in Kapi tel 4 2 5 erl utert Sobald die Datenbankope
119. betreffenden Datenbankbereichs Solange eine Schreiboperation ansteht oder derzeit durchgef hrt wird wartet dieser Aktivit tsstrang auf eine Antwort Sobald der Schreibsperren Task LQN Modell 118 die Anfrage bedienen kann Service Zeit 0 erh lt der Aktivit tsstrang eine Antwort und f hrt mit der n chsten Aktivit t fort dem Aufruf der Datenbankoperation Sobald diese abgeschlossen ist wird die Antwort an das aufrufende Objekt der Lastschritt Entry gesendet Sobald beide Aktivit tsstr nge ihre Aufgabe erledigt haben wird ber einen Aufruf der Signal Entry der Semaphor freigegeben Da diese Aufgabe le diglich eine verwaltende T tigkeit der LQN Simulation ist wird ihr kein Ressourcen verbrauch zugeschrieben Sollte eine Lesesperre gerade mit der Datenbankoperation besch ftigt sein und eine zweite Leseoperation ankommen wird diese nicht blockiert da Anfrage an den Schreibsperren Task sofort abgeschlossen werden kann und der Datenbankaufruf sowie die Antwort an den aufrufenden Lastschritt erfolgen kann Le diglich der zweite Aktivit tsstrang die Sperranfrage an den Semaphor bleibt solange blockiert bis die erste Leseoperation den Vorgang komplett abgeschlossen und der Semaphor wieder freigegeben hat sodass auch die zweite Leseoperation die Sperre setzen und sofort wieder freigeben kann Dies stellt allerdings kein Problem dar da dieser Verwaltungsakt keine Ressourcen verbraucht und lediglich die Aktivit t ab schlie t 2
120. bsperre Check Entry 56 s S1S 0 0 1 Semaphor Sperrbereich Signal Entry Service Zeit 57 s S1W 0 0 1 Semaphor Sperrbereich Wait Entry Service Zeit 58 P S1S Semaphor definiert S1S als Signal Entry 59 V S1W Semaphor definiert SIW als Wait Entry 60 Listing 5 5 Entry Deklarationen Beispiel Quelle eigene Darstellung Deklaration der Aktivit ten Sieht man von der expliziten GC Modellierung ab sieht das in Kapitel 4 2 vorgestellte Mo dell drei Entries mit Aktivit ten vor namentlich die Aktivit tsgraphen der Benutzer Interaktionen der Lesesperre sowie der Schreibsperre Der Aktivit tsgraph des Benutzertyp Tasks stellt eine Sequenz der einzelnen Interaktions schritte dar In Listing 5 6 sind die Aktivit tsdefinitionen der beiden beispielhaften Interakti Simulation und Evaluation 164 onsschritte dargestellt Jeder Interaktionsschritt wird genau ein Mal durchgef hrt dement sprechend ist die Anzahl der Aufrufe deterministisch Die Service Zeit des Interaktionsschritts wird auf 0 gesetzt da der Ressourcenverbrauch der Pr sentationsebene nicht betrachtet wird Wie sp ter noch gezeigt wird werden die durchschnittlichen Antwortzeiten zu den einzelnen Aktivit ten in der Ausgabedatei des Simulators ausgegeben 61 Aktivit ts Deklarationen 62 AU1 63 s U1A1 0 0 1 Interaktionsschritt Service Zeit 0 64 ZU1A10 0 optionale Denkzeit des Interaktionsschrittes 65 f U1A11 deterministische Anzahl an Au
121. ch GC Zeiten Zeiten der GC Mark Phasen Zeiten der GC Sweep Phasen Zeiten der GC Compact Phasen Zur Verf gung stehender Java Heap Speicher Gewonnener Java Heap Speicher Sobald die Daten eingelesen wurden wird ein Diagnose Algorithmus gestartet der eventuelle Speicherprobleme erkennt wie beispielsweise Java Heap Fragmentierungen oder zu gro e Speicheranfragen die nicht bedient werden konnten siehe Abbildung 3 24 Systemarchitektur und Monitoring 94 Bi Patten Modeling and Analysis Tool for Java Garbage Collector LEI File Analysis Yiew Help mame xxx BBSadd Par ist Oe8 24 Name First Garbage Collec Last Garbage C std_serverO out Wed Nov 16 16 28 Wed Feb 15 16 16 592 16 594 1 std_serverO out Wed Nov 16 16 28 Thu Feb 16 13 16 751 16 753 1 H std_server0 001 Wed Nov 16 13 52 Wed Nov 16 1 38 38 ay File name sap P33 usrsap JC33 work std_server0 001 Number of verboseGC cycles 1 e Number of Garbage Collections 38 e Number of Allocation failures 38 First Garbage Collection Wed Nov 16 13 52 14 2011 Last Garbage Collection Wed Nov 16 14 15 24 2011 Number of Java heap exhaustion o e Overall Garbage Collection overhead 0 28 Maximum Garbage Collection overhead 5 Wed Nov 16 13 53 20 2011 e Number of 100 AF overhead 0 Total Garbage Collection pause 3 seconds Maximum Tenured Area usage 566 514 10
122. ch der Anzahl der simultanen Benutzer hat zudem den Vorteil dass die Messergebnisse nicht durch zus tzliche Wechselwirkungen beeinflussen werden die beispielsweise nur sporadisch auftreten und ent sprechend analysiert werden m ssten Aufgrund der simultanen Anfragen die am System ankommen kommt es bei steigender An zahl an Benutzern zu einer zunehmenden Anzahl von Wartesituationen Warteschlangennetze siehe Kapitel 2 4 und im Speziellen die LQNs siehe Kapitel 2 5 stellen hierbei eine be w hrte Methode dar Warteschlangensituationen zu modellieren Mittels analytischer Verfah ren oder der in dieser Arbeit angewandten Simulation k nnen anschlie end ein bestimmtes Szenario berechnet und die Leistungsdaten ermittelt werden Die sukzessiv durchgef hrten Benutzeranfragen als Teil des modellierten Workloads wer den nicht direkt aufeinanderfolgend sondern erst nach einer spezifizierten konstanten Denk zeit des Benutzers gestartet Eine einzelne Benutzeranfrage wird auch als Interaktionsschritt bezeichnet Die Summe der einzelnen Interaktionsschritte ergibt den gesamten modellierten Workload wie zum Beispiel einen abgebildeten Gesch ftsprozess oder in diesem Falle die abgebildeten Schulungsinhalte Die wesentlichen Erweiterungen zu bereits bestehenden Ans tzen spiegeln sich vor allem in der Modellierung des Sperrmechanismus eines SAP Netweaver Java Systems und der Be trachtung des Garbage Collectors wieder Sowohl im Bereich des Ja
123. che Umsetzung der Modellkomponenten beschrieben und M glichkeiten zur akkuraten Parametrisierung aber auch Limitationen der Berechnung unbekannter Quantit ten aufgezeigt Kapitel 4 beantwortet somit die zweite Forschungsfrage in der die Erstellung und Beschreibung des Performance Modells gefordert ist In Kapitel 5 wird das erstellte Artefakt ber eine Fallstudie demonstriert und evaluiert Der Einsatz der Simulation des LQN Modells sowie der Vergleich zwischen den Mess und Simu lationsergebnissen ist zugleich Gegenstand von Forschungsfrage 3 Dazu werden zwei Szena rien entwickelt die eine unterschiedliche Systemkonfiguration beinhalten und in der Folge einen differenten Fokus auf den Untersuchungsgegenstand richten Im ersten Szenario werden die Systemressourcen in ausreichendem Ma e zur Verf gung gestellt sodass die Analyse auf Einleitung 14 die Einflussfaktoren und Architektureigenschaften des Portalsystems sowie dem daraus resul tierenden Antwortzeitverhalten gerichtet werden kann Das zweite Szenario dient der Pr fung der Antizipationsfahigkeit des Simulationsmodells bez glich der Auswirkungen knapper Sys temressourcen auf das Leistungsverhalten des Systems Da im Hochlastbereich externe Ein fl sse das Antwortzeitverhalten ma geblich mitbestimmen werden anschlie end der System Overhead und das Java Speichermanagement untersucht und somit die Ursachen f r die Di vergenz zwischen simulierten und gemessenen Antwortzeiten bei
124. chnittlichen Datenbankzeiten bei einer steigenden Anzahl von Benutzern beobachtet werden Die tats chliche Zeit f r eine ef fektiv durchgef hrte Datenbankabfrage h ngt somit lediglich von der potentiellen Wartezeit im Sperrmanagement und den zu Verf gung stehenden Datenbankverbindungen 10 pro Java Server Instanz vgl Kapitel 3 1 1 ab Beide sind im LQN Modell explizit ber das Sperrma nagement sowie die Multiplizit t des Datenbanktasks abgebildet Simulation und Evaluation 154 5 5 4 4 Sperrmanagement 120ms 100ms 80ms 60ms 40ms Durchschnittliche Enqueue Zeit pro Sperrobjekt ms 20ms Oms T T T T T T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer H 17 984 34 004 44 218 69 735 100 217 105 279 104 539 o 0 737 1 125 1 527 1 675 3 559 4 340 3 564 Cy 0 041 0 033 0 035 0 024 0 036 0 041 0 034 Median 17 956 34 139 43 983 69 651 100 223 105 550 104 713 01 25 17 567 33 539 43 178 68 618 98 086 101 919 102 668 Q3 75 18 439 34 664 45 315 71 023 102 425 108 105 106 736 Abbildung 5 13 Durchschnittliche Enqueue Zeit pro Sperrobjekt in Millisekunden Szenario 1 Quelle eigene Darstellung Die Zeit in der auf das Setzen einer Sperre bzw die Freigabe eines Objektes gewartet wird erh ht sich erwartungsgem mit der steigenden Anzahl an simultanen Benutzern In Abbil dung 5 13 kann die durchschnittliche Zeit die vom Enqueue Trace f r die einzelnen Sperran fragen aufgezeichnet wi
125. chnittstellen angeboten ber die die Benutzereingaben automatisiert gesteuert werden k nnen allerdings spiegeln diese nicht exakt die Abarbeitung der Auftr ge durch das konventionelle SAP GUI wider Nach Jehle 2010 18 f hren die Theoretische Grundlagen 20 2 se alternativen Schnittstellen zu einem erh hten Ressourcenverbrauch der in der Fol ge Messergebnisse verf lschen kann Im Gegensatz zu dem SAP GUI besteht die Pr sentationsschicht des J2EE Stacks aus einem nicht modifizierten Web Browser Es wird das im Internet standardm ig ver wendete HTTP Protokoll Hyper Text Transport Protocol Fielding et al 1999 ver wendet Applikationsschicht Die Applikationsschicht wird in einen betriebssystemspezifischen und in einen unab h ngigen Teil untergliedert Der betriebssystemspezifische Teil wird als Operating System Abstraktion OS Abstraktion bezeichnet und enth lt zum Beispiel den Kernel der SAP Anwendungsplattform Der betriebssystemunabh ngige Teil der Applikati onsschicht stellt die Umgebung dar in der alle Anwendungen abgeschottet von den Besonderheiten des zugrundeliegenden Betriebssystems verwaltet und ausgef hrt werden Die Anwendungen k nnen sowohl ABAP als auch J2EE als technologische Grundlage verwenden Der Java Bereich der Applikationsschicht bietet eine J2EE zertifizierte Laufzeitumgebung in der auch der Zugriff auf ABAP basierte Anwendungsobjekte m glich ist Zudem wird eine Reihe von Kommunika
126. chtsdestotrotz zeigt der lineare Anstieg deutlich dass die CPU Ressourcen abh ngig von der Anzahl an Benutzern genutzt werden und der Ressourcenbedarf somit der zweiten Annahme entspricht Simulation und Evaluation 156 5 5 5 Szenario 2 Knappe Systemressourcen Im zweiten Szenario wird wie bereits geschildert der Tabellenpuffer bewusst verkleinert sodass nicht alle Objekte darin Platz finden und es folglich zu Verdr ngungen kommt Zudem werden die CPU Ressourcen auf drei virtuelle Kerne gekappt damit eine Volllast der CPU Ressourcen gepr ft werden kann 5 5 5 1 Pufferzugriffe 100 80 4 60 40 20 Trefferrate der Pufferzugriffe 0 1 20 40 60 80 100 120 Anzahl simultaner Benutzer u 80 81 72 76 67 76 56 59 51 65 50 71 51 43 3 15 3 25 3 25 3 59 3 47 3 36 3 66 Cx 0 039 0 045 0 048 0 063 0 067 0 066 0 071 Median 81 55 73 53 68 53 57 46 52 48 51 51 52 48 Q1 25 79 49 71 41 66 41 55 17 50 26 49 34 50 72 Q3 75 82 80 74 80 69 80 58 79 53 79 52 79 53 59 Abbildung 5 15 Trefferrate der Pufferzugriffe in Prozent Szenario 2 Quelle eigene Darstellung Aufgrund der geringen Tabellenpuffergr e ist eine verminderte Trefferquote zu erwarten die mit einer steigenden Benutzeranzahl weiter verringert wird Dies begr ndet sich durch eine zunehmende Anzahl an Verdr ngungen und Invalidierungen Abbildung 5 15 zeigt die erhobenen Daten der Tabellenpufferaufzeichnung und best tig
127. d Gabelung zur parallelen Ausf hrung modelliert werden Dies nimmt jedoch keinen Einfluss auf die Sperrlogik bzw die Antwortzeiten da vereinfacht gesagt die berpr fung ob eine Schreibsperre vorliegt in jedem Fall die Lesesperre Anfrage blockiert Somit ist auch dieser Ansatz valide Simulation und Evaluation 165 74 Aktivit ts Deklarationen 75 ARS1 76 s RSA1 0 0 77 s RScheck 0 0 78 s RSlock 0 0 79 s RSdb 0 0 80 s RSreply 0 0 81 s RSpseudo 0 0 82 s RSrelease 0 0 83 y RScheck WS1CHK 1 0 84 y RSlock S1W 1 0 85 y RSdb P1E1 1 0 86 y RSrelease S1S 1 0 87 f RScheck 1 88 f RSlock 1 89 f RSdb O 90 f RSpseudo 1 91 f RSrelease 1 92 93 RSA1 gt RScheck 94 RScheck gt RSlock amp RSdb 95 RSdb gt RSpseudo amp RSreply 96 97 RSreply RS1E1 98 1 Startaktivitat Lesesperre keine Service Zeiten Aktivit t Pr fung ob Schreibsperre vorliegt Aktivit t Sperre am Semaphor setzen Aktivit t Datenbankanfrage Aktivit t Senden der Antwort Pseudo Aktivit t f r zus tzliche Und Gabelung Aktitivt t Freigabe des Semaphors Rendezvous mit Check Entry Anfrage an Wait Entry des Semaphors Anfrage an DB ber Tabellenpuffer Anfrage an Signal Entry des Semaphors deterministische Anzahl an Anfragen deterministische Anzahl an Anfragen stochastische Anzahl an Anfragen deterministische Anzahl an Anfragen deterministische Anzahl an Anfragen Definition
128. d folglich die Verdr ngungen und Invalidierungen aber abh ngig von dem tats chlichen Verlauf sind kann die Bestimmung der Weiterleitungswahrscheinlichkeit nur unter vereinfachenden Annahmen Poor Man s Assumption erfolgen Verdr ngungen l schen das Objekt im Puffer sodass es bei der n chsten Leseanfrage von der Datenbank gelesen werden muss Die Verdr ngungsh ufigkeit h ngt von zwei Faktoren ab Von der Gr e des Tabellenpuffers im Verh ltnis zur Gesamtgr e aller Objekte die im Workload gepuffert werden Von der Zugriffsh ufigkeit auf das Objekt LRU Prinzip Unter der Annahme dass alle Objekte gleich gro sind und dieselbe gleichverteilte Zugriffs h ufigkeit z besitzen also _ Gesamt Zugrif fe Anzahl der Objekte ergibt sich die Wahrscheinlichkeit dass sich ein Objekt im Puffer befindet aus dem Verh lt nis der Puffergr e zur Gesamtgr e aller Pufferobjekte Puf fergr e P ee Puffer Gesamtgr e aller Pufferobjekte Wie bereits erw hnt nimmt neben der Puffergr e die Zugriffsh ufigkeit Einfluss auf die Wahrscheinlichkeit ob ein Objekt im Puffer enthalten ist Nimmt man nun vereinfachend an LQN Modell 123 dass die Zugriffsintervalle dieselbe Dauer aufweisen l sst sich eine Gewichtung w der Aus gangswahrscheinlichkeit Ppuffer ermitteln und zwar _ Anzahl Zugriffe auf Objekt Gesamtanzahl Zugriffe Anzahl Objekte Ist w 1 entspricht die Zugriffsh ufig
129. dasteradedacsses 48 2532 Parameter in EON Modellen EN 52 2 3 3 Transformationsregeli E 52 Inhaltsverzeichnis II 2 6 2 7 2 8 3 1 3 2 3 3 3 4 4 1 2 5 4 L sen und Simulieren von LON Modellen 53 Benchmarks leere 56 2 6 1 Anforderungen an Benchmarks nei us 57 2 6 2 Benchmark Slandar ensure 58 20 37 EN E EE 59 Kapazitatsplanung oo sscaccssscvsecetsccentesccuus sscavoasbeucveectssetsscspicsaechscovoncasucataceasseadasscawnccoes 62 FMS ATTEN ASSUN Sos 50 c3s5 adescosccosecesvevencdoaausdcosusveecesccvussoncstoncensseensesucdnecenacsdeaideausoens 63 Systemarchitektur und Monitoring ss0sssessossssssnsssssonsnsnssnunsnsnsnsnnnne 65 System Architektur des SAP Netweaver AS Java ssssssssssonnsssnnessnnnsnnnnnennnnsennunee 65 3 1 1 Abarbeitung von Anfragen seele 66 3 1 2 EE EE 70 3 1 3 Spetttabellenver wal eur ensure en si aa iaaea 71 3 1 4 Reech 73 3 1 5 Eet 76 Monitoring des SAP Netweaver AS JaVa ssoessoesssesssesesoossoossoossssesssesssoessoossossssse 80 3 2 1 Java Application Response Time Measurement ersensensessnessensnenseenennn 82 322 BSingle Activity Track arcinaiii an ae ae S 84 3 23 Punktionaler Trace ee kennen skin 85 52 4 MSO Ls Trace na a ANTEIL 90 3 2 5 Blaek Box Monttofine u era 92 3 2 6 Monitoring des OGarbage Collectors nenn 93 Monitoring auf Betriebssystemebene scsssssnssssonnssnsnnsssnnnsnnnnnennnnnennnnnennnnnnnnnnnene 95 Dok Monitori
130. den Dabei erfolgt die Aufzeichnung der Leistungsdaten siehe Kapitel 3 2 und Kapitel 3 3 die f r die Parametrisierung des LQN Modells siehe Kapitel 4 2 sowie den Vergleich von simulierten und gemessenen Werten notwendig sind 5 4 Szenarien Eine g ngige Methode f r die Performance Analyse von Rechnersystemen ist der Vergleich von Alternativen Lilja 2000 61f Dieser Vergleich dient meist der direkten Vorher Nachher Analyse von unterschiedlichen Systemen bzw Systemkonfigurationen und erfolgt aufgrund der inh renten Fehlerquote in den Messungen ber statistische Verfahren In dieser Arbeit wird kein direkter Vergleich im Sinne einer Vorher Nachher Analyse angestrebt Die beiden Szenarien verfolgen das Ziel unterschiedliche Lastsituationen zu untersuchen Im ers ten Szenario wird nur das SAP Netweaver Portal System unter eine hohe Last gesetzt wo hingegen im zweiten Szenario auch die Systemressourcen des Hosts ausgereizt werden Im ersten Szenario wird somit die grunds tzliche Eignung des LQN Modells bez glich des Antwortzeitverhaltens des Portalsystems getestet Im zweiten Szenario werden die Rahmen bedingungen versch rft und Systemressourcen sowie Tabellenpuffer reduziert Beiden Szena rien gleich sind die verwendete Hardware Architektur und das zugrunde liegende Datenbank system Das Testsystem ist als virtueller Host auf einem IBM Power 750 Server installiert Dies erm glicht eine dynamische Konfiguration der Systemressourcen
131. den Nutzer darin unterst tzen das System zu verstehen Quellen der Leistungsunterschied aufzudecken und Optimierungen durchzuf hren Heinrich Lehner 2005 462 2 6 2 Benchmark Standards Wie bereits in Kapitel 2 3 1 angef hrt gibt es keinen offiziellen Standards f r Performance Metriken allerdings wurde eine Reihe von Standard Benchmarks f r bestimmte Szenarien entwickelt die zum Leistungsvergleich weltweit Verwendung finden Zwei bekannte Organi sationen die selbstentwickelte Benchmarks freigeben sowie Ergebnisse sammeln und ver f fentlichen sind SPEC Standard Performance Evaluation Corporation und TPC Transac tion Processing Performance Council Die SPEC Benchmarks betreffen insbesondere technische Anwendungsgebiete mit denen vorwiegend die Leistung von Arbeitsplatzrechnern und Mikroprozessoren ermittelt werden Zu einem der bekanntesten SPEC Benchmarks z hlt der CPU Benchmark womit die Rechen leistung unabh ngig von Betriebssystem Architektur etc verglichen werden kann Rechenberg Pomberger Pirklbauer 2006 460 Ziel der SPEC Organisation ist es die In dustrie mit realistischen Me latten auszur sten um die Leistung fortschrittlicher Rechensys teme zu messen Haas Zorn 1995 215 Das Ziel des internationalen Gremiums TPC ist die Definition von transaktionsorientierten Benchmarks f r nachpr fbare objektive Leistungsdaten hnlich wie bei SPEC m ssen so wohl neue Anwendungen als auch eng vernetzte und
132. denten Benutzer dieselben Aktionen durchf h ren und lediglich die Anzahl der Studenten ber die Multiplizit t des Referenz Tasks para metrisiert werden muss Allerdings sollen wie bereits erw hnt die Denkzeiten der einzelnen Interaktionsschritte keinen Absolutwert darstellen Daher ist es notwendig verschiedene Be nutzertypen zu modellieren indem mehrere Referenz Tasks mit den entsprechenden Interak tionsschritten definiert werden Die Denkzeiten der einzelnen Interaktionsschritte werden an schlie end exponentialverteilt parametrisiert Es sei an dieser Stelle vorgegriffen dass auf grund der ausgegebenen Simulator Resultate der Verzicht auf eine Multiplizit t gr er eins und die Modellierung jedes Benutzers als eigenen Task von Vorteil ist In Bezug auf den Ressourcenbedarf konzentriert sich die in dieser Arbeit durchgef hrte Per formance Analyse auf die Applikationsschicht daher wird bei den Clients von ausreichend zur Verf gung stehenden Ressourcen ausgegangen und infolgedessen der CPU Bedarf ver nachl ssigt Dies wird durch die Modellierung einer Client CPU Ressource mit unendlicher Multiplizit t erreicht In der Summe ergibt sich das in Abbildung 4 3 dargestellte Konzept der Benutzermodellie rung LQN Modell Sn ae in iy Interaktions Benutzertyp Denkzeit Denkzeit schritte 1 iz i Interaktions Benutzertyp Denkzeit Denkzeit schritte n Legende _ referena tTask Ly Entry J4 H H Aktivit tsgraph Abbild
133. des Aktivit tsgraphen 114 WSlock gt WSdb 115 WSdb gt WSrelease amp WSreply 116 WSreply WS1E1 Antwort 117 1 Listing 5 8 Aktivit tsdeklaration der Schreibsperre Beispiel Quelle eigene Darstellung 5 6 2 Ausgabedatei des Simulators Nachdem der Simulator mit der Eingabedatei gestartet und die Simulation durchlaufen wurde werden die Ergebnisse in einer Textdatei pr sentiert Im ersten Abschnitt der Ausgabedatei werden allgemeine Informationen ausgegeben siehe Listing 5 9 Version des Simulators sowie Urheberrechte Verwendeter Befehl zur Ausf hrung des Simulators Name der Eingabedatei Anzahl an durchgef hrten Iterationen Bl6cken sowie Wert des Konvergenztests Generated by Iqsim version 5 6 Copyright the Real Time and Distributed Systems Group Department of Systems and Computer Engineering Carleton University Ottawa Ontario Canada K1S 5B6 Invoked as Iqsim blocks 30 dss sample Ion Input dies sample Jon LD ON DU P DO MM PR Convergence test value 0 Number of iterations 30 r oO Listing 5 9 Allgemeine Informationen der Ausgabedatei Beispiel Quelle eigene Darstellung Danach folgen verschiedene Abschnitte die die Parametrisierung des Eingabemodells be schreiben Prozessorinformationen sowie Scheduling Algorithmen Task Informationen Name Typ Repliken Prozessor Priorit t Entries Parametrisierte Service Zeiten der Entries bzw A
134. die Anzahl an be dienten Elementen W die Wartezeit und R W S die Verweilzeit Eines der wichtigsten Gesetze der Warteschlangentheorie ist das Gesetz von Little 1961 Dieses besagt dass die durchschnittliche Anzahl an Elementen Auftr gen im System gleich der Ankunftsrate mal durchschnittliche Verweilzeit ist N A R In Warteschlangensystemen mit begrenzter Warteschlangenkapazitat gilt das Gesetz von Litt le dann wenn die tats chliche Ankunftsrate verwendet wird Ein weiterer wichtiger Aspekt bei Warteschlangensystemen ist die Auslastung p Sie ist der Anteil der Zeit in der die Bedienstationen Server besch ftigt sind p mu Bei einem stabilen Warteschlangensystem mit unbegrenzter Warteschlangenkapazit t darf somit die Ankunftsrate nicht gr er als die Bedienrate sein Ansonsten wird von einem insta bilen Warteschlangensystem gesprochen 2 5 Layered Queueing Networks Die in Kapitel 2 4 eingef hrten Warteschlangennetze sind eine verbreitete Methode um die Performance von Rechnersystemen zu analysieren und vorherzusagen Obwohl sie sehr viele Erfolge im Bereich von traditionellen Rechnern mit Zeitteilverfahren feiern konnten sto en sie bei komplexen Interaktionen zwischen Software und Hardwarekomponenten in Client Server Architekturen sehr oft an ihre Grenzen Das Konzept der stochastischen Rendezvous Netzwerke Woodside 1989 Woodside et al 1995 sowie der Method of Layers Rolia Servcik 1995 f hrten zu ein
135. die Datenbank geschrieben wurden Dieses Puffer Prinzip entspricht somit nicht der Funktionsweise der in einem SAP Netweaver Portal System verwendeten Tabellenpuffer bei dem Daten aus der Datenbank gelesen und in den Tabellenpuffer ge schrieben werden k nnen damit zuk nftige Zugriffe auf den entsprechenden Tabellenbereich einen effizienteren Weg ber den Puffer gehen k nnen Stochastisch betrachtet kann man die Frage ob ein Objekt aus dem Tabellenpuffer oder der Datenbank gelesen wird mit einer Weiterleitungswahrscheinlichkeit vom Puffer zur Daten bank beantworten In der LQN Modellierung wird die Weiterleitung einer Anfrage von einem zum n chsten Task ber eine weitergeleiteten Aufruf siehe Kapitel 2 5 1 modelliert Diesem kann eine Weiterleitungswahrscheinlichkeit zugewiesen werden die angibt mit welcher Wahrscheinlichkeit die Anfrage nicht von dem Task selbst bearbeitet wird bertragen auf die Tabellenpuffer gibt die Weiterleitungswahrscheinlichkeit an mit welcher Wahrscheinlichkeit das Objekt nicht vom Puffer sondern von der Datenbank gelesen wird Umsetzung Wie soeben beschrieben wird das Verh ltnis zwischen dem Lesen vom Puffer und dem Lesen von der Datenbank ber die Weiterleitungswahrscheinlichkeit angegeben Die Weiterlei tungswahrscheinlichkeit h ngt von verschiedenen Gr en ab die im Folgenden analysiert werden sollen Da lediglich die Puffergr e sowie die gepufferten Objekte bekannt die Zu griffssequenzen un
136. die betrachteten Einflussgr en anhand der in der Literatur beschrie benen Hauptfaktoren sowie der vorhandenen bzw messbaren Leistungsdaten eingegrenzt Dies ist notwendig da die Modellierung aller Einflussgr en falls berhaupt definierbar nicht praktikabel ist 4 1 1 Systemverhalten Betrachtet man die CPU Zeit f r einen einzelnen Interaktionsschritt die CPU Nutzlast und die Antwortzeiten der wegen der zunehmenden Anzahl von simultanen Benutzern ansteigen den Systemlast ergeben sich folgende Pr missen die sich direkt aus der Warteschlangentheo rie ableiten 1 Die CPU Zeit f r einen bestimmten Interaktionsschritt eines Benutzers ist gleichblei bend und somit unabh ngig von der Anzahl der simultan agierenden Benutzer Mit anderen Worten bleibt die reine Bearbeitungszeit konstant und ist somit unabh n gig von der Systemauslastung W rde die CPU Zeit f r einen bestimmten Interakti onsschritt zunehmen beispielsweise aufgrund von Busy Waiting Situationen z B Dijkstra 1971 w rde die gesamte CPU Nutzlast berm ig ansteigen und somit zu einer stark erh hten Antwortzeitkurve f hren In Abbildung 4 1 ist dieser Sachverhalt symbolisch dargestellt W rde bei steigender CPU Last y Achse hervorgerufen durch eine steigende Anzahl von Benutzern x Achse die reine CPU Zeit f r einen definierten Interaktionsschritt ansteigen w re diese von u eren Systembedingungen abh ngig Diese Abh ngigkeit w rde von dem Wart
137. dware und Softwarekomponenten sowie entsprechende Konfigurationen so zu w hlen dass sie bestimm ten Performance Charakteristiken gen gen Begrenzte Leistungskapazit ten und ein steigen der Bedarf f hren fr her oder sp ter zu einer S ttigung bei der das System bzw die System landschaft nahe der Vollauslastung arbeitet Dies f hrt wiederum zu einem Anstieg der Ant wortzeiten und somit zur Unzufriedenheit der Benutzer Kapazit tsplanung erfordert eine sehr gute Kenntnis der verwendeten Software Daher bieten viele gro e Hersteller eigene Werk zeuge und Leitf den an wie ihre Software konfiguriert werden kann Menasc Almeida 2002 haben einen allgemeinen Kapazit tsplanungsprozess entwickelt siehe Abbildung 2 24 der h ufig zum Bemessen von Systemen verwendet wird Risse 2006 wie zum Beispiel bei der Konfiguration eines datenintensiven verteilten Informations systems f r Erdbeobachtungen Gomaa Menasc Kerschberg 1996 Zu Beginn wird die Systemumgebung analysiert und ein Verst ndnis f r die gegebene Hard ware Software Konfigurationen etc geschaffen Danach wird der Workload charakterisiert ein Modell entwickelt anschlie end validiert und ggf in einem iterativen Prozess kalibriert und erneut validiert Das Workload Modell wird im n chsten Schritt f r eine Workload Prognose verwendet Dieselben Schritte werden bei der Erstellung des Performance Modells durchgef hrt Dabei wird in sehr vielen F llen auf Warteschla
138. e Anfrage von dem Cluster Manager des Java Dispatchers an den Java Server bergeben wurde wird sie dort von dem Gegenst ck dem Server Cluster Management ent gegengenommen Die Monitore des serverseitigen Cluster Managers entsprechen denen des Dispatcher Cluster Managers Ebenfalls identisch mit dem dispatcherseitigen Server Thread Manager sind die Monitore des serverseitigen System Thread Managers der die Anfrage von dem Cluster Manager erh lt Auch hier ist die standardm ige maximale Anzahl an simultanen Threads 100 wobei nicht alle den Benutzeranfragen zur Verf gung stehen da auch interne Kommunikations Threads damit verwaltet werden Systemarchitektur und Monitoring 69 Der HTTP Provider Service des Servers nimmt die Anfragen vom Server Thread Manager entgegen und z hlt die eingehenden Anfragen seit Serverstart Zudem werden Response Codes zur ckgegeben die Aufschluss dar ber geben welchen Status die einzelnen Anfragen besitzen In Tabelle 3 5 sind die wichtigsten Monitore des serverseitigen HTTP Provider Services aufgelistet Monitor Beschreibung AllRequestsCount Summe der Anfragen seit dem Start des Servers ResponsesFromCacheCount Summe der Anfragen deren Antworten aus dem Cache er folgt sind 2xxResponsesCount Summe der Anfragen die einen Response Code successful erhalten haben 3xxResponsesCount Summe der Anfragen die einen Response Code redirection erhalten haben 4xxResponses
139. e als einzige kontinuierliche Verteilung die Markov Eigenschaft der Ged chtnislosigkeit besitzt Entsprechend lassen sich somit viele Kennwerte wie bei der War teschlangentheorie siehe Kapitel 2 4 berechnen Fink Schneidereit Vo 2005 129 Vogel Heuser 2003 91 Ein stochastisches Petri Netz besitzt neben den bereits eingef hrten Ele menten PN S T W W M eine Menge der Schaltraten R r m wobei r den Mittelwert der zur Transition t geh renden exponentiell verteilten Schaltrate darstellt Obwohl stochastische Petri Netze viele Vorteile f r die analytische Modellierung besitzen sind auch einige Nachteile bekannt Beispielsweise zeigt Bause 1993 Probleme bei der Be schreibung von Scheduling Strategien mit Petri Netz Elementen auf und stellt dabei einen Formalismus der Petri Netze mit der Warteschlangenmodellierung kombiniert Queueing Petri Nets QPN vor Allerdings finden sich in der Literatur nur wenige praktische Beispiele f r den Einsatz von QPN Kounev Buchmann 2003 nutzen sie zum Beispiel f r die Perfor mance Evaluation von verteilten E Business Anwendungen Der Grund f r die wenigen An Theoretische Grundlagen 42 wendungsbeispiele k nnte darin liegen dass die Analyse der QPN immer noch auf Markov Ketten mit all ihren Vor und Nachteilen beruht 2 3 3 3 Simulation Arnold Isermann Kuhn 2004 beschreiben Simulation als das Nachbilden eines Sys tems mit seinen dynamischen Prozessen in ei
140. e des Sperrbereichs Jede Entry des LQN Tasks stellt die schreibende Datenbankoperation dar die im Workload auftritt und in diesen Sperrbereich f llt Zudem wird eine Entry f r die Abfrage ob zurzeit ei ne Schreiboperation ansteht oder gerade ausgef hrt wird eingerichtet Die Multiplizi t t wird auf 1 gesetzt da nicht mehrere Schreiboperationen gleichzeitig durchgef hrt werden k nnen Jede Entry bis auf die zus tzliche Abfrage Entry wird ber einen Aktivit tsgraphen beschrieben Einen Semaphor Task f r die Sperren zwischen Lese und Schreiboperationen Die Entries Wait und Signal stellen dabei die Operationen f r das Sperren und Freigeben des Semaphors dar Die Multiplizit t des Semaphors wird auf 1 gesetzt und stellt so mit einen Bin rsemaphor dar Schreibsperre Sperrbereich 1 AN Task gt synchron m Multiplizitat a Entry ck weitergeleitet SB Sperrbereich Abbildung 4 9 Aktivit ten der Sperrobjekte Quelle eigene Darstellung Der Aktivit tsgraph in der Lese bzw Schreibsperre wird wie folgt beschrieben l Die Anfrage einer Lesesperre erreicht den Lesesperren Task des betreffenden Daten bankbereichs Die Aktivit t teilt sich im Anschluss ber eine Und Gabelung zu zwei nebenl ufigen Str ngen Der erste Strang versucht ber einen synchronen Aufruf Rendezvous eine Sperre bei dem Semaphor zu setzen Der zweite Strang sendet zu erst eine synchrone Anfrage an die Check Entry der Schreibsperre des
141. e die folgenden Auswertungen zeigen f hren die GC L ufe immer wieder zu Einbr chen der CPU Nutzung F r die Untersuchung des Garbage Collectors wurden die Traces aus Szenario 2 bei 80 und 100 simultanen Benutzern verglichen Zur Aktivierung der Traces wurde der standardm ig eingeschaltete Parameter Verbose gc genutzt Der Heap Speicher wurde auf einen festen Wert gesetzt Xms1536 maximale Heap Gr e Xmx1536 minimale Heap Gr e Ebenso wurden die in Davis et al 2006 14 vorgeschlagenen Tuning Parameter fiir em SAP Netweaver Enterprise Portal auf emer IBM Power Architektur verwendet Xloratio0 05 minimale Large Object Heap Gr e Xconmeter0 Ausl ser f r die Garbage Collection Xconcurrentbackground einzelner Thread f r Concurrent GC Xgcthreads I Anzahl GC Threads Xconcurrentlevel4 Startzeitpunkt des GCs Xparroot Reduziert GC Pausen Die nachstehenden Diagramme zeigen die Kenngr en GC Dauer und GC Intervalle f r die betrachteten Benutzerzahlen Szenario 2 80 Benutzer Bei 80 simultanen Benutzern wird im Schnitt nach ca 29 2 Sekunden ein GC Lauf mit einer mittleren Dauer von ca 1 2 Sekunden gestartet siehe Tabelle 5 2 Dauer s Mark s Sweep s Intervall s u 1 211 1 013 0 198 29 276 o 0 933 0 869 0 105 2 405 Min 0 269 0 194 0 075 25 092 Max 4 078 3 726 0 453 33 728 Tabelle 5 2 Statistische Daten zum G
142. e dieser Methode ist dass viele Objekte sehr fr h zu Garbage werden und somit der Fokus auf die junge Generation gelegt wird Dazu wird wie bereits dargestellt der Speicherbereich in einen Young Generation und einen Tenured Generation Bereich auf geteilt Der Young Generation Bereich wird wiederum in zwei logische Einheiten aufgeteilt den Allocate Bereich und den Survivor Bereich Sobald der Allocate Bereich voll ist wird ein GC Lauf auch GC Zyklus genannt gestartet W hrend des sogenannten Scavenge Vorgangs werden alle erreichbaren Objekte abh ngig von ihrem Alter in den Tenured Bereich oder den Survivor Bereich kopiert Objekte die nicht erreichbar sind bleiben unber hrt So bald die Kopiervorg nge abgeschlossen sind werden die Rollen der beiden Bereiche Allo cate und Survivor vertauscht sodass der ehemalige Allocate Bereich der inzwischen keine erreichbaren Objekte mehr aufweist als Survivor Bereich f r den n chsten Scavenge Vorgang zur Verf gung steht Dieser Vorgang ist in Abbildung 3 11 grafisch dargestellt Vor dem Scavenge Vorgang Nach dem Scavenge Vorgang Erreichbare Objekte Allocate und Survivorbereich werden kopiert wurden vertauscht L Allocate Bereich L Survivor Bereich 2 Tenured Bereich Abbildung 3 11 Scavenge Vorgang Quelle eigene Darstellung In der Tenured Generation findet sich zudem ein spezieller Bereich f r die Allokation von gro en Objekten gt 64KB die sogenannte Large Objec
143. e effiziente Analyse und Optimierung eines modellierten Systems erm glicht Nicht zuletzt stellt die Modellierung externer Funktionen die innerhalb des Portals ausgef hrt werden eine weitere Forschungsm glichkeit dar Eine h ufig genutzte externe Portalfunktio nalit t ist beispielsweise die Integration von klassischen ERP Funktionen Mit den Ergebnis sen der derzeit am Lehrstuhl f r Wirtschaftsinformatik der TU M nchen durchgef hrten Ar beit zur Performance Modellierung und Simulation von ERP Systemen und einem vereinheit lichten Modell k nnten so im Portal integrierte ERP Funktionen die ber den ABAP Applikationsserver ausgef hrt werden modelliert werden Fazit 191 Die bis dato dargestellten Forschungsm glichkeiten beziehen sich auf die Weiterentwicklung des erstellten Artefakts Weitere Untersuchungen k nnen zudem im Bereich der Evaluation des Performance Modells erfolgen Die in dieser Arbeit durchgef hrte Demonstration und Evaluation basiert auf einem f r eine Schulungsumgebung typischen Workload Ergebnisse zu anderen Lastmustern w rden zus tzlichen Aufschluss ber die Aussagekraft des in dieser Arbeit entwickelten Performance Modells geben und dessen Einsatzm glichkeiten spezifizie ren Literaturverzeichnis 192 Literaturverzeichnis Alisch K 2004 Gabler Wirtschaftslexikon die ganze Welt der Wirtschaft Betriebswirtschaft Volkswirtschaft Recht Steuern 16 vollst berarb u aktual Aufl Gabler W
144. e schematische Darstellung des LQN Modells Aus Gr nden der bersichtlichkeit werden die CPU Ressourcen die an die Servertasks gekoppelt sind nicht dargestellt Der Benutzer CPU werden unbegrenzte Kapazit ten zugewiesen um einen Ein fluss auf die Benutzertasks zu vermeiden da lediglich das Serververhalten betrachtet werden soll Die Applikations und Persistenzschicht verf gen jeweils ber eine eigene CPU Ressource da die Messungen an einer dreistufigen Systeminstallation durchgef hrt werden vgl Kapitel 2 1 1 1 Zudem werden nur repr sentative Anfragen zwischen zwei Entries dar gestellt die die m glichen Pfade vom Benutzer Interaktionsschritt bis hin zur Datenbank komponente verdeutlichen sollen Die abgebildeten Komponenten zur Steuerung der GC Aktivit t werden erst im zweiten Schritt bei der Analyse des GC Verhaltens eingesetzt LON Modell 133 Interaktionsschritte GC Aktivitat Benutzer GC Intervall TT Benutzer f Java Server GC Dauer Check u 0 u Dauer Datenbankaufrufe Tabellen Sperrverwaltung puffer SQL Select SQL Enqueue BE Abfrage Abfrage Server Se H SS A SQL Select Tabellen Lesesperre SQL Schreibsperre Ra Abfrage puffer Sperrbereich Abfrage Sperrbereich E 7 Ki wd Sperrbereich x Datenbank N SQL Abfrage A SQL Abfrage SQL Abfrage Datenbank Legende AN Task L eg Entry Aktivit t gt Synchroner Auf
145. echnersystemen wird in Kapitel 2 3 3 1 erl utert Nach Finkelstein 1984 ist Messung als der Prozess definiert der Zahlen oder Symbole den Attributen von Entit ten in der realen Welt unter Einhaltung klar definierter Regeln zuordnet Eine Entit t kann ein Objekt wie beispielsweise eine Person oder eine Software Spezifikation aber auch ein Ereignis wie zum Beispiel die Testphase eines Softwareprojekts sein Ein Attribut ist eine Eigenschaft der Entit t wie zum Beispiel die Gr e H he einer Person oder die Dauer der Testphase Theoretische Grundlagen 25 Bortz D ring 1995 65 definieren Messen als eine Zuordnung von Zahlen zu Objekten oder Ereignissen sofern diese Zuordnung eine homomorphe Abbildung eines empirischen Relativ in ein numerisches Relativ ist Daf r sind folgende Aspekte von Bedeutung Es erfolgt eine Zuordnung von Zahlen zu Merkmalen von Objekten den Merkmals tr gern Die Relationen der Merkmalstr ger bez glich der Merkmalsauspr gung sollen durch die ihnen zugeordneten Zahlen wiedergegeben werden Der Messvorgang stellt die Konstruktion eines numerischen Relativs zu einem gege benen empirischen Relativ dar Ein empirisches Relativ besteht aus einer Menge von n Objekten zwischen denen eine oder mehrere Beziehungen bestehen Relationssystem Die Zuordnung des numerischen zum em pirischen Relativ ist homomorph das hei t die Beziehung der empirischen Objekte ist in der numerisch
146. eeeereaees 84 Abbildung 3 1 ele Take ua a in 85 Abbildung 3 17 Architektur des zentralen Monitoringsystems CEN sss ssssessseessesessssesee 86 Abbildung 3 18 Zuordnung der Leistungsdaten zu logischen Arbeitsschritten 87 Abbildung 3 19 Granularit t der DSR Datens tze und Performance Traces 88 Abbildung 3 20 Anzeige des funktionalen Trace nennen 89 Abbildung 3 21 Export der Performance Daten zur externen Analyse iceceeeereeeeeeees 90 Abbildung 3 22 SQL Trace einer bestimmten Transaktions ID eeeneee 91 Abbildung 3 23 Aktivierung des HTTP Access Trace inklusive Antwortzeiten 92 Abbildung 3 24 Pattern Modeling and Analysis Tool 94 Abbildung 3 25 Garbage Collector and Memory Analvzer 94 Abbildung 3 26 Exemplarische mpstat Ausgabe 97 Abbildung 3 27 Funktionsprinzip der Active Memory Exvpansaion 98 Abbildung 3 28 Exemplarische vmstat Ausgabe 99 Abbildung 3 29 Exemplarische ostat Ausgabe 100 Abbildung 4 1 Systemverhalten bei zunehmender CPU Zeit pro Interaktionsschritt 104 Abbildung 4 2 Erwartetes Systemverhalten nach der Warteschlangentheorie 105 Abbildung 4 3 LQN Modellierung der Benutzer 0 ccceeccecccecsceceteceeeceeeeeeseeeeaeeneeeeeeenseees 109 Abbildung 4 4 Multiplizit t und Repltzterumng en 111 Abbildung 4 5 Vorgeschaltete Dispatcher Einheit zum Verteilen der Anfragen 112 A
147. eigen auch in diesem Szenario keine wesentlichen Ver nderungen und best tigen somit die Unabh ngigkeit von Benutzeranzahl und CPU Zeit sowie der Anzahl an zugewiesenen virtuellen Kernen Simulation und Evaluation 158 5 5 5 3 Antwortzeiten 1500s T S 1200s P 3 2 cz 900s lt x 2 E 2 600s E o ZC 2 300s gt E 3 3 J Os 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer u 268 708 279 677 298 704 436 410 615 527 974 425 1412 108 o 17 344 17 306 19 023 29 224 45 460 114 731 181 838 Cy 0 065 0 062 0 064 0 067 0 074 0 118 0 129 Median 262 590 273 654 292 399 426 057 599 423 933 781 1347 691 Q1 25 260 603 271 829 290 012 423 087 594 802 922 119 1329 207 Q3 75 270 573 280 985 300 730 439 529 620 379 986 671 1431 516 Abbildung 5 17 Kumulierte Antwortzeiten in Sekunden Szenario 2 Quelle eigene Darstellung Die Antwortzeiten verzeichnen in diesem Szenario siehe Abbildung 5 17 einen deutlich h heren Anstieg als bei den Vergleichswerten in Szenario 1 Die Ursachen f r den erh hten Anstieg lassen sich nicht auf eine einzelne Einflussgr e beschr nken vielmehr k nnen in diesem Bereich die Auswirkungen allgemeiner Ressourcen Engp sse erkannt werden Neben den bereits im ersten Szenario festgestellten Ursachen f r den Anstieg der Antwortzeiten treten in diesem Szenario zunehmende Verdr ngungen sowie Invalidie rungen im Tabellenpuffer auf die in einer erh hten Anzahl von Datenb
148. eilungen des Ankunfts sowie des Bedienprozesses werden durch Buch staben abgek rzt und sind in folgender Tabelle aufgelistet M Exponentialverteilung M f r Markovian E Erlang Verteilung mit k Phasen Hp Hyper Exponential Verteilung mit Parameter k D Deterministische Verteilung G Allgemeine Verteilung unspezifiziert G Allgemeine Verteilung mit unabh ngigen Zufallsvariablen Tabelle 2 3 G ngige Verteilungen bei Warteschlangensystemen Quelle eigene Darstellung Bei der verk rzten Kendall Notation werden nur die ersten drei Parameter angegeben und die letzten drei Parameter mit oo oo 1 angenommen So beschreibt zum Beispiel die Notation M M 1 das Warteschlangensystem M M 1 00 00 1 Eine Reihe von Zufallszahlen und Parametern werden f r die Analyse von Warteschlangen systemen verwendet und sind in Abbildung 2 14 anschaulich dargestellt Vorherige Beginn der Ende der Ankunft Ankunft Bedienzeit Bedienzeit E ue 5 Zeit ee Abbildung 2 14 Zufallszahlen und Parameter in einem Warteschlangensystem Quelle eigene Darstellung T beschreibt hierbei den Ankunftszeitenabstand A 1 E T E f r Erwartungswert die durchschnittliche Ankunftsrate S die Bedienzeit u 1 E S die durchschnittliche Bedienra te f r eine Bedieneinheit m die Anzahl der Bedienstationen Server N die Anzahl an Ele Theoretische Grundlagen 47 menten im System Ng die Anzahl an Elementen in der Warteschlange N
149. ein entsprechendes Untermodell auszutauschen 2 1 1 2 Installationsvarianten Gr ere SAP Systeme die bis zu mehrere tausend Benutzer bedienen werden meist als drei stufige Systeme konfiguriert Dabei werden die Datenbank Applikations und Pr sentations schicht jeweils auf unterschiedlichen Rechnern installiert Die 3 Schicht Installation bietet die gr te Flexibilit t die Server Systeme dynamisch an ver nderte Nutzungsbedingungen anzu passen da der Anwendungsschicht ohne gr eren Aufwand weitere Server hinzugef gt wer den k nnen und das System daher sehr gut skaliert Zus tzlich ist es m glich durch Daten bank Cluster die Datenbank auf mehrere Server zu verteilen Zweistufige Systeme bei denen zwar die Pr sentationsschicht entkoppelt ist die Applikati ons sowie Datenbankschicht aber auf einem Server liegen findet man h ufig bei kleineren SAP Systemen die oft als Entwicklungs Schulungs oder Testsysteme eingesetzt werden Einstufige Systeme werden in der Praxis fast ausschlie lich zu Demonstrationszwecken ein gesetzt Bei bestimmten Testf llen kann es zudem n tzlich sein keine zus tzlichen bertra gungsmedien beachten zu m ssen Abbildung 2 4 zeigt die verschiedenen Installationsvarianten in Bezug auf die 3 Schicht Architektur von SAP Systemen Theoretische Grundlagen 22 1 stufige Ep Installation 2 stufige ed K Installation S SO 3 stufige Car lt Installation YR Ss Datenbank EH E K
150. eine ansteigende Vielfalt Obaidat Boudriga 2010 Eine Not wendigkeit die dabei entsteht ist die Auswahl eines bestimmten Systems f r eine bestimmte Anforderung Die richtige Auswahl ist dabei abh ngig von der Art der Anforderung Eine Systemarchitektur die sich f r eine bestimmte Klasse von Anforderungen eignet muss nicht zwangsl ufig f r alle anderen Problemklassen geeignet sein Hu Gorton 1997 Mit der Auswahl einer bestimmten Architektur stellen sich zugleich Fragen ber die Leis tungsf higkeit des Systems Wie wird sich die Leistungskurve des Systems bei zunehmender Last entwickeln Welche Kriterien sollen f r die Leistungsmessung herangezogen werden Welche Techniken und technischen Hilfsmittel k nnen f r die Leistungsbeurteilung verwen det werden All diese Fragen fallen in das Gebiet der Performance Evaluation von Computer systemen Laut Ferrari 1986 datiert die erste wissenschaftliche Erw hnung von Performance Evaluation von Computersystemen auf eine Arbeit von Alan Scherr 1965 zur ck Seitdem hat sich diese Fragestellung zu einer eigenen Disziplin entwickelt wobei neben einer Vielzahl von wissenschaftlichen Arbeiten auch diverse B cher erschienen sind wie zum Beispiel Jain 1991 oder Sauer Chandy 1981 In der Literatur finden sich verschiedene Definitionen zu dem Begriff Performance zum Bei spiel Doherty 1970 Graham 1975 Allgemein kann die Performance eines Systems mit der F higkeit eine bestimmte O
151. eines Portalsystems f llt auf dass die Werte auch nach einer ausreichenden Einschwingzeit sowie etlichen Messwiederholungen keinen konstanten Wert erreichen Jehle 2010 168f In der Literatur werden hierf r verschiedene Gr nde an gegeben beispielsweise Page Faults Parupudi Winograd 1972 oder Multitasking Mechanismen Lilja 2000 45 Zusammenfassend lassen sich die Ursachen mit nicht vorher sagbaren Einfl ssen auf Systemebene beschreiben Eine explizite Steuerung dieser Aktivit ten f r die Leistungsmessung w rde starke Ver nderungen am System erfordern und in der Folge das untersuchende Objekt stark beeinflussen Tanenbaum 2006 Diese Beeinflussung w rde wiederum eine bertragbarkeit der erhobenen Messwerte in Frage stellen Baumgarten Siegert 2007 Daher stehen keine nutzbaren Mittel zur Verf gung die Effekte Simulation und Evaluation 150 der Oszillation der Messwerte zu verhindern Nur durch die Anwendung statistischer Verfah ren kann dieser Effekt gemindert werden Zur Veranschaulichung sei der Lastschrittaufruf aus Kapitel 4 2 6 n her betrachtet Wie be reits dargestellt wurde ein Lastschritt Aufruf der Portalinformationen nach 5 Einschwing durchl ufen automatisiert 3000 Mal aufgerufen Bei dem Vergleich zwischen den ersten 30 und den letzten 30 Wiederholungen fallt auf dass keine Stabilisierung der Bearbeitungszeit auftritt siehe Abbildung 5 9 Folglich ist auch keine schwankungs rmere Antwortzeit m g
152. el eines Garbage Collector Laufs in der Logdatei Quelle eigene Darstellung Betrachtet man die Speicherverwaltung aus der Sicht der Performance Analyse einer Java Applikation unabh ngig von dem Workload und der Laufzeitkonfiguration k nnen drei Per formance Indikatoren unterschieden werden Cheng 2008 Framework Space Der Framework Space benennt die Gr e des freien Speichers der der JVM nach dem Starten f r Applikationen zur Verf gung steht User Session Space Der User Session Space gibt die Menge an Speicher an die von einem eingeloggten inaktiven Benutzer allokiert wurde und nicht von anderen Benut zern geteilt wird Processing Space pro Benutzerinteraktion Der Processing Space stellt den dynami schen Anteil an Speicherverbrauch dar und errechnet sich aus der durchschnittlichen Menge an gesammelten Garbage Speicher pro Benutzerinteraktion Abbildung 3 13 stellt den Messvorgang einer Java Applikation bei einem Mehr Benutzer Lasttest dar Damit die gemessenen Daten nicht verfalscht werden wird ein voller GC Lauf Mark Sweep Compact im Vorfeld durchgef hrt Der Framework Space kann nach dem Starten und Warm Up der JVM festgestellt werden Der User Session Space errechnet sich mittels M FrameworkSpace UserSessionSpace wobei Mdie Speichergr e und n die Anzahl der eingeloggten Benutzer darstellen Der Pro cessing Space errechnet sich mittels Systemarchitektur und Monitoring 80 Gesam
153. eld gepuffert Bei dem zweiten Beispiel unten rechts werden n 2 Schl sselfelder ausgewertet das dritte Schl sselfeld des Prim rschl ssels allerdings au er Acht gelas sen Dadurch l sst sich je nach Tabellenart und verwendung Gr e Art der Zugriffe etc der Pufferbereich auf ein sinnvolles Ma beschr nken Sobald ein Eintrag ge ndert wird m ssen die entsprechenden Eintr ge in den Tabellenpuffern der einzelnen Java Instanzen aktualisiert werden Dieser Vorgang wird als Puffersynchroni sierung bezeichnet Die Invalidierung veralteter Eintr ge geschieht je nach Art der Tabellen pufferung f r die entsprechende Region Systemarchitektur und Monitoring 75 Schl ssel 1 Schl ssel 2 Schl ssel 3 Schl ssel 1 Schl ssel 2 Schl ssel 3 e Je Je Vollstandige Pufferung Schl ssel 1 Schl ssel 2 Schl ssel 3 C FE wmo f o wmo fo o o mo f f mo f o Free Generische Pufferung mit einem Generische Pufferung mit zwei Schl sselfeld Schl sselfeldern Abbildung 3 8 Arten der Tabellenpufferung Ouelle eigene Darstellung Die einzelnen Objekte im Tabellenpuffer k nnen ber den Netweaver Administrator eingese hen siehe Abbildung 3 9 oder ber die Aktivierung der Puffer Traces aufgezeichnet werden gt Buffer Administration e le gt portalsim2 informatiktu muenchen de Estergege 333227250 ee portalsim2 P33 SAPP33DB Startup Reset Reinstall
154. elle 4 1 Einflussgr en auf die Antwortzeit in einem SAP Netweaver Portal System Quelle eigene Darstellung 4 2 Modellierung und Parametrisierung der Systemkomponenten Nachdem die theoretischen Grundlagen erarbeitet und die Dokumentation zur Systemarchi tektur sowie verf gbare Monitore analysiert wurden konnten die einzelnen Komponenten die das Verhalten des Gesamtsystems beschreiben modelliert werden In einer ersten Iteration wurden folgende Elemente identifiziert Benutzertyp abh ngig von den durchgef hrten Anfragen sowie der Denkzeit Lastschritt somit die Anfrage bzw der Task selbst Sperr Objekte Sperrtabellen Verwaltung im Enqueue Server Tabellenpufferung Pufferung von Daten im Hauptspeicher JDBC Call Durchf hrung eines Datenbankzugriffs LQN Modell 107 Datenbank wird als Black Box betrachtet In einer zweiten Iteration wurde das Verhalten des Garbage Collectors mittels einer logischen Garbage Collector Komponente modelliert Wie in Kapitel 6 noch gezeigt wird nimmt dieser im Hochlastbereich einen erheblichen Einfluss auf das Leistungsverhalten des Systems Durch das Hinzunehmen der GC Parameter im Modell konnte der Einfluss erh hter GC Aktivit ten auf die Antwortzeit getestet werden Nachstehend werden die einzelnen Komponenten des LQN Modells vorgestellt und dabei auf die Anforderungen Umsetzung und Parametrisierung eingegangen 4 2 1 Benutzer Wie bereits in der Einleitun
155. em anderen durchf hrt belegt jeder Benutzer maximal einen Applikations Thread Sieht man von evtl Denkzeiten ab bei denen kein Applikations Thread belegt wird gilt die genannte 1 zu 1 Beziehung und somit die Aus sage dass bei mehr als 80 Benutzern der Bedarf an parallelen Applikations Threads h her ist als die gegebene Multiplizit t von 80 Das soeben beschriebene Verhalten wird von der Simulation erfasst sodass ab 80 Benutzern ein deutlich h herer Anstieg zu verzeichnen ist Im Bereich zwischen 100 und 120 Benutzern nimmt die Simulationsgenauigkeit jedoch leicht ab Der Grund f r die zunehmende Ungenau igkeit kann zum einen einer nicht auszuschlie enden wachsenden Ungenauigkeit des model lierten Sperrmanagements geschuldet sein zum anderen an u eren nicht modellierten Sys temeinfl ssen liegen die trotz ausreichender Systemressourcen auftreten F r eine vollst ndige Betrachtung seien auch die verbleibenden Modellkomponenten ange sprochen die in diesem Szenario keinen nennenswerten Einfluss auf das Leistungsverhalten zeigen Die CPU Ressourcen sind wie bereits erw hnt nicht gekappt Daher entsteht in die sem Bereich kein Engpass Ebenfalls ist der f r die JVM zur Verf gung gestellte Hauptspei cher gr er als notwendig Auch die Gr e des Tabellenpuffers ist ausreichend sodass sich die Trefferrate mit einer zu nehmenden Anzahl an Benutzern nicht reduziert Der stetige Wert von knapp 99 Prozent ent spricht dem in
156. en zum anderen erleichtert die Automatisierung im Regelfall die Durchf hrung der Lastschritte Die Herausforderung liegt dabei vor allem bei der Interaktion mit dem zu untersuchenden Objekt da auf dynamisch generierte Inhalte entsprechend reagiert werden muss Wassermann et al 2008 Bei der Durchf hrung der Messungen ist darauf zu achten dass der Betrieb des Portalsystems durch zus tzliche Programme beispielsweise zur Generierung der Last oder zum Aufzeichnen der Leistungsdaten nicht beeinflusst bzw nur durch ressourcenschonende Werkzeuge beo bachtet wird vgl bspw intrusives Monitoring auf Betriebssystemebene in Kapitel 3 3 Da die in dieser Arbeit durchgef hrte Interaktion mit dem Portalsystem ausschlie lich ber die HTTP Schnittstelle erfolgt kann die Applikation auf der Pr sentations bzw Benutzer ebene d h der Web Browser durch ein Programm ersetzt werden das die manuelle Benutze rinterkation mittels vorkonfigurierter Interaktionsschritte nachbildet Dabei werden die An fragen k nstlich generiert und ein entsprechender http Request an den Web Server in diesem Falle das Portalsystem gesendet Der technische Aufwand zur Implementierung eines auto matischen Lastgenerators auf HTTP Basis ist verh ltnism ig gering und f hrt daher zu einer nahezu un berschaubaren Menge an angebotener Software Hower 2009 Die verschiedenen Werkzeuge unterscheiden sich jedoch in ihrer Zielsetzung Funktionalit t und Konfigurierbarke
157. en Anfrage First Request Zeitstempel der ersten Anfrage die von diesem Benutzer ge sendet wurde Last Request Zeitstempel der letzten Anfrage die von diesem Benutzer ge sendet wurde Threads Thread Der Name des Threads User Benutzer ID Request Name der Anfrage Req Time Bereits investierte Bearbeitungszeit f r diese Anfrage ms Component Der Name der derzeit ausgef hrten Komponente Comp Time Bearbeitungszeit innerhalb dieser Komponente ms Action Derzeit durchgef hrte Aktion Start Time Zeitstempel der ersten Anfrage in diesem Thread Sum Active Time Aufsummierte Bearbeitungszeiten aller Anfragen in diesem Thread Tabelle 3 9 Java Application Response Time Measurement JARM Daten Ouelle eigene Darstellung in Anlehnung an SAP 2011e Die zur Verf gung gestellte JARM Ansicht siehe Abbildung 3 15 kann jedoch nur als ber sicht dienen da Durchschnittswerte berechnet und ausgegeben werden F r die Performance Analyse von Portalen ist sie allerdings hilfreich um einen berblick ber das Leistungsver halten zu erhalten Speziell bei der Durchf hrung der Performance Messungen konnten damit die Threads sowie die gesendeten Benutzeranfragen berwacht und potentielle Abbr che schnell erkannt werden Erst wenn die berpr fung dieser aggregierten Daten keine Anoma lien aufzeigten wurden die erhobenen Leistungsdaten im Detail untersucht Systemarchitektur und Monitoring 84 E Visual Administrator P99 Server
158. en Anzahl an simultan agierenden Benutzern Diese Mehr Benutzer Lasttests k nnen gestaffelt durchge f hrt werden indem die Anzahl der Benutzer mit jedem Schritt erh ht wird sodass das Sys tem schrittweise unter einer h heren Last steht Die einzelnen Messergebnisse k nnen an schlie end in ein Diagramm eingetragen werden um den Verlauf aufzuzeigen Unter der selbst evidenten Annahme dass eine zunehmende Anzahl an simultan agierenden Benutzern die Systemlast ansteigen l sst kann somit beispielsweise der Anstieg der verwendeten Sys temressourcen beobachtet werden Dieser wird grunds tzlich in einen exponentiellen linearen und logarithmischen Verlauf kategorisiert je nachdem ob die Systemlast zunehmend gleich bleibend oder abnehmend ansteigt Der Hauptzweck von Mehr Benutzer Lasttests und Simulationen ist die Analyse der Skalier barkeit des Systems bei simultan durchgef hrten Benutzer Tasks Hierbei k nnen sich die durchgef hrten Operationen der Benutzer unterscheiden oder lediglich die Anzahl der Benut zer variiert werden ohne die Art und Reihenfolge der durchgef hrten Benutzeranfragen zu ver ndern Letzteres wurde f r die Fallstudie in dieser Arbeit verwendet da der Workload den Inhalten einer SAP Netweaver Portal Schulung entspricht die von einer gewissen Anzahl von Studenten durchgef hrt wird wobei jeder Student dieselben Aufgaben durchf hrt Die Tatsache dass sich die Systemlast nur in einer Dimension ver ndert n mli
159. en Forschung angeh rende gestaltungsorientierte Forschung ihre Zweckdienlichkeit aus dem Umfeld Environ ment Die Elemente des Umfelds werden in Menschen People Organisationen Orga nizations und Technologie Technology untergliedert die sich wiederum gegenseitig beeinflussen vgl bspw Kremar 2010 28 Der gestaltungsorientierte Forschungsprozess erfolgt iterativ zwischen der Entwicklung Develop Build und der Bewertung Jus Einleitung 10 tify Evaluate des Artefakts Hevner et al 2004 79 und erm glicht somit eine wiederholte berpr fung bzw Verbesserung des Artefakts Bei der Entwicklung des Artefakts wird auf etablierte Theorien Methoden und Modelle zur ckgegriffen die unter dem Begriff Wissens basis Knowledge Base subsumiert sind Hevner et al 2004 80 Dadurch wird die Strin genz Rigor des Vorgehens sowie der entwickelten L sungen sichergestellt und der Be zugsrahmen definiert Aus den Erfahrungen ber das entwickelte Artefakt und einem besseren Verst ndnis f r den Problemraum kann wiederum neues Wissen an die Wissensbasis zur ck gef hrt werden Unter Ber cksichtigung des Design Science Frameworks von Hevner et al 2004 folgt diese Arbeit dem Paradigma der gestaltungsorientierten Forschung Es wird eine aktuelle Heraus forderung im Unternehmensumfeld Business Need adressiert deren Problemstellung und Motivation bereits in Kapitel 1 1 dargestellt wurde
160. en Struktur so abgebildet dass die Eigenschaften erhalten bleiben Strukturgleich heit Dieser Zusammenhang ist in Abbildung 2 7 zusammenfassend dargestellt Formale Welt Ein Wert des Attributes 1 von Einheit 1 ns Ein Wert des Attributes 1 a von Einheit 1 Reale Welt Attribut 1 Attribut 1 S ep Empirisches Numerisches Relativ Relativ Messung Tr Abbildung 2 7 Relationssystem in der Messtheorie Quelle eigene Darstellung Die Regeln mit denen die Transformation der verschiedenen Attribute in numerische Werte durchgef hrt wird werden in einer Skala festgelegt Bortz D ring 1995 65 definieren eine Skala als ein empirisches Relativ ein numerisches Relativ und eine die beiden Relative verkn pfende homomorphe Abbildungsfunktion Die Messbarkeit eines Merkmals bzw die Konstruierbarkeit einer Skale ist an Bedingungen gekn pft Es gibt verschiedene Skalentypen die durch die jeweils auf ihnen zul ssigen Transformatio nen definiert werden Abh ngig von den zul ssigen Transformationen sind nur bestimmte statistische Berechnungsm glichkeiten anwendbar Die in Tabelle 2 1 aufgelisteten Skalenni veaus bauen aufeinander auf das hei t nachfolgend genannte Skalen beinhalten implizit auch alle Eigenschaften der vorher genannten Theoretische Grundlagen 26 Erlaubte Operationen Skalenniveau Eigenschaft 7 p z mathematisch stochastisch Nominalskala Reine Katego
161. en auf die Antwortzeiten von Benutzeranfragen erfasst und abge bildet werden k nnen wird zur Modellbildung die Auswahl sowie Granularit t der Kompo nenten nach folgenden Hauptkriterien getroffen LON Modell 106 1 Ist die Architektur der Komponente bekannt 2 Sind Performance Daten fiir die zu modellierende Komponente verfiigbar 3 Wie gro ist der Einfluss auf die Gesamtleistung des Systems Zur Beantwortung der Fragen wurde die Literatur siehe Kapitel 2 sowie die Systemdoku mentation siehe Kapitel 3 eingehend analysiert Die Identifikation der Objekte sowie der Einflussfaktoren dient als Grundlage f r die Modellierung und Parametrisierung der System komponenten Tabelle 4 1 zeigt eine bersicht der Auswertung Objekt Architektur Monitor Einflussfaktoren Kapitel Kapitel Client 3 1 1 n a Art der Anfragen Anzahl Denkzeit Lastschritt 3 1 1 3 2 2 Dispatching Zeit Task 3 1 2 3 2 3 Wartezeit 3 3 Bearbeitungszeit Abbr che durch Timeouts Datenbankaufrufe falls zutreffend Datenbank wird als 3 2 4 Bearbeitungszeit Aufrufe Black Bos 3 3 Sperrwartezeiten falls zutreffend betrachtet Tabellenpuffer falls zutreffend Tabellenpuffer 3 1 4 3 1 4 Verdr ngungen Invalidierungen Sperrobjekte 3 1 3 3 1 3 Wartezeit beim Enqueue Server Wartezeit bei blockierten Elementen Garbage 3 1 5 3 2 6 GC Dauer Collector GC 33 GC Intervall Tab
162. en mit dem Portal implementiert Die Wrapper Klasse iMacrosWrapper erm glicht dabei die Kommunikation mit dem iMacros Browser F r die Ausf hrung der Interaktions schritte sind hier unterst tzende Methoden implementiert die die Navigation durch den Portal Content Katalog die Steuerung der Kontextmen s sowie das Erkennen von Textausgaben und Bildern realisieren Zudem wird hier der iMacros Browser initiali siert und beendet UserBot Die Klasse UserBot implementiert das Interface Runable der Klasse Ihread Jede Instanz dieser Klasse repr sentiert einen Portal Benutzer bzw Schu lungsteilnehmer ObserverAgent Auch diese Klasse ist ein Singleton und Bestandteil des Observer Patterns Gamma et al 1995 Sie beobachtet ein UserBot Objekt und benachrich tigt den iMacrosTestDriver damit dieser die nachfolgenden Schritte einleiten kann CaseStudyLabs iMacrosPortalHandle_Labs Als Case Study Labs werden die einzel nen Tage der Portal Schulung bezeichnet Jede bungseinheit entspricht einem Lab In der Klasse CaseStudyLabs sind Funktionen f r die Initialisierung und Ausf h rung der Interaktionsschritte implementiert Die Klasse iMacrosPortalHandle_Labs erweitert die Superklasse CaseStudyLabs und beinhaltet die Implementierung der Makroinitialisierung sowie ausf hrung Das Interface iMacrosTestDriver_Interface definiert die ben tigten Methoden bzw Parame
163. en wahrscheinlichkeit Die Berechnung der Trefferquote kann nur gesch tzt werden Sperr Wartezeit beim En Implizit ch management queue Server und Modelliertes Lese Schreibsperren blockierten Elemen konzept bildet das Verhalten der Sperr ten objekte nach Garbage GC Dauer Zus tzliche GC N Collector GC GC Intervall Komponente fiir Das dynamische GC Verhalten ist eine statische Para nicht exakt abbildbar Die GC metrisierung Komponenten erm glichen allerdings eine statische Parametrisierung CPU System System Overhead Ressource A Ressource Prozessor Task Die gemessene CPU Nutzung folgt den Annahmen der Warteschlangentheorie bis in den Hochlastbereich dann aller dings nimmt der zunehmende System Overhead Einfluss auf die CPU Nutzung der Benutzer Prozesse Tabelle 6 1 Bewertung der Ergebnisse nach Modellkomponenten und Einflussfaktoren Quelle eigene Darstellung Fazit 186 Die Benutzer Komponente siehe Kapitel 4 2 1 stellt den Referenz Task dar und initiiert die Aufrufe der Lastschritte Eventuelle Ressourcenengp sse auf der Pr sentationsebene wurden in der vorgestellten Arbeit nicht behandelt k nnen aber durch eine entsprechende Modellie rung und Parametrisierung der Benutzer CPU eingef hrt werden Zudem ist es m glich ver schiedene Benutzertypen sowie deren Anzahl und optionale Denkzeiten zu definieren Die identifizierten Einflussfaktoren konnten somit ohne bekannte Einschr nkungen umge
164. enes Warteschlangensystem Die Warteschlangenkapazit t gibt an wie viele Elemente in einer Warteposition fest gehalten werden k nnen Auch hier kann im Modell eine unbegrenzte Kapazit t ange nommen werden Die Populationsgr e der eingehenden Elemente kann entweder begrenzt geschlosse nes System oder unbegrenzt sein offenes System Die Bedienstrategie auch Warteschlangenstrategie genannt legt fest in welche Rei henfolge die anstehenden Elemente abgearbeitet werden Die wohl g ngigste Be dienstrategie ist First Come First Served FCFS Hierbei wird das Element zuerst ab gearbeitet das die k rzeste Verweildauer in der Warteschlange aufweist Andere Strategien sind Last Come First Served LCFS Service in Random Order SIRO Last Come First Served with Preempt and Resume LCFS PR oder Round Robin Verfahren RR Bei letzterem kann jedes Element nur f r eine bestimmte Zeit die Be dieneinheit in Anspruch nehmen Falls mehr Zeit f r die Abfertigung ben tigt wird muss sich das Element wiederholt in die Warteschlange einreihen F r die Definition eines Warteschlangensystems m ssen alle sechs Parameter definiert sein Die Kendall Notation Kendall 1951 beschreibt diese in der Reihenfolge Theoretische Grundlagen 46 A S m B K SD wobei A der Ankunftsprozess S der Bedienprozess m die Anzahl der Bedieneinheiten B die Warteraumkapazit t K die Populationsgr e und SD die Bedienstrategie sind Die g ngigsten Vert
165. ennsnensnenennnnne nennen 51 Abbildung 2 21 Ablauf eines weitergeleiteten Aufrufs ensennennnsennennenennnn 52 Abbildung 2 22 LONS Meta Modell 54 Abbildung 2 23 Metamodell von Parasol aa ae ar 55 Abbildung 2 24 KapazitatsplanungsproZess cccccccescessceesceceseceeceseeesacecsaecnseeeeeeenseecueenes 63 Abbildung 3 1 Aufbau eines EE 65 Abbildung 3 2 Request Abarbeitung im Ditspatcher 68 Abbildungsverzeichnis VII Abbildung 3 3 Request Abarbeitung im Jova Server 70 Abbildung 3 4 Java Transaktionen 0 cceccccssceesseesseceecseeeeescecacecaecsenecescecsaeceaeceeseeeseeesaeenas 71 Abbildung 3 5 Struktur eines Sperrtabellen Eintrags nsennnennennnnennennnn 72 Abbildung 3 6 Anzeige der Sperreintr ge mittels SAP Konsole een 73 Abbildung 3 7 Tabellenpuffer im Java Server ProZess nn 74 Abbildung 3 8 Arten der Tabellenpufferung nennen 75 Abbildung 3 9 Anzeige der Tabellen Puffer nassen hex ea Seate aeeiaer ese 75 Abbildung 3 10 Aufbau des Heap Spechers nennen 77 Abbildung 3 115Scavenge Vorzane a nenn ae klin 78 Abbildung 3 12 Beispiel eines Garbage Collector Laufs in der Logdatei 79 Abbildung 3 13 Messverfahren bei einem Mehrbenutzer Lasttest einer Java Applikation 80 Abbildung 3 14 Monitoring Werkzeuge im SAP Netweaver AS Java ueneeneneeen 81 Abbildung 3 15 Komponentenansicht der JARM Daten eecsesseeeeceeeceeeeneeeeeee
166. er Erweiterung der Warteschlangennetze den LQNs um genau solche komplexen Interaktionen beschreiben zu k nnen Ein LON Modell wird durch einen azyklischen Graph repr sentiert wobei Knoten Software Komponenten und Hardware Ger te darstellen und Pfeile Service Anfragen symbolisieren siehe Abbildung 2 15 Die Tasks in LQN Modellen werden in drei Kategorien unterteilt Reine Clients Reine Clients auch als Referenz Tasks bezeichnet da sie das System antreiben k nnen nur Nachrichten bzw Anfragen senden Aktive Server Aktive Server k nnen Anfragen sowohl senden als auch empfangen Reine Server Reine Server k nnen lediglich Anfragen empfangen Theoretische Grundlagen 48 Reine Clients Referenz Tasks Aktiver Server Reine Server Abbildung 2 15 Beispielhaftes LQN Modell Quelle eigene Darstellung Die Kategorie der aktiven Server zeigt bereits einen der Hauptunterschiede zwischen Warte schlangenmodellen und LQN Modellen da sie Anfragen sowohl empfangen als auch senden k nnen und somit zu Clients weiterer Server werden k nnen An dieser Stelle sei zudem er w hnt dass der Begriff geschichtet bei LQN keine strikte Schichtung impliziert sondern Tasks durchaus andere Tasks aus derselben Schicht bzw Ebene aufrufen oder Schichten berspringen k nnen Petriu Shousha Jalnapurkar 2000 2 5 1 Komponenten von LON Modellen In diesem Kapitel werden die einzelnen Komponenten von LQN Modellen wie s
167. er anmelden 1 1 X 1 Benutzer l schen X 2 Gruppen l schen X 3 Ordner l schen X 4 Benutzer abmelden 1 14 Tabelle 7 1 Vollst ndige Transkription der Schulungsinhalte nach Funktionen Ouelle Jehle 2010
168. erbose gc Informationen zum Verhalten des Garbage Collectors protokolliert werden Die Daten werden standardm ig in die Server Log Datei std_server out geschrieben die unter usr sap lt SID gt JC work zu finden ist Die Log Datei kann sp ter ber diverse Analysepro gramme die von IBM bereitgestellt werden ausgewertet werden Ebenso ist es m glich die GC Daten grafisch darzustellen Zwei der Analyseprogramme sind bei den Garbage Collector Analysen in dieser Arbeit zum Einsatz gekommen und sollen in diesem Kapitel kurz vorgestellt werden Die zwei vorgestellten Hilfsprogramme geben Aufschluss ber den GC Overhead und dessen Einfluss auf die Bearbeitungszeit und somit Gesamtantwortzeit der durchgef hrten Tasks Speziell im Hochlastbereich spielt das Verhalten des Garbage Collectors eine entscheidende Rolle da eine zunehmende Anzahl an GC Pausen immer weniger Ausf hrungszeit der Appli kationen zulassen Dies kann zu stark ansteigenden Antwortzeiten und im schlimmsten Falle zu einem sogenannten Java Resonanz Effekt bei dem die CPU Auslastung zwischen 0 und 100 Prozent oszillieren kann Cheng Morrison 2007 Oracle 2011 f hren Pattern Modeling and Analysis Tool Das Pattern Modeling and Analysis Tool for IBM Java Garbage Collector PMAT IBM 2011g ist ein Java Programm das die Protokolldatei mit den detaillierten GC Daten einliest Dabei werden folgende Daten ber cksichtigt Java Heap Gr e Java Heap Verbrau
169. ereitungen e Login Navigation Personalisierung Men e Inhaltsverwaltung e Fortgeschrittene Inhaltsverwaltung e Kollaboration e ffentliche Dokumente Versionierung e Benutzerverwaltung und Sicherheit e Developer Studio Visual Composer Abbildung 5 1 Schulungsinhalte der SAP Netweaver Portal Fallstudie Ouelle eigene Darstellung in Anlehnung an Jehle 2010 63 1 Vorbereitungen F r die Durchf hrung der bungen am Portalsystem ist es notwen dig diverse Vorbereitungen zu treffen Dazu geh rt im ersten Schritt das Anlegen ei ner eigenen Gruppe der eine bestimmten Rolle zugewiesen wird damit entsprechende Zugriffsrechte erlangt werden Zudem wird ein Schulungsordner angelegt in dem die Schulungsteilnehmer ihre erstellten Objekte ablegen k nnen F r die Ausf hrung be stimmter Experimente wird weiterhin ein virtueller Schulungsraum kreiert Abschlie Simulation und Evaluation 136 Bend ben tigt jeder Schulungsteilnehmer ein eigenes Konto dem ebenfalls eine ent sprechende Rolle zugeordnet wird und mit einem initialen Password versehen wird Die Vorbereitungen werden vom Dozenten durchgef hrt und sind somit nicht Be standteil der bungen jedoch notwendig f r einen reibungslosen Ablauf der durchge f hrten Aktionen am Portal 2 Login Navigation Personalisierung Men An Tag 2 loggen sich die Schulungsteil nehmer zum ersten Mal mit dem vergebenen Initialpasswort an Daraufhin werden sie vom System aufgeforder
170. erfassung und auswertung gesammelt werden Die Qualit t der Daten ist f r die Parametrisierung der Modellkomponenten ausreichend wenngleich nicht immer eine nicht intrusive Monitoring L sung eingesetzt werden konnte Ebenso stellen die vorhandenen M glichkeiten zur Leistungsdatenerhebung eine Limitation bei der Auswahl der Granularit t dar diese gen gen jedoch den Anforderungen des in dieser Arbeit vorgestellten komponentenorientierten Ansatzes Eine bersicht der Komponenten Einflussfaktoren sowie M glichkeiten zur Datenerfassung wurde in Tabelle 4 1 dargestellt Die Beantwortung der Forschungsfrage 2 wie ein SAP Netweaver Portal System mittels LQN modelliert und parametrisiert werden kann wurde in Kapitel 4 behandelt Dabei wurden zu Beginn die Grundannahmen die sich direkt aus der Warteschlangentheorie ableiten darge stellt Sowohl die Erfahrungen in der Literatur zum Beispiel Cheng 2008 als auch die in dieser Arbeit erhobenen Leistungsdaten zeigen dass sich Warteschlangennetze f r die Model lierung eines SAP Netweaver Java Systems bis zu einem hohen Auslastungsgrad eignen Erst im Voll und berlastbereich bedingen u ere Einfl sse ein Systemverhalten das sich nicht vollst ndig mit den idealisierten Grundannahmen deckt Die Modellierung des Java Speichermanagements ist mit LON nur teilweise m glich Ein Ansatz zur statischen Model lierung wurde in dieser Arbeit vorgestellt der in bestimmten Situationen Vorteile gegen be
171. ert nicht mehr ben tigte Ob jekte im Heap Speicher die als Garbage bezeichnet werden und gibt sie frei sodass sie der JVM wieder zur Verf gung stehen Grunds tzlich f hrt dies zu einem Ausf hrungsstopp der laufenden Java Threads und der Garbage Collector erlangt die exklusive Kontrolle ber die virtuelle Maschine Dabei durchl uft der Garbage Collector folgende Phasen Mark W hrend der Markierungsphase werden alle Objekte die noch eine Referenz aufweisen markiert sodass der Rest in die Kategorie Garbage fallen muss Sweep W hrend der Sweep Phase werden die Speicherbereiche identifiziert die nicht mehr referenziert werden und zur erneuten Verwendung zur Verf gung gestellt Spei cherbereiche die kleiner als 512 Byte sind werden nicht in die Liste aufgenommen sondern erst dann wiederverwendet wenn benachbarte Objekte frei werden Compact Die Compaction Phase ist optional und kann eingesetzt werden um den Speicherbereich zu defragmentieren Da SAP das Generationenmodell wie in Abbildung 3 10 dargestellt im Heap Speicher der JVM empfiehlt wird bei einer Portalinstallation die IBM JVM Option Generational and Concurrent GC aktiviert Dieser GC Modus ist f r kurzlebige Objekte optimiert welches typisch f r transaktionsorientierte Applikationen ist und reduziert die Phase in der der Garbage Collector exklusiven Zugriff auf die JVM erh lt Systemarchitektur und Monitoring 78 Die Grundannahm
172. erver _flag gt spezifiziert Die Multiplizit t des Lesesperren Tasks wird auf infinit gesetzt da simultane Leseoperationen erlaubt sind Die Multiplizit t der Datenbank komponente entspricht der Anzahl an Datenbankverbindungen die vom gesamten System aufgebaut werden Die restlichen Komponenten werden mit einer Multiplizit t von 1 versehen 4 2 4 Tabellenpufferung Zur Erh hung der Performance werden f r Zugriffe auf bestimmte Datenbereiche Puffer ver wendet die im Hauptspeicher vorgehalten werden Ein Zugriff auf den Hauptspeicher erfolgt wesentlich schneller als der vergleichsweise langsame Datenbankzugriff Die zwei wesentli chen Merkmale bei der Tabellenpufferung die als Einflussgr en gewertet werden k nnen sind Verdr ngungen und Invalidierungen Verdr ngungen werden nach dem Least Recently Used Prinzip LRU Prinzip durchgef hrt Sollte ein Tabellenbereich neu gepuffert werden der Tabellenpuffer allerdings nicht mehr gen gend freien Speicher aufweisen m ssen ltere Pufferobjekte gel scht werden Dabei werden die Objekte zuerst aus dem Tabellenpuffer ge l scht die am l ngsten nicht mehr ben tigt wurden Invalidierungen treten immer dann ein wenn ein Datensatz ver ndert wird und somit der In halt des Puffers veraltet ist Die Verdr ngung bzw Invalidierung des gepufferten Tabellenbe reiches an sich verursacht keinen nennenswerten Ressourcenverbrauch der bei der n chsten Anfrage notwendig gewordene Datenbankzugr
173. es Tabellenpuffers ist daher nicht eindeutig m glich Allerdings wird in der Literatur erst eine Trefferrate von 95 Prozent oder h her als befriedigend Heiss Veirich Gratzl 2005 355 angesehen sodass bei einem gut konfigurierten Portalsys tem eine akkurate Parametrisierung m glich ist da die Weiterleitungswahrscheinlichkeit sehr gering gehalten werden kann Die bei der Analyse des Garbage Collectors in Kapitel 5 8 sowie bei der Modellierung in Ka pitel 4 2 6 eingef hrte GC Komponente erm glicht eine explizite Parametrisierung der Akti vit tsintensit t Dies war erforderlich da der implizite Anteil der GC Zeit in der Bearbei tungszeit aufgrund des berproportionalen Anstiegs der Speicherverwaltung im Hochlastbe reich nicht mehr ausreicht Wie bereits erl utert erm glicht der Modellierungsansatz zwar eine Untersuchung der Auswirkungen des Garbage Collectors bildet jedoch nicht das Verhal ten des Garbage Collectors dynamisch ab Diese Einschr nkung ist vor allem durch die be grenzten Mittel der LQN Modellierung sowie die fehlenden Detailkenntnisse ber die GC Implementierung bedingt Wie bereits dargestellt sind in der Literatur keine Konzepte zur expliziten Modellierung des Garbage Collectors mittels LQN pr sentiert worden Die GC Zeiten waren stets implizit in den Bearbeitungszeiten enthalten Die vorgestellte M glichkeit die Aktivit tsintensit t explizit zu parametrisieren stellt somit ein neuartiges Konzept bei der Analyse
174. eschlangenmodell nicht erfasst werden da sich eine konstante Netto Bearbeitungszeit unabh ngig von der Systemlast direkt von den Grundannahmen der LON Modell 104 Warteschlangentheorie ableitet Mit anderen Worten bleibt in einem Warteschlangen system die Zeit in der sich ein Element in einer Bedieneinheit aufh lt konstant und ist nicht von u eren Einfl ssen abh ngig Lediglich die Wartezeit bevor eine Bedien einheit frei wird und das Element prozessieren kann erh ht die Gesamtabarbeitungs zeit vgl Kapitel 2 4 CPU Last Antwortzeit ms Antwortzeit ms CPU Zeit pro Interaktionsschritt CPU Last Anzahl Benutzer Abbildung 4 1 Systemverhalten bei zunehmender CPU Zeit pro Interaktionsschritt Quelle eigene Darstellung 2 Die Nutzlast der CPU steigt linear zur Anzahl der simultan agierenden Benutzer an Die CPU Nutzlast steigt nur dann linear zur Anzahl der simultanen Benutzer an wenn das System die CPU Ressourcen verwenden kann und nicht aufgrund von anderweiti gen Einfl ssen derart besch ftigt ist dass nur ein Teil der vorhandenen CPU Ressourcen genutzt wird Die Antwortzeit w rde auch in diesem Falle berm ig schnell ansteigen Sollte das System ab einer gewissen Auslastung und somit ab einer gewissen Anzahl von simultanen Benutzern keine weiteren vorhandenen CPU Ressourcen nutzen w rde die Simulation des Warteschlangenmodells ab diesem Zeit punkt falsche Ergebnisse liefe
175. estellungen fal len in den Bereich der Performance Evaluation von Computersystemen Ein m glicher An satz ist dabei der Einsatz von modellbasierter Performance Simulation Einleitung 2 1 1 Problemstellung und Motivation der Arbeit Speziell im Unternehmensumfeld ist die Frage zur Leistungsfahigkeit der eingesetzten Com putersysteme von groBer Bedeutung Obwohl kein direkter Bezug zwischen der IT und ihrem erbrachten Wert hergestellt werden kann Kremar 2010 520 f hren unzureichende System ressourcen zu hohen Antwortzeiten und somit zu einer erh hten Prozessdurchlaufzeit w h rend im kontr ren Fall eine ungenaue und zu gro z gige Einsch tzung der ben tigten Sys temressourcen meist erh hte IT Investitionen nach sich zieht Die eingesetzten Gesch fts Applikationen in einem Unternehmen basieren oft auf verteilten mehrschichtigen Architekturen und beinhalten verschiedene Komponenten in einer heteroge nen Systemumgebung Die inh rente Komplexit t dieser Umgebung erschwert es Systemar chitekten die ben tigte Gr e und Kapazit t richtig einzusch tzen damit festgelegte Service Level Agreements SLAs eingehalten werden k nnen Kounev Buchmann 2003 Aufgrund der oft unzureichenden Integration der verschiedenen Gesch fts Applikationen der redundan ten Datenhaltung sowie der losen Kopplung von Einzelsystemen bietet sich der Einsatz eines unternehmensweiten integrierenden Systems an Dies wird von sogenannten Enterprise Re
176. et al 2010 Der in dieser Arbeit entwickelte Modellierungsansatz f r Lese und Schreibsperren war not wendig da in der LQN Modellierung kein Element f r einen derartigen Mechanismus vorge sehen ist vgl Franks 2011 Damit die in dieser Arbeit eingef hrte Modellierung mittels Ak tivit ten und Semaphore vereinfacht werden kann k nnte der Semaphor Task um eine ent sprechende Funktion erweitert werden Zudem bildet die tiefergehende Untersuchung der GC Modellierung eine weitere For schungsm glichkeit Wie sich aus der durchgef hrten Analyse des GC Einflusses schlie en l sst w rde eine detailliertere Abbildung des GC Verhaltens zu akkurateren Simulationser gebnissen im Hoch und berlastbereich f hren Ebenso stellt die Berechnung der Weiterlei tungswahrscheinlichkeit des Tabellenpuffers lediglich eine Ann herung der tats chlichen Trefferquote dar Eine weitergehende Forschungsarbeit k nnte in diesem Zusammenhang untersuchen ob eine Abbildung des Puffermechanismus nach dem Least Recently Used Prinzip mit LQN Mitteln durchf hrbar ist Im Bereich der Modellgenerierung w re die Entwicklung einer grafischen Anwendung hilf reich die aus den aufgezeichneten Performancedaten ein erstelltes Modell parametrisieren und die Eingabedatei des Simulators ausgeben bzw den Simulator damit starten kann In Kombination mit der Ausf hrung der Simulation und der Auswertung der Ergebnisse k nnte so ein Rahmenwerk geschaffen werden das di
177. etten Vorgang einer stochastischen Simulation kann man grob in folgende Teilschritte untergliedern Zu n chst wird ein Modell des realen Systems durch mathematische Mittel erstellt AnschlieBend stellt man die zufallsabh ngigen stochastischen Input Daten bereit Nachdem die Simulati onsexperimente durchgef hrt worden sind werden die Ergebnisse erfasst ausgewertet darge stellt und interpretiert Wenn n tig wird im letzten Schritt das Modell angepasst Die meisten Theoretische Grundlagen 43 Warteschlangensysteme und Markov Prozesse werden stochastisch modelliert Kolonko 2008 1f Rubinstein Kroese 2008 84 In einer statischen Simulation spielt der Faktor Zeit keine Rolle da sie nur einen Zeitpunkt betrachten und sozusagen eine Momentaufnahme darstellen Rubinstein Kroese 2008 84 Bei dem Einsatz der Monte Carlo Simulation k nnen die vorliegenden Objekte zum einen stochastischer Natur sein zum anderen kann man mit ihr auch deterministische Probleme 16 sen Sie stiitzt sich dabei auf wiederholten Stichproben und die statistische Analyse um die Ergebnisse zu berechnen Die Methode der Simulation bezieht sich stark auf Zufallsexperi mente somit ist ein spezifisches Ergebnis nicht im Voraus bekannt In diesem Kontext kann die Monte Carlo Simulation als eine sogenannte Was w re wenn Analyse angesehen werden Raychaudhuri 2008 Im Gegensatz zu den statischen Simulationsmodellen stellen dynamische Simulationsmodelle Systeme dar die
178. eue in der die Anfrage abgelegt wird ist Bestandteil des Cluster Managements Dieser Manager ist f r die Steuerung der Kommunikation zwischen Java Dispatcher und Java Server Prozess verantwortlich Auch hier existieren verschiedene Monitore die einen Status ber den derzeitigen Systemstand wiedergeben siehe Tabelle 3 4 Systemarchitektur und Monitoring 68 Monitor Beschreibung TotalSessionBytesReceived Summe der in dieser Sitzung erhaltenen Bytes TotalSessionBytesSent Summe der in dieser Sitzung gesendeten Bytes CurrrentSessionQueueSize Derzeitige Anzahl an Sessions in der Session Queue MaxSessionQueueSize Die Gr e der Session Queue Standardm ig hat sie eine gr e von 256 AverageSessionProcessTime Hier wird die durchschnittliche Verweilzeit in der Warte schlange angegeben Tabelle 3 4 Wichtige Monitore des Cluster Managers Quelle eigene Darstellung in Anlehnung an SAP 201 1a Der gesamte Verlauf der Anfrage Abarbeitung im Java Dispatcher ist zusammenfassend in Abbildung 3 2 grafisch dargestellt Socket Warteschlange O Dispatcher 1 I I I I l HTTP Server Socket i Listener 4 Connections i Manipulator 1 System Thread Manager Queue HTTP Provider i Service i Session Cluster ren i Queue 1 Management i Server Abbildung 3 2 Request Abarbeitung im Dispatcher Quelle eigene Darstellung in Anlehnung an Tschense 2004 22 Nachdem di
179. fern Systemarchitektur und Monitoring 97 3 3 1 Monitoring der CPU Fir die Performance Analyse ist es wichtig dass bei den Aufzeichnungen der CPU Auslastung zwischen Benutzerprozessen Systemprozessen I O Wartezeit und Leerlauf un terschieden wird Formal errechnet sich somit die Gesamtzeit wie folgt n m Ugesamt KS tBenutzer 2 system tijo tLeerlauf Das Betriebssystem Hilfsmittel mpstat IBM 2011f liefert neben weiteren Daten diese Un terscheidung der Prozessordaten bash 4 1 mpstat 1 1 gt mp out bash 4 1 cat np out System configuration lcpu 12 ent 0 3 mode Uncapped cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc Sec lcs 0 33 0 0 812 1616 508 l 1 100 2122 37 57 0 6 0 04 14 5 629 1 0 0 0 53 184 153 0 0100 27 3 6 0900 01 3 7 55 2 0 0 0 20 0 0 0 O O O 1 0990 01 33 21 3 0 0 O 28 0 0 0 O O O 2 0980 01 3 4 29 4 0 0 0 59 0 0 0 O 0 064 0360 00 0 2 59 11 0 0 0 33 0 0 0 0 O 058 0 420 00 0 1 33 U 075 0 22 74 7 ALL 33 0 O 1005 1800 661 l 1 100 2149 5 9 0 86 0 08 25 3 826 bash 4 1 J Abbildung 3 26 Exemplarische mpstat Ausgabe Quelle eigene Darstellung Wie man in Abbildung 3 26 sehen kann werden die Prozessorzeiten in us f r die Benutzerprozesse Sy f r die Systemprozesse wa f r die I O Wartezeiten und id f r die Leerlaufzeiten unterschieden Die Summe dieser Werte muss auf die Gesamtzeit und somit 100 P
180. ffen am 19 12 2011 2011 SAP Help 2011 SAP Help In http help sap com zugegriffen am 19 12 2011 2011 SAP UA 2012 SAP University Alliances In http www sap com corporate de sustainability csr education alliance epx zugegriffen am 10 03 2012 2012 SAP UCC TUM 2012 SAP University Alliances EMEA SAP University Competence Center In http www sap ucc com zugegriffen am 03 03 2012 2012 Sauer C H Chandy K M 1981 Computer Systems Performance Modeling Prentice Hall Englewood Cliffs NJ USA 1981 Scherr A L 1965 An Analysis of Time Shared Computer Systems Massachusetts Institute of Technology 1965 Schneider T 2008 SAP Performanceoptimierung 5 Aufl Galileo Press Bonn Boston 2008 Schulze P M 2007 Beschreibende Statistik 6 Aufl Oldenbourg Wissenschaftsverlag GmbH M nchen 2007 Schwarze J 1997 Einf hrung in die Wirtschaftsinformatik 4 Aufl Herne Berlin 1997 Schwarzer B Kremar H 2004 Wirtschaftsinformatik Grundz ge der betrieblichen Datenverarbeitung 3 Aufl Sch ffer Poeschel Verlag Stuttgart 2004 Shein B Callahan M Woodbuy P 1989 NFSStone A Network File Server Performance Benchmark In USENIX Summer Tech Conf Hrsg Baltimore MD 1989 S 269 275 Shousha C Petriu D Jalnapurkar A Ngo K 1998 Applying Performance Modelling to a Telecommunication System In First International Workshop on Software and Performance Hrsg Santa Fe New
181. frei Komplexere Sperrmechanismen wie die in dem Portalsystem verwendeten Lese und Schreibsperrtypen sind mittels LQN Modellierung nicht eins zu eins umsetzbar Dazu schreibt C Murray Woodside A full lock system with many separate locks and read and write locks requires special treatment The queueing disciplines are somewhat arcane and there are too many locks to represent each one separately This is a subject of current research Woodside 2002 18 LQN Modell 116 Ebenso formuliert Greg Franks in seiner k rzlich erschienenen Arbeit ber passive Ressourcen in LQNs In the future the semaphore task described here will be extended to handle read write locks A multi entry multi queue task will be necessary with separate queues for the read acquire write acquire and release operation Franks 2011 14 Zur Veranschaulichung des Problems sei ein Beispiel dargestellt Ein erster intuitiver Ansatz s he einen Lese und einen Schreibsemaphor vor die jeweils den Zugriff f r Lese und Schreiboperationen regeln Der Lesesemaphor weist eine unendliche Multiplizit t auf da mehrere Leseoperationen gleichzeitig aktiv sein k nnen der Schreibsemaphor die Multiplizi t t von 1 Da Leseoperationen den Schreibzugriff sperren m ssen wird von der Leseoperation eine Schreibsperre gesetzt Eine zweite simultane Leseoperation w rde zwar von dem Lese Semaphor sofort bedient werden der Aufruf der Wait Entry des Schreibsemaphor
182. frufen 66 y U1A1 W1E1 1 0 Aufruf des 1 Lastschritts 67 s U1A2 0 0 2 Interaktionsschritt 68 Z U1A2 0 0 optionale Denkzeit 69 f U1A2 1 deterministisch 70 y U1A2 W1E2 1 0 Aufruf Lastschritt 2 71 72 U1A1 gt U1A2 Aktivit tsgraph Sequenz von Al nach A2 73 1 Listing 5 6 Aktivit tsdeklaration der Benutzer Interaktionen Beispiel Quelle eigene Darstellung In Listing 5 7 ist die Aktivit tsdeklaration der Lesesperre aufgelistet Da es sich lediglich um einen logischen Mechanismus zur Realisierung der Lesesperre handelt werden alle Aktivit ten mit einer Service Zeit von 0 spezifiziert Der Rechenaufwand f r das Setzen der Sperre ist bereits in der Entry des Enqueue Servers definiert Im Gegensatz zur schematischen Darstellung in Kapitel 4 2 3 muss eine zus tzliche Und Gabelung eingef hrt werden die zum einen die Antwort an die aufrufende Entry sendet zum anderen die nebenl ufigen Threads wieder zusammenf hrt und die Anfrage zur Freigabe des Semaphors sendet Dazu wird eine Pseudo Aktivit t verwendet da der direkte Schritt von der Und Gabelung zur Und Vereinigung von LQsim nicht akzeptiert wird Da keine Service Zeiten f r die Aktivit ten definiert sind nimmt die zus tzliche Aktivit t keinen Einfluss auf die Antwortzeiten Zudem musste aufgrund eines Initialisierungsproblems des Simulators die Aktivit t zur ber pr fung ob eine Schreibsperre besteht vorgezogen werden und erst im Nachhinein die Un
183. ften zu betrachten Jain 1991 werden portaleigene Funktionen verwendet die wie in Abbildung 5 2 dargestellt abgebildet werden Realer Workload W U Erhebung Liste der vollst ndigen Funktionalit t ER Reduktion Portal innere Funktionalitat J Abh ngigkeitspr fung Modellierter Workload Wn Abbildung 5 2 Ermittlung des modellierten Workloads Quelle eigene Darstellung in Anlehnung an Jehle 2010 58 Als Grundlage fiir den modellierten Workload dient die im vorangegangenen Kapitel be schriebene Fallstudie die im Rahmen des SAP University Alliances Programms zu Schu lungszwecken eingesetzt wird Die Betrachtung des Reaktionsverhaltens eines Portalsystems innerhalb einer Schulung zeigt ein erwartetes Muster mit erh hten Lastspitzen vgl Jehle 2010 62 wenngleich das Nutzungsprofil der Schulungssysteme im Allgemeinen keinen di rekten Vergleich mit operativ betriebenen Systemen zul sst Mohr Simon Kremar 2005 4f F r die Evaluation des in Kapitel 4 vorgestellten Modells mittels Simulation werden folgende besonderen Gegebenheiten des Workloads genutzt Die Anzahl sowie Reihenfolge der durchgef hrten Portaloperationen ist statisch und ergibt sich aus der Analyse der Schulungsunterlagen Somit reduziert sich die Model lierung der Benutzer siehe Kapitel 4 2 1 auf Benutzertypen mit unterschiedlichen Denkzeiten Die Interaktionsschritte sowie deren Abfolge sind identisch Die Schulungsinhalte bezie
184. g zu Kapitel 4 erw hnt basiert der in dieser Arbeit verwendete Workload auf einer Portalfallstudie des SAP UCC der TU M nchen SAP UCC TUM 2012 Die Portalfallstudie wird von Dozenten der angeschlossenen Institutionen verwendet um den Studenten den Umgang mit dem Portal n her zu bringen Dabei f hrt jeder Student eine Reihe von Aktionen aus deren Art und Umfang stets identisch ist Somit wird die Lastintensit t in der Fallstudie lediglich durch die Anzahl der Benutzer gesteuert Da den Benutzern allerdings verschiedene Denkzeiten zugewiesen werden sollen damit sich der Ausf hrungszeitpunkt der einzelnen Lastschritte unterscheidet muss ein generischer An satz gew hlt werden bei dem verschiedene Benutzertypen definiert werden k nnen Dadurch k nnen neben einer variierenden Denkzeit auch unterschiedliche Interaktionsschritte f r jeden Benutzertyp definiert werden wodurch das Modellierungskonzept den Anspr chen der Ver allgemeinerbarkeit gen gt Lastintensit t Die Lastintensit t im allgemeinen Fall l sst sich wie folgt beschreiben Ein Benutzertyp BT kann durch folgendes 3 Tupel dargestellt werden BT I V D Folgende Aussagen gelten I ist eine endliche nichtleere Menge von Interaktionsschritten Die Flussrelation V definiert die durchgef hrten Interaktionsschritte mit V I x T Die Denkzeiten D in Sekunden sind Funktionen D I gt Ng Einem Benutzertyp wird zudem bei der Modellierung eines Workload Szen
185. ge ID des Ergebnisdaten Sets Input Parameter bergebene Parameter des Methodenaufrufs Table Names Alle Tabellennamen die bei diesem JDBC Aufruf involviert waren DB Error Code Falls ein SQL Fehler auftritt wird hier der Code und Status DB Error SOL State angegeben Tabelle 3 10 SQL Trace Informationen f r die Performance Analyse Ouelle eigene Darstellung Sollten nun bei einer Benutzeraktion des f r die Performance Evaluation verwendeten Work loads detaillierte Informationen zu den durchgef hrten Datenbankaufrufen ben tigt werden k nnen diese ber die Transaktions ID entsprechend zugeordnet werden Vor allem f r die bereits erw hnte Analyse von inhaltlichen und infrastrukturellen Datenbankaufrufen sind die im SQL Trace aufgezeichneten Daten sehr wertvoll Ein Beispiel zum Aufruf einer bestimm ten Transaktions ID ist in Abbildung 3 22 dargestellt Set Filter for Evaluation of J E portalsim informatik tu muenchen de 5 enSQLMonitors servlet S d e A Set Filter for Evaluation of Trace sat_sqltrace from node 2246250 Filter Values Session Id DSR Transaction Id User Application Min Duration microseconds Threads Evaluate m WESSEN 540bea945bee11e18df300000022466a portalsim informatiktu muenchen de Monit erviet SQL we Ze A S Show allthrea a Evaluation List for trace id sat_sqltrace from node 2246250 f SQLTrace Evaluation
186. gelegt Im zweiten Teil dieses Kapitels werden entsprechende Monitoring Funktionen darge stellt die die Erfassung und Aufzeichnung der Leistungsdaten erm glichen und die Voraus setzung f r eine akkurate Parametrisierung des angestrebten Performance Modells bilden Anschlie end wird die Leistungsdatenerfassung auf Betriebssystemebene vorgestellt die f r die Analyse der Systemressourcen ben tigt wird Kapitel 3 beantwortet somit die in For schungsfrage 1 gestellte Frage wie ein SAP Netweaver Portal System f r die Performance Modellierung und Simulation charakterisiert werden kann und welche Analyseinstrumente die ben tigten Informationen bereitstellen In Kapitel 4 wird das zentrale Artefakt dieser Arbeit das LQN Modell und die entsprechende Parametrisierung vorgestellt Bevor jedoch die einzelnen Modellkomponenten detailliert er l utert werden werden einige Grundannahmen getroffen die sich direkt aus der Warteschlan gentheorie ableiten Anschlie end werden die in der Literatur und der Systemdokumentation identifizierten Einflussfaktoren auf die Antwortzeit sowie deren M glichkeit zur Leistungs datenerfassung den zu modellierenden Komponenten zugeordnet Mit dieser Zuordnung wird die Grundlage f r das zu erstellende Modell geschaffen welches das Leistungsverhalten eines SAP Netweaver Portal Systems beschreiben soll Im anschlie enden Abschnitt ber die Mo dellierung und Parametrisierung der Systemkomponenten werden die tats chli
187. gene Darstellung Neben den Pufferzugriffen soll gepr ft werden ob die f r Datenbankanfragen ben tigte Zeit unabh ngig von der Wartezeit auf eine potentielle Sperrfreigabe oder einer freien Datenbank verbindung durch die Anzahl simultaner Benutzer beeinflusst wird Dazu kann die Daten bankzeit die im funktionalen Trace aufgezeichnet wird ausgelesen werden Diese stellt f r das SAP Netweaver Portal System eine Black Box dar da die Anfrage ber den JDBC Service an die Datenbank bergeben wird und die Zeit gemessen wird bis die Antwort von der Datenbank zur ckkommt Die Datenbankzeit stellt somit nicht die reine Bearbeitungszeit am Datenbanksystem dar sondern die zwischen dem Absender der Anfrage und dem Erhalt der Antwort verstrichene Zeit Ebenso ist im LQN Modell die Datenbank als Black Box mo delliert und aufgrund der eigenen CPU Ressource unabh ngig vom Portal Server Die Bear beitungszeiten im LQN Modell bilden die Datenbankzeiten des funktionalen Trace ab Es entsteht also die Notwendigkeit dass dem Datenbanksystem ausreichende Systemressour cen zur Verf gung gestellt werden und das reale System der Annahme im LQN Modell folgt dass sich keine zus tzlichen datenbankspezifischen Einfl sse auf die Antwortzeit auswirken Dies ist in Bezug auf die Praxis eine offensichtlich idealisierte Betrachtungsweise die sich direkt aus dem gew hlten Black Box Ansatz ableitet In Abbildung 2 1 kann der konstante Verlauf der durchs
188. gi schen Partitonen und dem physikalischen Host dar adapter Gibt an wieviele Daten zu den Adaptern der logischen Parti tion geschrieben bzw gesendet wurden vadapter Gibt Daten zu den virtuellen Adaptern wieder vios Gibt Informationen zu dem Durchsatz der Virtual I O VIO Server vios_adapter Gibt Informationen zu den Adaptern des Virtual I O Servers wieder Tabelle 3 12 Leistungsdaten Berichte des Betriebssystem Hilfsmittels topasout Ouelle eigene Darstellung Damit die mit topasrec bzw topasout geschriebenen Leistungsdaten ohne gr eren Auf wand grafisch dargestellt werden k nnen wird von IBM die Excel Datei To pas_cec_analyser_v1 0 xls zur Verf gung gestellt IBM 20111 Diese liest die mit dem Pa rameter c generierte CSV Datei ein und bereitet die Daten anschlie end auf Die mit den Aufzeichnungstool verbrauchten Systemressourcen w rden an sich die Ergebnis se der Messung verf lschen allerdings werden zum einen dieses oder hnliche Betriebssys temmittel auch im operativen Betrieb eingesetzt zum anderen kann der Ressourcenverbrauch der Messwerkzeuge als sehr gering bis unerheblich eingestuft werden der CPU Verbrauch im Testsystem schwankte je nach Konfiguration zwischen 0 1 und 0 2 Prozent In den folgenden Kapiteln werden spezielle Hilfsmittel zur Aufzeichnung der einzelnen Sys temressourcen aufgef hrt da diese im Vergleich zu Topas zus tzliche Leistungsdaten lie
189. gsdaten den Logical Units of Work LUW mit anderen Worten der logischen Sicht von einzelnen Benutzeraktionen zugeordnet werden k nnen Dazu wird eine Transaktion ID Global Uni que Identifier GUID generiert und an die nachfolgende Komponente bergeben siehe Ab bildung 3 18 Systemarchitektur und Monitoring 87 DSR GUID 001 Main Call Subsatz bergibt GUID 001 DSR GUID 001 Main bergibt GUID 001 Cert Subsatz Call Subsatz DSR GUID 001 Main Cert Subsatz lt Abbildung 3 18 Zuordnung der Leistungsdaten zu logischen Arbeitsschritten Quelle eigene Darstellung in Anlehnung an SAP 2011f Neben der Transaktion ID ist der DSR Datensatz in einen Hauptteil Main und falls zu treffend in Unterdatens tze gegliedert Ein Call Subsatz beinhaltet Informationen zu der auf gerufenen Komponente wogegen ein Cert Subsatz die Quelle der LUW spezifiziert Jeder DSR Datensatz kann eine beliebige Anzahl an aufgerufenen Komponenten und somit Call Subs tze aufweisen F r die in dieser Arbeit durchgef hrten Messungen ist dieses Prinzip vor allem f r die Zuord nung der Datenbankaufrufe sehr hilfreich F r jeden Datenbankaufruf wird ein Call Subsatz erstellt sodass die einzelnen Datens tze der Benutzeraktion LUW zugeordnet werden k n nen Somit errechnet sich nach SAP 2011g die reine Bearbeitungszeit mittels Bearbeitungszeit Antwortzeit
190. h Franks et al 2012 verwiesen werden Durchschnittliche Service Zeiten maximale Service Zeiten und quadrierte Variations koeffizienten werden f r jede einzelne Aktivit t im Aktivit tsgraph festgelegt Ebenso wird der Ressourcenverbrauch durch Koppelung an einen Prozessor Task f r jede Aktivit t einzeln definiert Allerdings betreffen die CPU Zeiten der einzelnen Last schritte die im funktionalen Trace siehe Kapitel 3 2 3 ausgelesen werden k nnen den gesamten Lastschritt Feingranularere CPU Zeiten der einzelnen Aktivit ten des Lastschrittes sind nicht vorhanden und k nnen somit nicht modelliert werden Daher wird lediglich die Lastschritt Entry an einen Prozessor Task gekoppelt Darunterlie gende Komponenten sind somit implizit mittels Durchschnittswerten mit inbegriffen und werden nicht mehr an einen Prozessor Task gekoppelt LQN Modell 121 n einem Aktivit tsgraphen der synchrone Anfragen annimmt muss genau eine Ant wort Aktivit t definiert sein Das Erreichen dieser Aktivit t muss bei jedem Ablauf muster garantiert sein Dies ist beim Lese und Schreibsperren Task der Fall und wird direkt nach der Datenbankoperation ausgef hrt Die Anfragen werden vom Enqueue Server ber einen weitergeleiteten Aufruf durch gereicht Die Funktionsweise von weitergeleiteten Aufrufen wurde bereits in Kapi tel 2 5 1 beschrieben Die Multiplizit t der diskutierten Komponenten wird ber den Parameter lt mul ti s
191. h vorhanden ist siehe Abbildung 3 27 Unkomprimierter Speicherbereich Komprimierter Speicherbereich Reale Speichergr e Erweiterte Speichergr e Abbildung 3 27 Funktionsprinzip der Active Memory Expansion Quelle eigene Darstellung Die Kompressionstechnologie wird vollst ndig vom System verwaltet und ist f r die laufen den Applikationen transparent Sie wird am SAP UCC der TU M nchen auch in der produk tiven Systemlandschaft eingesetzt und aufgrund des Praxisbezugs des eingesetzten Workloads auch in der in dieser Arbeit eingesetzten Testsystemlandschaft aktiviert Der Einfluss der AME auf den CPU Ressourcenverbrauch wurde in einer Studie von IBM Michel 2010 10 unter anderem f r ERP Systeme getestet und zeigte bis zu einer Hauptspei chererweiterung von 73 Prozent keinen nennenswerten bzw messbaren Einfluss auf die CPU Leistung Der Anstieg betrug in diesem Intervall nur 1 Prozent Es sei an dieser Stelle aller dings erw hnt dass die CPU Auslastung ohne AME bei 60 Prozent lag und somit kein Hoch lastszenario gew hlt wurde Damit in vmstat die zus tzlichen AME Felder angezeigt werden wurde der Parameter c verwendet Dieser bewirkt bei der Ausgabe folgende zus tzlichen Informationen esz Derzeitige Gr e des komprimierten Speicherbereichs Cfr Menge an freien Speicherseiten im komprimierten Speicherbereich Systemarchitektur und Monitoring 99 dxm Fehlmenge an er
192. haftlichen Umfeld verschieden Methoden der Performance Evaluation etabliert vgl Kapitel 2 3 In Bezug auf ERP Systeme und Unternehmenssoftware im Allgemeinen werden diese M glichkeiten in der Praxis jedoch nur teilweise genutzt Die Analyse be schr nkt sich haupts chlich auf die berwachung aktueller Leistungsdaten mittels integrierter Funktionen vgl Kapitel 1 1 Ziel dieser Arbeit war es daher das Leistungsverhalten eines SAP Netweaver Portal Systems mit den auf den Warteschlangennetzen basierenden LQNs zu beschreiben und durch Simulation des Performance Modells die Leistung bei steigenden Be nutzerzahlen zu bewerten In diesem Kapitel werden nun die erzielten Ergebnisse zusammen gefasst und bewertet Abschlie end werden die mit den Ergebnissen einhergehenden Limita tionen aufgezeigt und ein Ausblick auf weitere Forschungsm glichkeiten gegeben 6 1 Bewertung und Interpretation der Ergebnisse In Kapitel 3 wurde die in Forschungsfrage 1 gestellte Frage wie ein SAP Netweaver Portal System f r die Performance Modellierung und Simulation charakterisiert werden kann und welche Analyseinstrumente die ben tigten Informationen bereitstellen beantwortet Dabei wurden einzelne Komponenten des Systems betrachtet die in der Literatur als Performance Indikatoren genannt werden Mithilfe den theoretischen Grundlagen aus Kapitel 2 den Erfah rungen am SAP UCC der TU M nchen sowie der SAP Systemdokumentation konnten Me thoden zur Leistungsdaten
193. hen sich bis auf wenige Ausnahmen auf portaleigene Funktionen Somit bleibt trotz Reduktion ein Gro teil des realen Workloads erhalten Integrierende Funktionen wie beispielsweise das Einbinden von ABAP basierten ERP Modulen w rden die Modellierung der externen Komponenten oder in der mi nimalen Auspr gung die implizite Angabe der Antwortzeit der externen Komponente Simulation und Evaluation 138 in der Bearbeitungszeit des Lastschrittes erfordern Dies hatte zur Folge dass die zu s tzlichen u eren Einfl sse einen weiteren zu analysierenden St rfaktor f r die Evaluation der Simulationsergebnisse darstellen w rden Aus der Transkription der Schulungsinhalte in einzelne Operationen der Schulungsteilnehmer ergibt sich eine Liste von ber 100 durchgef hrten Funktionen siehe Tabelle 7 1 Neben dem Ausschluss von integrierenden Funktionen m ssen die Voraussetzungen f r bestimmte Portaloperationen erf llt sein so besteht zum Beispiel eine Abh ngigkeit zwischen dem L schen und vorausgehenden Erstellen eines Benutzerkontos Diese Abh ngigkeit ergibt sich aus der Abfolge der in der Schulung durchgef hrten Portaloperationen Bei einzelnen Last schritt Messungen oder bei Portaloperationen die von einer ausgeschlossenen Portalfunktion abh ngen muss sichergestellt sein dass die Voraussetzungen erf llt sind Zudem muss gepr ft werden ob die durchgef hrten Portalfunktionen parallel ausgef hrt wer den k nnen Die Untersuc
194. her in der Praxis aufgrund von diversen Einflussfaktoren Ressourcenengp sse Konfigurationsein schr nkungen selten erreicht wird Gray 1991 Daraus entstand die Notwendigkeit weitere Benchmarks zu entwickeln Weicker 1990 2 6 1 Anforderungen an Benchmarks Die Grundidee des Benchmarkings ist die Feststellung und das Auffinden von Unterschieden in den Prozessen Systemen und Methoden Durch einen Vergleich durch jeweils gleiche Benchmarks k nnen Verbesserungsm glichkeiten aufgezeigt werden Es ist wichtig zu wis sen welche Anforderungen an einen Benchmark bestehen wie zum Beispiel die Lauff hig keit auf allen eingesetzten Plattformen eines Vergleichunternehmens Die folgenden Anforde rungen an Benchmarks sollen nach Versick 2010 31ff erf llt sein um sie nutzbringend einsetzen zu k nnen Theoretische Grundlagen 58 Portabilitat Der Benchmark muss auf allen Plattformen die miteinander verglichen werden lauffahig sein Reprdsentativitat Unabh ngig von der Anzahl an Applikationen m ssen Benchmarks repr sentative Ergebnisse liefern Wiederholbarkeit Bei identischen Bedingungen m ssen Benchmarks gleichbleibende Ergebnisse liefern Verifizierbarkeit Ergebnisse der Benchmark L ufe m ssen nachvollziehbar und ber pr fbar sein Des Weiteren sollen Benchmarks eine gute Skalierbarkeit aufweisen und somit auch bei stei gender Systemleistung relevante Ergebnisse liefern Zudem soll ein Benchmark
195. her kann auch eine Lesesperre Einfluss auf die Perfor mance nehmen da Schreibvorg nge durch Lesesperren ver z gert werden E Exclusive lock Schreib Schreibsperren sind exklusiv Allerdings k nnen kumulative sperre Sperren gesetzt werden Kumulative Sperren sind dann m g lich wenn die Elementarsperre Name Argument Sperrtyp identisch ist und kein Sperreintrag des Typs X f r das betref fende Feld vorliegt X eXclusive but not cumula Schreibsperren bei denen auch kumulative Sperren unter tive lock Exklusive Schreib sagt sind sperre O Optimistic lock Optimis Optimistische Sperren sind vorerst Lesesperren Erst sobald tische Schreibsperre eine tats chliche nderung der Daten erfolgt wird die opti mistische Sperre in eine exklusive umgewandelt Tabelle 3 7 Sperrmodi Ouelle eigene Darstellung in Anlehnung an SAP 2011k F r die Anzeige die Bearbeitung und das Aufzeichnen von Sperrtabellen Eintr gen kann so wohl der Netweaver Administrator als auch die SAP Konsole siehe Abbildung 3 6 verwen det werden Systemarchitektur und Monitoring Telnet Administration SAP J2EE Engine v7 00 Login Administrator Password gt jump 0 You jumped on node 333227250 gt gt add locking gt show_locks lt internal gt 2011111616285797600000portalsim2 28 333227250 service ejb sap com caf runtime BWIransactionQueue lt internal gt 2011111616285
196. hread Thread Applikationsservers Tabelle im Hauptspeicher Tabellen Puffer des Applikationsservers Datenbank Server Datenbank Datenbank CPU Ressource des Thread Thread Datenbankservers Tabelle im Hauptspeicher Tabellen Puffer des Datenbankservers Abbildung 3 7 Tabellenpuffer im Java Server Prozess Quelle eigene Darstellung Es werden grunds tzlich drei verschiedene Arten von Tabellenpufferung unterschieden Einzelsatzpufjerung Einzelsatzpufferung wird dann angewendet wenn bei einem Zu griff der gesamte Prim rschl ssel also alle Felder die Teil des Prim rschl ssels sind verwendet wird Jeder Datensatz wird dann gepuffert sobald er das erste Mal gelesen wird Sobald ein weiterer Zugriff erfolgt kann er direkt vom Tabellenpuffer gelesen werden Vollst ndige Pufferung Bei der vollst ndigen Pufferung wird die gesamte Tabelle ge puffert sobald ein Lesezugriff auf einen Datensatz der Tabelle erfolgt Generische Pufferung mit n Schl sselfeldern Bei der generischen Pufferung wird ab h ngig von n die Anzahl der Schl sselfelder als der zu puffernde Bereich angesehen Mit anderen Worten werden alle Datens tze gepuffert deren n Schl sselfelder iden tisch mit den Schl sselfeldern des abgefragten Datensatzes sind In Abbildung 3 8 sind zwei Beispiele der generischen Pufferung abgebildet links unten wird nur ein Schl sselfeld n 1 ausgewertet und alle Datens tze mit demselben Wert in diesem F
197. ht Als Basis des Lin Pack Benchmarks einem alten FORTRAN Programm dient die L sung des Gleichungssys tems Ax b mittels Gau Elimination Der Einsatz des LinPack Benchmarks erlaubt die Darstellung der Entwicklung und bildet eine Rangfolge allerdings k nnen keine Aussagen ber die eigentliche Systemleistung getroffen werden Applikations Benchmarks Viele Computersysteme wurden f r ein bestimmtes Anwendungsszenario konzipiert wie zum Beispiel Reservierungssysteme Bankensysteme oder allgemein transaktionsorientierte Sys teme F r die Evaluation der Performance solcher Systeme reichen synthetische Programme nicht aus Daher entsteht die Notwendigkeit reale Funktionen die vom System ausgef hrt werden in den Benchmark zu implementieren Seit den siebziger Jahren wurden Debit Credit Benchmarks eine spezielle Form von Applika tions Benchmarks immer beliebter Diese wurden dahingehend entworfen transaktionsorien tierte Systeme zu vergleichen Die dabei am h ufigsten verwendete Metrik ist die Preis Performance Rate Der Preis stellt hierbei s mtliche Kosten f r den Kauf die Installation und die Wartung des Systems sowohl Hardware als auch Software ber einen bestimmten Zeit raum hinweg dar Die Performance wird mittels TPS gemessen Jede Transaktion beinhaltet Datenbanklese und schreiboperationen Der erste bekannte Debit Credit Benchmark wurde als TP bekannt Anonymous et al 1985 und gilt als De Facto Standard f r transak
198. hung dieser Eigenschaft erfolgt manuell indem die betrachtete Funktion zeitgleich von zwei verschiedenen Benutzern ausgef hrt wird vgl Jehle 2010 66 Nicht parallel durchf hrbare Funktionen spielen bei der Lasterzeugung eine Rolle da ein ent sprechender Automatismus daf r sorgen muss dass ein paralleler Aufruf unterbleibt damit der Lastschritt durchgef hrt wird und die ben tigten Daten aufgezeichnet werden k nnen Ebenfalls ist im SAP Netweaver Portal System eine Mehrfachanmeldung eines einzelnen Benutzerkontos nicht m glich sodass bei der Lasterzeugung unterschiedliche Konten ver wendet werden m ssen Gootzit 2008 Neben der Lasterzeugung muss auch bei der Simulation sichergestellt werden dass das Ver halten dem realen System entspricht Funktionen die nicht parallel ausgef hrt werden k n nen werden vom System so lange gesperrt bis der Benutzer den Lastschritt durchgef hrt hat Sollte ein weiterer Benutzer versuchen den Vorgang durchzuf hren w rde eine Fehlermel dung darauf hinweisen dass die Funktion derzeit gesperrt ist Die Sperrung der Funktion kann im Simulationsmodell ber einen Bin rsemaphor abgebildet werden siehe Abbildung 5 3 Dazu muss ein synchroner Aufruf der Wait Entry des Bin rsemaphors erfolgen und nach Be endigung ber einen Aufruf der Signal Entry in Phase 2 also nach dem Senden der Antwort an den Benutzer wieder freigegeben werden Lastschritte e Multiplizit t m Task 4 Semaphor Last
199. i dem verwendeten Workload mit identischen Interaktions schritten der Schulungsteilnehmer regelm ig Sperrsituationen auftreten Starker Anstieg in der zweiten Phase Ab ca 80 Benutzern ist ein deutlicher Anstieg der Antwortzeiten zu erkennen der vor allem darauf zur ckzuf hren ist dass die 80 Applikations Threads 2 Java Server Instanzen zu je 40 Applikations Threads ausge lastet sind und zus tzliche Wartesituationen eintreten Da die CPU Ressourcen nicht gekappt sind ist kein Einflusszuwachs des System Overheads vgl Jehle 2010 185f zu verzeichnen Simulation und Evaluation 152 5 5 4 2 Pufferzugriffe 100 eege a 98 96 94 92 Trefferrate der Pufferzugriffe 90 T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer u 98 89 98 91 98 80 98 98 99 02 98 81 98 89 o 0 09 0 07 0 08 0 10 0 07 0 07 0 09 Cx 0 001 0 001 0 001 0 001 0 001 0 001 0 001 Median 98 90 98 91 98 81 98 98 99 02 98 81 98 90 Q1 25 98 84 98 87 98 75 98 92 98 98 98 77 98 84 Q3 75 98 94 98 95 98 84 99 03 99 05 98 85 98 94 Abbildung 5 11 Trefferrate der Pufferzugriffe in Prozent Szenario 1 Quelle eigene Darstellung In Kapitel 4 1 2 konnten Invalidierungen und Verdr ngungen der Tabellenpuffer Inhalte als wesentliche Einflussgr en der SAP System Performance identifiziert werden Wie in Kapi tel 3 1 4 dargestellt l sst sich die Anzahl der Zugriffe auf den Puffer Requests sowie die Anzahl der
200. i gelten muss n Val p si Ein gro er Vorteil der Instruktion Mixes ist die relativ einfache Entwicklung Allerdings k n nen keine heterogenen Architekturen betrachtet werden beispielsweise CPUs mit RISC und CISC Architektur Zudem kann die Leistungsf higkeit des Gesamtsystems nicht bewertet werden solange nicht die CPU den Engpass des Systems darstellt da diese Art von Bench marks lediglich die Geschwindigkeit von CPUs misst Nicht zuletzt erschweren es weiterent wickelte Technologien wie zum Beispiel Caches oder Pipelines die Leistung einer Rechen einheit mittels Instruction Mixes richtig zu bewerten Einer der bekanntesten Vertreter dieses Benchmark Typs ist der von IBM entwickelte Gibson Mix Gibson 1970 Aufgrund der genannten Nachteile ist dieser Benchmark Typ allerdings weitestgehend obsolet Hu Gorton 1997 Synthetische Benchmarks Synthetische Benchmarks sind Programme die dazu dienen realen Workload zu simulieren Sie konsumieren eine bestimmte Menge an Systemressourcen oder senden bestimmte Anfra gen an das System Im SAP Umfeld stellt der Zachmanntest einen synthetischen Bench mark f r Hauptspeicher Operationen dar allerdings werden I O Operationen nicht behandelt Boegelsack Wittges Kremar 2010 K hnemund 2007 Weitere Vertreter von synthetischen Benchmarks sind Programme wie Whetstone und Dhrystone Weiss 1993 sowie NFSS tone Shein Callahan Woodbuy 1989 ein Benchmark fiir das N
201. ie beispiels weise in Franks et al 2012 beschrieben sind n her erl utert Server Server Knoten k nnen entweder Tasks oder Prozessoren darstellen Obwohl es in der LQN Notation nicht explizit dargestellt wird beinhaltet jeder Server implizit eine unendliche War teschlange um ankommende Anfragen in einer Warteposition aufzunehmen bis sie bedient werden k nnen Die standardm ige Bedienstrategie ist First Come First Served Weitere Bedienstrategien werden jedoch ebenfalls unterst tzt Ein Software oder Hardware Knoten kann mit einer Multiplizit t versehen werden Einzel oder Multi Server Ein Multi Server besteht aus mehreren identischen Klonen die parallel arbeiten jedoch dieselbe Warteschlange teilen Die Multiplizit t kann ebenso unendlich sein infiniter Server Tasks werden als Parallelogramm dargestellt Prozessoren als Kreise siehe Abbildung 2 16 Theoretische Grundlagen 49 d Task SUEN Einzel Server Task Pool Multi Server Prozessor Einzel Server Prozessor Multi Server ool Abbildung 2 16 Tasks und Entries im LQN Modell Quelle eigene Darstellung Entry F r einen LQN Task besteht die M glichkeit verschiedene Dienste anzubieten Diese werden mit sogenannten Entries modelliert siehe Abbildung 2 16 Eine Entry ist mit einer Adresse oder einem Port eines bestimmten Tasks vergleichbar bei dem ein bestimmter Dienst angebo ten wird Bei jeder Entry sind die Bedienzeit sowie optionale A
202. ie einen Einfluss auf die Gesamt performance des Systems nehmen und im Warteschlangenmodell modelliert werden Danach werden die f r die Leistungsanalysen eingesetzten Monitoring Werkzeuge sowohl des SAP Netweaver AS Java als auch auf Betriebssystemebene vorgestellt 3 1 System Architektur des SAP Netweaver AS Java Wie bereits in Kapitel 2 1 1 erw hnt basiert das SAP Netweaver Portal auf den SAP Netweaver AS Java kurz AS Java dem J2EE Applikations Server von SAP Die Gesamt heit der einzelnen Java Komponenten eines SAP Systems wird auch als Java Cluster be zeichnet Die einzelnen Komponenten sind Eine zentrale Java Instanz mit einem Dispatcher und mindestens einem Java Server Prozess Der Java Dispatcher nimmt dabei die Benutzeranfragen entgegen und verteilt sie anhand eines Round Robin Algorithmus Optional k nnen auch mehrere Java Server konfiguriert werden Die Central Services die den Message Server und den Enqueue Server beinhalten Der Message Server verwaltet die Liste der vorhandenen Dispatcher und Server Prozesse innerhalb eines Java Clusters Er stellt den Dispatchern die Lastverteilungs informationen zur Verf gung und stellt zudem eine Kommunikationsschnittstelle zwi schen den Knoten des Java Clusters dar Der Enqueue Server verwaltet logische Sper ren von Datenbankbereichen im Hauptspeicher die von einem Java Server Prozess bei der Abarbeitung einer Applikation gesetzt werden Zudem wird er von dem SAP S
203. ie in der LQN Literatur bis dato nicht untersucht worden sind F r die anschlie end durchgef hrte Evaluation des LQN Modells wird das Leistungsverhal ten eines SAP Netweaver Portal Systems unter einer ansteigenden Anzahl von Benutzern analysiert und mit den ermittelten Leistungsdaten der Simulation verglichen Die dabei ver wendete Performance Metrik beschr nkt sich auf die Antwortzeit als Messgr e da diese eine hohe Aussagekraft f r die besagte Fragestellung bietet mit den vorhandenen Analyse Hilfsmitteln gemessen werden kann und die Anforderungen an eine Metrik f r die Perfor mance Analyse erf llt Lilja 2000 Ziel ist es aus der Analyse und Interpretation der Evalua tionsergebnisse R ckschl sse auf die Aussagekraft der eingesetzten Performance Simulation zu ziehen Als Workload werden die Inhalte der SAP Netweaver Portal Schulung aus dem SAP University Alliances Programm SAP UA 2012 eingesetzt die unter anderem von dem SAP University Competence Center der Technischen Universit t M nchen SAP UCC TUM 2012 angeboten werden Dabei handelt es sich um ein breites Spektrum grundlegender und erweiterter Portalfunktionen die unter anderem zur Inhaltserstellung Verwaltung Personalisierung und Kommunikation mit anderen Benutzern verwendet werden Zusammenfassend lassen sich die Kernbeitr ge der vorliegenden Arbeit wie folgt festhalten Identifikation der wesentlichen Performance Einflussgr en aus den Erkenntni
204. ie statische Modellierung des GC Einflusses dient le diglich der speziellen GC Untersuchung und l st nicht die f r eine nicht gemessene Lastin tensit t unbekannte Variable des GC Einflusses Mit anderen Worten ist das vorgestellte Konzept der GC Modellierung nur dann sinnvoll wenn explizite Messdaten zur Verf gung stehen oder k nstlich erh hte GC Aktivit ten zu Testzwecken eingesetzt werden Eine expli zite Modellierung des Garbage Collectors die dessen dynamische Eigenschaften allgemein abbildet bleibt weiterhin offen und ist Bestandteil weiterer Untersuchungen 5 82 System Overhead Neben dem berproportionalen Zuwachs der GC Aktivit ten steigt mit zunehmender Auslas tung der Overhead auf Betriebssystemebene In den folgenden zwei Diagrammen ist die CPU Auslastung ber einen Zeitraum von f nf Minuten f r die betrachteten Benutzerzahlen darge stellt Die Einbr che der CPU Auslastung erkl ren sich ber die soeben dargestellten GC Aktivit ten Wie man deutlich erkennen kann steigt der Anteil des System Overheads und f hrt somit zu einer weiteren Beeintr chtigung der Leistungsf higkeit 100 u Gesamt 92 30 80 u Benutzer 81 26 60 E CPU System 40 CPU Benutzer 20 0 Os 300s 600s Abbildung 5 25 Vergleich zwischen Benutzer und System CPU Zeit Szenario 2 80 Benutzer Quelle eigene Darstellung In Abbildung 5 25 lassen sich deutlich die GC L ufe in einem durchschnittlichen 30
205. ied zwischen den beiden Fehlerarten liegt darin dass systematische Fehler das zuvor aufgestellte Axiom falsifizieren Der Schwellwert ab welcher Fehlerrate ein systematischer Fehler vorliegt muss versuchsbezogen festgelegt werden Die Fehlertheorie bestimmt somit die Kriterien in welchem Rahmen ein Axiom empirisch zu best tigen und ab wann es zu verwerfen ist Orth 1974 91 Nach Jehle 2010 37 gen gt bei der Leistungsanalyse von Portalsystemen prim r die Be trachtung ob Operationen vollst ndig abgeschlossen wurden F r die Fehlerdefinition wer den abh ngig von den ausgew hlten Attributen im Sinne der Messtheorie Erwartungswerte definiert So kann beispielsweise das numerische Relativ Antwortzeit innerhalb eines gewis sen Rahmens aber auch au erhalb liegen und somit als Fehler definiert werden Die fehler theoretische Analyse besch ftigt sich anschlie end mit der Frage wie viele Verfehlungen der Sollwerte akzeptabel sind 2 2 2 1 Ausrei er Ausrei er kommen h ufig durch unerwartete externe Einfl sse wie z B bertragungsfehler im Netzwerk zustande Ein m glicher Ansatz zur Definition des tolerierten Rahmens stellt die Schwellwertangabe des Konfidenzintervalls dar Werte die au erhalb dieses Rahmens liegen werden als Ausrei er klassifiziert und aus der Messreihe eliminiert Jehle 2010 165 Wie im Verlauf dieser Arbeit noch gezeigt wird k nnen jedoch auch architekturspezifische Eigenschaften zu vermeintlichen Me
206. ielsweise die bei dem Benutzertask vorgestellte Sequenz von Interakti onsschritten Sie formen einen gerichteten Graphen der Gabelungen Vereinigungen sowie Schleifen beinhalten kann und k nnen somit komplexere Abarbeitungsschemas abbilden Sie k nnen ebenso Anfragen und Antworten an andere Entries bzw Aktivit ten senden Die Anzahl der Anfragen die an weitere Server niedrigerer Ebenen gesendet werden k n nen mit einem stochastischen oder deterministischen Wert angegeben werden Bei einer de terministischen Angabe werden genauso viele Anfragen gesendet wie angegeben Bei einer LQN Modell 111 stochastischen Angabe wird der angegebene Wert als Durchschnitt interpretiert und eine ge ometrische Verteilung angenommen Die Bedienzeit wird anhand des Mittelwertes und der Streuung angegeben Dabei wird eine Anfrage an den verbundenen Prozessor Task gesendet Der quadrierte Variationskoeffizient CZ wird zur Beschreibung des Streuungsma es verwendet und folgt direkt aus dem Quad rieren des Variationskoeffizienten siehe Kapitel 2 2 1 2 go u F r die Generierung der Zufallsvariablen verwendet der Simulator folgende Verteilungen CS 0 deterministisch 0 lt C lt 1 Gammaverteilung C 1 Exponentialverteilung Mit der soeben beschriebenen Task Komponente sowie ihren zugeh rigen Entries bzw Akti vit ten k nnen die Lastschritte grunds tzlich modelliert werden Allerdings ist es in vielen Systemen so dass
207. iesbaden 2004 Alpar P Grob H L Weimann P Winter R 2008 Anwendungsorientierte Wirtschaftsinformatik 5 berarb u aktual Aufl Vieweg amp Teubner Wiesbaden 2008 Amberg M Remus U Holzner J 2003 Portal Engineering Anforderungen an die Entwicklung komplexer Unternehmensportale In Wirtschaftsinformatik 2003 Band II Medien M rkte Mobilit t Vol 2 Hrsg Uhr W Esswein W Schoop E Physica Verlag Springer Heidelberg 2003 S 795 817 Anderson P Arrow K Pines D 1988 The Economy as an Evolving Complex System Addison Wesley Redwood City 1988 Anonymous Bitton D Brown M Catell R Ceri S Chou T DeWitt D Gawlick D Garcia Molina H Good B Gray J Homan P Jolls B Lukes T Lazowska E Nauman J Pong M Spector A Trieber K Sammer H Serlin O Stonebraker M Reuter A Weinberger P 1985 A measure of transaction processing power In Datamation Vol 31 1985 Nr 7 S 112 118 Arnold D Isermann H Kuhn A 2004 Handbuch Logistik 2 aktual u korr Aufl Springer Berlin 2004 Baier C Haverkort B R Hermanns H Katoen J P 2003 Model Checking Algorithms for Continuous Time Markov Chains In IEEE Transactions on Software Engineering Vol 29 2003 Nr 7 S 1 18 Banks J Carson J Nelson B L Nicol D 2004 Discrete Event System Simulation Prentice Hall Englewood Cliffs NJ USA 2004 Barham P Dragovic
208. iff allerdings bedeutet eine h here Antwortzeit und muss somit vom LQN Modell ber cksichtigt werden Damit ein permanentes Laden einer Tabelle die st ndig invalidiert wird verhindert wird kann eine Tabelle nach dem Invalidieren erst nach Ablauf einer Wartezeit wieder in den Puffer geladen werden Es werden nur dann die Daten aus dem Puffer gelesen wenn das Open SQL Statement eine Select Anweisung ist die alle Schl sselfelder beinhaltet die bei der Definition des Pufferob jektes verwendet wurden siehe Tabellenpuffer Arten in Kapitel 3 1 4 Verschachtelte SQL Select Statements werden nicht vom Puffer bedient sondern direkt an das Datenbanksystem bergeben da diese dort effizienter verarbeitet werden Zus tzlich kann der Zugriff auf den Tabellenpuffer explizit bergangen werden Dazu wird dem SQL Statement eine Bypass Klausel hinzugef gt LQN Modellierung In der Literatur zur LQN Modellierung konnten keine Ans tze zur Modellierung von Puffern die der Funktionsweise der Tabellenpuffer entsprechen gefunden werden Lediglich die Ar beit von Franks 2011 besch ftigt sich mit passiven Ressourcen bei der die bereits vorge LQN Modell 122 stellten Semaphor Tasks eingesetzt werden Es wird gezeigt dass Semaphore zur Modellie rung des Puffer Pools f r die Videoaufzeichnung eines Sicherheitssystems eingesetzt werden k nnen Der Einsatz des Semaphors dient dabei der Sperrung des Pufferbereichs bis die Vi deodaten persistent in
209. ifiziert Fazit 189 6 2 Limitationen Die Performance Analyse von Unternehmenssoftware kann sowohl aus betriebswirtschaftli cher Sicht als auch in Hinblick auf technische Leistungskennzahlen erfolgen Die in dieser Arbeit durchgef hrte Performance Modellierung und Simulation eines SAP Netweaver Portal Systems beschr nkt sich auf die technische Leistungsbewertung Dazu wurde die Ant wortzeit als betrachtete Metrik spezifiziert und das Leistungsverhalten bei gleichbleibendem Workload sowie einer steigenden Anzahl von Benutzern beobachtet Dem vorgestellten Ansatz zur Performance Modellierung eines SAP Netweaver Portal Systems liegt die Annahme zugrunde dass durchgef hrte Portaloperationen ber fest defi nierte Key Performance Indikatoren beschrieben werden k nnen Diese wurden in Kapi tel 4 1 2 identifiziert wie zum Beispiel durchschnittliche Bearbeitungszeiten Datenbankzu griffe gepufferte Tabelleninhalte oder erzeugte Sperrobjekte Die Modellierung umfasst sowohl logische Software Komponenten des Portalsystems als auch Prozessor Ressourcen die mit den modellierten Software Komponenten verbunden sind Die Abbildung der Pr sentationsebene dient lediglich dem Erzeugen von Benutzeranfragen Ebenso wurde davon ausgegangen dass das Datenbanksystem auf einem eigenen Host instal liert ist und ber gen gend Systemressourcen verf gt Die Abarbeitung der Datenbankanfra gen wurde als Black Box modelliert sodass interne Abl ufe des
210. ikation erfolgt bidirektional Link Ein Link verbindet zwei Knoten f r eine unidirektionale Kommunikation Gruppe Eine Gruppe von Tasks wird ebenso wie bei dem LQNS Meta Modell f r ein spezielles Scheduling Verfahren verwendet Li Franks 2009 Host Ein Host bzw dessen Prozessoren f hren die Tasks aus Task Tasks kommunizieren untereinander indem sie Nachrichten an den entspre chenden Port senden Port Jeder Task besitzt einen Standard Port f r den Empfang der zu versendenden Nachrichten Weitere Ports k nnen je nach Bedarf definiert werden Die Tasks von Parasol werden von LQsim verwendet um s mtliche Task Typen in dem LQN Modell zu modellieren Zum besseren Verst ndnis ist die Hauptschleife des Task Templates im Listing 2 1 dargestellt der periodisch bei den Referenz Tasks reinen Clients oder immer dann wenn eine Nachricht bei einem der anderen Tasks ankommt aufgerufen wird Theoretische Grundlagen 56 1 procedure server_cycle mesg msg_in 2 begin 3 bool not_done true 4 while not_done do 5 compute msg_in entry 6 entry dst choose msg_in entry 7 if dst nil then 8 mesg msg_out 9 msg_out entry dst 10 msg_out reply_to reply_port 11 send dst std_port msg_out 12 receive reply_port 13 else 14 not_done false 15 fi 16 od 17 send msg_in reply_to nil 18 end Listing 2 1 Hauptschleife des Task Templates Quelle Franks 2011 Die Entries des LQN
211. ile liegen vor allem bei der Herstellung des Bezuges zwischen den Messdaten in der Hardware und den verursachten Programmen im Sys tem Heinrich Lehner 2005 535 Daher ist der Anwendungsbereich von Hardware monitoren meist auf hardwarenahe Analysen beschr nkt und kaum f r die Parametri sierung von Modellen geeignet Des Weiteren sind die Anschaffungskosten und das ben tigte Knowhow meist sehr hoch Jain 1991 100 Software Monitore Nach Teuffel Vaupel 2010 231 ist ein Software Monitor ein Programm das neben anderen Programmen auf dem Rechner l uft und Daten sammelt die entweder vom Betriebssystem oder von einzelnen Anwendungen zur Verf gung gestellt werden Dabei wird das Verhalten des zu untersuchenden Anwen Theoretische Grundlagen 36 dungssystems durch die in regelm igen Abst nden ausgef hrten Programmkompo nenten dem Softwaremonitor protokolliert Winkler 2010 27 Software Monitore k nnen auf den unterschiedlichsten Ebenen Daten sammeln Zu den typischen Daten die gemessen und analysiert werden z hlen CPU Zeiten Speicherbelegung I O Zugriffe und Cache Aktivit ten Der Vorteil von Software Monitoren liegt vor allem darin dass Rechner und Programmzust nde detailliert erfasst und dem verursachen den Programm zugeordnet werden k nnen Im Gegensatz zu Hardwaremonitoren ha ben Softwaremonitore eine h here Eingabebreite eine h here Aufnahmekapazit t wenn n tig kann man sie leichter modifiziere
212. in diesem Fall die Verteilungscharakteristik zu den einzelnen Warteschlangen der Repliken nur eine Ann herung an den effizienten Verteilungs algorithmus des Java Dispatchers Aufgrund der genannten Einschr nkungen sollte eine explizite Modellierung des Dispatchers nur dann durchgef hrt werden wenn mehrere Hosts mit unterschiedlichen CPU Ressourcen modelliert und anschlie end einzeln analysiert werden sollen Ansonsten eignet sich die Zu sammenf hrung der einzelnen Server Instanzen SI SI zu einer einzigen logischen Server Instanz deren Multiplizit t m die Gesamtsumme aller zur Verf gung stehenden Server Threads darstellt n m Anzahl Threads SI k 1 LQN Modell 113 Die einzelnen Lastschritte werden in den einzelnen Entries definiert Dabei muss jede durch gef hrte Operation des Workloads in jedem Task sofern mehrere Tasks modelliert wurden definiert sein Damit die Service Zeiten und Streuungsma e zu den einzelnen Lastschritten angegeben werden k nnen muss der funktionale Trace siehe Kapitel 3 2 3 ausgewertet wer den Zur Kapselung der Performancedaten zu den einzelnen Interaktionsschritten kann das Prinzip der Transaktionsverwaltung siehe Kapitel 3 1 2 angewendet werden Die vorgestell ten Performance Traces lassen eine Zuordnung der Leistungsdaten zu den jeweiligen Trans aktions IDs zu siehe Angabe der Transaktions IDs in den Traces in Kapitel 3 2 Die in Tabelle 4 1 definierten Einflussfaktoren der Lastsch
213. in kann siehe Abbildung 3 23 Visual Administrator P33 Server 0 33_32272 SericesiHTTP Provider r Connect View Tools Help SO an 0 Global Configuration A Cluster HE 4 Document Servi G LogResponseTime true 4 cote RSR Runtime Properties Additional Info Bebe 1 Mime java text plain MinFileLengthForLongDataTransfer 204800 MinimumGZipLength 8192 NeverCompressed alt CSS 4 DOE 4 EJB Container 4 File Transfer 4 HTTP Provider ZM IIOP Provider 4 Java Mail Client 4 Co RFC Provide 4 JDBC Connector 4 JMS Connector 4 JMS Provider 4 JMX Adapter 4 JMX Notification ZM INDI Registry i 4 JWF Wizard Seng 7 ProtocolHeaderName ClientProtocol ProxyServersCerificates SapCacheControl 86400 ServetinputStreamTimeout 180000 SersdetsLongDataTransferLimit 131072 SerdietsLongDataTransferTimeout 180000 E false Connected to portalsim2 informatik tu muenchen de Abbildung 3 23 Aktivierung des HTTP Access Trace inklusive Antwortzeiten Quelle eigene Darstellung Die Trace Datei findet sich unter log system httpaccess responses trc und kann f r jeden Java Server und Dispatcher einzeln konfiguriert werden Systemarchitektur und Monitoring 93 3 2 6 Monitoring des Garbage Collectors Wie bereits in Kapitel 3 1 5 beschrieben k nnen ber den IBM JVM Parameter v
214. iner steigenden Anzahl von Benutzern betrachtet Neben der Ge nauigkeit der Simulationswerte werden die Ursachen f r das Leistungsverhalten in den ent sprechenden Lastbereichen untersucht W hrend im ersten Szenario die Leistung des Portal systems bei gen gend Hardware Ressourcen unter die Lupe genommen wird werden im zweiten Szenario die Bedingungen versch rft indem bestimmte Hardware bzw Systemres sourcen verknappt werden Aus den Erkenntnissen dieser Ergebnisse werden im Anschluss der System Overhead und das Java Speichermanagement analysiert da diese im Hochlastbe reich einen starken Einfluss auf das Antwortzeitverhalten aus ben Der Vergleich der Mess und Simulationswerte widmet sich neben der Darstellung der Akku ratesse ebenso der Ursachenanalyse f r das Leistungsverhalten und etwaigen Abweichungen Dabei wird gepr ft wie sich die Einflussgr en auf das Antwortzeitverhalten auswirken und ob sie von dem Simulationsmodell entsprechend erfasst werden Diese Analyse zeigt ob die identifizierten Einflussgr en aus Forschungsfrage 1 das Antwortzeitverhalten ausreichend genau beschreiben und untersucht die Gr nde f r potentielle Abweichungen Dabei muss zwi schen Einschr nkungen bei der Messung und Parametrisierung sowie nicht explizit modellier ten Einflussgr en unterschieden werden Das Ergebnis von Forschungsfrage 3 ist somit die Evaluation des in Forschungsfrage 2 er stellten Artefakts mittels einer Fallstudie Die Be
215. ing of a java based session initiation protocol SIP application server Proceedings of the joint ACM SIGSOFT conference QoSA and ACM SIGSOFT symposium ISARCS on Quality of software architectures OoSA and architecting critical systems ISARCS S 63 72 Boulder Colorado USA ACM Franks G Maly P MWoodside M Petriu D Hubbard A 2012 Layered Queueing Network Solver and Simulator User Manual Department of Systems and Computer Engineering Carleton University Ottawa Canada 2012 Gadatsch A 2002 Management von Gesch ftsprozessen 2 berarb u erw Aufl Vieweg Verlag Braunschweig Wiesbaden 2002 Gamma E Helm R Johnson R Vlissides J 1995 Design Patterns Elements of Reusable Object Oriented Software 1 Aufl Addison Wesley Longman Publishing Co Inc Amsterdam 1995 Gibson J C 1970 The Gibson Mix TR 00 2043 IBM Systems Development Division Poughkeepsie NY USA 1970 Gomaa DA Menasc D A Kerschberg L 1996 A Software Architectural Design Method for Large Scale Distributed Information Systems In Distributed Systems Engineering Vol 3 1996 Nr 3 S 162 172 Gootzit D 2008 Key Issues for Enterprise Portals In Gartner Research 2008 Gordon W J Newell G F 1967 Closed Queueing Systems with Exponential Servers In Operations Research Vol 15 1967 Nr 2 S 254 265 G rtz M Hesseler M 2008 Basiswissen ERP Systeme Auswahl Einf hrung amp E
216. iniert werden Als Beispiel f r Redundanzfreiheit kann das von Robertazzi 2000 dargestellte Routing System angef hrt werden welches lediglich Pakete empf ngt und sendet Die durchschnittli che Anzahl n von Paketen im System kann mittels Little s Law Little 1961 errechnet wer den Transaction Processing Council http www tpc org Theoretische Grundlagen 32 N A T A ist hierbei die durchschnittliche Ankunftsrate T stellt die durchschnittliche Wartezeit dar Wie man unschwer erkennen kann reicht es aus entweder n oder T als Metrik zu w hlen da sich der jeweils zweite Wert aus den anderen Werten errechnen l sst Die dritte Eigenschaft Vollst ndigkeit bedeutet dass mit den gew hlten Metriken alle ge w nschten Performance Indikatoren abgedeckt werden sollen Leistungskenngr en k nnen zudem nach Zeit Durchsatz und Auslastung kategorisiert wer den Rechenberg Pomberger Pirklbauer 2006 454 Kenngr en zur Zeit Die Kenngr e Zeit kann in messbare Gr en unterteilt werden Die Bedienzeit auch Service Zeit genannt ist die Bearbeitungszeit in einem System also die Zeit die zur Abarbeitung eines Programms ben tigt wird Die Wartezeit be schreibt die aufsummierte Zeit die ein Programm auf seine Ausf hrung wartet Die Verweil oder Antwortzeit setzt sich aus Bedien und Wartezeit zusammen Sie be schreibt die gesamte Zeit vom Eintreffen bis zum Abgang eines Auftrags In diesem Zusammenhang treten auch
217. insatz betriebswirtschaftlicher Standardsoftware 1 Aufl W3L Verlag Herdecke Witten 2008 Gradl S 2012 Performance Modellierung und Simulation eines SAP ERP Systems Technische Universit t M nchen 2012 Graham R 1975 Performance prediction In Software Engineering Lecture Notes m Computer Science Vol 30 Hrsg Bauer F Dennis J Waite W Gotlieb C Literaturverzeichnis 195 Graham R Griffiths M Helms H Morton B Poole P Tsichritzis D Springer Berlin Heidelberg 1975 S 395 463 Gray K 1991 The Benchmark Handbook for Database and Transaction Processing Systems Morgan Kaufmann San Francisco 1991 Gro mann M Koschek H 2005 Unternehmensportale Grundlagen Architekturen Technologien Springer Verlag Berlin Heidelberg 2005 Haas M Zorn W 1995 Methodische Leistungsanalyse von Rechensystemen Oldenbourg M nchen Wien 1995 Haerder T Reuter A 1983 Principles of transaction oriented database recovery In ACM Comput Surv Vol 15 1983 Nr 4 S 287 317 Harris N Jeyakumar L R Mann S Sumarga Y Wei W 2005 Logical Partitions on the IBM PowerPC IBM 2005 Hartmann S 1996 The World as a Process Simulations in the Natural and Social Sciences In Modelling and Simulation in the Social Sciences from the Philosophy of Science Point of View Hrsg Hegselmann R 1996 Heilig L Karch S 2007 SAP NetWeaver Master Data Management Galileo Pre
218. ird somit nur der Effekt der Verdrangungen und Invalidierungen modelliert 4 2 5 Datenbank Das Datenbanksystem wird wie bereits in den vorangegangenen Kapiteln erw hnt als Black box betrachtet Dies hat auf der einen Seite zwar den Nachteil dass datenbankinterne Abl ufe wie zum Beispiel interne Puffer des Datenbanksystems nicht explizit modelliert werden k nnen auf der anderen Seite ist dadurch die Modellierung der Datenbankkomponente her stellerunabh ngig Zudem wird der Schwerpunkt auf die Applikationsschicht des in dieser Arbeit betrachteten SAP Netweaver Portal System gewahrt da die feingranulare Modellie rung eines Datenbanksystems eine ebenso hohe Komplexit t aufweisen w rde Datenbankaufrufe k nnen Sperren erfordern siehe Kapitel 4 2 3 vom Puffer bedient werden siehe Kapitel 4 2 4 oder direkt also ohne vorherige Sperranfragen an das Datenbanksystem gerichtet sein Die einzelnen Service Zeiten der im Workload durchgef hrten Aufrufe sowie die Wartezeiten auf eine freie Datenbankverbindung der Verbindungspool des JDBC Services ist standard m ig auf 10 pro Java Server Instanz begrenzt werden im funktionalen Trace siehe Kapi tel 3 2 3 wiedergegeben LQN Modellierung Zur Darstellung des Datenbanksystems als Black Box ist es ausreichend einen LQN Task zu modellieren Die Multiplizit t gibt dabei die Anzahl der Datenbankverbindungen an die vom JDBC Service im Verbindungs Pool vorgehalten werden Die einzelnen
219. it einem Benutzertask vergleichbar der eine synchro ne Anfrage alle a Zeiteinheiten nach dem Erhalt der Antwort der letzten Anfrage sen det Dies wird ber die Denkzeit des GC Client Tasks realisiert und stellt das durch schnittliche GC Intervall zwischen den GC L ufen dar Die Aufrufe m ssen die ge samte Zeitspanne der Simulation durchgef hrt werden also GCintervatt GCpauer Aufrufanzahl gt Simulationsdauer Es ist ausreichend die Anzahl der ben tigten GC Aufrufe unter dieser Bedingung ab zusch tzen da in der Simulationsausgabe unter anderem die gesuchten Antwortzeiten der Benutzertasks wiedergegeben werden und somit bersch ssige GC Aufrufe keinen Einfluss auf die Ergebnisse nehmen GC Sim Die Komponente GC Sim ahmt einen GC Lauf nach indem die eingehenden Anfragen vom GC Client mit einer Bearbeitungszeit von u bearbeitet werden Die Be arbeitungszeit u entspricht somit der durchschnittlichen GC Dauer Eine weitere Entry des GC Sim Tasks hat eine Bearbeitungszeit von 0 und nimmt eingehende Anfragen von den Lastschritten entgegen Die Multiplizit t der GC Sim Komponente betr gt 1 LON Modell 130 Zudem wird bei jedem Lastschritt ein Aktivit tsgraph modelliert der aus einer Sequenz von mehreren Aktivit ten besteht 1 Zun chst wird eine synchrone Anfrage an den GC Sim Task gesendet Sollte der GC Sim Task gerade nicht belegt sein wird die Antwort sofort zur ckgesendet Ansonsten ist der GC Sim Task gerade
220. it erheblich sodass die Eignung eines Lastgenerators stark von dem zu untersuchenden Objekt abh ngt Jianyi Zhengqiu 2008 Beispielsweise sind nicht alle Werk zeuge in der Lage auf dynamische R ckmeldungen ad quat zu reagieren Die Benutzer schnittstelle des SAP Netweaver Portals weist einige Charakteristika auf die von einem Lastgenerator ber cksichtigt werden m ssen und daher im Folgenden vorgestellt werden Im Anschluss wird auf den verwendeten Lastgenerator eingegangen 5 3 1 Charakteristiken der Benutzerschnittstelle Die Web Schnittstelle des SAP Netweaver Portal Systems bedient sich verschiedener Erwei terungen die nicht in den Bereich der klassischen HTML Spezifikation W3C 2011 fallen Die zus tzlich verwendeten Technologien zu denen JavaScript AJAX Eichorn 2006 und dynamisches HTML DHTML Klein 2000 z hlen erm glichen zum einen zus tzliche Funk tionen der Benutzerschnittstelle zum anderen wird die Datenmenge die zwischen Benutzer und Server gesendet wird reduziert Allerdings f hrt die Verwendung dieser Technologien auch dazu dass nicht alle Web Browser vom SAP Netweaver Portal System unterst tzt wer den Das prominenteste Beispiel der Zusatzfunktionen im SAP Netweaver Portal System ist die Verwendung von Kontextmen s die ber die rechte Maustaste aufgerufen werden Die darin angebotenen Funktionen sind kontextspezifisch und erm glichen eine von Microsoft Windows bekannte Handhabung durch einen Recht
221. k Simulator LRU Least Recently Used LUW Logical Unit of Work MRP Material requirements Planning MRP II Manufacturing Resource Planning MRP III Money resource Planning MVA Mean Value Analysis NFS Network File System Abk rzungsverzeichnis OS PARASOL PEER PCD PMAT PPR PS QPN RISC RR SAAS SAP SAP SID SAP UA SAP UCC SAPS SAT SDN SID SLA SPEC SQL SUN TPC TPN TPS TUM UA UCC VIO W3C XML XII Operating System Parallel Simulation Object Library Performance Evaluations Cockpit f r ERP Systeme Portal Content Directory Pattern Modeling and Analysis Tool Priority Preemptive Resume Processor Sharing Queueing Petri Nets Reduced Instruction Set Computer Round Robin Software as a Service Systeme Anwendungen und Produkte in der Datenverarbeitung SAP System Identifier SAP University Alliances SAP University Competence Center SAP Application Performance Standard Single Activity Trace SAP Developer Network siehe SAP SID Service Level Agreement Standard Performance Evaluation Corporation Structured Query Language Stanford University Network Transaction Processing Performance Council Time d Petri Nets Transaction per Second Technische Universit t M nchen siehe SAP UA siehe SAP UCC Virtual Input Output World Wide Web Consortium Extended Markup Language Einleitung 1 1 Einleitung Viele Bereiche der Natur Sozial und Wirtschaftswissenschaften sind ohne den Einsatz von c
222. kdaten werden vom DSR Collector st ndlich gesammelt aggregiert und in die CCMS Datenbank geschrieben Uber die SAP Transaktion ST03G k nnen diese angezeigt werden Damit die Leistungsdaten die in der letzten Stunde gesammelt und folglich noch nicht in die Datenbank geschrieben wur den ebenfalls aufgenommen werden k nnen die Daten auch direkt vom DSR Collector gelesen werden Einzeldatens tze Statistikrohdaten und Performance Traces k nnen ber die SAP Transaktion STATTRACE auch funktionaler Trace genannt abgerufen werden Der funktionale Trace bietet die feinste Granularit t der erfassten Leistungsdaten J2EE Instanz SAP Monitoring System CEN Gesamter Trace einzelne Datens tze STATTRACE i Write API gd CCMS Agent Performance Daten Aggregierte DSR Daten Collector STO3G Datenbank Abbildung 3 17 Architektur des zentralen Monitoringsystems CEN Quelle eigene Darstellung In den DSR Datens tzen wird ebenfalls festgehalten auf welchem Service Typ sich die Leis tungsdaten beziehen Die Servicearten einer J2EE Instanz teilen sich in Web Anfragen EJB Anfragen Sicherheits Tasks und System Tasks auf vgl Container Typen des Java Servers in Kapitel 3 1 1 Zudem werden Datens tze zu Datenbankaufrufen festgehalten Da sich Portaloperationen ber verschiedene Instanzen unterschiedlichen technologischen Stacks ABAP Java und Hosts erstrecken k nnen ist es notwendig dass die Leistun
223. keit dem arithmetischen Mittel x und die Grundwahr scheinlichkeit wird nicht ver ndert 1 NE 1 Zugriffsh ufigkeit lt x Zugriffsh ufigkeit gt x Das Intervall dieser Gewichtung liegt allerdings bei 0 Anzahl Objekte und muss daher in Abh ngigkeit von der Grundwahrscheinlichkeit Ppuffer auf das Intervall 0 ge trimmt werden Die daraus resultierende Gewichtung w ergibt sich somit ber die Bunter scheidung w f rw gt 1 wes Ppuffer Anzahl Objekte f w f rw lt 1 In Summe ergibt sich die Wahrscheinlichkeit mit der sich ein Objekt bei einem Zugriff im Puffer befindet mittels Pim_Puffer Ppuffer w Bei Invalidierungen verh lt sich das Prinzip hnlich Je fter ein Objekt invalidiert wurde dies ist aus dem Tabellenpuffer Trace ersichtlich desto h her wird die Wahrscheinlichkeit dass das Objekt aus der Datenbank gelesen wurde Auch hier m ssen wieder vereinfachende Annahmen erfolgen da der genaue Ablauf zwischen Zugriffen Verdr ngungen und Invalidie rungen nicht bekannt ist Hinzu kommt das bereits beschriebene Systemverhalten dass ein Objekt nachdem es invalidiert wurde f r eine gewisse Zeit nicht mehr in den Puffer geladen wird selbst wenn ein Lesezugriff darauf erfolgt Die Gewichtung des Invalidierungseinflusses i kann somit nur gesch tzt werden und muss ber mehrere Iterationszyklen und Rekalibrie rungen angepasst werden Will man nun die Wahrscheinlichkeit berechnen mit der
224. kgreifen k nnen wie beispielsweise Basisfunktionalit ten f r den Datenaustausch Monitoring Benutzermanagement etc Die Netweaver Plattform ist auf zwei technologischen S ulen Stacks genannt aufgebaut und zwar dem ABAP Stack und dem J2EE Stack SAP 2011b Der ABAP Stack r hrt noch von der betrieblichen Standardsoftware SAP R 3 her und wird st ndig weiterentwickelt Der Java Stack wurde im Zuge der bereits geschilderten In tegration von g ngigen Technologien eingef hrt und wird im Kapitel ber das SAP Netweaver Portal siehe Kapitel 2 1 2 n her erl utert Die Architektur der Anwendungsplatt form im Speziellen die 3 Schicht Architektur wird in Kapitel 2 1 1 1 dargestellt Die Komponente der Process Integration wird in das Business Process Management und den Integration Broker unterteilt Das Business Process Management unterst tzt die Mo dellierung und Automatisierung von Gesch fts und Integrationsprozessen ber Systemgren zen hinweg Der Integration Broker ist f r die Konvertierung und Zustellung der verschie denen Nachrichtenformate zust ndig und ist somit mit einem Service Bus zu vergleichen SAP 2011j Der Bereich der Information Integration umfasst die Bereiche Master Data Management Knowledge Management und Business Intelligence W hrend das Master Data Ma nagement eine zentrale Stammdatenverwaltung darstellt bietet das Modul Business Intelli gence Fu
225. kooperierende Systeme ber cksichtigt werden TPC verwaltet zum einen die Ergebnisse von Datenbankanwendungen dazu z hlen entscheidungsunterst tzende Systeme sowie Transaktionsverarbeitung zum anderen Paper and Pencil Benchmarks Paper and Pencil Benchmarks sind Benchmarks die Problemklas sen algorithmisch darstellen und die Implementierung unter bestimmten Regeln den Entwick lern berlassen Die ermittelten Leistungsma e werden normalerweise in der Transaktionsrate TPS Transaktionen pro Sekunde oder in Preis Leistungskenngr en angegeben Ein gro er Standard Performance Evaluation Corporation http www spec org Transaction Processing Performance Council http www tpc org Theoretische Grundlagen 59 Vorteil von TPC Benchmarks ist dass sie systemunabh ngig sind daf r aber auch sehr kom plex und aufwendig Haas Zorn 1995 216 Rechenberg Pomberger Pirklbauer 2006 460 2 6 3 Benchmark Typen Nachfolgend wird eine grunds tzliche Einordnung der Benchmarks durchgef hrt vgl Lilja 2000 112 116 Instruction Mix Ein Instruction Mix spezifiziert die Arten und die relative H ufigkeit der durchgef hrten Be fehle wie sie auch im realen Workload vorkommen Hu Gorton 1997 Danach wird die mitt lere Operationszeit T aus den Operationszeiten von n Befehlen berechnet n T pti i 1 t stellt hierbei die Operationszeit des Befehls i dar p die relative H ufigkeit des Auftretens Gewicht des Befehls i wobe
226. ktivit ten Durchschnittliche Anzahl an Rendezvous zwischen Entries bzw Aktivit ten Weiterleitungswahrscheinlichkeiten Phasentyp der Entries bzw Aktivit ten deterministisch oder stochastisch Simulation und Evaluation 167 Daraufhin werden die Ergebnisse des Simulationslaufs dargestellt Zuerst werden Angaben zu den durchschnittlichen Verz gerungen bei synchronen Anfragen und Vereinigungen wieder gegeben Im Anschluss folgen nach den einzelnen Phasen aufgeschl sselt die durchschnittli chen Service Zeiten f r die modellierten Entries bzw Aktivit ten Ungl cklicherweise wird der Begriff Service Zeit ebenfalls bei der Parametrisierung des Mo dells siehe Eingabedatei des Simulators Kapitel 5 6 1 verwendet und stellt dort die reine Bearbeitungszeit auch Bedienzeit genannt dar In der Ausgabedatei wird die durchschnittli che Service Zeit als Antwortzeit verstanden die sich aus folgenden Bestandteilen zusammen setzt den Wartezeiten am Prozessor den Wartezeiten bei synchronen Aufrufen weiterer Tasks der eigenen Bedien bzw Prozessorzeit den Bedienzeiten aufgerufener Tasks In dem in Kapitel 5 6 1 eingeftihrten Beispiel wiirde die Service Zeit der Lastschritt Entry des zweiten Interaktionsschrittes aus den Wartezeiten am Prozessor den Aufrufen des Tabellen puffers die bei Eintreten der Weiterleitung aus Warte und Bedienzeiten des Datenbank Tasks bestehen k nnen und der eigenen Bearbei
227. l fallt in die Kategorie der Unterneh mensportale einer speziellen Form der Portale Portale im Allgemeinen werden nach Nicolescu Klappert Kremar 2007 18 als Anwendungssysteme bezeichnet die durch die Integration von Anwendungen Prozessen und Diensten sowie durch die Bereitstellung von Funktionen zur Personalisierung Sicherheit Suche und Pr sentation von Informationen gekennzeichnet sind Gro mann Koschek 2005 32 definieren Unternehmensportale als ein geschlossenes Portal das den Anwendern einen individuellen personalisierbaren Zugang zu allen relevanten Inhalten bietet um alle Aufgaben bequem und schnell erledigen zu k nnen Dieser Zugang muss jederzeit und berall auf sicherem Weg erreichbar sein Zu den Anwendern eines Unter nehmensportals z hlen die Mitarbeiter des Unternehmens aber auch die Kunden Lieferanten oder Partner Das SAP Netweaver Portal war das erste J2EE basierte Produkt bei SAP und kann als zentra le Applikation zur Integration heterogener Anwendungen genutzt werden Die Integration der Daten unterschiedlicher Quellapplikationen geschieht typischerweise ber sogenannte Port lets die in der SAP Terminologie iViews genannt werden Popp 2002 23 Diese dynamische Integration wird mittels Drag and Relate Technologie Jay 2008 6 realisiert die logische Verkn pfungen zwischen Objekten von unterschiedlichen Applikationen erstellt So kann beispielsweise die Bestellung im ERP System zu de
228. lich 800 N oO CH O Su eh jo CH Wiederholungen 1 30 jo CH Wiederholungen 2971 3000 Bearbeitungszeit ms N LA D wow a fe Gi fe fe r Q 1 4 7 10 13 16 19 22 25 28 Lastschritt Abbildung 5 9 Oszillierende Messwerte Quelle eigene Darstellung 5 5 3 Messwiederholungen F r die einzelnen Messreihen w rde im Idealfall die Anzahl der Benutzer sukzessive um 1 erh ht werden Zudem sollten aufgrund des zentralen Grenzwertsatzes mindestens 30 Wie derholungen erfolgen Bei einer Grenzlast von 120 simultan agierenden Benutzern w rde dies zu 120 mal 30 Durchl ufen der modellierten Fallstudie f hren Bei einer gesch tzten Dauer von ca 200 bis 2000 Sekunden je nach Anzahl der Benutzer w rde dies einer gesamten Ausf hrungszeit von 200 bis 2000 Stunden entsprechen Daher wurde die Anzahl der Benut zer nicht jeweils um 1 sondern in 20er Schritten erh ht Bei 5 Wiederholungen zum Ein schwingen und 30 gemessenen Wiederholungen f hrt dies zu 245 Durchl ufen der Fallstudie und entspricht bei einer vorab gesch tzten mittleren Ausf hrungszeit von 500 Sekunden einer Gesamtdauer von 34 Stunden 5 5 4 Szenario 1 Ausreichende Systemressourcen Wie bereits dargestellt werden im ersten Szenario die Systemressourcen in ausreichendem Ma e bereitgestellt Zu Beginn werden die kumulierten Antwortzeiten f r die Durchf hrung der modellierten Portalfallstudie in Abh ngigkeit von einer
229. lich wird die Summe f r die einzelnen Tasks errechnet Der Durchsatz spiegelt die Anzahl an Aufrufen pro Zeiteinheit wider Der wiedergegebene Wert der Nutzung liegt im Bereich 0 lt Nutzungxomponente lt M wobei m die Multiplizit t der Komponente spezifiziert Er stellt somit die durchschnittliche Anzahl an verwendeten Threads dar ber die Nutzung der Komponenten k nnen potentielle Flaschenh lse erkannt werden Zeigt beispielsweise der Datenbanktask eine sehr hohe Nutzung der Threads bei einer durchschnittlichen Systemlast kann eine Erh hung der Datenbankverbindungen den Fla schenhals beseitigen Ebenso k nnen hohe Sperrzeiten einzelne Applikations Threads blo ckieren Sollten noch Systemressourcen vorhanden sein jedoch keine freien Applikations Threads mehr zur Verf gung stehen liegen diese brach Auch hier w rde eine Erh hung der Anzahl an Applikations Threads dem Flaschenhals entgegenwirken Der letzte Abschnitt der Ausgabedatei widmet sich der Nutzung und den Wartezeiten der mo dellierten Prozessoren Auch hier spiegelt die Nutzung die durchschnittlich verwendeten Ker ne des Prozessors wider und entspricht somit einem Wert von 0 lt Nutzungcpy lt m wobei m die Multiplizit t des Prozessors darstellt Liegt der Wert nahe m kann von einem Engpass an CPU Ressourcen ausgegangen werden Wartezeiten bei den Prozessorressourcen entstehen dann wenn eine Anfrage einer Kompo nente von dem entsprechenden Prozessor Task nicht sofo
230. ll normalverteilter Stichproben Liegt die Stichprobengr e bei 30 oder mehr kann aufgrund des Zentralen Grenzwertsatzes von einer Normalverteilung ausgegangen werden vgl bspw Zwerenz 2009 343 und mit Hilfe des z Werts das Konfidenzintervall berechnet werden Der z Wert ergibt sich aus dem gesch tzten Mittelwert x und dem unbekannten Mittelwert der Grundgesamtheit u und wird durch den Standardfehler geteilt Berman 2008 Ku Damit ein Konfidenzintervall f r den Mittelwert u aufgestellt werden kann muss der ge w nschte Vertrauensgrad angegeben werden damit der dem z Wert entsprechende Anteil ermittelt werden kann Die Berechnung des Konfidenzintervalls folgt schlie lich aus einer Umformung der Gleichung f r den z Wert Konfidenzintervall u x z Wert x Standardfehler Der Wert z Wert x Standardfehler wird auch als Fehlertoleranz der Stichprobe be zeichnet Theoretische Grundlagen 29 2 2 2 Messfehler Bei jeder Messung muss damit gerechnet werden dass der Messwert aufgrund von St rgr Den vom eigentlichen Wert abweicht Daher ist eine Fehlertheorie von N ten die sich mit der Sch tzung des wahren Wertes aus einer Reihe von fehlerbehafteten Messwerten mit dem Fehler dieser Sch tzung und der Fehlerfortpflanzung bei Verwendung in arithmetischen Ausdr cken beschaftigt Jaenecke 1982 Grunds tzlich wird zwischen zuf lligen und systematischen Fehlern unterschieden Der Un tersch
231. llenpufferung die davon abh ngigen Bearbeitungszeiten der Datenbank aufrufe abgebildet werden Die Evaluation der Ergebnisse zeigt zudem dass im berlastbe reich u ere Einflussfaktoren die von dem Modell nicht erfasst werden das Antwortzeitver halten entscheidend mitbestimmen und infolgedessen die Simulationsgenauigkeit stark beein tr chtigen Eine Ursachenanalyse verdeutlicht hierbei den hohen Wirkungsgrad der Garbage Collector Aktivit ten auf die erzielten Antwortzeiten Auswirkungen auf die Praxis Das in dieser Arbeit entwickelte Modell stellt einen neuarti gen Ansatz zur Ex Ante Leistungsanalyse eines SAP Netweaver Portal Systems dar Die Frage wie sich das System bei einer zunehmenden Lastintensit t aufgrund von ansteigenden Benutzerzahlen verh lt wird in der Praxis h ufig gestellt und kann mit dem vorgestellten Vorgehen fr hzeitig analysiert werden Aufgrund der hohen Marktdurchdringung von SAP Systemen und der starken Integration in die Gesch ftsprozesse eines Unternehmens weist das erstellte Artefakt eine hohe Relevanz auf Der Modellierungsansatz l sst sich ebenfalls auf architekturverwandte Systeme bertragen sodass lediglich das abgebildete Lastmuster sowie die Parametrisierung der Modellkomponenten angepasst werden m ssen Zus tzlich kann die Leistungsvorhersage im Zuge der Kapazit tsplanung f r eine Kosten Leistungs Analyse ver wendet und ben tigte Hardwareressourcen spezifiziert werden Inhaltsverzeichnis II
232. luation sehr aufge schlossen gegen ber Zwei Drittel erachten diese als sehr wichtig allerdings werden aus schlie lich die in den ERP Systemen integrierten Hilfsmittel zur Leistungsanalyse genutzt Als Grund f r den Verzicht auf weitere Hilfsmittel werden der notwendige Einarbeitungs und Betreuungsaufwand sowie zus tzliche Kosten genannt Knapp 70 Prozent der Befragten nutzen Lasttests jedoch nur ein Viertel verwendet analyti sche Modelle zur Performance Evaluation und nur etwa ein Drittel der Umfrageteilnehmer setzt Simulation ein Damit einhergehend wird nur selten versucht Prognosen ber die Eig nung der genutzten ERP Systeme f r zuk nftige Lastprofile zu erstellen Als Ursache hierf r werden funktionale Schw chen der verwendeten Werkzeuge genannt Zudem f hrt ein man gelndes Vertrauen in die Akkuratesse der prognostizierten Werte zu dem geringen Einsatz Keiner der Befragten ist voll zufrieden mit der Reliabilit t 62 5 Prozent sind im Allgemeinen zufrieden und ein Viertel der Befragten ist nur teilweise zufrieden mit den Ergebnissen der eingesetzten Hilfsmittel Nichtsdestotrotz werden die Vorteile der Leistungsanalyse von ERP Systemen gesehen vor allem in Bezug auf Effizienz 85 29 Risikominderung 76 47 h here Flexibilit t 50 sowie Kostenreduktion 44 12 Ebenso wurde in den freien Anmerkungen mehrfach betont dass ein reges Interesse an einer Entwicklung zus tzlicher Methoden und Hilfsmittel zur Leis tungsanaly
233. m AIX IBM 2011b wobei viele der vorgestell ten Tools auch f r andere Unix Derivate zur Verf gung stehen wenngleich in leicht ver n derter Form Tabelle 3 11 gibt einen kurzen berblick ber die in AIX vorhandenen Performance Tools f r die drei fundamentalen Systemressourcen sowie die explizit dargestellten Netzwerk und Prozessmonitore Ressource Programm CPU topas mpstat vmstat iostat sar time timex Hauptspeicher topas vmstat Isps ipcs ps VO Subsystem topas iostat vmstat lvmstat Isps Isdev Ispv Isvg Islv Netzwerk topas netstat atmstat entstat tokstat fddistat nfsstat Prozesse Threads topas pstat ps Tabelle 3 11 Monitoring Tools auf Betriebssystemebene AIX Quelle eigene Darstellung Einige Betriebssystem Hilfsmittel berschneiden sich in ihrer Funktionalit t und liefern Per formance Daten f r verschiedene Systemressourcen Ein generelles Werkzeug zur Leistungs berwachung ist topas IBM 2011h Vor allem bei den in dieser Arbeit verwendeten virtu ellen Hosts sogenannten logischen Partitionen LPAR Harris et al 2005 bietet topas die M glichkeit zwischen virtuellen Ressourcen und Ressourcen des physikalischen Hosts zu unterscheiden Zus tzlich zur interaktiven Wiedergabe der aktuell verwendeten Systemressourcen mittels topas werden zwei Hilfsmittel zur Aufzeichnung und Ausgabe der Daten bereitgestellt to pasrec IBM 2011k und topasout
234. m entsprechenden Kundensatz im Custo mer Relationship Management System CRM System gezogen werden Die grunds tzliche Architektur des SAP Netweaver Portals ist in Abbildung 2 6 dargestellt und basiert auf den folgenden Kernkomponenten HTTP Anfrage SAP Application Server Java Portal Laufzeit J2EE Anwendungen und Dispatcher Servlet Services Portal Applikationen Benutzermanagement Portal Komponenten Connector Framework Portal Dienste Abbildung 2 6 Portal Architektur Quelle eigene Darstellung in Anlehnung an SAP 2011m Theoretische Grundlagen 24 Die Portal Laufzeit stellt die Laufzeit f r die Portal Komponenten und Portal Dienste zur Verf gung Die eingehenden HTTP Anfragen werden ber ein Dispatcher Servlet an die Portal Komponenten weitergereicht Portal Applikationen bestehen aus einer Sammlung aus bereits zur Verf gung gestell ten Kernapplikationen zum Beispiel zur Darstellung von Navigationsleisten oder i Views sowie optionalen Eigenentwicklungen Dabei wird zwischen den bereits ge nannten Portal Komponenten und Portal Diensten unterschieden Letztere werden den Portal Components zur Verfiigung gestellt beispielsweise dem Java Naming and Directory Provider JNDI Provider fiir den Zugriff auf das Portal Content Directory Das Portal Content Directory PCD beinhaltet semantische Objekte wie zum Beispiel iViews Die J2EE Laufzeit Umgebung stellt weitere Applikationen bereit
235. mance Vorhersage mittels Simulation auch im Kontext der Kapazit tsplanung herangezogen werden Allerdings beschr nkt sich die Aussagekraft haupts chlich auf die Prognose der Ska lierbarkeit eines vorhandenen Systems da neue Hardwarekomponenten und eine Vielzahl an Konfigurationsm glichkeiten erst vermessen werden m ssten Fazit 190 6 3 Ausblick Das in dieser Arbeit entwickelte Artefakt bzw die bei der Evaluation erzielten Simulationser gebnisse sind abgesehen vom berlastbereich als positiv zu bewerten In Hinblick auf zu k nftige Forschungst tigkeiten k nnen verschiedene Modellerweiterungen angestrebt werden die sich aus den im vorangegangenen Abschnitt dargestellten Limitationen ableiten Das Datenbanksystem wurde in dieser Arbeit als Black Box betrachtet Da jedoch die Per formance der Persistenzschicht einen wesentlichen Einfluss auf die Gesamtleistung des Sys tems nimmt kann eine feingranulare Modellierung des Datenbanksystems besseren Auf schluss ber potentielle Leistungsengp sse im I O Bereich geben Die heterogenen Daten bankarchitekturen verschiedener Hersteller erfordern jedoch unterschiedliche Submodelle sodass auch hier nur ein herstellerabh ngiger Ansatz gew hlt werden kann Eine weitere M glichkeit zur Parametrisierung der Datenbank als Black Box stellen multidimensionale Regressionsverfahren dar die beispielsweise ber einen evolution ren Algorithmus realisiert werden k nnen Tertilt Kremar 2011 Tertilt
236. maphor f r die Dauer der Abar beitung besch ftigt und bearbeitet keine weiteren Anfragen Damit diese Transformation nicht mehr durchgef hrt werden muss wurde 2011 ein eigener Semaphor Task in die LQN Modellierung eingef hrt Franks 2011 Des Weiteren k nnen offene Warteschlangensysteme nicht nativ abgebildet werden Shousha et al 1998 schlagen deshalb eine Transformation des offenen Systems in ein geschlossenes Modell vor indem die Ankunftsrate 2 anhand von reinen Clients mit sehr geringer Bedienzeit damit das Performance Verhalten nicht verf lscht wird abgebildet wird Zudem m ssen asynchrone Aufrufe in weitergeleitete Aufrufe transformiert werden damit Anfragen nur dann akzeptiert werden wenn die notwendige Kapazit t vorhanden ist 2 5 4 L sen und Simulieren von LQN Modellen F r das analytische L sen und Simulieren von LQN Modellen wurden von der Real Time and Distributed Systems Group zwei Werkzeuge entwickelt und zwar der LONS LQN Solver und der LQsim LQN Simulator 2 5 4 1 LQN Solver Der LQNS der von Greg Franks entwickelt wurde Franks 1999 l st LQN Modelle nach einem analytischen Verfahren Die LQN Schichten werden dabei in separate Warteschlan gennetze Teilmodelle aufgegliedert und mittels Mean Value Analysis Petriu 1994 kurz MVA gel st Das MVA Ergebnis eines Teilmodells wird dann zur Feinabstimmung der ver bundenen Teilmodelle verwendet Am Ende der Kalibrierung wird die MVA er
237. matisch ausgedr ckt werden Die mathematischen Ausdr cke wiederum beinhalten Formeln oder auch eine graphische Repr sentation die mathematisch beschrieben werden kann Zum L sen des Modells k nnen diverse Simulationsans tze oder analytische Verfahren herangezogen werden Analytische Modelle basieren auf einer Reihe von Formeln und numerischen Algorithmen die zur Generierung von Performance Metriken von Modellparametern verwendet werden Performance Modellierungs Formalismen k nnen grunds tzlich in zwei Klassen eingeteilt werden deterministisch und probabilistisch Bei deterministischen Modellen sind die Mess gr en festgelegt wobei bei probabilistischen Modellen ein gewisses Ma an Ungewissheit m glich ist vgl Jonkers 1994 Zu den bekanntesten probabilistischen analytischen Model len z hlen Markov Ketten und Petri Netze die in diesem Kapitel vorgestellt werden sowie Warteschlangennetze die in Kapitel 2 4 n her beschreiben werden Zur Darstellung der gesammelten Leistungsdaten werden bei der analytischen Modellierung einfache mathematische Ausdr cke verwendet die in kurzer Zeit rechnerisch gel st werden k nnen Die Vereinfachung der Charakteristiken f hrt allerdings oft auch dazu dass das Mo Theoretische Grundlagen 38 dell das Systemverhalten nicht mehr ausreichend korrekt darstellt und somit zu inakkuraten Ergebnissen f hrt Dennoch f hren sehr viele Modelle in der Praxis zu annehmbaren Ergeb nissen die typischer
238. me Ein priorit tsbasierter Mechanismus bei dem An fragen mit einer h heren Priorit t sofort abgearbeitet werden sobald sie bei dem Task ankommen Priorit ten werden in den Entries mit einer Reichweichte zwischen 0 und o angegeben wobei der Standardwert 0 betr gt HOL Head of Line Priority Ebenfalls ein priorit tsbasierter Mechanismus bei dem allerdings die aktuell ausgef hrte Anfrage nicht unterbrochen wird und erst nach Be endigung die Anfrage mit erh hter Priorit t abgearbeitet wird Die einzelnen Entries des Tasks die in Kapitel 2 5 1 beschrieben wurden stellen die Operati onen dar die von dem Task durchgef hrt werden k nnen Hinsichtlich der eingehenden und ausgehenden Aufrufe wird unterschieden zwischen synchronen asynchronen und weitergelei teten Aufrufen Synchrone Anfragen werden auch als Rendezvous bezeichnet Zudem senden Entries die Antworten bei einem eingegangenen synchronen Aufruf Die Parameter einer Entry k nnen entweder lediglich ber Phasen oder ber zus tzliche Aktivit ten definiert wer den Es wird zwischen drei Phasen unterschieden wobei die erste Phase die Service Phase dar stellt die mit dem bereitgestellten Dienst einer Bedienstation in einem Warteschlangennetz verglichen werden kann Phase 2 und 3 sind autonome Phasen die nach dem Senden der Antwort durchlaufen werden Aktivit ten werden dann eingesetzt wenn das interne Verhalten einer Entry ein komplexeres Muster aufweist beisp
239. mehrere Kopien eines Tasks vorhanden sind die den bereitgestellten Dienst parallel abarbeiten k nnen Dazu werden beispielsweise in einem SAP Netweaver Portal System mehrere Server Instanzen konfiguriert die jeweils wiederum mehrere Threads aufweisen Bei der Modellierung dieser Parallelit t stehen zwei Varianten zur Verf gung Multiplizit t und Replizierung Eine Multiplizit t gr er eins kann mit einem Server verglichen werden der mehrere parallele Threads ausf hrt Replizierung hingegen ist eine weitere Instanz des Servers Der Hauptunter schied liegt dabei darin dass bei einem Server Task mit einer Multiplizit t gr er eins ein und dieselbe Warteschlange geteilt wird wobei bei mehreren Server Repliken jede Replik ihre eigene Warteschlange bereitstellt siehe Abbildung 4 4 3 1 Multi Server 2 Multiple Repliken Abbildung 4 4 Multiplizit t und Replizierung Quelle eigene Darstellung nach Franks et al 2012 Mit den Server Repliken k nnen somit mehrere Server Instanzen mit der Multiplizit t mul tiple Threads abgebildet werden Die Anwendung von Server Repliken reicht jedoch nur dann aus wenn die einzelnen Server Instanzen echte Kopien sind sowohl die unterst tzten Opera LQN Modell 112 tionen Entries als auch die Prozessoren m ssen identisch sein Sollten verschiedene Server Instanzen Unterschiede aufweisen m ssen sie explizit modelliert werden und eine Dispat cher Einheit vorgeschalten werden die die Anf
240. melte Menge an Garbage fiir k Benutzerinteraktionen k ProcessingSpace ML Framework Space k Benutzerinteraktionen Q Qo 1 1 gt 3 Sa 53 t D oo en t E of o S 3 Abbildung 3 13 Messverfahren bei einem Mehrbenutzer Lasttest einer Java Applikation Quelle Cheng 2008 Wie bereits erw hnt eignet sich diese Performance Betrachtung vor allem f r eine konkrete Java Anwendung beispielsweise f r die Code Optimierung F r die Leistungsanalyse eines SAP Netweaver Portalsystems unter einer bestimmten Last und Laufzeitkonfiguration wie sie in dieser Arbeit durchgef hrt wird haben diese Indikatoren wenig Aussagekraft Wie in Kapitel 5 8 noch dargestellt wird nimmt der Garbage Collector einen entscheidenden Einfluss auf die Performance des Portalsystems insbesondere im Hochlastbereich Daher ist es unabdingbar das Verhalten des Garbage Collectors zu analysieren Zur Evaluierung des GC Einflusses k nnen vor allem zwei Indikatoren herangezogen werden Cheng 2008 GC Dauer Die GC Dauer gibt die durchschnittliche Laufzeit eines GC Zyklus an Ein hoher Wert hat einen negativen Einfluss auf die System Performance GC Intervall Das GC Intervall gibt die durchschnittliche Zeit zwischen den GC Zyklen an Unter der Annahme dass die durchschnittliche Lebensdauer eines Objektes konstant bleibt ist ein GC Zyklus umso effizienter je h her das Intervall zwischen zwei GC
241. n sie sind einfacher zu entwickeln und die Anschaffungskosten sind geringer Jedoch haben sie generell eine niedrigere Ein gabegeschwindigkeit eine niedrigere Aufl sung und einen h heren Overhead da die Softwaremonitore mit anderen Prozessen des Objektsystems konkurrieren Jain 1991 95 Dieser Ressourcenverbrauch f hrt oft zu einer Verf lschung der Laufzeit und so mit des dynamischen Verhaltens des zu untersuchenden Objektes Software Monitore werden somit meist dann bevorzugt wenn sichergestellt ist dass das Zeitgef ge des zu messenden Systems nur unbedeutend gest rt wird Zitterbart 1990 Hybrid Monitore Hybrid Monitore sind eine Kombination aus einem Hardware und einem Software Monitor Ziel ist es die positiven Charaktereigenschaften beider Mo nitortypen in einem Typ zu vereinen Somit besitzt ein Hybridmonitor sowohl eine Software also auch eine unterst tzende Hardware Komponente Die gute Datenauf bereitungsm glichkeit des Softwaremonitors wird mit der guten Aufl sung und dem geringen Overhead des Hardwaremonitors kombiniert Die Softwarekomponente hilft die gew nschten Messdaten im Objektsystem zu ermitteln Die Hardware dient mit ei ner geeigneten Zeitbasis und einem Speicher zur Speicherung der Messdaten diese chronologisch zu erfassen und anschlie end zu speichern Zieher 1989 24 Eine weitere m gliche Klassifizierung ist nach dem Ausl semechanismus in zeitbasierte und ereignisbasierte Monitore m glich
242. n 1974 S 249 264 Cheng X 2008 Performance Benchmarking and Sizing in Developing Highly Scalable Enterprise Software Proceedings of the SPEC international workshop on Performance Evaluation Metrics Models and Benchmarks S 174 190 Darmstadt Germany Springer Verlag Cheng X Morrison T 2007 Best Practices for Java Performance and Load Tests In SAP Ed Teched 2006 Las Vegas Davis C Orb W Koechl M Calio C 2006 SAP Enterprise Portal on AIX 5 3 and POWERS IBM SAP Technical White Paper Walldorf 2006 Dijkstra E W 1971 Hierarchical Ordering of Sequential Processes In Acta Informatica Vol 1 1971 Nr 2 S 115 138 Doherty W J 1970 Scheduling TSS 360 for Responsiveness In AFIPS 1970 FJCC Vol 37 Hrsg AFIPS Press Montvale N J 1970 S 97 111 Domschke W Drexl A 2007 Einf hrung in Operations Research 7 berarb Aufl Springer Berlin 2007 Dongarra J J Moler C B Bunch J R Steward G W 1979 LINPACK User s Guide Society for Industrial and Applied Mathematics 1979 Eichorn J 2006 Understanding AJAX Using JavaScript to Create Rich Internet Applications Prentice Hall PTR Upper Saddle River NJ 2006 Eilert J Eisenhaendler M Matthaeus D Salm I 2003 Linux on the Mainframe Prentice Hall PTR Englewood Cliffs NJ 2003 Erlang A K 1909 The Theory of Probabilities and Telephone Conversations In Nyt Tidsskrift for Matematik Vol 20 1909 N
243. n Fehler gt 0 Fehler bei der Erfassung der Daten Start Time Zeitstempel wann die Bearbeitung der Anfrage gestartet wur de User Benutzer ID Description Beschreibung der Anfrage Level Monitoring Level Detailstufe Komponente Component Name Name der Komponente Avg Gross Time Durchschnittliche Bruttozeit ms Dies beinhaltet die Bear beitungszeit der Komponente und evtl Sub Komponenten Avg Net Time Durchschnittliche Nettozeit ms Dies beinhaltet nur die Be arbeitungszeit innerhalb dieser Komponente Systemarchitektur und Monitoring 83 Avg Outbound Data Durchschnittliche Menge an Daten die gesendet wurde Bytes Calls Anzahl an Komponenten Aufrufen Sum Gross Time Summe der Bruttozeiten aller Aufrufe ms Sum Net Time Summe der Nettozeiten aller Aufrufe ms Sum Outbound Data Summe der gesendeten Daten Bytes Comp Gross Time Provi Anzahl der Aufrufe die ordnungsgem beendet wurden ded Comp Net Time Provided Anzahl der Aufrufe bei denen alle Sub Komponenten ord nungsgem beendet wurden Comp Data Provided Anzahl der Aufrufe die Daten erzeugt haben Properties Eigenschaften der Komponente Description Beschreibung der Komponente Benutzer User Name Benutzername Avg Time Durchschnittliche Zeit einer Anfrage Total Time Aufsummierte Zeit aller Anfragen ms Num of Requests Anzahl der gesendet
244. n Locking Service entgegengenommen wurde an den Enqueue Server weitergeleitet der zuerst berpr ft ob bereits eine Sperre f r das angefragte Objekt besteht und setzt danach gegebenenfalls die gew nschte Sperre in der Sperrtabelle Die Sperrtabelle liegt im Shared Memory des Hauptspeichers Ein Eintrag weist dabei die in Abbildung 3 5 dargestellte Struktur auf Systemarchitektur und Monitoring 72 EECH E Elementarsperre tumer_1 tumer_2 Name Argument ID ID Z hler Z hler Name der Sperr Tabelle argumente Abbildung 3 5 Struktur eines Sperrtabellen Eintrags Quelle eigene Darstellung in Anlehnung an SAP 201 1k Das Eigent mer Feld beinhaltet eine eindeutige ID und einen Z hler der angibt wie oft diese Sperre bereits durch diesen Eigent mer gesetzt wurde Das Backup Feld entscheidet ob die Sperre gespeichert wird und somit auch nach einem Neustart des Enqueue Servers vorhanden ist Die n chsten Felder geben an welcher Bereich gesperrt werden soll und in welcher Art und Weise Dabei gibt der Name die Tabelle an bei der bestimmte Felder gesperrt werden sollen Zudem k nnen zus tzliche Sperrargumente eingetragen werden Der Sperrmodus ent scheidet ber die Art der Sperre Die verschiedenen Modi sind in Tabelle 3 7 angegeben Typ Beschreibung S Shared lock Lesesperre Es k nnen mehrere Lesesperren auf ein und dasselbe Feld zeigen allerdings blockieren sie Schreibsperren Anfragen Da
245. n Phasen des Design Science Prozesses dar Problem und Einleitung Zielbeschreibung nl el Theoretische Grundlagen Architektur und Monitoring Konzeption und Entwicklung j 4 LQN Modell und Parametrisierung Demonstration und Simulation und Evaluation der Fallstudie Evaluation 5 Kommunikation Fazit Abbildung 1 3 Aufbau der Arbeit in Bezug auf den Design Science Prozess nach Pfeffers et al 2006 Quelle eigene Darstellung In Kapitel 2 werden die theoretischen Grundlagen dieser Arbeit behandelt Dabei soll ein Uberblick Ober die Terminologie die technische Infrastruktur des betrachteten Systems sowie diese Arbeit betreffende und benachbarte Themenfelder gegeben werden Zu Beginn werden der Begriff Enterprise Ressource Planning ERP erl utert und ber die geschichtliche Ent wicklung Unternehmensportale entsprechend eingeordnet Mit der Applikations und Integra tionsplattform Netweaver und dem inh renten Bestandteil Netweaver Portal wird anschlie Bend auf die von SAP entwickelte Umsetzung f r eine unternehmensweite Modellierung Pla nung und Steuerung von Gesch ftsprozessen eingegangen Anschlie end wird das Feld der Messtheorie vorgestellt wobei vor allem auf die in den sp teren Kapiteln verwendeten statis tischen Kennzahlen Bezug genommen wird In Abschnitt 2 3 wird das zentrale Forschungs feld dieser Arbeit die Performance Evaluation von Rechnersystemen aufgearbeitet Die Einleitung 13 gleichwe
246. n anderen IT Benchmarks indem sie als Messgr e keine Standardmetrik wie zum Beispiel TPS verwenden sondern die Messung der Leistungsf higkeit eines Systems mit der produktiv verwendeten Gesch ftsan wendung welche bei Kundenimplementierungen verwendet wird vereinen Mittels der Durchf hrung von kompletten Gesch ftsprozessen werden anwendungsspezifische und ge sch ftsrelevante Performance Indikatoren aufgezeigt So werden zum Beispiel die maximalen Benutzerinteraktionen pro Stunde oder komplett durchgef hrte Auftragspositionen pro Stunde gemessen Marquard G tz 2008 Die Architektur von SAP Standard Applikations Benchmarks wurde dahingehend ausgelegt dass es f r das System keine Rolle spielt ob es sich um reale oder simulierte Benutzer han delt Beispielsweise bleiben alle System berwachungsprogramme die auch im produktiven Einsatz Verwendung finden eingeschaltet Der Lasttreiber Benchmark Treiber wird auf einem externen System ausgef hrt sodass keine zus tzliche Last auf dem unter Beobachtung stehenden System entsteht Janssen Marquard 2007 Der erzielte Durchsatz wird anschlie end auf die einzelnen Hardwarekomponenten wie z B CPU und Hauptspeicher abgebildet und als eine hardwareunabh ngige Einheit dargestellt den sogenannten SAP Application Performance Standard SAPS Kay 2001 Diese sind von dem SAP Sales and Distribution Benchmark SD Benchmark abgeleitet und sind definiert als 100 SAPS 2000 vollst ndig du
247. n wiederum bieten die h chste Genauigkeit k nnen allerdings erst dann durchge f hrt werden sobald das System zur Verf gung steht Ihr Ziel ist es leistungsschwache Pro grammteile aufzudecken und die Leistung der gesamten Rechenanlage oder auch nur von be stimmten Komponenten zu erfassen Rechenberg Pomberger Pirklbauer 2006 460 Versick 2010 29 Theoretische Grundlagen 35 2 3 3 1 Messung Messungen werden aus drei verschiedenen Gr nden durchgef hrt Zum einen sollen sie Daten zur Leistungsf higkeit eines Systems sammeln um Informationen zur Steigerung der Perfor mance zu erhalten Der zweite Grund f r die Durchf hrung von Messungen ist die Daten sammlung f r die Workload Modellierung Der dritte Anwendungsfall entsteht bei der Vali dierung von Performance Modellen Damit die Aktivit ten des Systems beobachtet werden k nnen wird ein sogenanntes Monito ring Tool verwendet In der Informatik ist ein Monitoring Tool ein Werkzeug welches zur Beobachtung der Aktivit ten auf einem System genutzt wird Im Allgemeinen berwachen Monitore die Performance von Systemen sammeln Performance Statistiken analysieren die Daten und zeigen die Ergebnisse an Jain 1991 93 Snodgrass 1988 definiert Monitoring als eine Extraktion von dynamischen Informationen eines Rechenvorgangs w hrend dieser ausgef hrt wird Ziel ist es die Ursachen f r die gemessene Leistung darzulegen Die dadurch gewonnenen Informationen dienen vor allem dazu
248. nd Interpretation der Ergebnisse erfolgt in Kapitel 6 1 5 8 Analyse des Garbage Collectors und System Overheads Die zunehmende Ungenauigkeit der Simulationswerte im Hochlastbereich f hrt zu dem Schluss dass Einfl sse au erhalb des Portalsystems zu einer Beeintr chtigung der Leistungs f higkeit des Systems f hren Neben dem Overhead auf Betriebssystemebene der auch bei Jehle 2010 185f beschrieben ist und im weiteren Verlauf dieses Kapitels betrachtet wird l sst sich eine weitere Einflussgr e auf der Ebene der JVM feststellen der Garbage Collector Zur Quantifizierung der Aktivit tsintensit t werden die Kenngr en durchschnittli che Dauer eines GC Laufes und durchschnittliches Intervall zwischen den GC L ufen be trachtet Die nachfolgenden Datenauswertungen und Diagramme des Garbage Collectors wurden mit dem von IBM zur Verf gung gestellten Hilfsmittel Garbage Collector and Memory Analy zer siehe Kapitel 3 2 6 der IBM Support Assistant Plattform IBM 2011c erstellt Die Da ten zur CPU Auslastung wurden ber das Betriebssystem Hilfsmittel topas nmon aufge zeichnet Simulation und Evaluation 176 5 8 1 Garbage Collector Aktivit t Bei einem hohen F llgrad des Hauptspeichers nehmen die GC Aktivit ten deutlich zu und beeinflussen dementsprechend das Leistungsverhalten des SAP Netweaver Enterprise Portals Diese Beobachtung deckt sich mit den Erkenntnissen aus der Literatur z B Davis et al 2006 Wi
249. nden Anzahl von Benutzern Der exponentielle Verlauf der Antwortzeitenkurve ab einer bestimmten Systemlast wird durch das verst rkte Eintreten von Wartesituationen erwartet Nur dann wenn das Systemverhalten des SAP Portals diesen Annahmen folgt kann das pro pagierte Warteschlangenmodell sinnvoll eingesetzt werden Cheng 2008 zeigt in seinen Ausf hrungen dass bei einem SAP Netweaver Java basierten System und somit bei einem SAP Portalsystem dieses Verhalten erwartet werden kann Wie im weiteren Verlauf dieser Arbeit noch dargestellt wird best tigen die durchgef hrten Messungen diese Annahmen gr tenteils Erst im Volllastbereich treten u ere Systemeinfl sse auf haupts chlich durch die Speichermanagement Mechanismen der Java Virtual Machine die von dem Warte schlangenmodell nicht erfasst bzw nur statisch parametrisiert werden k nnen Die CPU Nutzlast kann bei vollem Hauptspeicher aufgrund der Speichermanagement Aktivit ten keine vollst ndige Auslastung erreichen CPU Last Antwortzeit ms Antwortzeit ms CPU Zeit pro Interaktionsschritt CPU Last Anzahl Benutzer Abbildung 4 2 Erwartetes Systemverhalten nach der Warteschlangentheorie Quelle eigene Darstellung 4 1 2 Einflussgr en Die Frage der Einflussgr en sowie Anforderungen an das LQN Modell geht mit der Frage nach den zu modellierenden Komponenten einher Da bei einem komplexen Portalsystem nicht s mtliche Einflussgr
250. nderung im Code kann sich zum einen das Verhalten des Objektsystems ndern und zum anderen die Anwendungsperformance beeintr ch tigt werden Nissen Petsch Schorcht 2008 208 2 3 3 2 Analytische Verfahren Wie bereits zu Beginn des Kapitels 2 3 3 erw hnt ben tigen sowohl analytische Verfahren als auch Simulationsans tze ein zugrundeliegendes Modell Ferrari Serazzi Zeigner 1983 Damit ein einheitliches Verst ndnis f r die verwendeten Begriffe System Modell und analy tisches Verfahren bzw Simulation gegeben ist werden diese Begriffe in Abbildung 2 9 in den entsprechenden Kontext gesetzt System v v Experimente am echten Experimente an einem System Modell des Systems v H Physikalisches Modell Mathematisches Modell Analytisches Verfahren Simulation Abbildung 2 9 Terminologie der Systemmodellierung Quelle eigene Darstellung Ein System ist in sich strukturiert als Kollektion interdependenter Komponenten wobei ein zelne Komponenten auch Teilsysteme genannt wiederum aus Komponenten bestehen k n nen Die Durchf hrung der Experimente beispielsweise eine Performance Analyse kann nun am System selbst oder mit einem Modell des Systems erfolgen Ein Modell ist ein Ersatzsys tem welches unter Vereinfachung und Idealisierung mit der wesentlichen Zielsetzung der Reduktion der Komplexit t des zu untersuchenden Systems gebildet wird Es kann entweder physikalisch erstellt oder mathe
251. ndezvous zwischen dem Lastschritt und E1E1 Simulation und Evaluation 169 Nach der Auflistung der einzelnen Service Zeiten und somit der Antwortzeiten werden Vari anz und Variationskoeffizient zu den einzelnen Entries bzw Aktivit ten festgehalten Darauf hin folgt die Angabe zu den maximalen Service Zeiten Dabei wird die Wahrscheinlichkeit festgehalten mit der eine definierte maximale Service Zeit einer Entry oder Aktivit t ber schritten wurde Im anschlie enden Bereich werden die durchschnittliche Haltezeit bzw Verweilzeit die Varianz und die Nutzung des Semaphors zu den modellierten Semaphor Tasks wiedergegeben Die Werte des Sperrbereich Semaphors haben aufgrund der Modellar chitektur keine besondere Aussagekraft Allerdings l sst sich ber die Nutzung des Sema phors ein Richtwert zur H ufigkeit von konkurrierenden Sperranfragen ablesen Falls in der Eingabedatei Histogramm Abgrenzungen angegeben wurden werden im darauf folgenden Abschnitt f r die einzelnen Entries und Aktivit ten die Service Zeit Verteilungen angezeigt siehe Listing 5 11 F r jede Service Zeit Verteilung wird zudem die Dichtefunk tion graphisch dargestellt 1 Service time distributions for entries and activities 2 3 Histogram for entry W1E1 phase 1 4 lt bin lt mean 95 5 underflow 0 000001 0 005876 6 2 5 2 575 0 000106 0 011018 7 2 575 2 65 0 003381 0 036669 8 2 65 2 725 0 028118 0 098527 9 2 725 2 8 0 081842 0
252. nem experimentierbaren Modell um zu Er kenntnissen zu gelangen die auf die Wirklichkeit bertragbar sind Insbesondere werden die Prozesse ber die Zeit entwickelt Im weiteren Sinne wird unter Simulation das Vorbereiten Durchf hren und Auswerten gezielter Experimente mit einem Simulationsmodell verstan den In der Literatur variieren die Meinungen ber die Klassifizierung der Simulationsans tze Domschke Drexl 2007 Abbildung 2 11 stellt die in dieser Arbeit vertretene Klassifizierung dar Experimente am echten System Modell des Systems Physikalisches Modell Mathematisches Modell Analytisches Verfahren Abbildung 2 11 Klassifizierung der Simulationsans tze Ouelle eigene Darstellung l Experimente an einem Bei einem deterministischen Simulationsmodell sind keine Zufallsvariablen sondern nur de terministische Komponenten enthalten das hei t es werden alle mathematischen und logi schen Beziehungen zwischen den Elementen im Voraus festgelegt Rubinstein Kroese 2008 84 Ausschlaggebend f r Fragestellungen in der stochastischen Simulation sind zufallsabh ngige Gr en deren Einfluss man nicht vollst ndig erfassen kann Es m ssen Rechenalgorithmen gefunden werden die eine hinreichend genaue Nachbildung des zufallsbasierten Geschehens auf einem Rechner schaffen k nnen Da ein stochastisches Modell mindestens eine zuf llige Eingabevariable hat f hrt dies zu zuf lligen Ausgabevariablen Den kompl
253. nen ber Fib re Channel Adapter am virtuellen I O Server des I BM Power7 Hosts angebunden sind und an die logische Partition ber virtuelle Fibre Channel Adapter weitergereicht werden Der Aufruf des berwachungs Tools erfolgt ebenfalls mittels Angabe eines Intervalls und der Anzahl der Messungen iostat lt Intervall gt lt Anzahl gt gt lt Ausgabedatei gt Eine Beispielausgabe ist in Abbildung 3 29 dargestellt Die Werte spiegeln eine Momentauf nahme wider im Gegensatz zum Aufruf von iostat ohne zus tzliche Parameter wobei die letzten beiden Werte gelesene und geschriebene KB einen aufsummierten Wert darstellen Systemarchitektur und Monitoring 100 tty tin tout avg cpu user sys idle iowait physc entc 0 0 967 6 50 5 10 2 39 3 0 0 0 3 89 5 Disks tm_act Kbps tps Kb_read Kb_wrtn hdiskl 4 0 779 3 14 0 0 389 hdisk2 0 0 0 0 0 0 0 hdiskO 0 0 0 0 0 0 0 hdisk3 4 0 9 3 4 0 0 Abbildung 3 29 Exemplarische iostat Ausgabe Quelle eigene Darstellung Der Prozentwert Yotm_act gibt an wie lange das I O System f r den betrachteten Zeitraum aktiv war Kbps stellt die Ubertragungsrate in Kilobyte pro Sekunde dar und tps gibt die Anzahl an I O Vorga ngen pro Sekunde an Der Ressourcenverbrauch von iostat bewegt sich in einem hnlichen Rahmen wie die vorangegangenen berwachungs Tools und schwankt ebenso zwischen 0 05 und 0 1 Prozent CPU Zeit Die Aufzeichnung und Auswertung der
254. nenten des Workload Modells zugewiesen 3 Validierungsphase W hrend der Validierungsphase werden Evaluationskriterien defi niert und die Validit t des Workload Modells berpr ft Die Schwierigkeit liegt vor allem bei der Auswahl der Parameter Der zu analysierende Work load kann als n dimensionaler Raum wobei n die Anzahl an Workload Parametern darstellt verstanden werden Jedes Set von Parameter Werten repr sentiert einen Punkt in diesem Raum Die Herausforderung liegt nun darin die Anzahl an Punkten in dem Raum zu reduzie ren und Parameter mit hnlichen Charakteristiken zu gruppieren 2 3 3 Methoden der Performance Evaluation In der Literatur wie zum Beispiel bei Jain 1991 werden zumeist drei Methoden der Perfor mance Evaluation unterschieden 1 Messung 2 analytische Verfahren 3 Simulation Ferrari Serazzi Zeigner 1983 fassen analytische Verfahren und Simulation zu einer Gruppe zusammen da beide ein Performance Modell als Grundlage ben tigen Unabh ngig von der Klassifizierung h ngt die richtige Wahl der Methode vom Entwicklungsstand des Systems ab Risse 2006 Nach Jain 1991 und Trivedi et al 1994 werden analytische Verfahren haupt s chlich in sehr fr hen Entwicklungsstadien verwendet da sie einen geringeren Aufwand erfordern allerdings auch eine geringere Genauigkeit bieten Eine h here Genauigkeit aller dings verbunden mit einem gr eren Aufwand kann mittels Simulation erreicht werden Messunge
255. neut durchge f hrt solange bis eine maximale Anzahl an Iterationen erreicht ist oder die Ergebnisse gegen einen bestimmten vom Benutzer angegebenen Wert konvergieren Der LQNS kann verschiedene Methoden zur Schichtung der Teilmodelle verwenden Stan dardm ig werden die einzelnen Schichten aus so vielen Servern wie m glich gebildet Beim Loose Layering einer weiteren Schichtungsmethode besteht jede Schicht nur aus einem einzelnen Server w hrend Strict Layering die dritte Schichtungsmethode auf der Method of Layers Rolia Servcik 1995 basiert Die wohl wichtigste Einschr nkung beim LQN Solver ist die Forderung dass Modelle hierar chisch zerlegt werden k nnen Somit k nnen Gabelungen und Vereinigungen nur dann gel st werden wenn sie in ein und demselben Task auftreten Das LQNS Meta Modell ist in Abbildung 2 22 abgebildet Neben den bereits eingef hrten Elementen Prozessor Task Aktivit t Entry und Aufruf beinhaltet das Meta Modell folgende Komponenten Eine Gruppe von Tasks kann f r ein spezielles Scheduling Verfahren Li Franks 2009 definiert werden Eine Pr zedenz verbindet Aktivit ten Carleton University Ottawa siehe http www sce carleton ca rads rads html Theoretische Grundlagen 54 Ein z hlender Semaphor ist ein spezieller Task Typ zur Modellierung von Sperrme chanismen sowie Puffern Layered Queueing Network 1 execute 1 Aktivitat
256. ng der CPU E 97 3 3 2 Monitoring des Hauptspeichers 0 0 0 0 cecceecceesceesceceseceseceeceeeseecsaecneceeeeenseeeaeenes 98 3 3 3 Monitoring des VO Subsystems an a eegen 99 PMS AMIE NT ASS UNG 55550500655 os secscvuesoneasbeaudssensvsssuadessaussenuaesrduanvestunsverwseassuasevasmesuadbecniees 100 LObN Modelt EENS 102 Grundannahmen eeeieesendt ees e 103 A WE EE 103 ANZ Eintlusssroben 2 nn een ee 105 Inhaltsverzeichnis IV 4 2 4 3 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 Modellierung und Parametrisierung der Systemkomponenten ssesseees 106 42 1 Benutzer une elek ale Deine Deren 107 42 2 E As Nee eier ei 109 42 3 TEILEN ees 114 4 24 Tabellenp ffering uns Eed e 121 4 225 dees 125 4 26 Garbage Collector a ana ahnen 127 Gesamtbetrachtung des Modells sousssssssssonssssnnsensnnssnsnnssnnnnsnnnnnsnnnnnsnnnnnesnnnnene 131 Simulation und Evaluation nahmen 135 LCE nennt 135 WOrkKload D 137 PASTE ET 141 5 3 1 Charakteristiken der Benutzerschnittstelle c sscccccsesecesedessescensssccansasacscesntons 141 9 2 SAS EEE SEL e EE 142 KEE E 146 5 4 1 Szenario 1 Ausreichende Systemressourcen ceccceesceeseeenseeeteceeeeeeeeeeaeees 147 5 4 2 Szenario 2 Knappe SBwatemressourcen seen 147 KEN 148 Sook Einschwingverhahen geet ee 149 55 2 Oszillierende Messwerte len sans 149 35 3 Messwiederhol ngen 2 ki 150 5 5 4 Szenario 1 Ausreichende System
257. ngen des Leistungsverhaltens eines SAP ERP Systems mittels Performance Modellierung und Si mulation hervor siehe Abbildung 1 2 ABAP J2EE Performance Modellierung EN Performance Modellierung Modellierung R S S S a Simulati und Simulation eines und Simulation eines SAP Ana sina ER SAP ERP Systems Netweaver Portal Systems Performance und Skalierung Performance Messung eines Messung von SAP ERP Systemen in Portalsystems in virtualisierter virtualisierten Umgebungen Virtualisierung Umgebung am Fallbeispiel SAP Abbildung 1 2 Arbeiten im Forschungsbereich Performance Evaluation von ERP Systemen Quelle eigene Darstellung In beiden Arbeiten zur Performance Messung wurden die Auswirkungen der Virtualisierung auf das Leistungsverhalten des jeweiligen SAP Systems anhand eines kontrollierten Soft ware Experiments untersucht Auf Seiten der Technologieplattform ABAP wurden durch Anwendung des synthetischen Benchmarks Zachmanntest Boegelsack et al 2011 Ver gleichsmessungen durchgefthrt Boegelsack 2012 Darauf aufbauend wird derzeit ein Last generator entwickelt der ber die Web Service Schnittstelle in der Lage ist remotefahige Bausteine aufzurufen und Leistungsdaten aufzuzeichnen Diese Daten werden fiir die Model lierung und Simulation eines SAP ERP Systems verwendet Im Java Umfeld wurde fiir die Lasterzeugung und Aufzeichnung der Antwortzeiten das Per formance Evaluation Cockpit fiir ERP Systeme PEER entwickelt Jehle
258. ngenetzwerke zur ckgegriffen die eine flexible und umfangreiche Methode zur Abbildung von diversen Systemen darstellen Lazowska et al 1984 Robertazzi 2000 Theoretische Grundlagen 63 Analyse der Systemumgebung Charakterisierung des Workloads A ey Kostenmodells 2 Validierung und Kalibrierung des Workload Modells Worklgad Modell Workload Prognose Entwicklung des Performance Modells Se SES Perf Validierung und Kalibrierung des Performance Modells SE Kosten Modell Vorhersage Performance Vorhersage Kosten Performance Analyse Kosten Modell Konfigurationsplan Investmentplan Personalplan Abbildung 2 24 Kapazit tsplanungsprozess Quelle Menasc Almeida 2002 179 Neben den Workload und Performance Modellen wird ein Kostenmodell entwickelt sodass Kostenschwankungen bei der Auswahl verschiedener Systemgr en und architekturen dar gestellt werden k nnen Daraus abgeleitet ergibt sich eine Kosten Performance Analyse wel che in den verschiedenen Szenarien von Hardware und Softwarekonfigurationen Verwen dung findet Hieraus resultiert wiederum ein Konfigurationsplan der notwendige Hardware und Softwarekonfigurationen spezifiziert Zudem werden ein Investmentplan f r zuk nftige Investitionen sowie ein Personalplan f r evtl erforderliche Personalzuw chse entwickelt F r die Konfiguration eines J2EE Anwendungs Servers wurde eine weitere Methodik von Raghavachari Reimer Joh
259. ning and Optimization of J2EE Applications on the JBoss Platform In Journal of Computer Resource Management Vol 113 2004 S 40 49 Kourjanski M Varaiya P 1995 Stability of Hybrid Systems In Hybrid Systems IH LNCS 1066 Springer 1995 S 413 423 Kremar H 2010 Informationsmanagement 5 vollst berarb u erw Aufl Springer Verlag Berlin Heidelberg 2010 K hnemund H 2007 Documentation for SLCS v 2 3 SAP AG Linux Lab Walldorf Germany 2007 Lantzsch G Schneider A Schwarz P 2000 Verteilte ereignisorientierte Simulation auf Basis von High Level Architecture HLA In ASIM KI Workshop Literaturverzeichnis 198 Multiagentensysteme und individuenbasierte Simulatoren Hrsg W rzburg 2000 S 121 127 Lazowska E D Zahorjan J Graham G S Sevcik K C 1984 Quantitative System Performance Computer System Analysis Using Queueing Network Models Prentice Hall Englewood Cliffs NJ USA 1984 Li L Franks G 2009 Performance Modeling of Systems Using Fair Share Scheduling with Layered Queueing Networks In 17th IEEE ACM International Symposium on Modeling Analysis and Simulation of Computer and Telecommunication Systems MASCOTS 2009 Hrsg Imperial College London 2009 S 1 10 Libic P Tuma P Buley L 2009 Issues in performance modeling of applications with garbage collection Proceedings of the Ist international workshop on Quality of service oriented software system
260. nktionen zur Analyse von strukturierten Datenbest nden Unstrukturierte Daten Theoretische Grundlagen 19 werden im Modul Knowledge Management organisiert und vom SAP Netweaver Portal bernommen SAP 20111 Die People Integration bietet ber den Multi Channel Access die M glichkeit zur Integra tion von mobilen Endger ten Der Begriff Collaboration steht f r die Zusammenfassung von Funktionen wie Terminkalender oder Email SAP 20111 Das bedeutendste Modul in diesem Bereich ist allerdings das SAP Netweaver Portal Mittels eines webbasierten Front Ends werden Daten und Funktionen dem Benutzer zur Verf gung gestellt und der Zugriff darauf gesteuert Das SAP Netweaver Portal ist somit eines der zentralen Komponenten im Netweaver Stack mit denen der Benutzer interagiert B nnen Herger 2007 46 und wird in Kapitel 2 1 2 n her erl utert Mit dem Life Cycle Management werden Funktionen zur Verf gung gestellt die den Le benszyklus einer Anwendung begleiten Die wichtigste Komponente in diesem Bereich stellt der SAP Solution Manager dar SAP 2011n Die sechste und letzte Komponente des Netweaver Stacks das Composite Application Framework dient zur Unterst tzung der Entwickler und stellt eine Reihe von Hilfsmitteln zur Verf gung wie zum Beispiel zur Modellierung von Prozessen oder zur Gestaltung von grafischen Benutzeroberfl chen SAP 2011d 2 1 1 1 Architektur Seit der Einf hrung des R 3 Sy
261. nnen architekturale Unterschiede aufweisen und w rden eine Anpassung des Modells erfordern Wenngleich diese Anpassungen m glicherweise eine er neute Analyse der Systemarchitektur und vorhandener Monitoring Hilfsmittel erfordern k n nen aus dieser Arbeit die Modellierungskonzepte der betrachteten Einflussgr en bernom men werden Einleitung 6 1 3 Forschungsfragen kat o Aus der beschriebenen Problemstellung leiten sich drei forschungsleitende Fragen ab die dieser Arbeit beantwortet werden n Forschungsfrage 1 Wie kann im Zuge der Performance Modellierung und Simulation die Architektur eines SAP Netweaver Portal Systems charakterisiert werden und welche Systemkomponen ten sowie Einflussgr en auf das Leistungsverhalten lassen sich aus der Literatur und den gegebenen Hilfsmitteln zur Leistungsdatenerfassung ableiten Im Rahmen der ersten Forschungsfrage wird die Architektur eines SAP Netweaver Portal Systems analysiert Dabei werden die einzelnen Komponenten des Systems betrachtet die der Literatur folgend als wesentliche Einflussgr en auf das Leistungsverhalten des Systems gel ten Zudem werden vorhandene Hilfsmittel zur Erfassung und Aufzeichnung der Leistungsda ten ermittelt Die Beantwortung der ersten Forschungsfrage ergibt somit eine Gruppe von identifizierten Komponenten die die Performance wesentlich beeinflussen und deren Leistungsdatenerfas sung ber die gegebenen Analysewerkzeuge erm glich
262. nordnung der Unternehmensportale Abbildung 2 3 SAP Netweaver Komponentenansicht links und Produktansicht rechts 18 Abbildung 2 4 3 Schicht Architektur und Installationsvarianten c eeeeseeeteereeeeeeeeeeeees 22 Abbildung 2 5 Ressourcenbedarf nach Schichten nenn 22 Abbildung 2 6 Eoptak Gurt eege de tee air 23 Abbildung 2 7 Relationssystem in der Messthe Orie si Zeegiiog erdeelt Zeg edd 25 Abbildung 2 8 Aspekte der Letstungsbeuwertung nennen 31 Abbildung 2 9 Terminologie der Systemmodellierung 0 0 0 0 eee ceeceeceesceceteeeteeeeeeesseeesaeenes 37 Abbildung 2 10 Elemente von Petri Netzen u sn innen hen 41 Abbildung 2 11 Klassifizierung der Simulationsans tze rensesssessnessenseenseneennennnn 42 Abbildung 2 12 Ereignisdiskrete vs zeitdiskrete Smulaton 44 Abbildung 2 13 Schematische Darstellung eines Warteschlangensystems nee 45 Abbildung 2 14 Zufallszahlen und Parameter in einem Warteschlangensystem 46 Abbildung 2 15 Beispielhaftes LON Modell 48 Abbildung 2 16 Tasks und Entries im LQN Modell uensennnnennnnennnennnnennnn 49 Abbildung 2 17 Notation von Aktivit ten in LON Modellen 0 0 eceeceeeeceteeneeeteeeeeeeeeeeees 50 Abbildung 2 18 Notation der Aufrufe in LQN Modellen eesennenenennnnn 50 Abbildung 2 19 Ablauf eines synchronen Aufrufs nenn 51 Abbildung 2 20 Ablauf eines asynchronen AufrufS 0ssessnnns
263. ns f r IS Forscher unerl sslich die gestaltungsorientierten Wissenschaften besser zu verstehen und die gewonnenen Er kenntnisse bspw Design Theorien Design Prozesse in die Erstellung und Evalua tion neuer und n tzlicher Artefakte einflie en zu lassen Winter 2009 148 Besagte Artefakte werden in Konstrukte Modelle Methoden und Instanziierungen unterteilt um die Repr sentation die Analyse das Verst ndnis und die Entwicklung von bew hrten Informationssystemen innerhalb von Organisationen zu erm glichen March Smith 1995 Konstrukte bilden die Sprache in der Probleme und L sungen definiert und kommuniziert werden Modelle verwenden definierte Konstrukte um Probleme und den L sungsraum dar zustellen Sie stellen somit eine zielgerichtete Abstraktion der Realit t dar Methoden definie ren den Prozess wie Probleme gel st werden das hei t sie k nnen Algorithmen sowie infor male Beschreibungen von Best Practice L sungen enthalten die zeigen wie der L sungs Einleitung 9 raum entwickelt oder durchsucht wird Instanziierungen zeigen schlieBlich die Machbarkeit das hei t wie die Konstrukte Modelle und Methoden in der realen Welt umgesetzt werden k nnen vgl bspw Bichler 2006 Das Ziel eine Klasse von Problemen mittels eines innovativen Artefakts zu l sen und die Situation damit zu verbessern ist nicht immer einfach zu erreichen Der Grund hierf r liegt oft an dem Mangel an vorhandenen Theorien die als Basis
264. nskoeffizient 33 H W1E1 1 2 5 4 0 Lastschritt 1 Abgrenzungen Histogramm 34 f W1E1 0 1 Lastschritt 1 stochastische Aufrufe 35 y W1E1 E1E1 7 0 1 1 Anfrage Lesesperre SQL Query 1 36 y W1E1 E1E2 3 0 1 1 Anfrage Schreibsperre SQL Query 1 37 s W1E2 3 489 1 Lastschritt 2 Service Zeit 38 c W1E2 0 00414 1 Lastschritt 2 quadrierter Variationskoeffizient 39 f W1E2 0 1 Lastschritt 2 stochastische Aufrufe 40 y W1E2 P1E1 15 0 1 7 Anfragen ber Tabellenpuffer 41 s D1E1 0 017 1 SQL Query 1 Service Zeit Select Statement 42 c D1E1 0 00168 1 SQL Query 1 quadrierter Variationskoeffizient 43 s D1E2 0 029 1 SQL Query 2 Service Zeit Update Statement 44 c D1E1 0 00168 1 SQL Query 2 quadrierter Variationskoeffizient 45 s P1E1 0 0 1 Tabellenpuffer Service Zeit O da unwesentlich 46 F P1E1 D1E2 0 02 1 Tabellenpuffer Weiterleitungswahrscheinlichkeit 2 47 s E1E1 0 001 1 Enqueue Server Select Statement Service Zeit 48 c E1E1 0 0 1 quadrierter Variationskoeffizient 0 somit deterministisch 49 F E1E1 RS1E1 1 0 1 wird an die Lesesperre weitergeleitet 50 s E1E2 0 001 1 Enqueue Server Update Statement Service Zeit 51 c E1E2 0 0 1 quadrierter Variationskoeffizient 0 somit deterministisch 52 F E1E2 WS1E1 1 0 1 wird an die Schreibsperre weitergeleitet 53 A RS1E1 RSA1 Lesesperre Uber Aktivit t definiert 54 A WS1E1 WSA1 Schreibsperre ber Aktivit t definiert 55 s WS1CHK 0 0 1 Schrei
265. nson 2003 vorgeschlagen Hierbei wurden Anwendungscharakte ristiken und Konfigurationswerte w hrend einer willk rlichen Untersuchung der Konfigurati onsdaten untersucht Es wurde allerdings keine genaue Beschreibung des Untersuchungspro zesses gegeben Zur Optimierung der Konfiguration einer J2EE Anwendung haben Kounev Weis Buchmann 2004 verschiedene J2EE Konfigurationen entwickelt und diese mit der Standardkonfiguration verglichen 2 8 Zusammenfassung In diesem Kapitel wurden die theoretischen Grundlagen der in dieser Arbeit durchgef hrten Performance Modellierung und Simulation eines SAP Netweaver Portal Systems zusammen fassend dargestellt Dabei wurde zu Beginn das zu untersuchende System in die Dom ne ERP Systeme und im Speziellen in den Bereich der Unternehmensportale eingegliedert Als architekturale Basis dient das von SAP entwickelte Netweaver Framework welches in tech nologischer Hinsicht aus einem ABAP und einem Java Stack besteht Das Netweaver Portal Theoretische Grundlagen 64 ist dem Java Stack zuzuordnen und verwendet als Benutzerschnittstelle einen herk mmlichen Web Browser Daraufhin wurde ein Einblick in die Messtheorie gegeben die die Grundlage fiir die in dieser Arbeit durchgef hrten Messungen darstellt Dabei wurden im Speziellen die grundlegenden statistischen Kennzahlen dargestellt sowie die Analyse von und der Umgang mit potentiellen Messfehlern beschrieben Es konnte gezeigt werden dass eine Plausibilit
266. nter Last gesetzt wird Wie bereits aus den Messungen in Kapitel 5 5 4 ersichtlich wird erfolgt ein leichter Anstieg der Antwortzeiten aufgrund von zunehmenden Sperrsituationen die durch die erh h te Anzahl an simultan agierenden Benutzern hervorgerufen werden Dieser Anstieg ist im Vergleich zur Gesamtantwortzeit verh ltnism ig gering jedoch deutlich erkennbar Das berschaubare Ausma h ngt mit der Anzahl bzw dem Gewicht der Datenbankanfragen zu sammen die sich beim verwendeten Workload in Grenzen halten Bei datenbankintensiven Lastmustern w rde sich ein deutlicherer Anstieg der Antwortzeiten aufgrund von Sperrsitua tionen zeigen Den entscheidenden Zuwachs des Antwortzeitenanstiegs erh lt das System bei mehr als 80 simultan agierenden Benutzern Dies h ngt zum einen mit der Anzahl an konfigurierten Ap plikations Threads zusammen zum anderen mit der f r diesen Workload geltenden 1 zu 1 Simulation und Evaluation 172 Beziehung zwischen verwendeten Applikations Threads und Benutzern Mit anderen Worten ist aufgrund der Begrenzung von maximal 80 Applikations Threads die maximale Parallelitat der durchgef hrten Lastschritte erreicht Sobald mehr als 80 Lastschritte zeitgleich durchge f hrt werden sollen k nnen keine freien Applikations Threads f r die zus tzlichen Anfragen bereitgestellt werden und in der Folge treten Wartezeiten bei der Bearbeitung der Lastschritte auf Da jeder Benutzer sequentiell einen Lastschritt nach d
267. number f H m D V d Abbildung 3 22 SQL Trace einer bestimmten Transaktions ID Quelle eigene Darstellung Systemarchitektur und Monitoring 92 3 2 5 Black Box Monitoring Neben der Leistungsdatenanalyse auf Komponentenebene ist es zu Kontrollzwecken sinnvoll Daten ber die einzelnen Benutzeranfragen sowie deren Dauer Antwortzeit auf der Ebene der HTTP Requests zu sammeln HTTP Access Trace ohne sich die einzelnen Komponen ten oder Datenbankzeiten im Detail anzuschauen Dies kann unter anderem zur Ver gleichsanalyse der aufsummierten Komponentenzeiten dienen aber auch bei den in dieser Arbeit durchgef hrten Messungen des Portalsystems k nnen so die Antwortzeiten ohne Netzwerkzeit vom Client zum Server der einzelnen Benutzeraktionen protokolliert werden Wie bereits in Kapitel 3 1 1 erwahnt bietet der http Provider Service eine solche Funktionali t t Standardm ig werden die Daten im folgenden Format festgehalten Datum Client IP Request Return Code Bytes Zus tzlich k nnen noch eine Reihe weiterer Daten gesammelt werden unter anderem die be reits angesprochene Antwortzeit des Aufrufs Interessant f r die Performance Analyse ist vor allem auch der Parameter ab welcher Dauer in Millisekunden der HTTP Request in den Trace geschrieben werden soll Dadurch kann die Anzahl der analysierten Benutzeraktionen erheblich reduziert werden was vor allem bei sehr umfangreichen Workloads sehr hilfreich se
268. oft die Begriffe Latenzzeit und Verz gerungszeit auf Bei der Bedien Verweil und Wartezeit ist h ufig nur der Erwartungswert wichtig im Allgemeinen sind sie jedoch stochastische Gr en Melzer 2010 180 Rechenberg Pomberger Pirklbauer 2006 455 Kenngr en zum Durchsatz Die Kenngr e Durchsatz beschreibt die Anzahl der be arbeiteten Auftr ge pro Zeiteinheit Unter dem Begriff Grenzdurchsatz versteht man den maximal erreichbaren Durchsatz Man spricht auch von der Bandbreite wenn in einem Netzwerk der Durchsatz einen theoretischen H chstwert erreicht Dadurch wird die Antwortzeit beeinflusst da eine bertragene Antwort nie schneller ist als es die Bandbreite des bertragungsmediums zul sst Daher ist meist der maximal erreichba re Durchsatz an Auftr gen interessanter der erreicht wird ohne dass die Verweilzeit entweder die vorgegebene obere oder untere Schranke ber bzw unterschreitet Die Verlustrate beschreibt die Anzahl an abgewiesenen oder verlorenen Auftr gen pro Zeiteinheit Melzer 2010 180 Rechenberg Pomberger Pirklbauer 2006 456 Kenngr en zur Auslastung Die Kenngr e Auslastung oder auch Effizienz eines Systems bezeichnet das Verh ltnis von dem tats chlich erreichten Durchsatz zum Grenzdurchsatz Der ma gebliche Indikator der angibt wie performant ein System ist ist der Engpass auch Flaschenhals genannt Unter einem Engpass versteht man die Komponente mit der h chsten Auslastung somit is
269. omputergest tzten Modellierungs und Simulationstechniken nicht mehr denkbar Physiker simulieren dynamische Eigenschaften von hochenergetischen Nuklearreaktionen Bl ttel Koch Mosel 1993 oder die Entwicklung von Sternen und Galaxien Kippenhahn Weigert 1991 w hrend ihre Kollegen aus den wirtschafts und sozialwissen schaftlichen Disziplinen Kriegsausbr che Hermann Hermann 1972 konomische Entwick lungen Anderson Arrow Pines 1988 oder Entscheidungsfindungsprozesse in Organisationen Simon 1970 nachvollziehen vgl Hartmann 1996 Nach Niehans 1990 313 hat die ra der Modellentwicklung ihren Ursprung im sp ten 19 Jahrhundert Zu dieser Zeit begannen Wissenschaftler vor allem im Bereich der Physik ihre Aktivit ten auf die Bildung von Modellen zu konzentrieren So schreibt William Thompson 1884 beispielsweise dass er erst dann in der Lage sei ein Ph nomen zu verstehen wenn er ein Modell des zu untersuchenden Systems erstellen k nne Ebenso formuliert Heinrich Hertz in seiner Einleitung ber Die Prinzipien der Mechanik Ist es uns einmal gegl ckt aus der angesammelten bisherigen Erfahrung Bilder von der verlangten Beschaffenheit abzuleiten so k nnen wir an ihnen wie an Modellen in kurzer Zeit die Folgen entwickeln welche in der u eren Welt erst in l ngerer Zeit oder als Folgen unseres eigenen Eingreifens auftreten werden wir verm gen so den Thatsachen vorauszueilen und k nnen nach der gewonnenen Einsicht
270. onenten ist in Abbildung 4 14 noch einmal grafisch dargestellt i Lastschritt Aktivit ten Aufrufe Denkzeit a Antwort an den Benutzer GC Lauf Check Bearbeitungszeit u Bearbeitungszeit 0 Legende Gi Task L Entry 8 Aktivitat Synchroner Aufruf Abbildung 4 14 LQN Modellierung der Garbage Collector Parametrisierung Quelle eigene Darstellung LQN Modell 131 Mit der expliziten Parametrisierung der GC Aktivit tsintensit t m ssen die vom funktionalen Trace aufgezeichneten Ausf hrungszeiten der Java Server Tasks also die Bearbeitungszeiten der Lastschritt Entries von den GC L ufen bereinigt werden Dies ist ein aufw ndiger Pro zess da die einzelnen Lastschrittaufrufe mit den Ausf hrungszeitpunkten der GC L ufe ver glichen werden und die Stichproben verworfen werden miissen die in den Zeitraum eines GC Laufs fallen Beispielhaft sei die Stichprobe der Bearbeitungszeiten eines Lastschritts Aufruf der Portalin formationen in Abbildung 4 15 dargestellt Hierbei wurde ein einzelner Lastschritt tiber den Lastgenerator 3 000 Mal automatisiert durchgef hrt nach f nf vorangegangenen Ein schwingdurchl ufen und die Bearbeitungszeiten ber den funktionalen Trace aufgezeichnet Wie man unschwer erkennen kann sind nach periodischen Abst nden immer wieder einige Ausrei er mit stark erh hten Werten zu erkennen die sich mit den vom System durchgef hr ten GC Zyklen erkl ren lassen
271. onenten zusammen l sst sich die in Abbildung 6 2 dargestellte Simulations genauigkeit nach der Auslastung des Systems bewerten Freie Portal und Systemressourcen Abbildung der Sperrobjekte und Tabellenpufferung Abbildung der Wartezeiten die durch die Vollauslastung des Portalsystems bedingt sind Lastintensit t Abbildung der Wartezeiten die durch die Vollauslastung der CPU Ressourcen bedingt sind berlastete Systemressourcen Ungenaue Simulationsergebnisse aufgrund von u eren Einfl ssen GC System Overhead Abbildung 6 2 Bewertung der Ergebnisse nach der Lastintensit t Ouelle eigene Darstellung Die in Abbildung 6 2 dargestellten Situationen entsprechen den in Abbildung 6 1 identifizier ten Lastbereichen Im ersten Bereich sind die Portal und Systemressourcen nicht voll ausge lastet Der leichte Anstieg der Antwortzeiten l sst sich ber die Sperrwartezeiten und eventu ellen Verdr ngungen bzw Invalidierungen im Tabellenpuffer erkl ren Dies wird von dem Simulationsmodell entsprechend abgebildet Der zweite Bereich stellt eine Vollauslastung der Fazit 188 Applikations Threads auf Portalsystem Seite bzw der CPU Ressourcen auf Seiten des Hosts dar je nachdem welche Grenze zuerst erreicht wird Beide Limitationen rufen Warte zeiten hervor die von dem Simulationsmodell ebenfalls erfasst werden Der dritte Bereich stellt schlie lich den Uberlastbereich dar bei dem sich hohe GC Zeiten sowie ein
272. ormance Hrsg Ottawa Canade 2000 S 189 194 Petriu D Shousha C Jalnapurkar A 2000 Architecture Based Performance Analysis Applied to a Telecommunication System In IEEE Transactions on Software Engineering Vol 26 2000 Nr 11 S 1049 1065 Pfeffers K Tuunanen T Gengler C E Rossi M Hui W Virtanen V Bragge J 2006 The Design Science Research Process A Model for Producing and Presenting Information Systems Research In Proceedings of the Ist International Conference on Design Science in Inofrmation Systems and Technology Hrsg Chatterjee S Hevner A Claremont 2006 S 83 106 Pollaczek F 1930 Uber eine Aufgabe der Wahrscheinlichkeitstheorie In Mathematische Zeitschrift Vol 32 1930 S 64 100 Popp K 2002 Nutzbarmachung von Portaltechnologie mySAP Enterprise Portals In HMD Vol 39 2002 Nr 225 S 21 29 Prechelt L 2001 Kontrollierte Experimente in der Softwaretechnik Potenzial und Methodik Springer Berlin 2001 Prior D 2003 Who Sets the Pace in the SAP Performance Olympics In Gartner 2003 S 6 Raghavachari M Reimer D Johnson R D 2003 The Deployer s Problem Configuring Application Servers for Performance and Reliability In 25 International Conference on Software Engineering Hrsg IEEE Computer Society Portland OR 2003 S 484 489 Raychaudhuri S 2008 Introduction to Monte Carlo Simulation In Winter Simulation Conference 2008 Hrsg
273. ount Anzahl der in der WaitingTasksQueue vorhandenen Benut zeranfragen WaitingTasksQueueOverflow Anzahl der Aufgaben die bei einer vollen WaitingTasks Queue keinen Platz mehr gefunden haben WaitingTasksQueueSize Derzeitige Gr e der WaitingTasksQueue Die Gr e wird auch hier dynamisch an den momentanen Bedarf angepasst ActiveThreads Count Anzahl der derzeit aktiven Applikatons Threads im System Tabelle 3 6 Wichtige Monitore des Application Thread Managers Quelle eigene Darstellung in Anlehnung an SAP 201 1a Systemarchitektur und Monitoring 70 Je nach Anfragetyp wird der Thread an den Web Container oder Enterprise Java Beans Container EJB Container weitergeleitet In diesem Container wird somit die eigentliche Ab arbeitung der Anfrage durchgef hrt Der Web Container wird dabei der Pr sentationsschicht zugeordnet da er Servlets und Java Server Pages enth lt wo hingegen der EJB Container der Applikationsschicht angeh rt und Session sowie Entity Beans enth lt Sollten w hrend der Bearbeitung der Aufgabe sprich bei der Abarbeitung des Programms Datenbankzugriffe erforderlich sein werden diese dem JDBC Connector Service bergeben Der Connection Pool ist dabei standardm ig auf 10 simultane Verbindungen begrenzt Nachdem das Programm abgearbeitet wurde wird das Ergebnis ber das Cluster Management wieder zur ck an den Dispatcher gesendet der die Antwort wiederum an den Client weitergib
274. ox Monitorings eingegangen welches die gesamte Ausf hrungszeit einer Benutzeranfrage am Serversystem aufzeichnet sowie die Analyse des Garbage Collectors mittels bereitgestellter Hilfsmittel vorgestellt Der letzte Teil dieses Kapitels besch ftigt sich mit den Hilfsmitteln zur Leistungsanalyse auf Betriebssystemebene Dabei wurden die drei Performance Faktoren CPU Hauptspeicher und VO behandelt W hrend die O Betrachtung aufgrund des Black Box Ansatzes des Daten banksystems eine untergeordnete Rolle in dieser Arbeit spielt und der Hauptspeicher ausrei chend dimensioniert wird ist die Leistungsanalyse der CPU Ressource auf Betriebssysteme Systemarchitektur und Monitoring 101 bene nicht zuletzt f r die Analyse des Garbage Collector Verhaltens bzw dessen Auswirkun gen auf die Systemperformance ein sehr wichtiger Bestandteil Zudem kann das Verh ltnis zwischen CPU Zeit f r Verwaltungsaufgaben des Betriebssystems und nutzbarer User CPU Zeit betrachtet werden Vor allem im Hochlastbereich spielt dies eine immer gr ere Rolle LON Modell 102 4 LQN Modell In diesem Kapitel wird die Modellierung der Systemkomponenten und des Workloads sowie deren Parametrisierung beschrieben Wie bereits in Kapitel 2 3 3 1 erw hnt ist einer der drei Gr nde f r Messungen am System die Datensammlung zur Parametrisierung des Warteschlangenmodells Ein Lasttest mit meh reren Benutzern simuliert dabei einen bestimmten Workload mit einer spezifiziert
275. peration in einer festen Zeit in bestimmter Qualit t und H u figkeit durchzuf hren definiert werden John Eeckhout 2006 Nach Hu Gorton 1997 sind folgende Aspekte in Bezug auf Performance von Computersystemen von Belang Funktionalit t Zuverl ssigkeit Geschwindigkeit konomische Effizienz Funktionalit t und Zuverl ssigkeit werden in den meisten F llen bereits von den Systement wicklern ber cksichtigt Demnach liegt das Hauptaugenmerk der Performance Analysten haupts chlich auf der Geschwindigkeit des Systems sowie der konomischen Effizienz Die Geschwindigkeit eines Systems wird durch Leistungskenngr en wie zum Beispiel Durchsatz oder Antwortzeit ausgedr ckt konomische Effizienz bewertet die Kosten beim Design und der Implementierung eines Systems F r die Leistungsbewertung eines Systems m ssen im ersten Schritt Leistungskenngr en Metriken definiert werden Unterschiedliche Metriken k nnen g nzlich unterschiedliche Performance Werte ergeben Jain 1991 Daher ist die Auswahl passender Metriken ein ent scheidender Faktor f r eine erfolgreiche Leistungsbewertung Ebenso wichtig ist die Auswahl einer entsprechenden Belastung des Systems Workload Nachdem passende Metriken und Theoretische Grundlagen 31 der Workload definiert wurden muss eine passende Methode der Performance Evaluation gew hlt werden Diese werden grunds tzlich in Messung analytische Verfahren und Simula tion unterteilt
276. r B S 33 39 Feldt K C 2007 Programming Firefox O Reilly Beijing 2007 Literaturverzeichnis 194 Ferrari D 1986 Considerations on the insularity of performance evaluation In IEEE Transactions on Software Engineering Vol 12 1986 S 678 683 Ferrari D 1978 Computer Systems Performannce Evaluation Prentice Hall 1978 Ferrari D Serazzi G Zeigner A 1983 Measurement and Tuning of Computer Systems Prentice Hall Englewood Cliffs NJ USA 1983 Ferschl F 1970 Markovketten Springer Verlag Heidelberg 1970 Fielding R Gettys J Mogul J Frystyk H Masinter L Leach P Berners Lee T 1999 Hypertexst Transfer Protocol HTTP 1 1 In http www ietf org rfe rfc2616 txt zugegriffen am 10 12 2011 2011 Fink A Schneidereit G Vo S 2005 Grundlagen der Wirtschaftsinformatik 2 berarb Aufl Physica Verlag Heidelberg 2005 Finkelstein L 1984 A Review of the Fundamental Concepts of Measurement In Measurement Vol 2 1984 Nr 1 S 25 34 Franks G 2011 Simulating layered queueing networks with passive resources Proceedings of the 2011 Theory of Modeling amp Simulation Symposium DEVS Integrative M amp S Symposium S 8 15 Boston Massachusetts Society for Computer Simulation International Franks G 1999 Performance Analysis of Distributed Server Systems Carleton University 1999 Franks G Lau D Hrischuk C 2011 Performance measurements and model
277. r der in der Literatur stets verwendeten impliziten Parametrisierung verspricht vgl Kapi tel 4 2 6 sowie Kapitel 5 8 1 Zudem ist mit der Modellierung des Sperrmechanismus eine detaillierte Analyse des Sperrverhaltens m glich Diese Erweiterungen stellen einen Mehr wert zu der in der Literatur verwendeten impliziten Parametrisierung dar da die explizite Modellierung die Anzahl der ben tigten Messreihen stark reduziert Fazit 183 In Kapitel 5 wurde Forschungsfrage 3 beantwortet die sich mit der Durchf hrung sowie Ana lyse der Simulation besch ftigt Bei dem Vergleich zwischen den Mess und Simulationser gebnissen in Kapitel 5 7 wurde bereits detailliert dargestellt wie sich das Antwortzeitverhal ten der beiden durchgef hrten Szenarien erkl ren l sst Anschlie end wurden die Ursachen f r die divergierenden Mess und Simulationswerte im Hochlastbereich von Szenario 2 analy siert und ein berproportionaler Anstieg der Garbage Collector Zeiten festgestellt Bei genauerer Betrachtung lassen sich allerdings weitere Schl sse aus den erzielten Ergebnis sen ziehen Im ersten Szenario das keine Engp sse in den bereitgestellten Systemressourcen beinhaltet und ein gut konfiguriertes Portalsystem mit ausreichender Tabellenpuffergr e darstellt lassen sich zwei Bereiche identifizieren siehe Abbildung 6 1 Bereich 1 Dieser Bereich stellt den Niedriglastbereich dar in dem nicht alle Applika tions Threads ausgelastet sind Es komm
278. r Analyse von Ausrei ern siehe Kapitel 2 2 2 1 kann festgestellt werden dass beson ders bei den ersten Messreihen von wiederholt durchgef hrten Lastsequenzen untypische Werte auftreten Die Antwortzeiten nehmen in den ersten Durchl ufen ab siehe Abbil dung 5 8 und stellen ein Einschwingverhalten dar das unter anderem auf die Verwendung von Puffern zur ckzuf hren ist Meyer Guicking 1974 Das gew hlte Beispiel entspricht der bei Jehle 2010 167 verwendeten Benutzerinteraktion bei der die Content Administration aus der Top Level Navigation aufgerufen wird und best tigt die Minderung der Antwortzeit in den ersten 3 5 Durchl ufen 3 2 5 g a2 e p 1 5 a o 3 S 1 lt 0 5 0 1 2 3 4 5 6 7 Wiederholungen Abbildung 5 8 Einschwingverhalten am Beispiel einer Men Navigation Quelle eigene Darstellung Die n tige Anzahl an Wiederholungen zur Stabilisierung der Antwortzeiten h ngt von dem betrachteten System ab Bei der Analyse von ERP Systemen im Allgemeinen wird eine drei malige Wiederholung der Lastsequenz empfohlen Barham et al 2003 bei einen SAP Netweaver Portal System wurde ein Minimum von f nf Wiederholungen vorgeschlagen Jehle 2010 167 Auch die eigene Erhebung zeigt eine hnliche Charakteristik und veranlasst somit eine Einschwingzeit von f nf Wiederholungen bei den in dieser Arbeit durchgef hrten Performance Messungen 5 5 2 Oszillierende Messwerte Bei der Messung von Leistungsdaten
279. r Nutzung und Wartezeiten der Pro zessoren ablesen lassen Die Begrenzung der CPU Ressourcen sowie die Begrenzung der ma ximalen Anzahl an Applikations Threads stellen somit die Schranken dar bei denen Warte zeiten f r die Abarbeitung der Lastschritt Anfragen entstehen Im ersten Szenario wurde zu erst die Schranke der Applikations Thread Begrenzung erreicht bei 80 Benutzern CPU Ressourcen waren nicht gekappt w hrend im zweiten Szenario zwar 80 Applikations Threads konfiguriert sind die CPU Ressourcen jedoch bereits bei 40 simultanen Benutzern voll ausgelastet sind Aufgrund des direkten Zusammenhangs zwischen Benutzern mit identi schem Workload und 1 Applikations Thread pro Benutzer entsprechen im bertragenen Sinne die gegebenen CPU Ressourcen einer maximalen Parallelit t von 40 Applikations Threads ohne Wartezeiten Betrachtet man die Auslastung Nutzung der Server CPU Ressource bei 40 Benutzern in den Simulationsergebnissen erreicht diese einen Wert von ca 36 von m glichen 40 siehe Lis ting 5 12 Die Differenz l sst sich mit den Sperrzeiten erkl ren bei der der Applikations Thread eines Lastschrittes keine CPU Last erzeugt hnlich zu einer blockierenden I O Operation 1 Utilization and waiting per phase for processor Processor_Server 2 3 TaskName Pri n Entry Name Utilization 4 wi 0 80 W1E1 0 7142 53 Task Total 36 1034 LI Listing 5 12 Beispielhafte Auslastung der Server CPU Ressource bei 4
280. r beiden vorgestellten Szenarien werden in diesem Kapitel mit den Simula tionswerten verglichen Wie bereits in Kapitel 2 3 1 beschrieben wird f r die in dieser Arbeit durchgef hrten Leistungsanalysen die Antwortzeit als Vergleichswert betrachtet Daher wird in den folgenden Diagrammen die Gesamt Antwortzeit der modellierten Fallstudie dargestellt die sich aus den Antwortzeiten der einzelnen Interaktionsschritte zusammensetzt Die beiden Szenarien sollen wie bereits in Kapitel 5 4 beschrieben einen unterschiedlichen Schwerpunkt setzen Mit der Gegen berstellung von simulierten und gemessenen Werten wird dabei gepr ft ob das Modell auf die in Kapitel 4 1 2 identifizierten Einflussgr en ent sprechend reagiert 5 7 1 Szenario 1 Ausreichende Systemressourcen 600s i Messwerte Q1 25 Messwerte Q3 75 500s Simulation 400s 4 300s Kumulierte mittlere Antwortzeit sec 200s T T T T T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer Sim u 259 722 266 09 277 189 289 196 308 252 386 882 467 859 Q1 25 252 829 260 829 267 829 282 287 310 287 392 744 484 573 03 75 262 573 270 573 277 573 294 466 322 466 407 359 508 932 Abbildung 5 19 Vergleich der Simulations und Messwerte Szenario 1 Quelle eigene Darstellung Im ersten Szenario siehe Abbildung 5 19 sind geniigend Systemressourcen vorhanden so dass lediglich das Portalsystem durch eine steigende Anzahl von Benutzern u
281. r oft auch als ERP II Systeme bezeichnet Bond et al 2000 Ein Blick auf die historische Entwicklung von ERP Systemen soll den identifizierten inhaltli chen Wandel weiter illustrieren Als erste Generation betrieblicher Anwendungen und Vor g nger von ERP Software gelten die in den sechziger Jahren entwickelten Material Requirements Planning Systeme kurz MRP Systeme Wannenwetsch Nicolai 2004 72 Sie erm glichten eine bedarfsorientierte Materialdisposition und wurden im Laufe der Jahre um diverse Funktionen wie Beschaffung Fertigung Lager Kapazit ts und Terminplanung er g nzt Dies f hrte zu den sogenannten MRP II Systemen dem Manufacturing Resource Planning Mertens 2001 141 Vereinzelt wird in der Literatur auch von MRP III Systemen dem Money Resource Planning gesprochen wenn neben den mengenorientierten Gr en auch wertorientierte Indikatoren ber cksichtigt wurden Mertens 2001 142 Theoretische Grundlagen 16 Parallel zu den Produktionsanwendungen wurde seit den sechziger Jahren das betriebliche Rechnungswesen in die elektronische Datenverarbeitung integriert Mitte der achtziger Jahre trafen beide Entwicklungszweige zusammen und erg nzten das MRP II Konzept um Rech nungswesen Einkauf und Personalwesen Zu Beginn der neunziger Jahre wurde zur Be schreibung solcher Systeme der Begriff Enterprise Resource Planning gepr gt und innerhalb k rzester Zeit wurde er zum Synonym f r vollintegrierte betriebliche
282. ragen auf die jeweiligen Server Instanzen ver teilt Dispatcher p 0 5 Server Server instanz 1 instanz 2 Abbildung 4 5 Vorgeschaltete Dispatcher Einheit zum Verteilen der Anfragen Quelle eigene Darstellung 1 p 0 5 Umsetzung Wie in Kapitel 3 1 beschrieben besteht ein SAP Netweaver AS Java aus einem Java Dispatcher und ein oder mehreren Java Server Instanzen die wiederum multiple Threads aufweisen Standardm ig sind f r jeden Java Server 40 Threads konfiguriert die allerdings ber einen entsprechenden Parameter konfiguriert werden k nnen Nach Rolia et al 2009 kann die explizite Modellierung des Dispatchers eines rein auf dem ABAP Stack basierenden SAP ERP Systems vernachl ssigt werden da der Dispatcher kei nen nennenswerten Einfluss auf die Systemperformance nimmt Aufgrund der engen Archi tekturverwandtschaft des im Java Stack eingesetzten Dispatchers wird auch in der vorliegen den Arbeit von dieser Annahme ausgegangen Zudem ist die Abbildung des Verteilungsme chanismus nur ber eine Ann herung m glich da keine komplexen Verteilungsalgorithmen im LQN Model integriert werden k nnen Die multiplen Threads einer Java Server Instanz werden ber die Multiplizit t modelliert da sie dieselbe Warteschlange innerhalb des Java Server Prozesses teilen Mehrere Java Server Instanzen k nnen ber die Server Repliken modelliert werden solange sie dieselben Charak teristiken aufweisen Allerdings ist auch
283. ration durchgef hrt worden ist und die Antwort die Entry am Lese bzw Schreibsperren Task erreicht wird die Antwort an die aufrufende Lastschritt Entry ge sendet Dies erfolgt aufgrund des weitergeleiteten Aufrufs der Anfrage vom Enqueue Server an den Lese Schreibsperren Task Sperrbereich 1 m 1 Sg Enqueue Server 7 N Pa FS a a NG Z N Sequentielle Abarbeitung verhindert zeitgleiche Sperranfragen Sperrbereich 1 Legende y 4 Task synchron m Multiplizitat FF Entry weitergeleitet SB Sperrbereich Abbildung 4 10 LQN Modellierung der Sperrverwaltung Quelle eigene Darstellung LQN Modell 120 Optimistische Sperren werden erst dann von einer Lese zu einer Schreibsperre wenn es auf grund einer durchgefiihrten Anderung des Benutzers notwendig ist Da der Workload und somit die Benutzeraktionen bekannt sind k nnen optimistische Sperren als entsprechende Lese bzw Schreibsperren modelliert werden Kumulative Schreibsperren k nnen nur dann gesetzt werden wenn die Schreibsperre von demselben Eigent mer angefordert wird Daher k nnen nach der Analyse der Sperranforde rungen in der Log Datei siehe Kapitel 3 1 3 kumulative Sperren eines Lastschrittes zu einer 1 Schreibsperre zusammengefasst werden Die Ermittlung der Sperrbereiche erfolgt ber die Analyse der Sperranforderung Log Dateien sowie der SQL Traces bei der die einzelnen Datenbankoperationen der im Workload durch gef hrten Last
284. rchgef hrte Auftragspositionen pro Stunde In technischen Werten ausgedr ckt entsprechen 100 SAPS 6 000 Dialogschritten mit 2 000 Verbuchungen bzw 2 400 SAP Transaktionen Da sich diese Einheit ber die Jahre hinweg nicht ge ndert hat kann die Leistungsentwicklung ber Jahrzehnte hinweg beobachtet werden Schneider 2008 276f Die SAP Standard Applikations Benchmarks haben zu einem Wettbewerb der Hersteller ge f hrt den h chsten SAPS Wert zu erreichen Prior 2003 Die Benchmark Ergebnisse wurden unter anderem dadurch optimiert dass durch die Verwendung von Caches Zugriffe auf den Hintergrundspeicher nicht mehr notwendig sind Zudem werden alle Operationen auf Haupt speicherzugriffe und CPU Operationen reduziert sodass keine langsamen I O Operationen anfallen Dies erh ht zwar die Anzahl an durchgef hrten Auftragspositionen pro Stunde und verbessert somit das Benchmark Ergebnis allerdings leidet darunter die Repr sentativit t eines realen Workloads Jehle 2010 Theoretische Grundlagen 62 Bei dem ersten Benchmark fiir J2EE basierte SAP Systeme handelte es sich um einen Kernel test der verschiedene Berechnungen innerhalb der Applikationsschicht ausf hrt und deren Bearbeitungszeit misst Sp ter wurde ein weiterer J2EE Benchmarks f r Java basierte SAP L sungen entwickelt SAP 2011h der die Grundfunktionen eines Portalsystems untersucht Allerdings kann dieser Benchmark kaum f r die eigenen Bed rfnisse angepasst werden da
285. rd vgl Kapitel 3 1 3 betrachtet werden Die dargestellten Enqueue Zeiten EZ beinhalten die Zeit der Datenbankabfrage da sich die Werte aus der Zeitdifferenz zwischen dem Erstellen tereate und dem L sen der Sperre tdelete berechnen EZ tereate tdelete Auffallend ist hierbei der stetige Zuwachs bis zu einer Anzahl von 80 gleichzeitig agierenden Benutzern Die ann hernd gleichbleibende Enqueue Zeit ab 80 Benutzern ergibt sich aus der maximalen Parallelit t ber die das Portalsystem aufgrund der 80 konfigurierten Applikati ons Threads verf gt Simulation und Evaluation 155 5 5 4 5 CPU Zeiten 600ms 6 core s oo q E T gt 00ms Score s 3 N 5 gt 2 E 400ms Acore s 5 v v SS eee SG ZS fee ee pr 2 300ms 1 3 core s 5 S 1 S gt 200ms 2 core s g 9 2 A V 100ms 1 1 core s S a Oms T O core s 1 20 40 60 80 100 120 Anzahl simultaner Benutzer CPU Zeit CPU Nutzung H 341 573 350 497 344 091 342 906 350 312 350 289 355 537 wo 24 962 26 963 25 574 24 111 26 851 32 837 30 426 N Cx 0 073 0 077 0 074 0 070 0 077 0 094 0 086 z Median 341 312 350 543 343 758 343 312 350 097 339 359 351 561 Q1 25 318 938 325 933 320 937 320 938 325 934 320 256 335 780 Q3 75 357 321 368 153 360 088 358 478 367 386 380 678 374 888 u 0 974 1 885 2 784 3 834 4 612 4 804 4 894 a o 0 018 0 028 0 052 0 064 0 099 0 109 0 109 gt Cx 0 019 0 015 0 019 0 017 0 022 0 02
286. reich bestimmt die Parameter der Entries Dies k nnen zum Beispiel Service Zeiten oder Aufrufe anderer Entries sein 5 Deklarationen der Aktivit ten Im letzten Abschnitt werden die Aktivit ten sofern sie im Modell definiert sind deklariert Das folgende exemplarische Modell vgl auch die schematische Darstellung des vollst ndi gen Modells in Abbildung 4 16 beschreibt die in Kapitel 4 2 dargestellten Komponenten Aus Griinden der Ubersichtlichkeit wird die jeweilige Anzahl der Komponenten reduziert 1 Benutzertyp mit 4 Benutzern 2 Interaktionsschritte 1 Java Server Instanz mit 2 korrespondierenden Lastschritten Lastschritt 1 stellt eine Lese und eine Schreibsperren Anfrage Lastschritt 2 eine lesende DB Anfrage ohne Sperrobjekt 2 SQL Abfragen eine lesend Select und eine schreibend Update 1 Sperrbereich f r beide SQL Abfragen 1 Tabellenpuffereintrag der lesenden SQL Abfrage Allgemeine Informationen Fur die Definition der Simulator Parameter werden die Standardwerte aus der Dokumentation bernommen Mit Ausnahme des explizit modellierten Garbage Collectors Simulation und Evaluation 161 1 Beispielhafte Modellierung Parametrisierung von 2 vereinfachten Interaktionsschritten 2 ausgef hrt mit LQsim v5 6 3 G 4 Modellbeispiel optionaler String f r Informationen 5 0 0001 Konvergenzkriterium 6 0 Iterationsgrenze 7 0 Ausgabeintervall 8 0
287. ressourcen csccessceeseeetseceeceteeeteeeeaeees 150 5 5 5 Szenario 2 Knappe Swvatemressourcen nee 156 SIUNT EEE LI t eege eege EEN ek 159 5 6 1 Eingabedatei Ges Simulators sun ea ee 160 5 6 2 Ausgabedatei des EIER aan En Eege 166 Vergleich der Mess und Simulationsergebnisse cccscccccssssssssssccsssscesessees 171 5 7 1 Szenario 1 Ausreichende Systemressourcen ccccceesceesceesseceeceseeeeeeeeseees 171 5 7 2 Szenario 2 Knappe Svatemressourcen 173 Analyse des Garbage Collectors und System Overheads 0sss000000000000000000000 175 Inhaltsverzeichnis V KO Ne EE EE 176 EE EE 179 3 9 E EE ET 180 6 E VA E 182 6 1 Bewertung und Interpretation der Ergebnisse ssssssssosssssnsesonnennonnennnnsennunne 182 6 2 aber Ee Eeer 189 E 190 7 Literaturverzeichnis siciss Sosiccessisasnsceseckscdavacsssccadbacsbaastesuucsessuccsuseunssncuacesse 192 Abbildungsverzeichnis VI Abbildungsverzeichnis Abbildung 1 1 Design Science Framework cccccceseceseceseeessceescecaeceseeeeeeeeaeecsaecneeeeeeenseees 9 Abbildung 1 2 Arbeiten im Forschungsbereich Performance Evaluation von ERP Systemen as near Asien leisen nel 11 Abbildung 1 3 Aufbau der Arbeit in Bezug auf den Design Science Prozess nach Pfeffers et ab 2006 WEE 12 Abbildung 2 1 Prinzipieller Aufbau eines ERP Systems ceceseeceeeeceeeceseeneeeseeeeeerennees 16 Abbildung 2 2 Entwicklung von ERP Systemen sowie Ei
288. risierung von Modus S Werten Frequenz 2 Ordinalskala Skalenwerte geordnet und lt gt Median vergleichbar Perzentil Werte geordnet Distanzen lt gt Arithmetisches S Intervallskala bestimmbar Mittel Standard Abweichung ES Wert dnet Skala hat lt gt trisch E Verhaltnisskala W erte geordne ala ha lt gt Geome risches einen absoluten Nullpunkt Mittel Skalenwerte sind absolute lt gt Absolutskala Gr en RR J 7 ag 0 Tabelle 2 1 Skalentypen Quelle eigene Darstellung in Anlehnung an Lilienthal 2008 Mittels Ma validierung wird sichergestellt dass die numerische Charakterisierung des be trachteten Merkmals g ltig ist das hei t dass zuverl ssige Messwerte geliefert werden k n nen Sie umfasst zwei Schritte eine interne und eine externe Validierung Bei der internen Validierung wird zuerst berpr ft ob die Grunds tze der Messtheorie eingehalten werden ber die externe Validierung wird festgestellt ob die zugrunde liegende Fragestellung durch die erhobenen Messwerte und ihre Interpretationen beantwortet wird Zuse 1998 71f 2 2 1 Statistische Kennzahlen Nachstehend werden die f r diese Arbeit relevanten grundlegenden statistischen Kennzahlen zusammenfassend aufgef hrt Vorab seien folgende Grundbegriffe beschrieben Stichproben sind Teilerhebungen aus der Grundgesamtheit da es oft nicht m glich ist die Grundgesamtheit also die
289. ritte beinhalten neben den behan delten Themen zudem noch potentielle Datenbankaufrufe sowie Abbr che durch Timeouts Datenbankaufrufe werden in den nachfolgenden Kapiteln zu den Sperrobjekten der Tabellen pufferung sowie der Datenbank behandelt Abbr che durch Timeouts stellen sicher dass ein Lastschritt nicht dauerhaft im System bleibt und den belegten Applikations Thread nicht mehr freigibt Eine derartige Situation k nnte beispielsweise durch eine nicht rechtzeitig aufgel s te Sperrsituation eintreten Daher ist es m glich eine maximale Bearbeitungszeit f r eine Ent ry anzugeben In dem Simulationslog kann im Nachgang gepr ft werden mit welcher Wahr scheinlichkeit es zu berschreitungen der maximalen Service Zeit gekommen ist Abbildung 4 6 stellt die Modellierung der Lastschritte schematisch dar Multiplizitat Server Threads N Replizierung e es Server Instanzen z Lastschritt d Lastschritt n 1 f p C u Cg Last Schritte Abbildung 4 6 LQN Modellierung der Lastschritte Quelle eigene Darstellung Parametrisierung Im Folgenden werden die Parameter der einzelnen Lastschritte genannt Dabei beschr nkt sich die Aufz hlung auf die Parameter f r die Konfiguration der individuellen Eigenschaften die im vorangegangenen Abschnitt diskutiert wurden LON Modell 114 4 2 3 Die Anzahl der Server Threads wird ber die Multiplizit t des LQN Tasks angegeben und mit dem Parameter lt multi_
290. rkierung Die Netzstruktur ist ein eingetragener bipartiter gerichteter Graph der den statischen Teil des Systems darstellt Dazu geh ren Stellen Transitionen und Kanten die die statischen Verhalt nisse eines Systems modellieren Ein Knoten in einem Petri Netz Modell besteht aus Stellen und Transitionen Stellen sind passive Elemente und stellen Zustandszust nde dar Graphisch wird eine Stelle durch einen Kreis dargestellt Transitionen sind aktive Elemente die lokale Zustands berg n ge modellieren k nnen Eine Transition wird graphisch durch ein Rechteck manchmal auch durch ein Quadrat dargestellt Kanten verbinden Stellen und Transitionen Sie stellen somit eine Beziehung zwischen den beiden Elementen her Dabei k nnen Stellen nicht mit anderen Stellen und Transitionen nicht mit anderen Transitionen verbunden werden Die Kanten werden graphisch mit einem Pfeil der die Richtung der Relation angibt dargestellt Markierungen sind das vierte Element von Petri Netzen Diese modellieren die dynamischen Verh ltnisse eines Systems indem sie angeben in welchem Zustand sich das Gesamtsystem im Augenblick befindet Sie befinden sich auf einer Stelle und werden als schwarze Kreise in den Stellen graphisch dargestellt Abbildung 2 10 zeigt die vier genannten Elemente und de ren entsprechende graphische Notation Theoretische Grundlagen 4 Transitionen Stellen Gerichtete Kante Markierung Token Abbildung 2 10 Elemente von
291. rn da der CPU im LQN Modell weiterhin Ressourcen zur Verf gung stehen 3 Das Antwortzeitverhalten folgt der Annahme aus dem Warteschlangenmodell Wie bereits im Kapitel ber Warteschlangennetze dargestellt beschreibt in einem Warteschlangenmodell eine mathematische Verteilung das Ankunftszeitverhalten so wie das Bedienzeitverhalten Aus dem Markov Ketten Modell M M n siehe Kendall Notation in Kapitel 2 4 welches zum Beispiel f r symmetrische Multipro zessor Systeme verwendet wird ergibt sich ein Antwortzeitverhalten das zuerst linear und ab einem gewissen Punkt exponentiell ansteigt Der exponentielle Anstieg ist da bei meist durch starke Wartesituationen bedingt LQN Modell 105 Aus den drei soeben erl uterten Annahmen ergibt sich somit folgendes Systemverhalten Die CPU Zeit pro Interaktionsschritt bleibt konstant und ist unabh ngig von der Anzahl simulta ner Benutzer und somit von der Systemauslastung Annahme 1 Die CPU Nutzlast steigt linear mit der Anzahl an Benutzern an und kann bei entsprechender Auslastung 100 errei chen Annahme 2 Das Antwortzeitverhalten setzt sich aus einer linear ansteigenden Phase und einem exponentiellen Anstieg zusammen Annahme 3 In Abbildung 4 2 werden diese Annahmen bildlich zusammengefasst W hrend die CPU Zeit pro Interaktionsschritt gleich bleibend und somit von u eren Systembedingungen unabh ngig ist steigen sowohl CPU Last bis zu 100 als auch die Antwortzeit bei einer zunehme
292. rn nur von der Gegenwart abh ngen Diese Markov Eigenschaft macht es leichter einen Prozess zu analysieren da man sich nicht an den kompletten vergan genen Bewegungsablauf erinnern muss Jain 1991 516 Auch der Zustandsraum eines stochastischen Prozesses kann kontinuierlich oder diskret sein Bei Markov Prozessen ist der Zustandsraum im Allgemeinen stetig Bei diskretem Zustands raum wird von Markov Ketten gesprochen Die folgende Vier Felder Tafel zeigt eine Klassi fizierung auf zwei Ebenen auf Diskreter Kontinuierlicher Parameterraum Parameterraum Diskreter Diskrete Kontinuierliche Zustandsraum Markov Kette Markov Kette Kontinuierlicher Diskreter Kontinuierlicher Zustandsraum Markov Prozess Markov Prozess Tabelle 2 2 4 Felder Tafel Quelle eigene Darstellung in Anlehnung an Ferschl 1970 Eine zeitdiskrete Markov Kette kann aufgrund ihrer Zustandsmenge Z entweder endlich oder unendlich sein Lunze 2006 338 Zeitkontinuierliche Markov Ketten sind eine wichtige Klasse von stochastischen Prozessen die weithin in der Praxis verwendet werden um Sys temperformance und Zuverl ssigkeitsmerkmale zu bestimmen Ihre Analyse betrifft am h u figsten die Berechnung von Dauerzustands und vor bergehenden Zustandswahrscheinlich keiten Baier et al 2003 Beide Arten von Markov Ketten bieten verschiedene dennoch mit einander verwandte Modellierungstechniken an jeder von ihnen mit einer anderen Anwen dungsdom ne
293. rozent kommen Insgesamt baut sich der verwendete mpstat Befehl aus folgenden Paramatern zusammen mpstat lt Intervall gt lt Anzahl gt gt lt Ausgabedatei gt Ebenso wie bei topas berechnet sich die Gesamtlaufzeit aus der Anzahl der zu erhebenden Stichproben multipliziert mit dem angegebenen Intervall Der Einfluss von mpstat auf das Testsystem ist ebenso sehr gering In den verschiedenen Testsystem Konfigurationen schwankte der CPU Ressourcen Bedarf bei einem Intervall von 1 Sekunde zwischen 0 05 und 0 1 Prozent Auch hier gilt die Aussage dass die Uberwachung Systemarchitektur und Monitoring 98 der Prozessorauslastung im Regelbetrieb durchgef hrt wird und somit ein praxisgetreues Sze nario nicht verf lscht F r die Aufzeichnung der Daten wurden die Daten anstelle des Standard Ausgabe Streams in eine Datei umgeleitet und anschlie end in Excel importiert Aufgrund der Blockstruktur ge f llt mit Leerzeichen konnten die einzelnen Spalten getrennt eingelesen und anschlie end grafisch dargestellt werden 3 3 2 Monitoring des Hauptspeichers F r die berwachung des Hauptspeichers bietet vmstat IBM 2011m die M glichkeit zu s tzlich Daten zur Active Memory Expansion AME IBM 201la zu erhalten Active Memory Expansion ist eine von IBM entwickelte Technologie f r IBM Power7 Systeme die Hauptspeicherdaten komprimiert und somit eine gr ere Hauptspeicherkapazit t anbieten kann als physisc
294. rproportionale Anstieg nicht vom LQN Modell erfasst wird diver gieren die gemessenen und simulierten Antwortzeiten Fazit 184 Szenario 1 Szenario 2 1500s 1500s Kai T 4 3 a 5 1200s 5 1200s 8 8 o fe amp 900 2 900 E S SCH E Ss Max Applikations Threads lt CPU Ressourcen ersch pft 5 gt Wartezeiten 5 gt Wartezeiten 600s 600s E E ZS 3008 amp 3005 Ab ca 80 Benutzern _ E berproportionaler E J E 4 Anstieg der GC Zeiten Os a T T T T T I Os T 7 T T B T u T T 7 1 20 40 60 80 100 120 1 20 40 60 80 100 120 Anzahl simultaner Benutzer Anzahl simultaner Benutzer 1 2a 1 2b 3 Messwerte Q1 25 Messwerte Q3 75 Simulation Abbildung 6 1 Bewertung der Ergebnisse nach dem Antwortzeitverhalten Ouelle eigene Darstellung Beurteilt man die identifizierten Bereiche nach den erreichten Simulationsergebnissen k n nen vor allem in den Bereichen 1 und 2a 2b vielversprechende Prognosen festgestellt werden Das Auftreten von Wartezeiten das durch eine Begrenzung der Applikations Threads oder durch ersch pfte CPU Ressourcen bedingt sein kann wird von der Simulation zuverl ssig erkannt Ebenso werden die Wartezeiten im Sperrmanagement sowie zunehmende Daten bankzugriffe aufgrund von Verdr ngungen und Invalidierungen im Tabellenpuffer simuliert Lediglich den im dritten Bereich zunehmenden externen Einfl ssen
295. rstellen Das Workload Modell Wn ist nun quivalent zu dem realen Workload W wenn Lm inner halb bestimmter Grenzen von L liegt vgl Ferrari 1978 Zwei Begriffe werden in der Literatur im Zusammenhang mit Workload Charakterisierung h ufig verwendet vgl Jain 1991 1 Eine Workload Komponente beschreibt Einheiten in dem zu analysierenden System Dies k nnen Applikationen Programme Kommandos Maschineninstruktionen aber auch Benutzer sein Theoretische Grundlagen 34 2 Workload Parameter stellen die Messgr en Ressourcenanforderungen und Service Anfragen dar welche verwendet werden um den Workload zu charakterisieren bei spielsweise Paketgr en Transaktionstypen etc Nach Ferrari Serazzi Zeigner 1983 erfolgt die Modellbildung in drei Phasen 1 Formulierungsphase W hrend der Formulierungsphase werden die zu betrachtenden Parameter definiert Dies ist abh ngig von dem Ziel der Performance Analyse sowie den zur Verf gung stehenden Daten Neben den klassischen Parametern auf dem phy sikalischen Level CPU Zeit Hauptspeicher und IO Operationen k nnen Parameter auf funktionalem Level in Betracht gezogen werden wie beispielsweise Ausf hrungs h ufigkeit bestimmter Programme oder die Anzahl der Aufrufe eines Web Services 2 Konstruktionsphase Bei der Konstruktionsphase werden die gew hlten Parameter mit den entsprechenden Werten der gesammelten Daten in Verbindung gebracht und die Werte den einzelnen Kompo
296. rt die Auswirkungen einer zu fr h greifenden Einschr nkung der zur Verf gung stehenden Applikations Threads verdeutlicht werden Obwohl noch gen gend Systemressourcen vorhanden waren wurde eine h here Pa rallelit t durch die konfigurierte Grenze verhindert Auf der anderen Seite darf jedoch die Menge an zur Verf gung stehenden Applikations Threads trotz vorhandener CPU Ressourcen nicht zu hoch angesetzt werden da eine h here Anzahl an simultan abgearbeiteten Benutzer anfragen einen h heren Speicherverbrauch mit sich bringt und zu erh hten GC Aktivit ten f hren kann falls der Heap Speicher fast zur G nze belegt wird Kapazit tsplanung Einen weiteren Blickwinkel auf die Simulationsergebnisse stellt die Betrachtung hinsichtlich der Kapazit tsplanung und dem damit einhergehenden Bemessen der Systeme Sizing dar Der in Kapitel 2 7 vorgestellte Kapazit tsplanungsprozess nach Menasc Almeida 2002 179 sieht eine Charakterisierung des Workloads und die Erstellung eines Performance Modells vor das zur Performance Vorhersage genutzt wird Dies kann mit dem in dieser Ar beit vorgestellten Modellierungs und Simulationsvorgehen bewerkstelligt werden Daneben muss ein Kostenmodell zur Kostenvorhersage erstellt werden das im Zusammenspiel mit der Performance Vorhersage zur Kosten Performance Analyse f hrt Daraus kann wiederum ein Konfigurationsplan entwickelt werden der notwendige Hardware und Softwarekonfiguratio nen spez
297. rt bedient werden kann da alle Be dienstationen Prozessor Threads besch ftigt sind Als Beispiel seien die CPU Ressourcen aus Szenario 2 betrachtet die ab ca 40 simultan agierenden Benutzern ausgereizt sind Die Server CPU im LQN Modell wird entsprechend mit einer Multiplizit t von 40 parametrisiert da die CPU lediglich 40 Applikations Threads und somit 40 simultane Benutzer zeitgleich bedienen kann Zusammenfassend wird somit eine Vielzahl an statistischen Informationen zu den einzelnen Modellkomponenten dargestellt Die in dieser Arbeit betrachtete Metrik Antwortzeit wird anhand von Mittelwerten sowie deren Verteilungen wiedergegeben Antwortzeiten werden in der Ausgabedatei als Service Zeiten bezeichnet und sind wie bereits ausf hrlich erl utert nicht mit den Service Zeiten der Parametrisierung zur verwechseln Sie stellen die gesamte Ausf hrungszeit dar Im konkreten Fall des vorgestellten Modells m ssen von der Service Zeit der einzelnen Interaktionsschritte dargestellt als Aktivit ten im Benutzer Task mit einer Service Zeit von 0 potentielle Denkzeiten abgezogen werden um die Antwortzeit zu erhal ten Die Summe der einzelnen Antwortzeiten ergibt die Gesamtantwortzeit der Fallstudie oh ne Denkzeiten Diese aggregierten Werte werden im folgenden Kapitel mit der Summe der gemessenen Antwortzeiten der Fallstudie verglichen Simulation und Evaluation 171 5 7 Vergleich der Mess und Simulationsergebnisse Die Messwerte de
298. rtige Notwendigkeit der Festlegung der verwendeten Leistungskenngr e auch Met rik genannt dem Workload und der Methode der Leistungsbewertung bei der Analyse eines bestimmten Systems spiegelt sich in den entsprechenden Unterkapiteln wider Neben der in dieser Arbeit eingesetzten Simulation von LQNs einer speziellen Form von Warteschlangen netzen wird ebenso auf alternative Methoden der Performance Evaluation kurz eingegangen Daraufhin wird dargestellt welche Vergleichskriterien in Form von Benchmarks f r die Leis tungsbewertung von Rechnersystemen eingesetzt werden k nnen Den Abschluss des Grund lagenkapitels bildet ein kurzer berblick ber die Kapazit tsplanung die sich mit der Frage besch ftigt wann die Systemauslastung ges ttigt ist und welche kosteng nstigen Methoden den S ttigungspunkt am l ngsten hinausz gern Kapitel 3 widmet sich der Architektur und den M glichkeiten zur berwachung der Leis tungsdaten eines SAP Netweaver Portal Systems Bei der Beschreibung der Architektur wird zu Beginn die Abarbeitung von Anfragen dargestellt und die Konfiguration beteiligter Ele mente erl utert Daraufhin wird die Funktionsweise der Systemkomponenten aufgezeigt die in der Literatur und der Systemdokumentation als wesentliche Einflussgr en auf die Ant wortzeit identifiziert wurden Ein Hauptaugenmerk wird dabei auf das Sperrmanagement von Datenbankobjekten die Pufferung von Datenbanktabellen und das Java Speichermanagement
299. ruf Weitergeleiteter Aufruf Abbildung 4 16 Schematische Darstellung des LQN Modells Quelle eigene Darstellung Mit dem vorgestellten Modell ist es m glich SAP Netweaver Portal Systeme mittels LON zu modellieren Die Komponenten der Sperrverwaltung des Tabellenpuffers und die bei der Analyse des Garbage Collectors eingef hrten GC Komponenten erm glichen eine explizite Parametrisierung der identifizierten Einflussfaktoren im System siehe Kapitel 4 1 2 Der Workload wird ber die modellierten Lastschritte charakterisiert und von den Benutzer Tasks ber die darin definierten Interaktionsschritte aufgerufen Die Definition unterschiedli cher Benutzertypen erm glicht die Charakterisierung verschiedener Aktivit ten und Denkzei ten Da der betrachtete Workload inh renter Bestandteil des LQN Modells ist muss er bei jeder nderung entsprechend angepasst werden Das vorgestellte Modellierungskonzept kann jedoch f r eine Vielzahl von unterschiedlichen Lastmustern eines SAP Netweaver Portal Systems angewendet werden und gen gt somit den Anforderungen der Verallgemeinerbar keit Zusammenfassend konnte mit den aus der Warteschlangentheorie abgeleiteten Grundannah men Kapitel 4 1 1 sowie der Identifikation und Einordnung der Einflussfaktoren Kapi tel 4 1 2 der Rahmen f r das in diesem Kapitel erstellte Artefakt festgelegt und anschlie end erstellt werden Dieses Kapitel beantwortet somit Forschungsfrage 2 das hei
300. rung des Warteschlangenmodells m ssen daher inhaltliche und infrastrukturelle Datenbankaufrufe getrennt werden Der SQL Trace kann ber die Web Applikation Open SQL Monitors aktiviert und die auf gezeichneten Daten evaluiert werden siehe Abbildung 3 22 Die zur Verf gung gestellten Daten k nnen anhand unterschiedlichster Parameter Sitzungs ID DSR Transaktions ID Benutzer Dauer Applikation usw gefiltert oder auch als XML Datei exportiert werden Eine entsprechende Document Type Definition Datei DTD Datei wird ebenfalls bereitge stellt Die f r die Performance Analyse relevanten Daten sind in Tabelle 3 10 aufgelistet Attribut Beschreibung Statement SQL Statement oder JDBC Methodenaufruf Time Startzeitpunkt des JDBC Methodenaufrufs Location Name der JDBC Methode Duration Dauer des Methodenaufrufs in Mikrosekunden J2EE User J2EE User der den Methodenaufruf durchgef hrt hat J2EE Session J2EE Sitzungs ID J2EE Application Name der J2EE Applikation die den Methodenaufruf initi iert hat DSR Transaction ID Zugeh rige Transaktions ID Database ID String der die verwendete Datenbankverbindung angibt Dieser besteht aus dem Datenquellennamen und dem Daten Systemarchitektur und Monitoring 91 bankbenutzer Thread Thread der den JDBC Aufruf durchgef hrt hat Prepared Statement ID Eindeutige ID des SQL Statements ResultSetID Eindeuti
301. s S 3 10 Amsterdam The Netherlands ACM Lilienthal C 2008 Komplexit t von Softwarearchitekturen Universit t Hamburg 2008 Lilja D J 2000 Measuring Computer Performance A Practitioner s Guide Cambridge University Press Cambridge 2000 Lindley 1952 The Theory of Queues with a Single Server In Cambridge Philosophical Society Vol 48 1952 S 277 289 Little J D C 1961 A Proof for the Queueing Formula L lamda W In Operations Research Vol 9 1961 Nr 3 S 383 387 LQsim 2011 LQsim Man Page In http www sce carleton ca rads lgns lgqn documentation lgsim txt zugegriffen am 18 10 2011 2011 Lunze J 2006 Ereignisdiskrete Systeme Modellierung und Analyse dynamischer Systeme und Automaten Markovketten und Petrinetzen Oldenbourg M nchen Wien 2006 March S T Smith G 1995 Design and Natural Science Research on Information Technology In Decision Support Systems Vol 15 1995 Nr 4 S 251 266 March S T Storey V C 2008 Design science in the information systems discipline an introduction to the special issue on design science research In MIS Q Vol 32 2008 Nr 4 S 725 730 Marquard U G tz C 2008 SAP Standard Application Benchmarks IT Benchmarks with a Business Focus In Vol 5119 Hrsg Kounev S Gorton L Sachs K Springer Berlin Heidelberg 2008 S 4 8 Mayer M Gradl S Schreiber V Wittges H Kremar H 2011 A Survey on Performance
302. s zum Schutz vor Schreibzugriffen w rde jedoch so lange in der Warteschlange verweilen bis die erste Leseoperation ihren Zugriff beendet hat und ber einen Aufruf der Signal Entry die Schreibsperre aufhebt Abbildung 4 8 Beispiel zweier sich blockierender Leseoperationen Quelle eigene Darstellung Umsetzung In einem SAP Netweaver Portal System kommen Lese und Schreibsperren zum Einsatz Da wie soeben erw hnt in LQN Modellen ein Lese Schreib Sperrmechanismus nicht nativ um gesetzt werden kann soll folgende Ann herung das Sperrverhalten beschreiben Im LQN Modell wird jede Datenbankoperation die im Workload auftritt modelliert damit die einzelnen Service Zeiten entsprechend vergeben werden k nnen Datenbankoperationen die sich gegenseitig ausschlie en fallen in einen Sperrbereich F r jeden Sperrbereich wird eine Sperrverwaltung wie in Abbildung 4 9 dargestellt modelliert Eine Sperrverwaltung f r einen Sperrbereich besteht aus drei Komponenten 1 Einem regul ren LON Task f r die Lesesperre des Sperrbereichs Jede Entry des LQN Tasks stellt die lesende Datenbankoperation dar die im Workload auftritt und in diesen Sperrbereich f llt Die Multiplizit t wird auf unendlich gesetzt da mehrere LQN Modell 117 3 Leseoperationen gleichzeitig durchgef hrt werden k nnen Jede Entry wird ber einen Aktivit tsgraphen beschrieben der noch n her erl utert wird Einem regul ren LON Task f r die Schreibsperr
303. s Thread Pools Die Gr e wird dyna misch an den momentanen Bedarf angepasst InitialThreadPoolSize Initiale Pool Gr e MinimumThreadPool ize Minimale Pool Gr e MaximumThreadPoolSize Maximale Pool Gr e WaitingTasksCount Anzahl der in der WaitingTasksQueue vorhandenen Aufga Systemarchitektur und Monitoring 67 ben WaitingTasksQueueOverflow Anzahl der Aufgaben die bei einer vollen WaitingTasks Queue keinen Platz mehr gefunden haben WaitingTasksQueueSize Derzeitige Gr e der WaitingTasksQueue Die Gr e wird auch hier dynamisch an den momentanen Bedarf angepasst ActiveThreadsCount Anzahl der derzeit aktiven Threads im System Tabelle 3 2 Wichtige Monitore des System Thread Managers Quelle eigene Darstellung in Anlehnung an SAP 201 1a Speziell fiir Leistungsanalysen die eine hohe Anzahl an Anfragen an den Dispatcher senden sind die beiden Monitore ActiveThreadsCount und MaximumThreadPoolSize sowie die An zeige der WaitingTasksQueueOverflow von Bedeutung Sollte bei letzterer ein Wert gr er Null gemeldet werden wurden Anfragen nicht korrekt bearbeitet und ein Fehler zur ckgege ben Der HTTP Provider Service legt die Daten der Anfrage in die Session Queue ab und gibt an schlie end den System Thread wieder frei Zudem wird in diesem Service entschieden an welchen Java Server Prozess die Anfrage weitergeleitet wird und die Verbindung zum Client aufrechterhalten Sollte das Zei
304. s mit ein B blocks runtime skip Alternativ kann die Anzahl der Bl cke manuell festgelegt werden Die beiden anderen Werte sind analog zu Option A R Mit diesem Parameter werden zus tzliche statistische Information in der Stan dardausgabe ausgegeben Unter Verwendung von Option A oder B werden zu s tzlich die Percentile 95 sowie 99 ausgegeben 7 Revision 9242 11 Februar 2011 Der verwendete Simulator Version 5 6 hatte unter Microsoft Windows Probleme bei der Ausf hrung der Simulationsl ufe mit Option A und B Daher wurde ein Linuxsystem f r die Simulationsl ufe eingesetzt Simulation und Evaluation 160 S seed Bestimmt den Saatwert der f r die Initialisierung des Zufallszahlengenerators verwendet wird 5 6 1 Eingabedatei des Simulators Die Eingabedatei des Simulators stellt eine editierbare Textdatei dar die grunds tzlich in f nf Bereiche unterteilt wird 1 Allgemeine Informationen Neben einem String zur Beschreibung der Eingabedatei werden in diesem Bereich Simulator Parameter bergeben beispielsweise das Kon vergenzkriterium die Iterationsgrenze oder das Ausgabeintervall 2 Prozessordeklarationen Dieser Bereich deklariert die Prozessoren deren Scheduling Typ sowie die Anzahl ihrer Kerne 3 Task Deklarationen In diesem Abschnitt werden die Tasks deren zugeh rigen Ent ries und task spezifische Parameter deklariert 4 Entry Deklarationen Der Entry Be
305. saktion 2 Anderung und T Pre NS y Abbildung 3 4 Java Transaktionen Quelle eigene Darstellung 3 1 3 Sperrtabellenverwaltung Die in einer Java Transaktion durchgef hrten Datenbankaufrufe k nnen Sperren erfordern die ber die Sperrtabelle des Enqueue Servers verwaltet werden Da Sperreintr ge eines Pro grammes die Abarbeitung anderer Aufgaben verz gern und somit die Performance stark be einflussen k nnen wird die Sperrverwaltung in diesem Kapitel dargelegt Die Sperrverwaltung ist grunds tzlich Aufgabe des J2EE Frameworks und dementsprechend im J2EE Standard spezifiziert Das Verhalten ist dabei jedoch abh ngig von der verwendeten Datenbankplattform Der Enqueue Server wurde daher analog zum ABAP Stack eingef hrt um ein einheitliches Sperrmanagement zu schaffen welches datenbankunabh ngig ist Um einen Eintrag in der Sperrtabelle hinzuzuf gen spricht das Java Programm das entspre chende Interface des Application Locking Service an Der Application Locking Service bie tet dabei verschiedene M glichkeiten auf welche Art und Weise die Sperren gesetzt werden SAP 2011c Neben der klassischen Tabellensperre bei der eine komplette Datenbanktabelle oder ein Tabellenbereich gesperrt wird existieren logische und serverinterne Sperren die je doch eine untergeordnete Rolle im Zuge der Leistungsbetrachtung spielen und daher in dieser Arbeit nicht weiter betrachtet werden Die Sperranfrage wird sobald sie von dem Applicatio
306. sch oder als Liste erfolgen In der Hie rarchieanzeige wird zun chst eine Liste mit Initialsystemen angezeigt Wenn eine Be nutzeraktion LUW in weiteren Komponenten oder Instanzen verarbeitet wurde fin den sich in den Ebenen darunter die entsprechenden Aufrufe sowie deren Perfor mancedaten Zu den einzelnen Datens tzen k nnen diverse Detailansichten aufgerufen werden siehe Ab bildung 3 20 Systemarchitektur und Monitoring 89 Statistik Springen System Hilfe VE g sl d H eee BAR SNS BE ep Funktionaler Trace Volbild ein aus x Daten Selektion Analysierter Zeitraum 21 02 2012 03 30 00 21 02 2012 03 40 00 Zeitzone CET d et Neue Selektion Analysierte Systeme portalsim2_P33_333227250 portalsim2_P33_333227250_DBI amp 1 Zeiteinheit davor Keine Daten lieferten portalsim2_P33_333227250_DBI 1 2 Zeiteinheit davor w 1 2 Zeiteinheit sp ter 1 Zeiteinheit sp ter la BE BEE trace paten Jl Hierarchie gt amp Einstellungen amp Protokoll Systeme Aktionen User Startz Aktion Service Anwender Antw Z en Syetan CI SAPIZENode portalsim2_P33_3332 592 EB Anzeige Analyseoptionen C sapyzeNode portalsim2_P33_3332 40 HE Trace ein ausschatten C SAPJ2ENode portakim2_P33_3332 42 146 B Anwendungsprotokoll DI SAPJ2ENode portakim2_P33 3332 3 872 OH portalsim2_P33_333227250 0 D 03 33 44 Detalanalse des gews d EJB Request Administrator 3 837 B
307. schritt x Abbildung 5 3 Sequentielle Abarbeitung bestimmter Lastschritte Quelle eigene Darstellung Simulation und Evaluation Abschlie end ist zu pr fen welche Portaloperationen mehrfach durchgef hrt werden da auf eine doppelte Parametrisierung desselben Lastschrittes verzichtet werden kann vgl Jehle 2010 65 Dementsprechend reduziert sich die vollst ndige Liste der Portaloperationen unter Ber cksichtigung der genannten Aspekte auf die in Tabelle 5 1 aufgelisteten Funktionen Mehrfach durchgef hrte Operationen werden in dieser Darstellung nicht aufgef hrt ID Funktion Einzeln Parallel wiederholbar nutzbar Tag I Vorbereitungen 1 0 Portal Seite ffnen X X 1 1 Logon Admin X 12 User anlegen X X 1 3 Gruppe anlegen X X 1 4 User zu Gruppen hinzuf gen X 1 5 Ordner anlegen X X 1 6 Rolle anlegen X X 1 7 Objekt Rolle ffnen X 1 8 Einstiegspunkt aktivieren X 1 9 Rolle zu Gruppe zuordnen X 1 10 Rolle anpassen X X 1 11 Leserechte f r Portal Content vergeben X X 1 12 Schreibrechte f r Ordner anlegen X X 1 13 Kurskonfiguration pr fen X X 1 14 Logout X X Tag 2 Login Navigation Personalisierung Men 2 1 Initiales Passwort ndern X X 2 4 Zur Startseite wechseln X 2 5 Personalisieren Darstellungsschema ndern X X 2 6 Personalisieren Darstellungsschema speichern X 2 8 De
308. schritte aufgezeichnet werden Jede Datenbankoperation besteht neben der ei gentlichen SQL Anfrage aus weiteren Schritten connect commit close usw die im SQL Trace einzeln angegeben sind Diese Schritte m ssen zun chst zu einer Datenbankopera tion zusammengefasst und die durchschnittliche Service Zeit sowie die Streuung berechnet werden Die einzelnen Datenbankoperationen die sich gegenseitig ausschlie en werden wie derum zu einer Gruppe zusammengefasst und stellen einen Sperrbereich dar Nicht alle in den Lastschritten durchgef hrten Datenbankaufrufe fordern eine Sperre an dies liegt am Entwick ler des Java Programms Daher wird ber die Enqueue Log Datei gepr ft welche Sperran forderungen gesendet wurden und anschlie end werden nur jene modelliert die auch tats ch lich eine Sperrung durchf hren Parametrisierung Im Folgenden wird die Parametrisierung der Sperrverwaltung dargestellt Auch hier soll sich die Aufz hlung auf die diskutierten Aspekte beschr nken Die zwei Entries Wait und Signal werden ber die Entry Definitons Option P f r die Signal Entry und Option V f r die Wait Entry spezifiziert F r jeden Sperrbe reich wird ein eigener Semaphor eingerichtet Die Aktivit ten in den Lese bzw Schreibsperr Tasks werden ber die Aktivit ts Notation realisiert Aufgrund der komplexen Notation soll hier auf die einzelnen Ob jekte nicht n her eingegangen sondern auf das Benutzerhandbuc
309. sdiskrete Simulation aus folgenden Phasen 1 Die Simulationsuhr wird initialisiert und die Zeiten zuk nftiger Ereignisse werden festgelegt 2 Die Simulationsuhr wird auf den Zeitpunkt des n chsten Ereignisses gestellt 3 Der Systemstatus wird aktualisiert 4 Die Zeiten zuk nftiger Ereignisse werden aktualisiert und Schritt 1 wird wiederholt Bei zeitdiskreten Simulationen schreitet die Simulationsuhr hingegen in festen Zeiteinheiten At fort Nach jedem Schritt werden die Variablen f r das Intervall t t At aktualisiert Der Unterschied zwischen ereignisdiskreten und zeitdiskreten Simulationen ist in Abbildung 2 12 visualisiert Theoretische Grundlagen 44 Zustand Zustand 4 Zeit 4 Zeit Ereignisse Ereignisse ereignisdiskret zeitdiskret Abbildung 2 12 Ereignisdiskrete vs zeitdiskrete Simulation Quelle eigene Darstellung in Anlehnung an Banks et al 2004 11 Werden kontinuierliches und diskretes Simulationsverhalten kombiniert spricht man von ei ner hybriden Simulation Kourjanski Varaiya 1995 2 4 Warteschlangennetze Im t glichen Leben begegnen uns sehr viele Situationen bei denen wir warten ob bei einem Zahnarzttermin vor dem Kaffeeautomaten oder der Supermarktkasse Bei Rechnersystemen sind ebenfalls viele Warteschlangensituationen vorzufinden beispielsweise bei der Prozess verwaltung auf der Betriebssystemebene bei der Nutzung geteilter Ressourcen zum Beispiel Drucker oder bei Kommunikationsprotokollen
310. se und prognose besteht die die bisherigen genannten Defizite mindern Es stellt sich somit heraus dass der Bedarf an einem methodischen Vorgehen zur Perfor mance Evaluation von Unternehmenssoftware besteht das den bestehenden M ngeln der Leistungsbewertung entgegenwirkt Ebenso hat sich gezeigt dass sich die Leistungsanalyse haupts chlich auf die Verwendung von integrierten Hilfsmitteln beschr nkt und modellbasier te analytische Verfahren sowie Simulation nur teilweise zum Einsatz kommen Diese L cke soll mit der vorliegenden Arbeit reduziert werden indem ein in der Literatur etablierter mo dellbasierter Ansatz zur Leistungsanalyse eines SAP Netweaver Portal Systems welches in den Kontext von Unternehmenssoftware einzuordnen ist angewendet wird Einleitung 4 1 2 Ziele Zusammenfassend hat die vorliegende Arbeit das Ziel aus den Erkenntnissen der Literatur und den analytischen Hilfsmitteln eines SAP Netweaver Portal Systems relevante Leistungs daten zu erfassen und tiber die Modellierung und Simulation eines gegebenen Lastmusters Workloads sowie der Komponenten die als Einflussgr en f r das Leistungsverhalten gel ten Leistungswerte bei einer steigenden Anzahl von Benutzern zu ermitteln Im ersten Schritt werden aus der Literatur die Grundlagen erarbeitet die fiir die Performance Evaluation eines SAP Netweaver Portal Systems ben tigt werden F r die Modellierung und Simulation werden die auf der Warteschlangentheorie
311. server_flag gt definiert Die Anzahl der Server Instanzen kann in bestimmten F llen ber Repliken gesteuert und mit dem Parameter lt replication_flag gt spezifiziert werden Soll ein Dispatcher modelliert werden wird dieser in einem eigenen Task modelliert der eine Aktivit t beinhaltet die ber eine oder mehrere Oder Gabelungen auf die ver schiedenen Server Instanzen verweist In dieser Arbeit wird aus den im Abschnitt ber die Umsetzung genannten Gr nden auf die explizite Modellierung des Dispatchers verzichtet und ist somit implizit ber die Multiplizit t des Lastschritte Tasks gegeben Der Scheduling Mechanismus wird ber den Parameter lt task_sched_type gt bestimmt Die Warteschlangengr e nicht zu verwechseln mit der Multiplizit t und somit der Anzahl an Bedienstationen des Tasks wird in dieser Arbeit nicht definiert damit es im Simulationsmodell nicht zur unerwarteten Ablehnung von Anfragen kommt die im realen System aufgrund der Warteschlange des Dispatchers und dessen Verteilungsal gorithmus nicht auftreten w rden Grunds tzlich kann diese aber ber den Parameter lt queue_length gt spezifiziert werden Ebenso werden keine unterschiedlichen Priorit ten Parameter lt entry_priority gt ein zelner Anfragen abgebildet durch die entsprechende Entry gesetzt Dies begriindet sich direkt aus dem Verhalten des betrachteten Portalsystems Die durchschnittliche Service Zeit u wird ber den Parameter lt service_
312. setzt werden Die Modellierung der Lastschritte umfasst verschiedene Elemente die sich auf die Antwort zeit auswirken Die erzielten Ergebnisse lassen auf eine gute bis sehr gute Abbildbarkeit der Lastschritte schlie en Die Angabe einer maximalen Service Zeit f hrt zwar nicht zum Ab bruch der Aktion w hrend der Simulation es wird allerdings in der Ausgabedatei des Simula tors die Wahrscheinlichkeit f r eine berschreitung des Limits angegeben Dies erm glicht beispielsweise die berpr fung ob bestimmte SLAs eingehalten werden Die Datenbank wurde in dieser Arbeit als Black Box betrachtet Eine Bewertung der Simula tionsgenauigkeit kann deswegen nur dahingehend erfolgen dass bei akkurat parametrisierten Bearbeitungszeiten der Zugriff auf die Persistenzschicht entsprechend nachgezeichnet wird Das mit den Datenbankzugriffen zusammenh ngende Sperrmanagement konnte ber ein neu artiges Modellierungskonzept der Lese und Schreibsperren vielversprechend abgebildet wer den Die Abbildung des Tabellenpuffers wurde ber die Angabe einer Weiterleitungswahr scheinlichkeit realisiert die sich mit dem in Kapitel 4 2 4 dargestellten Ansatz berechnen l sst Die Genauigkeit dieser Angabe ist sehr stark von vorhandenen Messdaten und der Ta bellenpuffergr e in Relation zu der Gr e der gepufferten Objekte abh ngig und stellt folg lich lediglich eine Sch tzung der tats chlichen Trefferrate dar Die Bewertung der Simulati onsgenauigkeit d
313. sich im Laufe der Zeit weiterentwickeln Mit Hilfe von Zustandsvariablen beschreibt man den Zustand zu einem Simulationszeitpunkt Die zeitlichen nderungen k n nen kontinuierlich oder diskret stattfinden Bei einer kontinuierlichen Simulation ndert sich der Wert der Zustandsvariablen kontinuier lich ber die Simulationszeit Solche Modelle bilden mittels einer oder mehrerer Differential gleichungen den Zusammenhang zwischen Zeitfortschritt und nderungen der Zustandsvari ablen ab Dabei entziehen sich die Differentialgleichungen aufgrund ihrer Komplexit t einer analytischen Behandlung Durch den Einsatz von numerischen L sungsverfahren k nnen kontinuierliche Modelle angen hert gel st werden Daher wird der Wert einer kontinuierli chen Variablen meist iterativ ermittelt Somit ist in kontinuierlichen Modellen ebenfalls nur eine endliche Anzahl von unterschiedlichen Variablenwerten abgreifbar Lantzsch Schneider Schwarz 2000 Domschke Drexl 2007 227 Bei einer diskreten Simulation ver ndert sich der Wert der Zustandsvariablen nur an endlich vielen Zeitpunkten Bei einer ereignisdiskreten Simulation so wie sie auch von dem in dieser Arbeit verwendeten Simulator LOsim siehe Kapitel 2 5 4 durchgef hrt wird ndert sich der Zustand eines Modells nur an einer diskreten Menge an simulierten Zeitpunkten auch Ereig niszeit genannt Im Zeitraum zwischen zwei Ereignissen bleibt der Wert einer Variablen kon stant Somit besteht eine ereigni
314. sklick auf das Objekt kontextbezogene Aktionen angeboten zu bekommen Die Schwierigkeit bei der Behandlung dieser nicht standardisierten Schnittstellen ist vor allem der ordnungsgem e Aufruf der Funktion die ber ein solches Element angesteuert wird Simulation und Evaluation 142 Die Beschrankung auf einige wenige unterstiitzte Web Browser aufgrund der Verwendung nicht standardisierter Technologien wirkt sich auch auf die Lastgeneratoren aus Diese miis sen mit den dynamischen Elementen der Benutzerschnittstelle umgehen k nnen Von einer ausreichenden Kompatibilit t kann jedoch nur ausgegangen werden wenn der Hersteller das entsprechende Produkt freigibt Ansonsten k nnen auch nur kleine Ver nderungen die bei einem Versionssprung vorgenommen werden zu einem Kompatibilit tsbruch des verwende ten Lastgenerators f hren Da SAP als Benutzerschnittstelle f r das Portal lediglich den Web Browser nennt liegt es nahe den Browser als Vermittler zwischen Lastgenerator und Portalsystem zu verwenden Dazu kann eine vom Microsoft Internet Explorer Microsoft 2011 oder auch von Mozilla Firefox angebotene Schnittstelle Feldt 2007 genutzt werden die es erlaubt automatisiert bzw programmgesteuert Benutzerfunktionen aufzurufen 5 3 2 Lastgenerator Der in dieser Arbeit verwendete Lastgenerator basiert auf dem in einer vorangegangenen Dis sertation Jehle 2010 entwickelten java basierten Performance Evaluation Cockpit f r ERP
315. speicher I O er rtert Aus den Erkenntnissen der theoretischen Grundlagen der dokumentierten Architektur sowie der verf gbaren Monitoring Hilfsmittel werden die zu modellierenden Komponenten abgelei tet die als wesentliche Performance Einflussgr en eines SAP Netweaver Portal Systems gelten Dazu werden den einzelnen Architekturkomponenten zentrale Einflussfaktoren und M glichkeiten zur Leistungsdatenerfassung zugeordnet Beispielsweise k nnen aus der Ar chitekturkomponente Tabellenpuffer die speziellen Einflussfaktoren Verdr ngungen und In validierungen identifiziert werden deren Anzahl ber den Tabellenpuffer Trace erfasst und festgehalten wird Mit der Identifikation der zu modellierenden Komponenten bzw Einflussgr en ist es Ziel dieser Arbeit ein entsprechendes LQN Modell zur Performance Simulation eines SAP Netweaver Portal Systems zu erstellen Da der verwendete Workload inh renter Bestandteil eines LQN Modells ist wird die Modellierung und Parametrisierung einzelner Lastschritte erm glicht die wiederum entsprechend ihrem tats chlichen Verhalten einzelne Systemkom ponenten verwenden Dieser Schritt der Modellierung ist stets abh ngig vom verwendeten Workload allerdings bleibt das grunds tzliche Vorgehen identisch F r das Sperrmanagement und zur expliziten Parametrisierung der Aktivit tsintensit t des Garbage Collectors GC Einleitung 5 werden in der vorliegenden Arbeit zus tzliche Komponenten modelliert d
316. sperre Query Sperrbereich a Enqueue Sab avery Server Datenbank Legende Weitergeleiteter Aufruf bk Synchroner Aufruf Abbildung 4 12 LQN Modellierung der Datenbank Quelle eigene Darstellung Parametrisierung Die Parametrisierung des Datenbank Tasks ergibt sich ber die im vorangegangenen Ab schnitt diskutierten Aspekte der Anzahl an Datenbankverbindungen im JDBC Service und der aufgezeichneten Service Zeit im funktionalen Trace Die Anzahl an verf gbaren Datenbankverbindungen im Verbindungspool wird ber die Multiplizit t des Datenbank Tasks abgebildet Analog zur Aufsummierung der Server Threads der n Java Server Instanzen siehe Kapitel 4 2 2 wird auch hier die Summe der Datenbankverbindungen der n Verbindungspools gebildet n m gt AnzahlVerbindungen Verbindungspool k 1 Die durchschnittliche Service Zeit ermittelt sich aus den Messdaten der Datenbankzeit im funktionalen Trace Obwohl diese Zeitangabe einen Bruttowert darstellt der im LQN Modell der CPU Zeit entspricht wird auf eine Absch tzung der tats chlichen CPU Zeit verzichtet da diese wie im vorherigen Abschnitt erw hnt nicht ber die verf gbaren Monitore bzw Traces zu ermitteln ist 4 2 6 Garbage Collector Der Garbage Collector nimmt einen wesentlichen Einfluss auf die System Performance und somit die resultierenden Antwortzeiten siehe zum Beispiel Libic Tuma Buley 2009 oder Ufimtsev 2006 Dieser Einfluss
317. ss Bonn Boston 2007 Heinrich L J Lehner F 2005 Informationsmanagement Planung berwachung und Steuerung der Informationsinfrastruktur 8 vollst berarb u erg Aufl Oldenbourg M nchen 2005 Heiss F J Veirich E Gratzl e 2005 SAP NetWeaver Web Application Server Pearson Deutschland GmbH M nchen 2005 Henning J L 2006 SPEC CPU2006 Benchmark Descriptions In SIGARCH Comput Archit News Vol 34 2006 Nr 4 S 1 17 Hermann C Hermann M 1972 An Attempt to Simulate the Outbreak of World War I In Simulations in Social and Administrative Science Overview and Case Examples Hrsg Guetzkow H Kotler P Schultz R Prentice Hall Englewood Cliffs NJ 1972 Hertz H 1894 Die Prinzipien der Mechanik Aus Kollektion Naturwissenschaften und Technik Thiiringer Universitats und Landesbibliothek Jena Jena 1894 Hevner A R 2007 A Three Cycle View of Design Science Research In Scandinavian Journal of Information Systems Vol 19 2007 Nr 2 S 87 92 Hevner A R March S T Park J Ram S 2004 Design Science in Information Systems Research In MIS Quarterly Vol 28 2004 Nr 1 S 75 105 Hoetzel A Benhaim A Griffiths N Holliday C 1998 Benchmarking in Focus IBM 1998 Hofmann R Klar R Mohr B Quick A Siegle M 1994 Distributed Performance Monitoring Methods Tools and Applications In IEEE Trans Parallel Distrib Syst Vol 5 1994 Nr 6 S
318. ssen der Literatur und Dokumentation des SAP Netweaver Portal Systems in Abh ngig keit von den gegebenen M glichkeiten zur Leistungsdatenerfassung Erstellung eines LQN Modells zur Performance Simulation eines SAP Netweaver Portal Systems unter Ber cksichtigung der identifizierten Einflussgr en Das LQN Modell beinhaltet unter anderem einen Ansatz zur Abbildung von Lese und Schreib sperren im Sperrmanagement sowie der Aktivit tsintensit t des Garbage Collectors da diese in der LQN Literatur bisher nicht behandelt wurden Evaluation und Interpretation der Simulationsergebnisse anhand der Modellierung und Simulation einer am SAP UCC der Technischen Universit t M nchen angebotenen Portal Schulung Nicht Bestandteil dieser Arbeit ist die Modellierung der Komponenten des zugrundeliegenden Datenbanksystems Dieses wird als Black Box betrachtet und m gliche Performance Engp sse ausgeschlossen damit der Fokus allein auf die Applikationsebene gesetzt werden kann Ebenso wird davon ausgegangen dass die Clients auf der Pr sentationsebene ber ge n gend Ressourcen verf gen Da die Leistungsdaten direkt am Applikationsserver erfasst werden beinhalten die ermittelten Antwortzeiten keine Netzwerkzeiten zwischen Client und Server Nicht zuletzt beschr nkt sich das in dieser Arbeit entwickelte LQN Modell auf die Architektur eines SAP Netweaver Portal Systems Portalsysteme anderer Hersteller oder zu k nftige Portal Versionen k
319. ssfehlern f hren siehe bspw Einfl sse des Garbage Collectors auf die Antwortzeit in Kapitel 4 2 6 und 5 8 Die grunds tzliche Elimination die ser Werte w rde zu einer zu optimistischen Einsch tzung des Antwortzeitverhaltens f hren Daher ist eine individuelle Plausibilit tskontrolle einer automatisierten Elimination vorzuzie hen 2 2 2 2 Konsistenz und Glaubw rdigkeitspr fung Die Plausibilit tskontrolle der Messwerte verfolgt das Ziel unerwartete Werte zu untersuchen und m gliche Fehler zu identifizieren Dazu wird eine Konsistenzpr fung sowie eine Glaub w rdigkeitspr fung der Daten durchgef hrt Prechelt 2001 176f Die Konsistenzpr fung pr ft die logische Korrektheit der erhobenen Messwerte Im Falle der Antwortzeiten k nnte ein Kriterium eine Antwortzeit gt 0 fordern Die Glaubw rdigkeitspr fung stellt die Frage zur Plausibilit t der erhobenen Messwerte Bei auffallenden Werten f hrt dies zu einer Untersu chung der m glichen Gr nde Beispielsweise kann ein auffallend hoher Wert durch die Akti vit t des Garbage Collectors als plausibel eingestuft werden eine Netzwerkst rung jedoch zu einem nicht plausiblen Wert f hren Theoretische Grundlagen 30 2 3 Performance Evaluation von Rechnersystemen Die Komplexit t moderner Computersysteme steigt aufgrund immer gr er werdender Funk tionalit t Doch nicht nur die Komplexit t der Systeme an sich sondern auch die zugrundelie genden Architekturen erfahren
320. ssource Planning Systemen ERP Systemen bernommen vgl bspw Kremar 2010 236 Nah Zuckweiler Lau 2003 Dar ber hinaus bieten Unternehmensportale eine einheitliche Oberfl che f r Mitarbeiter Kunden und Lieferanten sowohl zur Integration verschiedener Dienste und Anwendungen als auch zur Personalisierung und flexiblen Zuweisung von Benutzerrollen Mit anderen Worten stellen sie eine Integrationsplattform f r die Optimierung der betrieblichen Informations und Wissenslogistik dar und er ffnen neue organisatorische und informationstechnische M glich keiten Daher begannen die Unternehmen zu Beginn dieses Jahrtausends stark in Unterneh mensportale zu investieren Beispielsweise verk ndeten SAP und Siemens im Jahr 2002 SAP 2002 die Portaltechnologie von SAP k nftig konzernweit f r alle rund 400 000 Siemens Mitarbeiter einzusetzen Amberg Remus Holzner 2003 Die Integration der Dienste und Anwendungen auf einer einheitlichen Plattform werfen umso mehr kritische Fragen zur Leistungsf higkeit des zentral verwendeten Systems auf Welche maximalen Benutzerzahlen kann das System mit einer akzeptablen Geschwin digkeit bew ltigen Welche durchschnittliche Antwortzeit kann bei einer gegebenen Lastintensit t erzielt werden Welche Hardware und Software Ressourcen stellen Engp sse dar Welche Systemressourcen werden ben tigt um gegebene SLAs einzuhalten Oft werden zur Beantwortung dieser Fragen Expertenmeinungen
321. stbereich keine ausreichende Genauigkeit erzielen Die Hauptursache liegt in der feh lenden Modellierung der u eren System Einfl sse und ist Bestandteil weiterer Untersuchun gen Wie bereits in Kapitel 4 2 6 aufgezeigt wurde ist die LQN Modellierung des Garbage Collectors ein m hsames und fehlertr chtiges Unterfangen In der Literatur ist kein Ansatz zur GC Modellierung mittels LQN gegeben und der GC Zeitanteil stets implizit in den Ser vice Zeiten enthalten siehe z B Franks Lau Hrischuk 2011 Ufimtsev 2006 Ufimtsev Murphy 2006 Xu et al 2005 Daher wurde in dieser Arbeit ein Ansatz zur Ana lyse der GC Auswirkungen mittels Modellierung der Einflussgr en GC Intervall und GC Dauer vorgestellt der jedoch nicht die dynamischen Aspekte des GC Verhaltens abbildet und auf vorhandene Messdaten angewiesen ist Ebenso ist die Simulationsgenauigkeit von der Qualit t der Portalsystem Konfiguration ab h ngig so hat beispielsweise eine nicht ausreichende Tabellenpuffergr e einen negativen Einfluss auf die Simulationsgenauigkeit Dies liegt wiederum wie bereits in Kapitel 4 2 4 dargestellt an der Sch tzung der Trefferrate deren exakte Berechnung bei fehlenden Auf zeichnungen des Tabellenpuffers nicht m glich ist Unabh ngig davon reagieren die Simulationsergebnisse den Einflussgr en entsprechend und erzielen bei einer m igen Auslastung der Ressourcen eine vielversprechende Genauigkeit Eine detailliertere Darstellung u
322. stems setzt SAP auf eine 3 Schicht Architektur die die Da tenbank von der Applikations und der Pr sentationsschicht trennt Diese Trennung erm g licht nicht nur eine individuelle Spezialisierung der einzelnen Komponenten sondern bietet auch die Grundlage f r eine h here Skalierbarkeit Jehle 2010 13f Die drei Schichten un terteilen sich in 1 Pr sentationsschicht Die Pr sentationsschicht bildet die oberste Ebene und dient der Kommunikation mit dem Benutzer Dazu geh ren die benutzerfreundliche Aufbereitung und Darstellung der Informationen und die Entgegennahme und Weiterleitung von Benutzeraktionen an die Anwendungsschicht F r die Pr sentation kommen vorwiegend zwei Typen von Clients zum Einsatz zum einen das SAP Graphical User Interface SAP GUI und zum anderen der Web Browser auf dem Client Dar ber hinaus bietet die SAP Mobi le Infrastructure auch f r mobile Endger te Zugriff auf die Applikationsschicht Bei dem SAP GUI kommt das propriet re DIAG Protokoll Dynamic Information and Action Gateway zum Einsatz das f r jeden Dialogschritt nur wenige Kilobytes an Daten an die Applikationsschicht bertr gt Aufgrund des nicht offengelegten Kommunikationsprotokolls ist es nicht m glich ber einen alternativen Client der zum Beispiel spezielle Funktionen f r die Leistungsanalyse von SAP Systemen bereit stellt in derselben Art und Weise mit der Applikationsschicht zu kommunizieren Es werden zwar S
323. stochastischen Natur von LQNs zum anderen an den fehlenden Detailkenntnissen der GC Implementierung Ufimtsev 2006 92 Die zwei Indikatoren zur Aktivit tsintensit t GC Dauer und GC Intervall lassen sich jedoch ber den GC Trace und die bereitgestellten Analysetools die in Kapitel 3 2 6 dargestellt wur den ermitteln Bei der Auswertung der Simulations und Messergebnisse die in Kapitel 5 7 beschrieben wird kann im Hochlastbereich ein starker Anstieg der Antwortzeiten festgestellt werden Die Ursachenanalyse ergibt eine sehr hohe Aktivit tsintensit t des Garbage Collectors die den berm igen Anstieg der Antwortzeiten erkl ren kann Damit die Auswirkungen auf die Antwortzeit im Modell getestet werden k nnen wird in einer zweiten Iteration eine GC Komponente eingebaut siehe Abbildung 4 13 die die Angabe der beiden Aktivit tsindizes GC Dauer und GC Intervall als Parameter erlaubt GC Aktivit ten Messen Kapitel 5 8 GC Komponenten Kapitel 4 2 6 Simulieren Abbildung 4 13 Zweiter Zyklus der Modellbildung Quelle eigene Darstellung LQN Modell 129 LQN Modellierung In der LQN Literatur konnten keine Ans tze zur expliziten Modellierung des Garbage Collectors bei Java basierten Anwendungen identifiziert werden Die GC Zeiten waren stets implizit in den Bearbeitungszeiten der Komponente bzw der Komponenten enthalten siehe zum Beispiel Franks Lau Hrischuk 2011 Ufimtsev 2006 Ufimtsev Murphy 2006 oder Xu et
324. t G rtz Hesseler 2008 5 Die standardisierten Module umfassen mengenorientierte Funktionen zum Beispiel Vertrieb Materialwirtschaft Produktionsplanung Fertigung etc sowie wertorientierte Sys teme beispielsweise Rechnungs und Finanzwesen gleicherma en Gadatsch 2002 212 und k nnen auf die speziellen Anforderungen und Bed rfnisse des Unternehmens angepasst wer den Aufgrund der Vielf ltigkeit von ERP Systemen unterscheiden sich auch die Definitionsvari anten des Begriffs Dies ist auf inhaltliche Schwerpunkte sowie die historische Entwicklung von ERP Software zur ckzuf hren In den meisten F llen wird ein ERP System als Standard software charakterisiert das f r eine gro e Anzahl von Kunden entwickelt wird und an die speziellen Anforderungen und Bed rfnisse eines Unternehmens individuell anpassbar ist Somit lassen sich ERP Systeme von Individualsoftware abgrenzen die f r ein bestimmtes Unternehmen zu einem bestimmten Anwendungszweck entwickelt wird Schwarze 1997 329 Ein weiteres zentrales Merkmal ist die Integration Galten fr her ERP Systeme als ein vor wiegend innerbetriebliches integriertes Informationsverarbeitungssystem ber cksichtigen j ngere Definitionen ebenso Aspekte der zwischen oder berbetrieblichen Integration Wallace Kremzar 2001 10f Damit dieser neuen Generation von ERP Systemen die auch berbetriebliche Kollaboration erm glichen soll Rechnung getragen wird werden sie in der Literatu
325. t Die Abarbeitung einer Anfrage in einem Java Server ist zusammenfassend in Abbildung 3 3 grafisch dargestellt Dispatcher I I 1 Cluster Management System Thread Manager Queue HTTP Provider I I Service i Application Thread Mgr Queue Web EJB i Container JDBC Connector Service Abbildung 3 3 Request Abarbeitung im Java Server Quelle eigene Darstellung in Anlehnung an Tschense 2004 25 3 1 2 Transaktionsverwaltung hnlich zum AS ABAP wird auch im AS Java das ACID Prinzip Atomicity Consistency Isolation Durability Haerder Reuter 1983 Kemper Eickler 2011 bei der transaktionsori entierten Verarbeitung der Aufgaben verfolgt Der Java Transaction Service ist dabei verant wortlich f r die Verwaltung der durchgef hrten Transaktionen im AS Java In diesem Service wurden die zwei J2EE Standards Java Transaction API JTA und Java Transaction Service JTS implementiert Im AS Java werden durchgef hrte nderungen die der Benutzer ber den Web Browser in das Benutzer Interface eintr gt nicht sofort persistent in der Datenbank gespeichert Erst Systemarchitektur und Monitoring 71 wenn der Benutzer seine Eingaben speichert wird die Java Transaktion abgeschlossen und ber eine Datenbanktransaktion gespeichert Abbildung 3 4 illustriert diesen Sachverhalt Benutzer Datenbank Anderung Speichern der Anderungen Java Transaktion DB Tran
326. t ein neues Benutzerpasswort zu bestimmen Sobald dies durchgef hrt wurde werden erste Schritte am Portal durchgef hrt Dazu geh ren die nderung des Darstellungsschemas das Eintragen detaillierter Benutzerinformatio nen die Navigation innerhalb des Portals sowie weitere grunds tzliche Portaloperatio nen 3 Inhaltsverwaltung Am dritten Schulungstag legen die Schulungsteilnehmer eigene Unterordner im Schulungsordner an und legen in diesen ihre eigenen erstellten i Views siehe Kapitel 2 1 2 ab Auf Grundlage der erstellten iViews wird eine eigene Portal Webseite zusammengestellt Diese wird daraufhin einem eigens daf r erstellten Workset zugewiesen dem damit generierten Objekt eine Rolle zugeordnet und somit die Konfiguration der Freigabeparameter durchgef hrt ber einen Aufruf der erstell ten Portal Website wird abschlie end das Ergebnis berpr ft Die an diesem Schu lungstag erstellten iViews beinhalten ausschlie lich portaleigene Funktionen 4 Fortgeschrittene Inhaltsverwaltung F r die Integration externer Inhalte werden am vierten Schulungstag weitere iViews erstellt Im brigen gleichen die durchgef hrten Aktionen dem des vorherigen Schulungstages 5 Kollaboration F r die Kommunikation zwischen den Teilnehmern des Portalsystems werden Funktionen zur Zusammenarbeit zur Verf gung gestellt Die in der Schulung durchgef hrten Kollaborationsfunktionen betreffen das Erstellen eines Meeting Rooms die Nutzung der Ins
327. t Area LOA Dieser Bereich wird immer dann verwendet wenn aufgrund von Fragmentierung in der Small Object Area SOA kein Speicherbereich gro genug f r das aufzunehmende Objekt ist Mit der Reservierung eines zusammenh ngenden Speicherbereichs f r gro e Objekte wird versucht die Anzahl der Compaction Phasen die den SOA Bereich defragmentieren und so zu gr eren zusammen h ngenden freien Speicherbereichen f hren w rden zu reduzieren und somit einen Perfor mance Gewinn zu erzielen Die GC Aktivit ten k nnen in eine Log Datei geschrieben werden damit die Leistungsdaten sp ter analysiert und ausgewertet werden k nnen Dazu muss der Schalter verbose gc als Parameter bergeben werden Zudem k nnen folgende Optionen angegeben werden DIR_PATH das Verzeichnis in dem die Log Datei geschrieben werden soll FILE NAME der Dateiname der Log Datei X Anzahl der vorgehaltenen Dateien Y Anzahl der GC L ufe die pro Datei festgehalten werden Abbildung 3 12 zeigt einen beispielhaften GC Zyklus und die dabei aufgezeichneten Perfor mance Daten Systemarchitektur und Monitoring 79 lt af type nursery id 2 timestamp Nov 16 16 28 50 2011 intervalms 2741 194 gt lt minimum requested_bytes 152 gt lt time exclusiveaccessms 0 133 gt Zeit die ben tigt wurde lt nursery freebytes 0 totalbytes 209715200 percent 0 gt exklusiven Zugriff auf die lt tenured freebytes 172353633
328. t daher nicht zu Wartezeiten beim Verteilen der Benutzeranfragen an die Applikations Threads Eine leichte Erh hung der Ant wortzeiten erkl rt sich ber auftretende Wartezeiten bei gesperrten Objekten Bereich 2a Bei mehr als 80 simultanen Benutzern wird die maximale Parallelit t 80 konfigurierte Applikations Threads berschritten Die nun auftretenden Wartezeiten bedingen steigende Antwortzeiten hnlich verh lt es sich im zweiten Szenario in dem drei Bereiche unterschieden werden k n nen Bereich 1 Dieser Bereich stellt auch hier den Niedriglastbereich dar in dem die Sys temressourcen noch nicht ausgesch pft sind Die ansteigenden Antwortzeiten erkl ren sich ebenfalls ber auftretende Sperrzeiten aber auch ber zunehmende Verdr ngun gen im unzureichend dimensionierten Tabellenpuffer Bereich 2b Der zweite Bereich in Szenario 2 wird ebenfalls durch auftretende Warte zeiten charakterisiert die allerdings nicht durch eine konfigurierte Limitation der Ap plikations Threads sondern durch die ersch pften CPU Ressourcen bedingt sind Wie bereits in Kapitel 5 7 dargestellt f hren beide Schranken zu Wartezeiten die die Be arbeitung der Benutzeranfragen verz gern und folglich zu einem Anstieg der Ant wortzeiten f hren Bereich 3 Der berlastbereich im zweiten Szenario ist vor allem durch den wachsen den Einfluss des Speichermanagements gekennzeichnet der in Kapitel 5 8 analysiert wurde Da der be
329. t das erwartete Verhalten Die in der Literatur f r ein gut konfiguriertes System geforderte Treffer rate von 95 Heiss Veirich Gratzl 2005 355 wird nicht erreicht Zudem ist im Vergleich zum ersten Szenario eine deutlich h here Streuung zu verzeichnen die haupts chlich auf die unterschiedliche Anzahl an Verdr ngungen zur ckzuf hren ist Die Weiterleitungswahrscheinlichkeit ist in diesem Szenario au erdem von der Anzahl simul taner Benutzer abh ngig und muss entsprechend parametrisiert werden Diese Abh ngigkeit ist jedoch nicht in der in Kapitel 4 2 4 vorgestellten Berechnungsmethode abbildbar Somit kann die Trefferrate nur ber Erfahrungswerte gesch tzt werden falls keine Messdaten zur Verf gung stehen sollten Die Sch tzung stellt einen wesentlichen Ungenauigkeitsfaktor dar sodass bei datenbankintensiven Workloads eine unzureichende Gr e des Tabellenpuffers auch einen erheblichen Einfluss auf die Simulationsgenauigkeit nimmt Simulation und Evaluation 157 5 5 5 2 CPU Zeiten 600ms 6 core s ao _ 500ms 5 5 GE ms core s 3 ZE 4 E 2 2 2 400ms 4 4core s 5 ee Teen SE OO 5 5 2 come S e 300ms 3 core s lt ZS E a S E g H 200ms 4 2 core s 5g 2 J lt x A V 100ms 1 core s S a Oms 4 T T 1 0 core s 1 20 40 60 80 100 120 Anzahl simultaner Benutzer CPU Zeit CPU Nutzung H 346 350 345 398 355 888 346 398 344 402 356 896 357 386 ce
330. t er die schw chste Komponen te in einem System Um die Leistung des Gesamtsystems zu steigern muss die Leis tung der Engpasskomponente verbessert werden Weitere Kenngr en der Auslastung sind die Nutzlast die Systemauslastung der Verwaltungsaufwand sowie die Skalier barkeit Melzer 2010 181 Rechenberg Pomberger Pirklbauer 2006 456 In dieser Arbeit wird die Leistung von Portalsystemen unter einer ansteigenden Anzahl von simultanen Benutzeranfragen evaluiert Die dabei verwendete Performance Metrik beschr nkt sich auf die Antwortzeit als Messgr e da diese die Anforderungen an eine Metrik f r die Performance Analyse erf llt Lilja 2000 Theoretische Grundlagen 33 mittels der Analysewerkzeuge des Portalsystems f r die einzelnen Komponenten ge messen werden kann sowie eine hohe Aussagekraft f r die Fragestellung wie sich eine steigende Anzahl an Be nutzern auf das fiir einen Benutzer gefiihlte Leistungsverhalten des Portalsystems auswirkt bietet 2 3 2 Workload Systeme sind dahingehend konzipiert in einer bestimmten Umgebung unter bestimmten Lastmustern zu arbeiten Dementsprechend ist bei der Performance Analyse darauf zu achten eine hnliche Umgebung mit hnlichen Lastmustern zu schaffen Nach Oed Mertens 1981 ist der Workload definiert als die Gesamtheit aller Prozesse Aufgaben Transaktionen und Daten die innerhalb eines bestimmten Zeitraums abgearbeitet werden Aufgrund der Komplexit t
331. t von PEER beibehalten Daher wird das von PEER geforderte Interface PerformanceDriver verwendet Das im Listing 5 1 dargestellte Interface gibt dabei die abstrakte Definition der Methoden vor die von dem Lasttreiber implementiert werden m ssen Simulation und Evaluation 143 1 public interface PerformanceDriver 2 public String dolnit 3 public String doExec 4 public String doCleanup 5 public PerformanceStatus getStatus 6 public String abortRun 7 Listing 5 1 Implementiertes PEER Interface Quelle Jehle 2010 137 Da verschiedene Lastmodule bzw Testtreiber unterschiedliche Parameter erfordern bei spielsweise das zu setzende Passwort oder den Namen des iViews werden in PEER soge nannte Configurables eingesetzt die beim Einbinden des Testtreibers durch den Class Loader bernommen und nicht durch interne Bezeichnungen ersetzt werden Dadurch ist es m glich dass die Verwaltungseinheit von PEER die Variablennamen sowie typen zur Lauf zeit auswerten kann Auch diese Architekturforderung wird bernommen damit ein Einbin den in die PEER Oberfl che m glich bleibt Der interne Aufbau des Testtreibers f r die Portalfallstudie ist in Abbildung 5 4 dargestellt und wird im Folgenden kurz beschrieben I i uses 1 lt lt Interface gt gt IMacrosTestDriver_ ObserverAgent Interface E rd IMacrosTestDriver F CourseConfiguration creates 1 executes
332. t wird Somit bildet das Ergebnis der ersten Forschungsfrage die Grundlage f r eine akkurate Performance Modellierung eines SAP Netweaver Portal Systems Forschungsfrage 2 Wie k nnen die ermittelten Komponenten und Einflussgr en in einem LQN Modell umgesetzt und parametrisiert werden damit m glichst akkurate und zuverl ssige Simu lationsergebnisse erzielt werden Die zweite Forschungsfrage widmet sich der Umsetzung der in Forschungsfrage 1 ermittelten Komponenten und Einflussgr en in einem LQN Modell und damit der Erstellung des zentra len Artefakts dieser Arbeit Aufgrund von modellierungsbezogenen Limitationen sowie der stochastischen Natur von LQNs entspricht die Abbildung der Komponenten einer Ann he rung an das tats chliche Verhalten Daher wird bei dem vorgestellten Vorgehen zur Modellie rung der einzelnen Komponenten auf bestehende Einschr nkungen hingewiesen und f r die Festsetzung einzelner Parameter M glichkeiten zur Berechnung aufgezeigt Das Ergebnis von Forschungsfrage 2 ist wie bereits erw hnt ein LQN Modell zur Perfor mance Evaluation eines SAP Netweaver Portal Systems M gliche Performance Einfl sse auf der Pr sentations sowie Datenbankebene werden ausgeschlossen damit der Fokus auf die Applikationsebene gelegt werden kann Da der betrachtete Workload inh renter Bestandteil des LQN Modells ist sieht das vorgestellte Modell die Modellierung einzelner Lastschritte vor die von den Benutzern a
333. taillierte Benutzerinformationen eintragen X X 2 9 Top Level Navigation Unterpunkte aufrufen X X 2 10 Startseite Portal Information abrufen X X 2 11 Content Management Direct Links zu Komponen X X ten 2 12 Kollaboration Grundlage f r asynchrone Zusam X X menarbeit 2 13 Curriculum Congress Personalisierter Inhalt X X 2 15 History Funktion Wechseln zu Curriculum X X Congress 2 17 Navigation berblick ber field areas X X Tag 3 Inhaltsverwaltung 3 1 Vorschau SAP iViews X X 3 3 iView in neuen Ordner kopieren X X 3 4 Neues iView anlegen X X Simulation und Evaluation 140 3 5 Neues iView konfigurieren X 3 6 Portal Webseite erstellen X X 3 7 Portal Webseite konfigurieren X 3 8 neues Workset erstellen X X 3 9 neues Workset konfigurieren X 3 10 Webseite mit Workset verlinken Delta Link X 3 12 Workset mit Rolle verlinken Delta Link 3 13 Workset schlie en 3 14 Rolle Class role aktualisieren X X Tag 5 Kollaboration 5 1 SAP Meeting Room erstellen X X 5 2 SAP Meeting Room konfigurieren X 5 3 Benutzer Gruppen zum SAP Meeting Room hinzu X f gen 5 4 nderungen abspeichern X 5 5 Room Directory aufrufen X X 5 6 Eigenen Meeting Room aufrufen X X 5 7 Eigenen Task anlegen Single Step X X 5 8 Collaboration Launch Pad CLP aufrufen X X 5 9 User zum CLP hinzuf gen X Tag
334. tandardab weichung ergibt zeigt sich dass der Faktor N 1 diese Untersch tzung korrigiert Berman 2008 Theoretische Grundlagen 28 m N 1 Variationskoeffizient Der Variationskoeffizient cy einer Messreihe x1 Xn ist definiert als das Verh ltnis zwi schen der Standardabweichung o und dem arithmetischen Mittel x Cy S il Q firx 0 Im Gegensatz zur Varianz 0 ist der Variationskoeffizient ein relatives Streuungsma das hei t er h ngt nicht von der Ma einheit der Variablen ab Er ist mit anderen Worten eine Normierung der Varianz Falls die Standardabweichung gr er als der Mittelwert ist weist der Variationskoeffizient einen Wert gt 1 auf 2 2 1 3 Parametersch tzung Will man bei einer statistischen Untersuchung die Parameter einer Grundgesamtheit genau berechnen muss jede Einheit der Grundgesamtheit bei der Berechnung erfasst werden Da dies jedoch oft unm glich ist werden auf Basis von Stichproben N herungswerte der entspre chenden Parameter sogenannten Punktsch tzer berechnet Dabei wei man jedoch nicht ob diese von dem tats chlichen Wert abweichen und falls ja wie gro der Fehlbetrag ist Anstelle eines Punktsch tzers kann nun ein Intervall um den Messwert einer Stichprobe be rechnet werden f r das gilt dass der tats chliche Parameterwert zu einem bestimmten Ver trauensgrad in diesem Bereich liegt Dieses Verfahren bezeichnet man als Intervallsch tzung Konfidenzinterva
335. tant Message Funktionalit t sowie das Versenden von Emails Zu diesen Kollaborationskomponenten werden zudem die ben tigten Konfigu rationsschritte sowie das Rechtemodell vorgestellt 6 ffentliche Dokumente Versionierung Zur F rderung des Austauschs von Informati onen zwischen den Portal Teilnehmern besteht die M glichkeit ffentliche Dokumen te beispielsweise Ordner zu erstellen Ein ausgepr gtes Rechtemodell sorgt f r die genaue Definition welche Teilnehmer berechtigt sind darauf zuzugreifen An diesem Schulungstag wird die Bereitstellung der ffentlichen Dokumente vorgestellt und durchgef hrt 7 Benutzerverwaltung und Sicherheit Am vorletzten Schulungstag werden die Portal operationen vorgestellt die der Dozent am ersten Tag f r die Schulungsvorbereitung durchgef hrt hat und zwar das Anlegen und Konfigurieren von Benutzern und Rollen 8 Developer Studio Visual Composer Am letzten Schulungstag werden tiefergehende Werkzeuge zur Konfiguration und Entwicklung von Portalinhalten und deren Abh n Simulation und Evaluation 137 gigkeiten vorgestellt wobei in den Ubungen lediglich auf den Visual Composer ein gegangen wird 5 2 Workload Der modellierte Workload W wird wie in Kapitel 2 3 2 1 beschrieben ber ein vereinfach tes Abbild des realen Workloads W gebildet Da es ftir die Betrachtung komplexer Software Systeme zu denen das zu untersuchende Portalsystem z hlt nicht reicht statische Eigen scha
336. tei sat trc lt n gt geschrieben die standardm ig unter folgendem Pfad zu finden ist usr sap lt SAPSID gt JC lt J2EE Instanz gt j2ee cluster server lt n gt log Die Trace Datei kann ber den Log Viewer einer mitgelieferten Java Applikation angezeigt und als Comma Separated Value Datei CSV Datei exportiert werden Das Ursprungsformat trennt die einzelnen Werte eines Eintrags mit dem Rautenzeichen F r die Zuordnung der Eintr ge zu einer bestimmten Transaktion wird neben den Leistungs daten auch eine Transaktions ID erfasst Dadurch k nnen diese den Eintr gen anderer Traces beispielsweise des SQL Traces siehe Kapitel 3 2 4 zugeordnet werden siehe Abbil dung 3 16 Systemarchitektur und Monitoring 85 Visual Administrator P8S Server 0 0_22462 Services Performance Tracing r ICT Connect View Tools Help BElENENE elt ale Global Configuration Cluster LE Trreurer Runtime Properties Additional Info if Application tracing JARM Trace Config Activities aa Module Static SAT Trigger vi Deactivate Imayerm T ZM Key Storage Zo Leak Detector ZA Licensing Adapter ZM Locking Adapter ZM Log Configurator 4 Log Viewer JDBI SQL Trace Deactivate Da ei amp Memory IMS Refresh 4 D Connected to portalsim informatik tu muenchen de di portalsim informatik tu
337. time gt ange geben Die Streuung C wird ber den Parameter lt coeff of variation gt gesteuert Der Parameter lt max_service_time gt spezifiziert die maximale Bearbeitungszeit Die Anzahl der synchronen Anfragen definiert der Wert des Parameters lt rendez vous gt Ob es sich bei diesem Wert um eine deterministische oder stochastische Anga ben handelt wird mit dem Schalter lt ph_type_flag gt f r jede Phase festgelegt 0 stochastisch 1 deterministsich und somit auf 1 gesetzt Sperrmanagement Wie bereits in Kapitel 3 1 3 dargestellt k nnen Datenbankaufrufe der einzelnen Interaktions schritte Sperren erfordern Diese werden ber den Enqueue Server verwaltet der die einzel nen Sperranfragen sequentiell abarbeitet Dabei kann es zu Wartezeiten kommen bis die ge w nschte Sperre gesetzt ist Sollte das zu sperrende Objekt bereits gesperrt sein erh ht sich die Wartezeit bis das Objekt wieder freigegeben wird und die Sperre gesetzt werden kann Bei den Sperranfragen wird zwischen Lese Schreib exklusiven Schreib und optimistischen Sperren unterschieden LQN Modell 115 LQN Modellierung F r die Abbildung eines Sperrmechanismus kann ein spezieller Task Typ verwendet werden ein sogenannter Semaphor Task Franks 2011 Ein Semaphor Task beinhaltet zwei Entries eine Entry Signal und eine Entry Wait Die Wait Entry wird ber eine synchrone Anfrage aufgerufen Daraufhin werden so lange keine Anfragen mehr
338. tintervall welches ber den Wert KeepaliveTimeout definiert wird berschritten werden wird die Verbindung zum Client abgebrochen Der HTTP Provider Service stellt somit eine der Kernkomponenten des Java Dispatchers dar da nicht nur die Annahme der Anfragen von au en erfolgt sondern auch die Weiterleitung an einen Java Server Prozess und das Halten der Verbindung ber diesen Dienst erfolgt Tabelle 3 3 zeigt die wichtigsten Monitore des HTTP Provider Services Monitor Beschreibung ConnectionsInKeepAlive Derzeitige Anzahl an aktiven Verbindungen ConnectionsClosedByClient Anzahl der Verbindungen die durch den Client beendet bzw abgebrochen wurden ConnectionsClosedByServer Anzahl der Verbindungen die durch den Server geschlossen wurden Dies kann sowohl durch das Uberschreiten des KeepaliveTimeout Parameters als auch ber einen entspre chenden Funktionsaufruf erfolgt sein AllRequestsCount Anzahl der insgesamt angekommenen Anfragen seit die In stanz gestartet wurde ConnectionsReadingHeaders Anzahl der Anfragen die gelesen wurden um sie einem Java Server Prozess zuzuordnen ConnectionsReadingResponse Anzahl der derzeit verarbeiteten Anfragen deren Antwort vom Java Server Prozess noch aussteht um sie an den Cli ent zur ckzuschicken Tabelle 3 3 Wichtige Monitore des http Provider Services im Dispatcher Quelle eigene Darstellung in Anlehnung an SAP 201 1a Die zuvor erw hnte Session Qu
339. tion Die Software wird nicht mehr in einer Eins zu Eins Beziehung zwischen Anbieter und Kunde sondern einer Vielzahl von Servicekonsumen ten bereitgestellt Kremar 2010 698 Die technische Entwicklung wurde in den letzten Jahren vor allem durch das Internet und die damit verbundenen Standards und Technologien gepr gt So erm glichen Unternehmenspor tale einen ortsungebundenen Zugang zu relevanten Informationen f r Mitarbeiter Kunden und Lieferanten Aber auch Standards wie XML eXtended Markup Language und Webs ervices treiben die Interoperabilit t heterogener Systeme sowohl im inner als auch im zwi schenbetrieblichen Umfeld heran Abbildung 2 2 skizziert die Entwicklung von ERP Systemen und ordnet Unternehmens Portale entsprechend ein ERP II 1960 1970 1980 1990 2000 Abbildung 2 2 Entwicklung von ERP Systemen sowie Einordnung der Unternehmensportale Quelle eigene Darstellung 2 1 1 SAP Netweaver Die genannten technischen Entwicklungen sowie die Ber cksichtigung entstehender Ge schaftsmodelle im Internet forderten eine unternehmensweite service orientierte Integrati onsplattform die bei SAP mit dem Namen Netweaver realisiert wurde Ziel dieser Anwen dungs und Integrationsplattform ist es eine unternehmensweite Modellierung Planung und Steuerung von Gesch ftsprozessen anzubieten und die Integration von bestehender Software in diese Prozesse zu verwirklichen Durch das sogenannte Shared Collaboration
340. tionsori entierte Systeme und relationale Datenbanken Aus dem TP1 Benchmark entstand der von dem Transactions Processing Performance Council TPC entwickelte TPC A Benchmark TPC 1989 Dieser fordert dass alle Anfragen von realen Terminals gesendet werden und die durchschnittliche Ankunftszeit von Anfragen bei zehn Sekunden liegt Im Gegensatz dazu generiert der sp ter entwickelte TPC B Benchmark TPC 1990 so viele Anfragen wie m g lich mittels eines internen Treibers Der Hauptvorteil von Applikations Benchmarks liegt vor allem darin dass sie auf dem tat s chlichen System laufen und echte Funktionen ausf hren Dabei bieten sie die M glichkeit Siehe auch http top500 org Theoretische Grundlagen 61 echte Systemeffekte zu analysieren wie zum Beispiel administrative und verarbeitende Funk tionen der zentralen Recheneinheit oder die tats chliche Geschwindigkeit der verschiedenen VO Ger te Bei einer treffenden Repr sentation des realen Workloads bieten Applikations Benchmarks eine genaue Messung der Leistungsf higkeit des Systems da reale sprich repr sentative Funktionen auf dem tats chlichen System ausgef hrt werden Sind sie hingegen schlecht konfiguriert oder unpassend gew hlt ist ihre Aussagekraft verschwindend gering da beispielsweise ein Engpass aufgezeigt wird der im realen Lastszenario nicht auftritt oder um gekehrt Joslin 1965 SAP Benchmarks SAP Standard Applikations Benchmarks unterscheiden sich vo
341. tionsstandards unterst tzt wie beispielsweise Web Services die die Entwicklung von Gesch ftsprozessen die meh rere Gesch ftspartner mit unterschiedlichen Anwendungssystemen integrieren erm g lichen F r den Zugriff auf die Daten die in der Datenbankschicht vorgehalten werden ist ei ne st ndige Verbindung zwischen der Applikationsschicht und der Datenbankschicht notwendig Somit ist das Leistungsverhalten der Applikationsschicht auch von der da runter liegenden Datenbankschicht abh ngig Damit diese Abh ngigkeit verringert werden kann werden die zu verarbeitenden Daten in der Applikationsschicht in der Regel im Hauptspeicher zwischengespeichert Datenbankschicht Die Datenhaltung erfolgt in der Datenbankschicht auch Persistenzschicht genannt Beim SAP Netweaver Application Server Java kurz Netweaver AS Java kann dies eine v llig autonome Datenbankanbindung aber auch ein eigenes Schema in der Da tenbank sein Die dort gespeicherten Daten werden der Applikationsschicht zur Verf gung gestellt Das Ansprechen der relationalen Datenbank erfolgt ber die Structured Query Lan guage SQL Chamberlin Boyce 1974 Java Anwendungen verwenden dabei bli cherweise die JDBC API Java Database Connectivity Application Programming Interface als Kommunikationsschnittstelle Aufbauend auf die JDBC API hat SAP eine Open SQL Schicht implementiert wie sie in hnlicher Weise auch beim SAP Netweaver AS ABAP verwendet
342. ts Ende der siebziger Jahre durch eine umfangreiche Studie von Xerox gepr gt S bbing 2006 445 Benchmarking ist das Vorgehen ein oder mehrere Benchmark Ergebnisse zu ermitteln und damit die Leis tungsf higkeit eines Programms oder einer Methode zu charakterisieren Prechelt 2001 43 Im wirtschaftswissenschaftlichen Bereich gilt Benchmarking als ein Wettbewerbsanaly seinstrument zum kontinuierliche n Vergleich von Produkten Dienstleistungen sowie Prozessen und Methoden mit mehreren Unternehmen um die Leistungsl cke zum sog Klassenbesten Unternehmen die Prozesse Methoden etc hervorragend beherrschen syste matisch zu schlie en Alisch 2004 Technische Benchmarks von Computersystemen k nnen unter dem Einfluss einer generierten Last CPU Leistung Grafikf higkeit sowie Input Output Verhalten die Leistung von Rech nernetzen und vieles mehr messen Siebert Kempf Ma alski 2008 9 In den Anf ngen wur den als Leistungskennzahl Rechenoperationen pro Zeiteinheit angegeben So konnte bei spielsweise die erste auf der Von Neumann Architektur basierende Rechenmaschine einen Rechenschritt pro Sekunde durchf hren Knuth 1970 Im weiteren Verlauf wurden bald Floating Point Operations per Second FLOPS als Ma einheit verwendet welches der zentralen Bedeutung der Berechnung von Flie kommazahlen geschuldet ist Henning 2006 Dieser Wert entspricht dem rechnerisch erzielbaren Durchsatz eines Rechners welc
343. tschaftsinformatik 2005 Hrsg Springer Bamberg 2005 S 847 859 Moore G E 1965 Cramming More Components onto Integrated Circuits 1965 M ller J 2005 Workflow based Integration Grundlagen Technologien Management Springer Berlin 2005 Nah F F Zuckweiler K M Lau J L 2003 ERP Implementation Chief Information Officers Perceptions of Critical Success Factors In Int J Human Computer Interaction Vol 16 2003 S 101 123 Neilson J E 1991 PARASOL A Simulator for Distributed and or Parallel Systems Vol SCS TR 192 Ottawa Kanada Carleton University Neilson J E Woodside C M Petriu D C Majumdar S 1995 Software Bottlenecking in Client Server Systems and Rendezvous Networks In IEEE Trans Softw Eng Vol 21 1995 Nr 9 S 776 782 Nicolescu V Klappert K Kremar H 2007 SAP Netweaver Portal 1 Aufl Galileo Press Bonn 2007 Niehans J 1990 History of Economic Thought The John Hopkins University Press Baltimore 1990 Nissen V Petsch M Schorcht H 2008 Service orientierte Architekturen Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen Deutscher Universit ts Verlag GWV Fachverlage GmbH Wiesbaden 2008 Nunamaker J F Dennis A R Valacich J S Vogel D George J F 1991 Electronic Meeting Systems In Communications of the ACM Special Issue on Computer Graphics State of the Arts Vol 34 1991 Nr 7
344. tungszeit zusammengesetzt werden Die ei gene Bearbeitungszeit parametrisierte Service Zeit wird zwischen den Aufrufen aufgeteilt und entspricht dem Bedarf an Prozessorzeit Zur Veranschaulichung ist der Sachverhalt in Abbildung 5 18 dargestellt wobei zur Vereinfachung nur zwei Tabellenpufferaufrufe durch gef hrt werden Legende lt ONE Cuisine vedavuecacdusudd abuuce te veivduveuds OA ETE I EEAS Service Zeit E 7 Eigene Wartezeit Eigene Service Zeit Aufgerufene Tasks Synchroner Aufruf Weitergeleit Aufruf Antwort Processor_Server Abbildung 5 18 Zusammensetzung der Service Zeit in der Ausgabedatei Beispiel Quelle eigene Darstellung Die durchschnittlichen Wartezeiten fiir Task Aufrufe sind in dem bereits genannten Abschnitt zu den durchschnittlichen Verz gerungen bei synchronen Aufrufen und Vereinigungen aufge Simulation und Evaluation 168 f hrt Die durchschnittlichen Wartezeiten am Prozessor werden in einem sp teren Abschnitt ber die Wartezeiten sowie Nutzung der Prozessoren pro Phase angegeben In Listing 5 10 sind die Service Zeiten eines Simulationslaufes des Beispiels aus Kapitel 5 6 1 dargestellt Neben den durchschnittlichen Service Zeiten der beiden exemplarischen Interak tionsschritte Aktivit ten U1A1 und U1A2 gibt die Service Zeit der Entry UIE1 also der Entry des Benutzer Tasks die akkumulierten Service Zeiten und somit die Gesamtantwortzeit des modellierten Workloads an da die Ser
345. u erreichen Simon 1996 In diesem Zusammenhang postuliert Simon 1996 141f in seinem Buch The Science of the Artificial zwei grunds tzliche Elemente Zum einen soll der Problemraum definiert werden der die gew nschte Situation die derzeitige Situation und den Unterschied zwischen den Situationen darstellt Zum anderen sollen ber einen Suchpro zess Aktionen definiert werden die mit gro er Wahrscheinlichkeit bestimmte Unterschiede zwischen der derzeitigen und der gew nschten Situation beseitigen Es ist somit die Haupt aufgabe der gestaltungsorientierten Forschung Designprobleme aufzuzeigen und L sungen zu erstellen und zu evaluieren March Storey 2008 Neben der verhaltensorientierten Forschung erfreut sich der gestaltungsorientierte For schungsansatz in der Wirtschaftsinformatik aber auch zunehmend im angloamerikanisch ge pr gten Information Systems Research ISR einer immer gr er werdenden Beliebtheit Hevner 2007 Iivari 2007 A Hevner formuliert diesbez glich in einem f r die Zeitschrift Wirtschaftsinformatik durchgef hrten Interview Ich sehe die steigende Wahrnehmung der Design Research im Bereich Information Systems als eine ganz nat rliche Evolution unseres Forschungsgebiets Ein Gro teil der Arbeit von IS Fachkr ften und Managern besch ftigt sich mit Gestal ten Design dem zweckorientierten Einsatz von Ressourcen zur Erreichung eines Ziels Aus diesem Grund ist es meines Erachte
346. ufgerufen werden Diese m ssen zwar bei einer nderung des betrachteten Workloads angepasst werden das grunds tzliche Vorgehen kann jedoch beibe halten werden Einleitung 7 Forschungsfrage 3 Welche Resultate werden unter Verwendung eines Workloads aus der Praxis mittels Simulation des LQN Modells im Vergleich zu den Messwerten erzielt und wie lassen sich auftretende Abweichungen erklaren Die Simulation und Evaluation des in Forschungsfrage 2 erstellten LQN Modells steht bei der Beantwortung von Forschungsfrage 3 im Fokus Eine am SAP UCC der TU Miinchen einge setzte Portal Schulung auch Fallstudie genannt dient als Basis f r den modellierten Work load F r die Lasterzeugung wird das in Jehle 2010 131f entwickelte Performance Evaluation Cockpit f r ERP Systeme PEER eingesetzt Dabei wird die Funktionalit t zur Generierung des Workloads genutzt die Ermittlung der Leistungsdaten erfolgt ber die entsprechenden Log und Trace Dateien des SAP Netweaver Portal Systems Ein Lasttreiber f r das Portal system von SAP ist bereits vorhanden sodass dieser lediglich f r die Ziele dieser Arbeit an gepasst werden muss Im Zuge der Evaluation der Simulationsergebnisse werden zwei Szenarien entwickelt die den Fokus auf unterschiedliche zu untersuchende Eigenschaften des Performance und Simulati onsverhaltens legen Grunds tzlich wird die aggregierte Antwortzeit der einzelnen Interakti ons bzw Lastschritte bei e
347. ufrufe anderer Dienste defi niert Server mit mehreren Entries haben jedoch nur eine Warteschlange sodass Anfragen an verschiedenen Diensten dieselbe Warteschlange teilen F r Interaktionen die Gabelungen und Vereinigungen beinhalten ist eine detaillierte Be schreibung notwendig Dies wird mit sogenannten Aktivit ten erreicht die im n chsten Kapi tel erl utert werden Aktivit t Eine Aktivit t ist eine detailliertere Beschreibung einer Entry und befindet sich auf der unters ten Modellierungsebene eines LQN Modells Sie werden mittels Pfeilen zu einem gerichteten Graphen verbunden der ein oder mehrere Ausf hrungsm glichkeiten darstellt Die Elemente der Aktivit ten Notation sind in Abbildung 2 17 aufgezeigt Theoretische Grundlagen 50 Aktivitatsfluss Aktivitat Und Gabelung Und Vereinigung Oder Gabelung Oder Vereinigung Abbildung 2 17 Notation von Aktivit ten in LQN Modellen Quelle eigene Darstellung Anfrage Anfragen auch Aufrufe genannt werden in LQN Modellen als Pfeile dargestellt und verbin den die Entries untereinander Die Beschriftung der Pfeile gibt dabei die durchschnittliche Anzahl an Anfragen pro Aufruf an Drei verschiedene Arten von Anfragen k nnen zwischen den Entries ausgetauscht werden siehe Abbildung 2 18 Synchroner Aufruf Asynchroner Aufruf Weitergeleiteter Aufruf Abbildung 2 18 Notation der Aufrufe in LQN Modellen Quelle eigene Darstellung 1 Synchroner
348. ulze 2007 64 Spannweite Die Spannweite R ist der einfachste Streuungsparameter und ist definiert als die Differenz zwischen dem gr ten und dem kleinsten vorkommenden Beobachtungswert R X max X min Der gr te Nachteil der Spannweite und somit eine Einschr nkung der Aussagekraft ist dass sie nur aus zwei Werten gebildet wird und im Falle von Ausrei ern also untypischen Mini mal bzw Maximalwerten nicht zu repr sentativen Ergebnis f hrt Quartile und Quantile Unterteilt man die Beobachtungswerte in vier gleich gro e Abschnitte dann sind die Werte an den drei Schnittstellen die Quartile Das zweite Quartil 50 ist folglich der Median Die Differenz zwischen dem ersten und dritten Quartil wird Interquartilsabstand genannt und stellt somit ein Streuungsma dar Da die Unterteilungen oft variieren beispielsweise zehn Dezile oder hundert Perzentile werden die Abschnitte im Allgemeinen Quantile genannt Standardabweichung und Varianz Zu den bekanntesten Streuungsma en z hlen die Standardabweichung und die Varianz Die Varianz beschreibt den durchschnittlichen quadratischen Abstand der Beobachtungswerte zum arithmetischen Mittel n 02 ax x i 1 Die Standardabweichung wird entsprechend aus der Quadratwurzel der Varianz gebildet Da bei Stichproben die relativ klein sind im Verh ltnis zur Grundgesamtheit die Division durch die Gesamtzahl der Beobachtungen tendenziell eine zu niedrige Sch tzung der S
349. und Inhomogenit t realer Workloads muss ein Test Workload entwickelt werden der den realen Workload repr sentiert Dieser sollte den statischen und dynamischen Eigenschaften des realen Workloads bestm glich entsprechen Zudem sollte er einfach reproduzierbar sein damit er f r verschiedene Systemanalysen verwendet werden kann Jain 1991 Die Lasterzeugung wird in der Regel mit einem eigenst ndigen Programm durchgef hrt wel ches ber eine definierte Schnittstelle mit dem System kommuniziert Durch die automatisier te Lasterzeugung wird eine Reproduzierbarkeit gew hrleistet die vergleichende Untersu chungen erm glicht Wilhelm 2001 2 3 2 1 Workload Charakterisierung Bei der Workload Charakterisierung wird ein Workload Modell erstellt welches ein verein fachtes Abbild des realen Lastmusters darstellt Dabei wird aus der Vielzahl an gesammelten Daten w hren der Systemlaufzeit eine Teilmenge an relevanten Daten extrahiert Der Repr sentationsgrad eines Workload Modells kann mittels einer quivalenzrelation aus gedr ckt werden Gegeben seien ein System S sowie ein Set von Performance Indizes L welche von einem bestimmten Workload W gewonnen werden Es kann nun eine Funktion fs f r S definiert werden sodass L fs W Sei nun W der reale Workload und L die entspre chenden Performance Indizes dann ergibt sich L fs W Ebenso gilt Lm fs Win wo bei Wn das Workload Modell und Lm die entsprechenden Performance Indizes da
350. ung 4 3 LQN Modellierung der Benutzer Quelle eigene Darstellung Parametrisierung 109 Wie bereits geschildert werden die Benutzer als Referenz Tasks und die einzelnen Benutzer anfragen Interaktionsschritte als Aktivit ten modelliert Folgende Parameter die sich auf die traditionelle Schreibweise der Eingabedatei f r den LQNs bzw LQsim beziehen siehe Kapi tel 2 5 4 sowie Franks et al 2012 definieren die Eigenschaften der Benutzer Die Anzahl der Benutzer desselben Benutzertyps kann ber die Multiplizit t des Tasks die ber den Parameter lt multi_server_flag gt gesteuert wird festgelegt werden Die Denkzeit des Benutzers wird mit dem Parameter lt think_time gt definiert Dieser wird fiir jeden Interaktionsschritt definiert da unterschiedliche Benutzeraktionen un terschiedliche Denkzeiten erfordern Im Normalfall sollten die Denkzeiten der einzel nen Interaktionsschritte exponentialverteilt werden Da der Ressourcenbedarf bei den Benutzern keinen Einfluss nehmen soll werden die gekoppelten CPU Ressourcen mit einer unendlichen Multiplizit t modelliert Dazu wird der Parameter lt multi_server_flag gt des Prozessor Tasks auf infinite gesetzt Die Service Anfragen Requests siehe Kapitel 2 5 1 verbinden die Interaktionsschrit te des Benutzers mit den entsprechenden Lastschritten am Server Die durch den Be nutzer get tigten Aufrufe der Lastschritte sind synchron da bis zur Erledigung der
351. ung der Simulationser gebnisse sind vor allem die Werkzeuge zur allgemeinen Systemanalyse von Bedeutung da nicht nur Problemsituationen aufgedeckt sondern die Leistungsdaten kontinuierlich gesam melt werden sollen Abbildung 3 14 zeigt die verschiedenen Monitoring Werkezeuge und ordnet sie dabei ihrem Detaillierungsgrad zu Die drei abgerundeten Bl cke stellen den unter schiedlichen Verwendungszweck dar Verf gbarkeits Monitor Zustandsmonitore Aggregierte Statistiken Log Monitoring Performance Trace Single Activity Trace SOL Trace Detaillierungsgrad Developer Trace Application Trace Remote Debugging Abbildung 3 14 Monitoring Werkzeuge im SAP Netweaver AS Java Quelle eigene Darstellung Der erste Block oben beinhaltet Werkezeuge zur allgemeinen Uberwachung des Systemzu stands Verfiigbarkeitsmonitoring der Applikationen und Java Engines wird ber den soge nannten Generic Request and Message Generator GRMG erreicht Zustandsmonitore berwachen die einzelnen Java Engines Systemarchitektur und Monitoring 82 Log Dateien protokollieren die einzelnen Aktivit ten auf einer allgemeinen Ebene Aggregierte Statistiken beinhalten verdichtete Leistungsdaten die zur bersicht der Systemleistung genutzt werden Angezeigt werden Antwortzeiten Wartezeiten CPU Zeiten Netzzeiten usw Der dritte Block unten beinhaltet Entwicklerwerkzeuge f r die Samml
352. ung von Leistungsda ten auf Quellcode Ebene So zeigt beispielsweise der Applikations Trace einzelne Methoden aufrufe sowie ihre Bearbeitungszeiten Der zweite Block Mitte umfasst schlie lich Werkzeuge zur Systemanalyse auf Komponen tenebene und wird im Folgenden n her betrachtet 3 2 1 Java Application Response Time Measurement Das Java Application Response Time Measurement JARM bildet die technische Basis der Leistungsdatenerhebung und erm glicht prim r das Sammeln von Antwortzeiten einer Java Applikation Neben den Antwortzeiten der einzelnen Komponenten werden auch der Benut zer der die Anfrage gesendet hat sowie die Menge an Daten die transferiert wurden ange geben Das JARM Monitoring ist im Gegensatz zu dem Performance Trace siehe Kapi tel 3 2 3 auch bei Produktivsystemen standardm ig eingeschaltet und kann somit als nicht intrusiv gewertet werden Die Leistungsdaten die in der JARM Ansicht zur Verf gung ge stellt werden sind in Tabelle 3 9 dargestellt Element Beschreibung Benutzeranfrage Request Name Name der Anfrage Response Time Dauer der Bearbeitung Antwortzeit ms Outbound Data Components Menge an gesendeten Daten Bytes Anzahl an Komponenten Comp Max Time Komponente mit der h chsten Bearbeitungszeit Data Die Menge an Daten die bei der Komponente mit der h chsten Bearbeitungszeit gesendet wurden Status Monitoring Status 0 kei
353. unsere gegen w rtigen Entschl sse richten Hertz 1894 1f Etwa 30 Jahre sp ter erfreute sich die Modellbildung auch in den Wirtschaftswissenschaften gro er Beliebtheit wenngleich bereits im 18 Jahrhundert durch die konomen Adam Smith und David Ricardo erste theoretische Modelle zur Beschreibung von konomischen Zusam menh ngen entwickelt worden waren Niehans 1990 Werden in einem dynamischen Modell zeitliche Abl ufe beschrieben k nnen Simulations techniken zur L sung der zugrundeliegenden Gleichungen eingesetzt werden Eine Simulati on imitiert somit die zeitliche Entwicklung eines weltlichen Prozesses oder Systems Banks et al 2004 Werden diese Abl ufe von Computersystemen berechnet wird von einer Compu tersimulation gesprochen Eben solche Computersysteme erfahren seit ihrem Beginn mit dem von Konrad Zuse im Jahr 1941 entwickelten frei programmierbaren Rechenautomaten eine enorme Entwicklung in ihrer Leistungsf higkeit vgl Moore s Law Moore 1965 Heutzutage ist der Computer ein zentrales Instrument f r verschiedenste Einsatzzwecke sowohl im gesch ftlichen als auch im privaten Bereich Mit dem vielf ltigen Einsatz geht ein breites Spektrum an verf gbaren Ar chitekturen einher das wiederum die Auswahl eines bestimmten Computersystems f r eine bestimmte Anforderung erfordert Sobald die Auswahl einer Architektur getroffen wurde stellen sich Fragen zur Leistungsf higkeit des gew hlten Systems Diese Frag
354. unterschiedlichen Anzahl an simultan agierenden Benutzern dargestellt Im Anschluss werden verschiedene Komponenten sowie deren Einfluss vgl Kapitel 4 1 2 betrachtet Simulation und Evaluation 151 5 5 4 1 Antwortzeiten 600s ke a 500s 3 2 E et 4 H 400s E E P J E 300s J E bi 2 J 200s T T T 1 1 20 40 60 80 100 120 Anzahl simultaner Benutzer u 260 725 269 180 275 775 292 156 319 540 404 587 504 311 Ei 17 318 17 330 17 285 21 647 21 103 25 977 43 295 Cx 0 066 0 064 0 063 0 074 0 066 0 064 0 086 Median 254 590 262 999 269 860 284 487 312 620 395 384 488 974 Q1 25 252 829 260 830 267 939 282 287 310 140 392 744 484 573 Q3 75 262 573 270 900 277 504 294 466 322 556 407 359 508 932 Abbildung 5 10 Kumulierte Antwortzeiten in Sekunden Szenario 1 Quelle eigene Darstellung In Abbildung 5 10 ist die Dauer die f r die Abarbeitung der Portalfallstudie ben tigt wird bei einer steigenden Anzahl von simultanen Benutzern dargestellt Das aus den Grundannah men abgeleitete Verhalten vgl Kapitel 4 1 1 l sst sich dabei deutlich erkennen Leichter Anstieg in der ersten Phase Die aggregierten Antwortzeiten steigen zun chst in geringem Ma e an bis eine Anzahl von ca 80 gleichzeitig agierenden Benutzern erreicht wird In dieser Phase sind noch gen gend freie Applikations Threads vorhan den Der leichte Anstieg l sst sich mit zunehmenden Enqueue Zeiten im Sperrma nagement erkl ren da be
355. va Application Response Time Measurement JARM Daten 83 Tabelle 3 10 SQL Trace Informationen f r die Performance Analyse 91 Tabelle 3 11 Monitoring Tools auf Betriebssystemebene AIX 95 Tabelle 3 12 Leistungsdaten Berichte des Betriebssystem Hilfsmittels Iopasout 96 Tabelle 4 1 Einflussgr en auf die Antwortzeit in einem SAP Netweaver Portal System 106 Tabelle 5 1 Konsolidierte Liste der modellierten Portalfunktionen eeee 140 Tabelle 5 2 Statistische Daten zum Garbage Collector Szenario 2 80 Benutzer 176 Tabelle 5 3 Statistische Daten zum Garbage Collector Szenario 2 100 Benutzer 177 Tabelle 6 1 Bewertung der Ergebnisse nach Modellkomponenten und Einflussfaktoren 185 Tabelle 8 1 Vollst ndige Transkription der Schulungsinhalte nach Funktonen 207 Abkiirzungsverzeichnis XI Abk rzungsverzeichnis ABAP ACID AIX AJAX AME API AS ASP BYD CCMS CEC CEN CISC CLP CTMC CPN CPU CRM CSV DHTML DIAG DSAG DSR DTD DTMC EJB ERP FCFS FIFO FLOPS GC GRMG Advanced Business Application Programming Atomicity Consistency Isolation Durability Advanced Interactive Executive Asynchronous Javascript and XML Active Memory Expansion Application Programming Interface Application Server Application Service Provider Business By Design Computing Center Management System Cross Electronic Circuit Central Monitoring System Complex Instruction
356. va Speichermanagements LON Modell 103 siehe zum Beispiel Franks Lau Hrischuk 2011 Ufimtsev 2006 Ufimtsev Murphy 2006 oder Xu et al 2005 als auch bei der Behandlung des SAP Sperrmanagements siehe zum Beispiel Rolia et al 2009 oder Cheng 2008 konnten keine expliziten Ans tze in der Lite ratur identifiziert werden Die Einfl sse dieser Komponenten finden sich stets implizit in den Bearbeitungszeiten wieder In Zusammenarbeit mit Gradl 2012 wurde aus diesem Grunde ein Konzept zur Modellie rung des SAP Sperrmechanismus entwickelt welches sowohl auf den ABAP als auch auf den Java Stack anwendbar ist und in Kapitel 4 2 3 n her erl utert wird Damit wird es m g lich das Verhalten des Sperrmechanismus nachzubilden Bei der impliziten Parametrisierung der Sperrwartezeiten in den Bearbeitungszeiten k nnten diese nicht dynamisch abh ngig von der parallelen Nutzung des Systems mit einbezogen werden 4 1 Grundannahmen Zun chst werden in Kapitel 4 1 1 Annahmen bez glich des Systemverhaltens getroffen die sich aus der Warteschlangentheorie ableiten lassen Dies stellt eine Voraussetzung f r das in dieser Arbeit entwickelte Warteschlangenmodell dar da sich nur bei entsprechendem Sys temverhalten der Einsatz eines Warteschlangennetzes anbietet Wie die im weiteren Verlauf dieser Arbeit dargestellten Messergebnisse zeigen werden erf llt ein SAP Portalsystem diese Voraussetzungen weitestgehend In Kapitel 4 1 2 werden
357. vice Zeiten der Benutzeraktivit ten sowie die Denkzeiten 0 sind Im allgemeinen Fall errechnet sich die Antwortzeit der Interaktionsschritte aus Wiedergegebene Servicezeit der Aktvit t des Interaktionsschrittes Denkzeit der Aktivit t des Interaktionsschrittes Antwortzeit des Interaktionsschrittes Die Summe der Antwortzeiten ergibt folglich die Gesamtantwortzeit des modellierten Work loads 1 Service times 2 3 Task Name Entry Name Phase 1 Phase 2 4 UI U1E1 6 39862 0 5 Activity Name 6 U1A1 2 97635 7 U1A2 3 42226 8 WI W1E1 2 97635 9 W1E2 3 42226 15 RS1 RS1E1 0 0073017 0 0011371 16 Activity Name 17 RSA1 0 18 RScheck 0 00672217 19 RSdb 0 000579533 LI Listing 5 10 Service Zeiten in der Ausgabedatei Beispiel Quelle eigene Darstellung Im Lesesperrenbereich RS1 kann man die durchschnittlichen Sperrzeiten des Lesesperrenbe reichs erkennen Die Entry RSIEI stellt die durchschnittliche Service Zeit einer Sperranfrage ohne Enqueue Server Zeit dar Den Mittelwert der reinen Datenbankzeit findet man bei der Aktivit t RSab Die Zeit am Enqueue Server ist in dem Wert RSIEI nicht enthalten und kann aufgrund des weitergeleiteten Aufrufs von EIEI nach RSIEI nicht direkt abgelesen werden Allerdings ergibt sich die durchschnittliche Gesamtzeit inkl Datenbankzeit der SQL Abfrage E1E1 ber die Addition der mittleren Service Zeit von RS1E1 der mittleren Service Zeit von E1E1 sowie der mittleren Verz gerung des Re
358. w sap com germany plattform in SAP SAP SAP SAP SAP SAP SAP SAP SAP SAP SAP SAP SAP memory computing index epx zugegriffen am 03 01 2012 2012 201 1a Active Monitors In http help sap com saphelp_nw04 Helpdata EN 43 84be64d44a22aee10000000a1553f 6 content htm zugegriffen am 10 09 2011 2011 2011b Application Platform by Key Capability In http help sap com saphelp_nw70 helpdata en 17 f1b640c9aa054fal12493e48912909c content htm zugegriffen am 18 10 2011 2011 2011c Architecture of the Locking Service Adapter In http help sap com saphelp_nw04 helpdata en 9a 4cdcc80fa4c747a2ccb5859f467412 content htm zugegriffen am 19 09 2011 2011 2011d Composite Application Framework by Key Capability In http help sap com saphelp_nw70 helpdata en 0c 58497f4 1 1a7848985ae2aa0dda0bd3 frameset htm zugegriffen am 18 10 2011 2011 2011e Configuring Tables In http help sap com saphelp_nw04 helpdata de bf 86eb3 f0c49f106e10000000a1550b0 content htm zugegriffen am 12 10 2011 2011 2011f Distributed Statistics Records DSRs In http help sap com saphelp_nw04 helpdata de ee 40fd2b396dd442a1acle0409bce5c9 content htm zugegriffen am 03 08 2011 2011 20119 DSR Example Simple Transaction Step In http help sap com saphelp_nw04 helpdata en 1d 58f85b87f12e49ab9bf4a93a799d58 content htm zugegriffen am 04 09 2011 2011 2011h Employee Self Service Portal EP ESS In http w
359. weise eine Fehlerquote von zehn bis drei ig Prozent aufweisen Diese Fehlerquote ist f r viele Anwendungen ausreichend Lazowska et al 1984 Markov Ketten Ein stochastischer Prozess ist definiert als eine Familie von Zufallsvariablen X t T wo bei jede Zufallsvariable X einen Index t T aufweist der als Parameter der Zeit verstanden wird wenn gilt T R 0 0 Die Menge aller m glichen Werte von X f r jedes t ET wird als der Zustandsraum S bezeichnet Bolch et al 2006 52 F r jeden beliebigen Zeit punkt t E T liefert der stochastische Prozess also eine diskrete oder kontinuierliche Zufallsva riable Dadurch entstehen von Zeitpunkt zu Zeitpunkt zuf llige stochastische berg nge Markov Prozesse sind eine besondere vielleicht die wichtigste Unterklasse von stochasti schen Prozessen Sie bieten ein sehr flexibles leistungsf higes und effizientes Mittel zur Be schreibung und Analyse von dynamischen Systemeigenschaften Zudem stellen Markov Prozesse die fundamental Theorie des zugrundeliegenden Konzepts der Warteschlangen Systeme dar Bolch et al 2006 51f Sie erf llen die Forderung dass Zust nde nur von dem jeweiligen vorherigen Zustand stochastisch abh ngig und von allen weiter zur ckliegen den Zust nden stochastisch unabh ngig sind unze 2006 347 Mit anderen Worten wird ein Prozess Markov Prozess genannt wenn die zuk nftigen Zust nde eines Prozesses nicht von der Vergangenheit sonde
360. weiterter Speichergr e In Abbildung 3 28 ist eine exemplarische vmstat Ausgabe abgebildet F r eine Beschrei bung der einzelnen Werte sei an dieser Stelle an die vmstat Dokumentation IBM 2011m verwiesen bash 4 1 cat vmstat out System Configuration lcpu 12 mem 10496MB tmem 8192MB ent 0 30 mmode dedicated E kthr memory page faults cpu rb avm fre csz cfr dxm ci co pi po in sy cs us sy id wa pc ec 4 2 2318621 314695 124856 8750 0 0 0 0 0 25 2233 903 0 099 0 0 00 1 0 bash 4 1 E Abbildung 3 28 Exemplarische vmstat Ausgabe Quelle eigene Darstellung Der Einfluss von vmstat auf den Ressourcenverbrauch verh lt sich wie bei mpstat im Bereich zwischen 0 05 und 0 1 Prozent und kann ebenso als Bestandteil eines praxisbezoge nen Szenarios gewertet werden Ebenso analog zu mpstat k nnen bei vmstat Intervall und Anzahl angegeben werden sodass sich folgende Befehlszeile f r die in dieser Arbeit durchgef hrten Messungen ergibt vmstat lt Intervall gt lt Anzahl gt gt lt Ausgabedatei gt Die in die Datei geschriebenen Aufzeichnungen wurden im Anschluss in Excel importiert und ausgewertet 3 3 3 Monitoring des I O Subsystems F r die berwachung und Aufzeichnung des I O Subsystems wurde das Betriebssystem Hilfsmittel iostat IBM 2011e verwendet Bei dem verwendeten Testsystem kam das Sto ragesystem XIV IBM 2011d zum Einsatz deren logische Festplattenpartitio
361. wertung erfolgt zun chst faktisch ber den Vergleich zwischen den gemessenen und simulierten Antwortzeiten sowie der Analyse des Antwortzeitverhaltens und potentiellen Abweichungen Abschlie end wird eine Interpretation der Ergebnisse durchgef hrt die die erreichten Resultate einordnet und erlangtes Wissen be schreibt Einleitung 8 1 4 Forschungsdesign Ein wesentlicher Bestandteil der Wirtschaftsinformatik ist das Design und die Implementie rung von Artefakten der Informationstechnologie mit dem Ziel die Performance von Unter nehmen zu verbessern Das Management der Unternehmen sieht die Performance aus einer konomischen Perspektive und stellt gerechtfertigterweise die Fragen warum Investitionen in IT Artefakte oftmals nicht die gew nschte Wertsteigerung erzielen und welche IT Artefakte dies erreichen k nnen W hrend die erste Frage theoriebasiert und kausalbezogen ist stellt die zweite Frage eine konstruktionsorientierte probleml sende Fragestellung dar Wissenschaft liche Arbeiten die letztere Frage adressieren und dabei IT Artefakte erstellen und evaluieren fallen in den Bereich der gestaltungsorientierten Forschung Design Science vgl March Storey 2008 Die gestaltungsorientierte Forschung hat ihre Wurzeln in den ingenieurswissenschaftlichen Disziplinen und untersucht im Gegensatz zu den Naturwissenschaften die nat rlich vorkom mende Ph nomene erforschen vom Menschen erschaffene Gegebenheiten um bestimmte Ziele z
362. wie zum Beispiel das Benutzermanagement oder das Connector Framework Auf die Architektur des Portalsystems bzw des SAP Netweaver AS Java sowie der Mittel zur Leistungsanalyse wird in Kapitel 3 detailliert eingegangen Wie eingangs bereits detailliert dargestellt setzt sich diese Arbeit f r die Performance Evaluation von SAP Netweaver Portal Systemen zum Ziel einen Ansatz zur Modellierung und Simulation eines SAP Netweaver Portals vorzustellen Aufgrund der Nutzung des HTTP Protokolls ist eine automatisierte Lasterzeugung die Auftr ge an die Applikationsschicht schickt m glich und bildet somit die Grundlage f r die Messung der Leistungsdaten Das Profil der Ressourcennutzung aus Kapitel 2 1 1 3 zeigt dass der Ressourcenverbrauch haupt s chlich im Bereich des Hauptspeichers und der CPU liegt sodass der Verzicht auf eine fein granulare Modellierung der Datenbank keinen starken Einfluss auf die Genauigkeit der Ant wortzeitprognose nimmt 2 2 Messtheoretische Grundlagen Die Messtheorie ist kein zentraler Gegenstand dieser Arbeit allerdings stellt sie die Grundla ge der durchgef hrten Messungen am Portalsystem dar Die Messungen erfolgen dabei aus zwei Gr nden Zum einen werden verschiedene Messreihen zur Parametrisierung des Warte schlangenmodells verwendet zum anderen dienen die Messungen am realen Testsystem zum Validieren bzw Vergleichen der Simulationswerte Die Messung im spezifischen Kontext der Performance Evaluation von R
363. ww sap com solutions benchmark ep ess epx zugegriffen am 14 12 2011 2011 2011j Information Integration Key Areas In http help sap com saphelp_nw70 helpdata en 0c 58497f411a7848985ae2aa0dda0bd3 frameset htm zugegriffen am 18 10 2011 2011 2011j Integration Processes ccBPM In http help sap com saphelp_nw70 helpdata en 3c 83 1620a4f1044dba38b370f77835cc frameset htm zugegriffen am 09 10 2011 2011 2011k Lock Table In http help sap com saphelp_gts72 helpdata en f4 670f9b9d62f94db4ea7361b34ea214 frameset htm zugegriffen am 18 10 2011 2011 20111 People Integration by Key Capability In http help sap com saphelp_nw70 helpdata en 0c 58497f411a7848985ae2aa0dda0bd3 frameset htm zugegriffen am 18 10 2011 2011 2011m Portal Architecture In http help sap com saphelp_nwO04 helpdata en 44 42bfc481ce2152e10000000al 14a6b content htm zugegriffen am 03 09 2011 2011 Literaturverzeichnis 202 SAP 2011n Solution Life Cycle Management by Key Capability In http help sap com saphelp_nw70 helpdata en 0c 58497f411a7848985ae2aa0dda0bd3 frameset htm zugegriffen am 18 10 2011 2011 SAP 2002 Siemens and SAP Agree to Provide mySAP tm Enterprise Portal to All Siemens Employees as Well as Its Global Partners Customers and Suppliers In http www sap com press epx pressid 1400 zugegriffen am 01 04 2012 2012 SAP Education 2011 SAP Education In www sap com germany services education index epx zugegri
364. ystem zur internen Synchronisation verwendet Eine Datenbank f r die zentrale Datenhaltung Pr sentationsschicht Applikationsschicht Central Services Message Server Enqueue Server A Datenbankschicht Ee Abbildung 3 1 Aufbau eines Java Clusters Quelle eigene Darstellung Systemarchitektur und Monitoring 66 Wie in Abbildung 3 1 dargestellt wird als Benutzerinterface standardm ig ein normaler Web Browser verwendet Die eingehenden Anfragen werden vom Java Dispatcher an den Server Prozess weitergeleitet wo die eigentliche Abarbeitung der Anfrage stattfindet Im Ge gensatz zum SAP Netweaver AS ABAP kurz AS ABAP sind die Cluster Knoten des AS Java nebenl ufig Somit k nnen von einem Java Server Prozess mehrere Benutzeranfragen gleichzeitig abgearbeitet werden W hrend der Abarbeitung der Benutzeranfragen ist es oft notwendig auf die Daten im ent sprechenden Schema der Datenbank zuzugreifen Daher ist jeder Java Server Prozess mehr fach ber den Datenbank Connection Pool mit dem Datenbankschema verbunden Puffer beschleunigen dabei die Abarbeitung der Benutzeranfragen da die in dem Puffer zwischenge speicherten Daten einen Zugriff auf die Datenbank vermeiden Jeder Java Server Prozess verwaltet seinen eigenen Puffer 3 1 1 Abarbeitung von Anfragen Einkommende Benutzeranfragen werden von Server Socket Listeners im Java Dispatcher angenommen Sollten mehr Anfragen ankommen als weitergeleitet werden k
365. zeigt den Verlauf einer asynchron bear beiteten Anfrage Client Asynchroner Aufruf Phase 1 besch ftigt i Leerlauf Phase 2 Weiterer Serviceaufruf Zeit aS I Abbildung 2 20 Ablauf eines asynchronen Aufrufs Quelle eigene Darstellung 3 Weitergeleiteter Aufruf Em weitergeleiteter Aufruf wird mittels eines gestrichelten Pfeils symbolisiert und stellt einen synchronen Aufruf dar der durch eine Kette von Servern bedient wird Der Client sendet dabei einen synchronen Aufruf an Server 1 der in Phase 1 beginnt die Anfrage zu bearbeiten Am Ende von Phase 1 wird die An frage an den n chsten Server weitergeleitet und Server 1 beginnt die restlichen Phasen abzuarbeiten Der Client hingegen bleibt blockiert bis die Server Kette terminiert und der letzte Server die Antwort an den Client schickt Der Ablauf einer weitergeleiteten Nachricht ist beispielhaft in Abbildung 2 21 dargestellt Theoretische Grundlagen 52 Synchroner Aufruf Phase 1 Phase 2 sah Client Phase 1 Phase 2 Abbildung 2 21 Ablauf eines weitergeleiteten Aufrufs Quelle eigene Darstellung Eine Phase kann zudem deterministisch oder stochastisch sein und folgt folgenden Annahmen Petriu et al 2000 2 5 2 Der CPU Ressourcen Bedarf einer Phase welcher als Parameter angegeben wird ist in exponentialverteilte Teile ftir jede Anfrage an Servern niedriger Ebenen aufgeteilt Die durchschnittliche Ausf hrungszeit ist bei allen Teilen
366. zur Laufzeit Als Betriebssystem wird AIX verwendet der Hauptspeicher ist mit einem AME Faktor vgl Kapitel 3 3 2 von 1 3 konfiguriert Das Datenbanksystem ist auf einem eigenen virtuellen Simulation und Evaluation 147 Host installiert damit der Server der Applikationsschicht nicht beeinflusst wird Die CPU Ressource des Datenbanksystems ist somit v llig unabh ngig vom betrachteten Applikations server Da die Datenbank lediglich als Black Box betrachtet und nicht n her analysiert wird werden dem Datenbank Host ausreichend Systemressourcen zur Verf gung gestellt 5 4 1 Szenario 1 Ausreichende Systemressourcen Im ersten Szenario werden wie bereits erw hnt die Systemressourcen in ausreichendem Ma Be vergeben siehe Abbildung 5 6 Zum einen werden die CPU Ressourcen nicht gekappt damit der zunehmende Bedarf bei steigender Benutzeranzahl beobachtet werden kann Ebenso werden die Tabellenpuffer ausreichend dimensioniert sodass es nicht zu Verdr ngungen kommt Dies reduziert die Weiterleitungswahrscheinlichkeit im Tabellenpuffer Task und so mit dessen Einfluss auf das Antwortzeitverhalten Das erste Szenario stellt folglich ein Basisszenario dar in dem auf erh hte Einfl sse der Res sourcenknappheit verzichtet wird Prim res Ziel dieses Szenarios ist die berpr fung des Sys temverhaltens unter optimierten Bedingungen sowie der Vergleich der Daten mit den erziel ten Simulationsergebnissen Testsystem Szenario 1 DN

Performance-Modellierung und Simulation eines SAP

Contents

Download Pdf Manuals

Related Search

Related Contents