FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN. Bachelorarbeit in Wirtschaftsinformatik

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Konzeption und Entwicklung einer Java EE- Anwendung zum Datenaustausch zwischen einer Performance-Simulationsumgebung und einer Performance-Analyseplattform Markus Dlugi

2 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Konzeption und Entwicklung einer Java EE- Anwendung zum Datenaustausch zwischen einer Performance-Simulationsumgebung und einer Performance-Analyseplattform Design and development of a Java EE application for the data transfer between a performance simulation environment and a performance analysis platform Bearbeiter: Markus Dlugi Themensteller: Prof. Dr. Helmut Krcmar Betreuer: Andreas Brunnert, M.Sc. Abgabedatum: 16. Dezember 2013

3 Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Garching b. München, den Ort, Datum Unterschrift

4 Zusammenfassung Um die Validierung von Performance-Modellen zu unterstützen, wird in dieser Arbeit ein Tool namens Simulation Data Service entwickelt. Dieses ist in der Lage, Simulationsergebnisse verschiedener Simulationswerkzeuge zu empfangen und einheitlich in einer Datenbank abzulegen. Dieses Tool dient später als Grundlage für die Performance Management Work Tools, eine Plattform, welche die einfache Validierung von Performance-Modellen ermöglichen soll. Neben dem Service wird zudem ein exemplarischer Client für ein spezifisches Simulationswerkzeug entwickelt, um die Funktionsfähigkeit des Services zu demonstrieren. Zunächst muss dafür untersucht werden, welche Daten für einen Vergleich von Simulationsund Messergebnissen notwendig sind; dies geschieht durch ein Literaturreview, das statistische Verfahren bei der Performance Evaluation untersucht. Anschließend wird eine Workload-Definition aufgestellt, welche mithilfe des Kolmogorov-Smirnov-Tests validiert wird. Mit diesen Daten wird daraufhin ein Datenmodell auf Grundlage des Structured Metrics Metamodel (SMM) gebaut und mithilfe von JPA auf einem JBoss Application Server implementiert. Schließlich wird untersucht, welche Möglichkeiten es für die Übertragung der Daten zum Server gibt; in der Arbeit wird JAX-WS in Kombination mit gzip verwendet. Der Wert der Arbeit liegt damit neben der Entwicklung eines Tools für eine einfachere Validierung in der erstmaligen dokumentierten Verwendung von SMM für Ergebnisse aus Performance- Modellen. Stichworte: Performance-Modell, PCM, Palladio, PMWT, Validierung, Simulation, Workload, SMM, Kolmogorov-Smirnov-Test, Java EE, JPA, JBoss, gzip, JAX-WS In order to support the validation of performance models, a tool called Simulation Data Service is developed in this thesis. It is capable of receiving simulation results from various simulation tools and persisting them uniformly in a database. This tool will later build the foundation for the Performance Management Work Tools, a platform designed to ease the validation of performance models. In addition to this service, an exemplary client for a specific simulation tool is developed in order to demonstrate the effectiveness of the service. The thesis starts off with an analysis to find out which data is necessary for a comparison of simulation results and measurements; this is done by conducting a literature review examining statistical methods used in performance evaluation. Subsequently, a workload definition is given and validated using the Kolmogorov-Smirnov test. Using this data, a data model is built on the basis of the Structured Metrics Metamodel (SMM) and implemented on a JBoss application server using JPA. Ultimately, possibilities for sending the data to the server are reviewed; in the thesis, JAX-WS in combination with gzip is used. The value of this thesis, besides developing a tool for easier validation, is the first documented use of SMM for results gathered from performance models. Keywords: performance model, PCM, Palladio, PMWT, validation, simulation, workload, SMM, Kolmogorov-Smirnov test, Java EE, JPA, JBoss, gzip, JAX-WS III

5 Inhaltsverzeichnis Zusammenfassung... III Abbildungsverzeichnis... VI Tabellenverzeichnis...VII Abkürzungsverzeichnis... VIII 1 Einleitung Motivation Struktur der Arbeit Grundlagen Performance-Modelle Allgemeines Palladio Component Model Java EE Evaluation von Performance-Modellen Grundlagen der Evaluation Auswahl notwendiger Daten Workload Bedeutung von Workload Workload im Palladio Component Model Definition von Workload Kolmogorov-Smirnov-Test Validierung der Definition Fazit Datenaustausch zwischen einer Performance-Simulationsumgebung und einer Performance-Analyseplattform Repräsentation von Performance-Daten Referenzmodelle Common Information Model Structured Metrics Metamodel Auswahl eines Referenzmodells Anpassung des Referenzmodells Übertragung von Performance-Daten Wahl eines Web Services Definition des Service-Interfaces Reduzierung des HTTP- und TCP-Overheads Reduzierung des Payloads IV

6 4.3 Fazit Architektur des Prototyps Überblick Java Persistence API Grundlagen Abbildung von Vererbung Probleme der Vererbungs- und Generationsstrategie Effiziente Persistierung einer großen Zahl von Messungen Architektur des Clients Fazit Zusammenfassung Ausblick Literaturverzeichnis Anhang Anhang A Datenmodelle V

7 Abbildungsverzeichnis Abbildung 1: Schichtenmodell der PMWT... 2 Abbildung 2: Entwickler-Rollen und Modelle im PCM... 5 Abbildung 3: Schema des Java EE Container-Modells... 6 Abbildung 4: Beispielhaftes PCM Usage Model Abbildung 5: Klassendiagramm der Workload-Definition Abbildung 6: Beispielhaftes Objektdiagramm der Workload-Definition Abbildung 7: Grundlegender Ansatz von CIM Abbildung 8: Grundlegender Ansatz von SMM Abbildung 9: Datenmodell des Simulation Data Service Abbildung 10: Interface des Simulation Data Service Abbildung 11: Generierte SOAP-Nachrichten Abbildung 12: Verbessertes Interface des Simulation Data Service Abbildung 13: SOAP-Nachricht des Aufrufs createtimemeasurementcollection Abbildung 14: Verbesserte SOAP-Nachricht für createtimemeasurementcollection Abbildung 15: Anteile der Verarbeitungszeit Abbildung 16: Observation-Klasse mit JPA-Annotationen Abbildung 17: Beispiel für eine JPQL-Abfrage Abbildung 18: INSERT-Zeit pro Messung bei verschiedenen Batch-Größen Abbildung 19: INSERT- und StringBuilder-Zeit pro Messung Abbildung 20: Code-Fragment des PMWTJobs Abbildung 21: Screenshot der Konfiguration des PMWT-Plugins Abbildung 22: CIM Metrics Schema Abbildung 23: SMM Kernklassen Abbildung 24: SMM Measure Klassendiagramm Abbildung 25: SMM Collective Measures Klassendiagramm VI

8 Tabellenverzeichnis Tabelle 1: Statistische Verfahren in wissenschaftlichen Publikationen... 9 Tabelle 2: Performance-Metriken in wissenschaftlichen Publikationen Tabelle 3: Beispielhafte Zahl von Systemaufrufen Tabelle 4: Für die Validierung verwendete Workloads Tabelle 5: Ergebnisse des KS-Tests für , und Messungen Tabelle 6: Ergebnisse des KS-Tests für , und 1,2 Mio. Messungen Tabelle 7: Ergebnisse der Optimierung der Übertragung Tabelle 8: Hypothetische Ergebnisse für einen praxisnahen Simulationsdurchlauf VII

9 Abkürzungsverzeichnis ACM Association for Computing Machinery API Application Programming Interface CBSE Component-Based Software Engineering CDF Cumulative Distribution Function CLOB Character Large Object CORBA Common Object Request Broker Architecture DMTF Distributed Management Task Force EJB Enterprise Java Bean EMF Eclipse Modeling Framework HTTP Hypertext Transfer Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force Java EE Java Platform, Enterprise Edition Java SE Java Platform, Standard Edition JAX-RS Java API for RESTful Web Services JAX-WS Java API for XML Web Services JDBC Java Database Connectivity JPA Java Persistence API JPQL Java Persistence Query Language JSON JavaScript Object Notation JSP Java Server Pages KS-Test Kolmogorov-Smirnov-Test LZ77 Lempel-Ziv 77 LZSS Lempel-Ziv-Storer-Szymanski MIME Multipurpose Internet Mail Extensions MOF Meta Object Facility OCL Object Constraint Language OMG Object Management Group ORM Object-Relational Mapping PCM Palladio Component Model PDF Probability Density Function PMWT Performance Management Work Tools POJO Plain Old Java Object QN Queuing Network REST Representational State Transfer RFC Request for Comments VIII

10 RPC SPE TCP UML UML-MARTE UML-SPT URI URL XML Remote Procedure Call Software Performance Engineering Transmission Control Protocol Unified Modeling Language UML Profile for Modeling and Analysis of Real-Time and Embedded systems UML Profile for Schedulability, Performance, and Time Specification Uniform Resource Identifier Uniform Resource Locator Extensible Markup Language IX

11 Einleitung Motivation Im traditionellen Software Engineering nimmt die Performance (in Form von Antwortzeiten, Durchsatz oder Ressourcenverbrauch) der zu entwickelnden Software häufig eine Nebenrolle ein. Viele Software-Entwickler beschäftigen sich erst mit der Performance, wenn das Projekt sich dem Ende zuneigt und die Performance nicht dem gewünschten Niveau entspricht (Smith 2007, 396). Daher sucht die Forschung im Bereich des Software Performance Engineerings (SPE) schon seit vielen Jahren nach Möglichkeiten, die Performance einer Software früher im Entwicklungsprozess abschätzen zu können; dadurch können bessere Designentscheidungen getroffen und daraus resultierende Fehlentwicklungen verhindert werden. In der Forschung wird dazu häufig der Einsatz von Performance-Modellen vorgeschlagen, welche eine Repräsentation eines Software-Systems darstellen und durch deren Lösung eine Abschätzung der Performance möglich wird (Smith 2007, 397). Während Performance-Modelle in der Forschung weit verbreitet sind, haben sie in der Praxis bisher kaum Verwendung gefunden (Woodside et al. 2007). Dies liegt zum einen an der großen Zahl unterschiedlicher Modelle und Ansätze, welche im Laufe der Zeit entwickelt wurden, angefangen von Queueing Networks (QNs) bis hin zu simulationsbasierten Ansätzen. Infolgedessen wurde eine Fülle an Tools entwickelt, die diese Ansätze implementieren, was zu einem hohen Grad an Diversität und damit einer mangelnden Standardisierung geführt hat (Woodside et al. 2007), trotz Standardisierungsversuchen wie dem Unified Modeling Language (UML) Profile for Schedulability, Performance, and Time Specification (UML-SPT) und dem UML Profile for Modeling and Analysis of Real-Time and Embedded systems (UML- MARTE) (Object Management Group 2005a, 2005b). Neben der fehlenden Standardisierung ist ein weiteres Problem von Performance-Modellen, dass für einen korrekten Einsatz ihre Validität überprüft werden muss es muss sichergestellt werden, dass das Modell tatsächlich dem modellierten System entspricht und die erhaltenen Ergebnisse plausibel sind. Diese Evaluation stellt eine der größten Herausforderungen und zugleich einen der kritischen Erfolgsfaktoren bei der Verwendung von Performance-Modellen dar (Smith 2007, 409). Für die Evaluation bietet sich der Vergleich der aus den Modellen gewonnenen Ergebnissen mit den tatsächlich gemessenen Werten an (Woodside et al. 2007). Aufgrund fehlender Standards ist es bislang jedoch meist mit einem hohen Aufwand verbunden, die Ergebnisse aus verschiedenen Werkzeugen miteinander zu vergleichen. Das Ziel dieser Arbeit ist es, einen Beitrag zur Lösung dieser Probleme bei der Verwendung von Performance-Modellen zu leisten. Dazu wird ein Service entwickelt, der Simulationsergebnisse verschiedener Performance-Werkzeuge empfangen und einheitlich in einer Datenbank ablegen kann. Dieser Service, der als Teil einer Plattform namens Performance Management Work Tools (PMWT) entwickelt wird, dient dabei als Grundlage zur späteren Analyse und Evaluation von Simulationsergebnissen verschiedenster Herkunft. Zusätzlich wird im Rahmen dieser Arbeit ein erster exemplarischer Client umgesetzt, um die Funktionsfähigkeit des Services zu demonstrieren; dieser wird für das Simulationswerkzeug Palladio- Bench entwickelt. Damit trägt diese Arbeit dazu bei, eine einfachere Verwendung von Performance-Modellen in der industriellen Praxis zu ermöglichen. 1

12 Struktur der Arbeit Wie im vorherigen Abschnitt erläutert, beinhaltet die Arbeit eine Reihe von unterschiedlichen Bestandteilen. Wichtigster Bestandteil ist der Simulation Data Service, welcher Daten verschiedener Simulationswerkzeuge empfängt und strukturiert ablegt. Abbildung 1 stellt das konzeptuelle Schichtenmodell der PMWT einschließlich dem Simulation Data Service dar. Abbildung 1: Schichtenmodell der PMWT Quelle: Eigene Darstellung Der Simulation Data Service wird in einem ersten Schritt an die Palladio-Bench angebunden. Gleichzeitig wird der Dienst jedoch so allgemein gehalten, dass später zusätzliche Werkzeuge mit geringem Aufwand hinzugefügt werden können. Wie weiterhin aus der Abbildung hervorgeht, existiert daneben zum einen der Load-Test Data Service, welcher analog zum Simulation Data Service für die Persistierung von Lasttestergebnissen zuständig ist; und zudem das Model Evaluation Tool, das für die Evaluation der übertragenen Modelle verantwortlich ist. Der Fokus dieser Arbeit liegt jedoch auf dem Simulation Data Service und den in der Grafik fett hervorgehobenen Abhängigkeiten. Damit lässt sich die Arbeit in drei wesentliche Bestandteile gliedern. Diese sind 1. die Entwicklung eines Plugins für die Palladio-Bench, welches die relevanten Ergebnisse einer Simulation extrahiert, aufbereitet und an den Service schickt, 2. die Konzeption und Entwicklung des Simulation Data Services, inkl. einem Datenmodell, das eine einheitliche Repräsentation der Ergebnisdaten ermöglicht, sowie 3. die Wahl einer geeigneten Übertragungsmethode zwischen Client und Server. Zur strukturierten Bearbeitung wurden zu Beginn der Arbeit drei Forschungsfragen formuliert. Diese beinhalten die wissenschaftlichen Fragestellungen, die im Laufe der Arbeit beantwortet werden sollen. Jede der Fragen gehört dabei zu einem der drei oben aufgeführten Bestandteile: 2

13 1. Welche Daten sind für den Vergleich von Performance-Simulations- und -Messergebnissen relevant? 2. Wie können die in Forschungsfrage 1 gefundenen Daten in einem einheitlichen Format repräsentiert werden? 3. Wie können die relevanten Performance-Daten aus einem Simulationswerkzeug an die Performance Management Work Tools übertragen werden? Zunächst werden in Kapitel 2 Grundlagen die theoretischen Grundlagen der Arbeit erläutert. Danach wird in Kapitel 3 Evaluation von Performance-Modellen die erste Forschungsfrage behandelt; konkret wird untersucht, welche Daten für eine Evaluation von Performance- Modellen notwendig sind und wie sich Workloads darstellen lassen. In Kapitel 4 Datenaustausch zwischen einer Performance-Simulationsumgebung und einer Performance- Analyseplattform wird zunächst in Abschnitt 4.1 die zweite Forschungsfrage behandelt. Dazu wird untersucht, welche Möglichkeiten es zur Repräsentation von Messdaten gibt; anschließend werden die Möglichkeiten verglichen, und das ausgewählte Modell dient schließlich als Grundlage für die Entwicklung eines eigenen Datenmodells. In Abschnitt 4.2 wird die dritte Forschungsfrage behandelt. Dazu werden erst mögliche Web Service-Typen beschrieben, um dann einen davon für die weitere Bearbeitung auszuwählen; anschließend wird ein Interface für den ausgewählten Service entwickelt. Schließlich wird analysiert, wie die Übertragungsmenge sowohl in Bezug auf den Overhead als auch den Payload reduziert werden kann. Nachdem die Behandlung der Forschungsfragen abgeschlossen ist, wird in Kapitel 5 Architektur des Prototyps auf die konkreten Eigenschaften der Implementierung, speziell im Bereich der Persistenz, eingegangen. Schließlich werden in Kapitel 6 Fazit zusammenfassend die Ergebnisse präsentiert und ein Ausblick auf mögliche Erweiterungen gegeben. 3

14 Grundlagen Performance-Modelle Allgemeines Ein Performance-Modell ist ein Abbild eines realen oder gedachten Software-Systems, welches das Verhalten des Systems in Bezug auf seine Performance repräsentiert (Menascé et al. 1994, 76). Ist ein Modell erst formuliert, lässt es sich mithilfe verschiedener Verfahren lösen, um zu verschiedenen Performance-Metriken zu gelangen. Diese Performance-Metriken treffen eine Aussage darüber, wie gut oder schlecht die Performance des Systems, auf das sie sich beziehen, ist. Die am häufigsten verwendeten Metriken sind die Antwortzeit, die Ressourcennutzung und der Durchsatz. Performance-Modelle wurden in den 1970er Jahren entwickelt wurde erstmals der Einsatz von QNs zur Repräsentation von Performance-Modellen eingesetzt (Buzen 1971). Seither wurden viele verschiedene Möglichkeiten zur Erstellung von Performance-Modellen entwickelt. Einerseits existieren Modelle, welche größtenteils analytisch gelöst werden, um Aussagen über die Performance treffen zu können; die wichtigsten Vertreter dieser Kategorie sind QNs, stochastische Prozessalgebren und stochastische Petri-Netze (Balsamo et al. 2004, ). Daneben gibt es noch simulationsbasierte Ansätze, welche das Modell in ausführbaren Code umwandeln und die Performance anschließend während der Ausführung messen; ein Beispiel dafür ist das Palladio Component Model (PCM) (Becker et al. 2009). Während analytische Verfahren in der Regel genauer und wesentlich schneller sind als Simulationen, haben sie den Nachteil, dass sich komplexe Systeme, wie sie in der Realität auftreten, oftmals nicht analytisch lösen lassen (Becker et al. 2009). Dies trifft insbesondere auf Systeme zu, die mittels Component-Based Software Engineering (CBSE) entwickelt werden (Chen et al. 2005, 35). CBSE ist ein Paradigma, nach welchem die zu entwickelnde Software in Komponenten unterteilt wird. In der Fachwelt hat sich bisher keine allumfassende Definition für den Begriff der Komponente durchgesetzt; für den Zweck dieser Arbeit seien Komponenten nahezu unabhängige und austauschbare Bausteine, welche eine klar definierte Funktion erfüllen (Brown/Wallnau 1998, 38). Ein großer Teil der modernen Software-Systeme arbeitet komponentenbasiert (Chen et al. 2005, 35). Bei solchen Systemen beeinflusst die Architektur die Performance wesentlich. Allerdings sind Änderungen an der Architektur nach der Implementierung nur selten möglich (Becker et al. 2006, 169f); daher ist eine fundierte Performance- Analyse bei komponentenbasierten Systemen besonders wichtig. Gerade CBSE ist jedoch besonders problematisch im Hinblick auf SPE. Dies liegt u.a. daran, dass die Komponenten oft in eine besondere Infrastruktur eingebettet werden, wie z.b. bei der Java Enterprise Edition (Java EE). Diese Infrastruktur beeinflusst die Performance der Komponenten, was bei einer Evaluation mitberücksichtigt werden muss (Chen et al. 2005, 36). Zwar lassen sich derartige Systeme auch mittels klassischer QNs oder stochastischer Prozessalgebren modellieren, jedoch gibt es Alternativen, die eigens für die Spezifikation von komponentenbasierten Systemen konzipiert wurden (Becker et al. 2006, 169; Koziolek 2010). Ein solches Modell ist das Palladio Component Model. 4

15 Palladio Component Model Das Palladio Component Model (PCM) ist ein Metamodell, welches 2007 in einem internen Bericht der Universität Karlsruhe erstmals vorgestellt wurde (vgl. Reussner et al. 2007); erste Grundlagenarbeit durch die Definition von sog. Service Effect Specifications (SEFFs) wurde bereits 2001 geleistet (vgl. Reussner 2001). Es erlaubt die Spezifikation von Informationen, welche für die Performance einer komponentenbasierten Architektur relevant sind (Becker et al. 2007, 54f). Dabei berücksichtigt PCM die Informationsverteilung innerhalb eines typischen Entwickler-Teams, indem es die Spezifikation des Systems in mehrere Modelle unterteilt, welche von jeweils unterschiedlichen Personen erstellt werden. Eine Übersicht der verschiedenen Entwickler-Rollen und der zugehörigen Modelle ist in Abbildung 2 zu sehen. Abbildung 2: Entwickler-Rollen und Modelle im PCM Quelle: Reussner et al. (2007, 9) Dieser Ansatz bringt einige Vorteile mit sich. So lassen sich bspw. sehr einfach Analysen im Hinblick auf die Eignung verschiedener Architekturoptionen durchführen, da jeweils nicht das komplette Modell geändert werden muss. Zudem sind die verschiedenen Modelle stark an die Modelle der UML angelehnt, welche in der Praxis bereits häufig eingesetzt werden, sodass nur eine geringe Einarbeitungszeit notwendig ist, um lauffähige Modelle erstellen zu können. Auf Basis von PCM ist eine Software namens Palladio-Bench entstanden, welche neben den reinen Metamodellen auch Methoden anbietet, um die erzeugten Modelle zu lösen. Palladio- Bench ist ein Plugin für die Java-Entwicklungsumgebung Eclipse, welches das Eclipse Modeling Framework (EMF) zur Spezifikation der Meta-Modelle verwendet (Palladio Team o.j.). Zusätzlich zur analytischen Lösung wird auch das Erzeugen von Prototypen und insbesondere die Durchführung von Simulationen mithilfe des Frameworks SimuCom bereitgestellt (Becker et al. 2009). Bei der Durchführung von Simulationen mit SimuCom werden die Modelle mittels Model-2-Text-Transformation in ausführbaren Java-Code umgewandelt und bei der Ausführung die Performance-Metriken gemessen (Becker 2008, 127). Dabei liegt der Simulation ein Queueing Network zugrunde (Becker 2008, 109). 5

16 Java EE Die Java Platform, Enterprise Edition ist die Spezifikation einer Middleware-Plattform, welche für die Verwendung in Unternehmen entwickelt wurde, mit dem Ziel, die Entwicklung von Unternehmensanwendungen zu vereinfachen und dadurch Kosten zu sparen (Oracle 2013, 1). Sie baut auf der Java Platform, Standard Edition (Java SE) auf und erweitert diese. Java EE ermöglicht die Entwicklung von Desktop-Anwendungen, Browser-Anwendungen und Web Services (Oracle 2013, 8). Dazu enthält die Plattform verschiedene Container, welche den Applikationen eine Laufzeitumgebung und verschiedene Dienste zur Verfügung stellen. Ein Schema der Container und der bereitgestellten Dienste ist in Abbildung 3 zu sehen. Abbildung 3: Schema des Java EE Container-Modells Quelle: (Oracle 2013, 6) In der Abbildung sind der Applet Container, der Web Container, der Application Client Container und der Enterprise Java Beans (EJB) Container dargestellt. Der Applet Container ist für 6

17 die Ausführung von Java Applets, also Java-Applikationen in einem Web Browser, zuständig. Der Application Client Container steuert die Ausführung von Java Desktop-Anwendungen und kann dazu mit dem Web Container, dem EJB Container und der Datenbank kommunizieren. Der Web Container ist verantwortlich für die Bereitstellung von Web Services wie Java Server Pages (JSP) und Servlets; auch er hat Zugriff auf den EJB Container und die Datenbank. Der EJB Container schließlich enthält häufig die Geschäftslogik in Form von EJBs, während die anderen Applikationen nur auf die von den EJBs bereitgestellten Funktionalitäten zugreifen (Oracle 2013, 9). Allerdings kann die Logik auch in der Applikation selbst abgelegt werden, da alle Container (bis auf den Applet Container) auch selbst Zugriff auf die Datenbank haben. Es gibt mehrere Produkte verschiedener Hersteller, die die Java EE-Spezifikation implementieren. In dieser Arbeit wird der JBoss Application Server 7 als Grundlage verwendet, um den Simulation Data Service zu entwickeln und auszuführen. Dabei wird der Service als Servlet umgesetzt; somit wird der Service im Web Container ausgeführt werden. Die Geschäftslogik wird im Servlet selbst implementiert, also ohne die Erstellung einer zusätzlichen EJB, da die Logik nicht so umfangreich ist. Weitere Details der Implementierung werden in Kapitel 4 und 5 behandelt. Nachdem nun die theoretischen Grundbegriffe der Arbeit erläutert wurden, wird im folgenden Kapitel die Evaluation von Performance-Modellen untersucht, um herauszufinden, welche Daten der Simulation Data Service später verarbeiten muss. 7

18 Evaluation von Performance-Modellen Grundlagen der Evaluation Für eine korrekte Verwendung von Performance-Modellen ist deren Verifikation und Validierung von essentieller Bedeutung (Smith 2007, 409). Verifikation beantwortet dabei die Frage bauen wir das Modell richtig?, z.b. in Bezug auf die Abschätzung der Ressourcennutzung oder des Nutzungsverhaltens. Damit entscheidet die Verifikation darüber, ob die erhaltenen Ergebnisse exakt die Performance des Systems widerspiegeln. Demgegenüber steht die Validierung, die die Frage bauen wir das richtige Modell? beantwortet. Hier ist von Bedeutung, ob das Modell eine valide Repräsentation des modellierten Systems darstellt, d.h. dass alle für die Performance relevanten Aspekte des Systems korrekt im Modell abgebildet wurden (Smith 2007, 408f). Im Folgenden wird zusammenfassend für beide Aspekte der Begriff Evaluation verwendet. Wird keine Evaluation durchgeführt, kann nicht sichergestellt werden, dass die aus der Lösung des Performance-Modells resultierenden Ergebnisse in irgendeiner Relation zum modellierten System stehen. Daher sollte nach der Erstellung des Modells stets zunächst eine Evaluation durchgeführt werden. In der Regel erfolgt diese iterativ, d.h. es wird eine Evaluation vorgenommen, welche wiederum als Grundlage für Änderungen am Modell dient, woraufhin eine erneute Evaluation durchgeführt werden muss, bis das Modell valide ist (Kounev 2005, 167). Die einfachste Möglichkeit der Evaluation ist, die Ergebnisse, die aus dem Performance-Modell gewonnen wurden, mit denen des realen Systems zu vergleichen (Kounev 2005, 144). Voraussetzung dafür ist, dass ein reales System existiert, auf dem Messungen durchgeführt werden können bei Systemen, die sich in der Entwicklung befinden, ist dies in der Regel nicht der Fall; dann muss auf Prototypen oder ältere Versionen des entwickelten Systems zurückgegriffen werden. Ist ein reales System vorhanden, sollten aber Messungen für einige repräsentative Workloads und Konfigurationen durchgeführt werden (Kounev 2006, 495; Lavenberg 1983, 10). Wurden sowohl die Ergebnisse des Performance-Modells als auch Messdaten eines Referenzsystems erhoben, kann der Vergleich dieser Daten auf vielfältige Weise geschehen; in der Praxis wird eine große Bandbreite an statistischen Methoden angewandt. Die Wahl der Methode hängt maßgeblich davon ab, für welchen Zweck das Performance-Modell erstellt wurde (Kobayashi/Mark 2009, 702). Häufig wird der Vergleich anhand des Mittelwertes einer vorher festgelegten Metrik durchgeführt, z.b. der mittleren Antwortzeit. Mittels statistischer Techniken wie der Varianzanalyse oder dem t-test kann daraufhin bestimmt werden, ob sich die Ergebnisse statistisch signifikant unterscheiden. Es können auch rigorosere Untersuchungen vorgenommen werden, die mehr als nur den Mittelwert einer Variable berücksichtigen; Beispiele für solche Methoden sind der Chi-Square-Test und der Kolmogorov-Smirnov-Test (Kobayashi/Mark 2009, 702), welche beide zu den Tests der Anpassungsgüte (engl. goodness-of-fit tests ) gehören. Auswahl notwendiger Daten Die PMWT werden den Vergleich von Modell- und Messergebnissen ebenfalls in Form des Model Evaluation Tool unterstützen. Allerdings wurde noch kein spezifisches Verfahren dazu 8

19 ausgewählt; jedoch ist es sinnvoll, dass alle Verfahren unterstützt werden, die auch in der Praxis gängig sind. Daher muss zunächst geklärt werden, welche statistischen Verfahren vorrangig für den Vergleich von Modell- und Messergebnissen in der wissenschaftlichen Praxis verwendet werden. Daraufhin kann bestimmt werden, welche Daten für die gängigen Verfahren benötigt werden und damit bei einer Übertragung von Ergebnissen an den Simulation Data Service mitberücksichtigt werden müssen. Zu diesem Zweck wurde ein Literaturreview durchgeführt, das eine Auswahl an wissenschaftlichen Publikationen im Bereich der Performance Prediction auf die verwendeten statistischen Verfahren hin untersucht. Dabei wurden die Literatur-Datenbanken Google Scholar, ACM Digital Library und IEEE Xplore mit den Stichworten software performance model prediction, software performance model evaluation, software performance model validation und ähnlichen Kombinationen durchsucht. Die dabei gefundenen Publikationen dienten weiterhin als Grundlage für die Suche nach ähnlichen Publikationen derselben Forschungsgruppen. Dies führte schließlich zu einer Auswahl von zwölf wissenschaftlichen Publikationen, welche eine Evaluation von Performance-Modellen mittels Vergleich von Ergebnissen beinhalten. Bei der Untersuchung fiel auf, dass viele Publikationen die Methodik bei der Evaluation nicht genau dokumentieren. Dies ist problematisch, da die Ergebnisse der Evaluation damit für andere Forscher nicht immer nachvollziehbar sind und sich nicht reproduzieren lassen (Georges et al. 2007, 59). In diesen Fällen wurde versucht, die verwendeten Verfahren aus den Ergebnissen zu erschließen. Die Ergebnisse der Untersuchung finden sich in Tabelle 1. Dabei kennzeichnet ein X, dass die angegebene Publikation das angegebene Verfahren verwendet; das Fehlen eines X kennzeichnet, dass die Publikation das Verfahren nicht verwendet bzw. die Anwendung des Verfahrens nicht dokumentiert wurde. A B C D E F G H I J K L Arithmetisches Mittel X X X X X X X X X Fehlerspanne X X X X X X X X Median X Quartile X Standardabweichung X X X Konfidenzintervall X X X Bestimmtheitsmaß X Histogramm / PDF 1 / CDF 2 X X X X Kolmogorov-Smirnov-Test X Tabelle 1: Statistische Verfahren in wissenschaftlichen Publikationen Quelle: Eigene Erhebung 3 1 Probability Density Function, dt. Dichtefunktion 2 Cumulative Distribution Function, dt. Verteilungsfunktion 3 A: Noorshams et al. (2013); B: Kounev (2005); C: Koziolek et al. (2007); D: Becker et al. (2009); E: Brosig et al. (2009); F: Chen et al. (2005); G: Franks et al. (2009); H: Gilly et al. (2012); I: Snavely et al. (2002); J: Wu (2003); K: Gradl (2012); L: Mayer (2013) 9

20 Aus der Tabelle ist ersichtlich, dass ein sehr großer Teil der Publikationen den Vergleich mithilfe des arithmetischen Mittels durchführt, d.h. es werden die Mittelwerte einer oder mehrerer Performance-Metriken direkt miteinander verglichen. Dies wird häufig ergänzt durch die Angabe einer Fehlerspanne (engl. margin of error ). Die anderen Verfahren wie die Angabe von Konfidenzintervallen oder die Durchführung von Tests der Anpassungsgüte werden nur vereinzelt durchgeführt. Einzig der Vergleich von Histogrammen, Dichte- oder Verteilungsfunktionen wird etwas häufiger durchgeführt; die formalisierte Variante in Form des Kolmogorov-Smirnov-Tests wurde allerdings nur einmal dokumentiert. Fasst man die tiefergehentiefergehenden Verfahren zusammen, wird jedoch in mehr als der Hälfte der Publikationen ein Verfahren eingesetzt, welches über die Berechnung des arithmetischen Mittels hinausgeht. Als erstes Ergebnis lässt sich somit festhalten, dass die Mehrheit der Publikationen tiefergehende Analysen in irgendeiner Form durchführt, die Art der Analyse variiert jedoch relativ stark. Ein kleiner Teil der Publikationen führt Validierungen lediglich mithilfe des arithmetischen Mittelwerts ohne die Anwendung weiterer Verfahren durch; für eine statistisch rigorose Untersuchung wird jedoch zumindest die Bildung von Konfidenzintervallen empfohlen (Georges et al. 2007, 65f). Ohne die Angabe eines Konfidenzintervalls kann das Ergebnis einer Simulation erheblichen Ungenauigkeiten aufgrund statistischer Schwankungen unterliegen (Sauer/MacNair 1983, 56). Aufgrund dieser Tatsachen sollten die PMWT Verfahren wie die Bildung von Konfidenzintervallen oder die Durchführung von Tests der Anpassungsgüte ebenfalls unterstützen. Die Voraussetzung dafür ist, dass alle Simulationsergebnisse übertragen werden. Damit ist eine Reduktion der Ergebnisdaten auf Teile oder gar nur Mittelwerte bestimmter Metriken nicht sinnvoll. In diesem Zusammenhang ergibt sich weiterhin die Frage, ob es reicht, bspw. nur die Antwortzeiten zu übertragen, da die anderen Performance-Metriken in der Praxis vielleicht nicht analysiert werden. Daher wurde zusätzlich zur Untersuchung der verwendeten statistischen Verfahren ebenfalls eine Analyse der Publikationen im Hinblick auf die untersuchten Performance-Metriken durchgeführt. Die Ergebnisse dieser Untersuchung finden sich in Tabelle 2; die Matrix ist analog zu interpretieren wie Tabelle 1. A B C D E F G H I J K L Antwortzeiten X X X X X X X X X X X Ressourcennutzung X X X X X Durchsatz X X X X Tabelle 2: Performance-Metriken in wissenschaftlichen Publikationen Quelle: Eigene Erhebung Es ist offensichtlich, dass die Antwortzeiten als wichtigste Metrik angesehen werden, da sie fast ausnahmslos untersucht wurden. Im Vergleich dazu werden Ressourcennutzung und Durchsatz wesentlich seltener in die Betrachtung miteinbezogen; betrachtet man sie jedoch zusammen, kann auch hier festgehalten werden, dass zumindest eine der beiden Metriken in der Mehrheit der Publikationen untersucht wurde. Damit sollten auch diese Metriken, sofern sie in den Simulationsergebnissen vorhanden sind, an den Simulation Data Service übertragen werden. 10

21 Zusammenfassend kann gesagt werden, dass alle Ergebnisdaten, die bei einer Simulation entstehen, übertragen werden sollten, um eine statistisch gesicherte Evaluation der Performance- Modelle durchführen zu können. Neben den Performance-Metriken bezieht sich das vor allem auch auf die Werte der Metriken; diese sollten nicht nur im Mittel oder in Teilen, sondern in ihrem kompletten Zeitverlauf übertragen werden. Workload Bedeutung von Workload Eine wichtige Eigenschaft von Performance-Modellen, die bisher noch nicht betrachtet wurde, ist der Workload. Der Workload beschreibt die Last, mit welcher ein Computer-System durch die Anfragen, die daran gerichtet werden, belastet wird (Menascé et al. 1994, 76). Es gibt verschiedene Workload-Parameter, welche bei der Belastung des Systems eine Rolle spielen einer der wichtigsten Parameter ist die Anzahl der User, die gleichzeitig auf das System zugreifen. Andere Faktoren sind aber ebenfalls von Bedeutung, z.b. auf welche Teile des Systems ein Nutzer konkret zugreift. Jede Funktion des Systems verursacht eine andere Last; daher spielt das Nutzerverhalten ebenfalls eine zentrale Rolle bei der Beschreibung von Workload. Für die Evaluation von Performance-Modellen spielt der Workload eine besonders wichtige Rolle. Denn bei der Evaluation werden, wie bereits beschrieben, Modell- und Messergebnisse miteinander verglichen. Es macht jedoch keinen Sinn, Modellergebnisse, welche bei einer Belastung mit 100 Nutzern entstanden sind, mit Messergebnissen, welchen ein Workload von 1000 Nutzern zugrunde lag, zu vergleichen. Wenn der Workload der beiden Ergebnisse nicht derselbe ist, sind die Ergebnisse nicht vergleichbar und eine Evaluation damit nicht möglich. Daher ist neben den Ergebnisdaten für jedes Simulationsergebnis auch der Workload festzuhalten, der Grundlage dieser Ergebnisse war; nur so kann festgestellt werden, ob zwei Ergebnisse vergleichbar sind. Dabei tritt allerdings das Problem auf, dass ein Vergleich von Workloads schwierig ist, wenn diese qualitative Größen wie das Nutzerverhalten beinhalten. Aus diesem Grund muss zunächst eine quantifizierbare Definition von Workloads erfolgen. Workload im Palladio Component Model Um eine eigene Workload-Definition zu erstellen, wird zunächst betrachtet, wie Workload in PCM behandelt wird. In PCM wird das sog. Usage Model verwendet, um den Workload eines Systems zu beschreiben. Das Usage Model enthält mindestens ein UsageScenario. Dieses besteht aus zwei Komponenten: dem ScenarioBehaviour, das das Verhalten der Nutzer beschreibt, und den sog. Intensitätsparametern, welche im Modell als Workload bezeichnet werden (Becker et al. 2007, 57). Die Beschreibung des Nutzerverhaltens erfolgt mithilfe von modifizierten UML Aktivitätsdiagrammen, welche neben den Funktionen, die ein Nutzer aufruft, auch die Wahrscheinlichkeit, mit welcher er dies tut, beinhalten (Reussner et al. 2007, 69). Damit können auch komplexe Verhaltensmuster abgebildet werden. Die Art der Intensitätsparameter wird von der Klassifizierung des Workloads bestimmt. Im Allgemeinen werden Workloads wie folgt klassifiziert: 11

22 - Offene Workloads sind durch eine Arrival-Rate, welche üblicherweise als λ bezeichnet wird, gekennzeichnet. Diese drückt aus, wie viele Nutzer auf das System pro Zeiteinheit zugreifen (Kounev 2005, 136). - Geschlossene Workloads haben im Gegensatz dazu eine fixe Population, welche ausdrückt, wie viele Nutzer gleichzeitig auf das System zugreifen. Zusätzlich haben sie eine Think Time, welche ausdrückt, wie lange ein Nutzer im Schnitt wartet, bevor er eine neue Anfrage an das System schickt (Kounev 2005, 136). In Abbildung 4 ist ein Beispiel für ein einfaches PCM Usage Model zu sehen. Abbildung 4: Beispielhaftes PCM Usage Model Quelle: Eigene Darstellung Das in der Abbildung dargestellte Modell enthält ein UsageScenario mit dem Namen Dealerships-Driver Workload. In dem rechten Kasten ist der Workload dargestellt; in diesem Fall handelt es sich um einen geschlossenen Workload mit einer Population von Nutzern und einer Think Time von 9,7 Sekunden. Links davon ist das ScenarioBehaviour abgebildet. Der Nutzer wird darin so charakterisiert, dass er zufällig auf eine von drei verschiedenen Funktionen zugreift: die Funktion idealerdriver.browse ruft er mit einer Wahrscheinlichkeit von 50% auf, die Funktionen idealerdriver.purchase und idealerdriver.manage mit Wahrscheinlichkeiten von jeweils 25%. Definition von Workload Wie in der Workload-Definition des PCM Usage Models zu sehen ist, reicht es, einen Workload neben der Intensität durch das Verhalten der Nutzer zu charakterisieren. Während die Intensitätsparameter in dieser Form auch in anderen Modellen enthalten sind oder gemessen werden können, ist dies beim Nutzerverhalten nicht so einfach. Zwar ist eine Umwandlung von anderen Workload-Modellen oder Messergebnissen in das PCM Usage Model theoretisch denkbar, es erfordert aber jeweils einen immensen Aufwand. Aus diesem Grund ist es sinn- 12

23 voll, eine eigene Definition von Workload zu erstellen, in welcher das Nutzerverhalten auf die wesentlichen Komponenten reduziert repräsentiert wird. Diese selbsterstellte Definition wird im Folgenden vorgestellt. Sie entspricht dabei insofern der Definition des PCM Usage Models, als dass sich der Workload durch die Intensitätsparameter und das Nutzerverhalten abbilden lässt. Das Nutzerverhalten wird allerdings reduziert auf die Anzahl der Systemfunktionen und der Häufigkeit, mit der diese aufgerufen werden. Das dazugehörige Klassendiagramm dieser Definition ist in Abbildung 5 dargestellt. Abbildung 5: Klassendiagramm der Workload-Definition Quelle: Eigene Darstellung Im linken Teil des Diagramms finden sich die Intensitätsparameter des Workloads wieder. So gehört zu jedem Modell genau ein Workload; dieser ist entweder ein offener oder ein geschlossener Workload. Offene Workloads werden durch eine arrivalrate gekennzeichnet, während geschlossene Workloads durch eine population und eine thinktime charakterisiert werden. Neben diesen fixen Parametern, die in der Regel aus dem Modell entnommen werden können, findet sich rechts davon die Repräsentation des Nutzerverhaltens. Demnach besteht ein Workload aus einer gewissen Anzahl an Systemfunktionen. Systemfunktionen sind in diesem Zusammenhang Funktionen, welche der Nutzer selbst aufruft; die Definition schließt explizit Funktionen aus, welche nicht direkt durch den Benutzer aufgerufen werden. Im Modell dient die Klasse Systemfunktion dabei lediglich dazu, die Anzahl der Aufrufe, die diese spezifische Funktion im gesamten Simulationszeitraum erfahren hat, zu speichern. Dies erfolgt durch die Komposition mit der Klasse Batch; die Aufteilung in Batches dient dabei der Beschreibung des zeitlichen Verlaufs der Systemaufrufe. So besteht ein Batch aus einer batchtime und einem batchcount. Im Attribut batchcount wird die Anzahl der Aufrufe gespeichert, die die Systemfunktion zum Zeitpunkt batchtime erfahren hat. So ist die gesamte Zahl der Aufrufe, die eine bestimmte Systemfunktion erfahren hat, durch die Summe der batchcounts aller der Systemfunktion zugeordneten Batches definiert. Als Verdeutlichung diene folgendes Beispiel: ein System biete dem Nutzer die drei Funktionen browse, purchase und manage. Es wurde eine Simulation mit einer Simulationszeit 13

24 von drei Sekunden durchgeführt. Nach der Simulation wird die Zahl der Aufrufe der drei Funktionen gezählt; das Ergebnis der Zählung findet sich in Tabelle 3. Zeitabschnitt 1 Zeitabschnitt 2 Zeitabschnitt 3 Summe browse purchase manage Tabelle 3: Beispielhafte Zahl von Systemaufrufen Quelle: Eigene Darstellung Aus der Tabelle lässt sich entnehmen, dass die Funktion browse im Zeitabschnitt 1 genau Mal aufgerufen wurde, während die Funktionen purchase und manage im selben Zeitraum jeweils nur halb so oft aufgerufen wurden. Betrachtet man die Summe der Aufrufe, lassen sich Wahrscheinlichkeiten analog zu den stochastischen Ergänzungen des PCM Usage Models ausdrücken: die Funktion browse wird mit einer Wahrscheinlichkeit von 50% aufgerufen, während die Funktionen purchase und manage nur mit jeweils 25-prozentiger Wahrscheinlichkeit aufgerufen werden. Die Aufteilung in Zeitabschnitte dient als zusätzliches Unterscheidungskriterium, wenn zwei Verteilungen sich zwar in der Summe der Aufrufe ähneln, aber im Zeitverlauf unterscheiden. So wäre eine Verteilung, bei der browse in den drei Zeitabschnitten die Aufrufe 5.000, und erfahren hätte, zwar in Summe identisch mit der obigen Verteilung, dennoch läge dieser Verteilung ein anderes Nutzerverhalten und damit ein anderer Workload zugrunde. Statt nur die Summe zu betrachten, werden daher auch Batches mit dem Zeitverlauf der Aufrufe gespeichert, um derartige Unterscheidungen treffen und den Vergleich verbessern zu können. Nachfolgend ist in Abbildung 6 ein Objektdiagramm dargestellt, welches beschreibt, wie das obige Beispiel gemäß dem Klassendiagramm aus Abbildung 5 repräsentiert werden würde. Dem geschlossenen Workload, welcher zwei beliebige Intensitätsparameter enthält, ist eine Systemfunktion zugeordnet, welche der Funktion browse aus dem obigen Beispiel entspricht. Die Funktionen purchase und manage sowie das Modell-Objekt sind der Übersichtlichkeit halber in dieses Diagramm nicht dargestellt. Der Systemfunktion sind schließlich drei Batches zugeordnet, welche den drei Zeitpunkten des obigen Beispiels entsprechen. Abbildung 6: Beispielhaftes Objektdiagramm der Workload-Definition Quelle: Eigene Darstellung 14

25 Dieser Ansatz zur Repräsentation von Workload hat den Vorteil, dass er unabhängig vom jeweiligen Workload-Modell ist. Die Anzahl der Aufrufe lässt sich generell bei jeder Art von Performance-Ergebnisdaten feststellen, unabhängig davon, ob diese durch eine Simulation oder eine Messung entstanden sind. Zudem ist die Bestimmung vergleichsweise einfach, da keine komplizierten Berechnungen durchgeführt werden müssen, um das Nutzerverhalten zu bestimmen. Jedoch muss zuerst nachgewiesen werden, dass dieser Ansatz zur Repräsentation von Workloads auch wirklich funktioniert. Daher wird in den nächsten Abschnitten die Validierung dieser Definition durchgeführt. Kolmogorov-Smirnov-Test Im Folgenden muss nachgewiesen werden, dass eine Definition des Workloads mittels Intensitätsparametern und Nutzerverhalten, welches durch die Anzahl der Systemaufrufe im zeitlichen Verlauf beschrieben wird, einen Workload identifiziert und damit den Vergleich von Workloads zulässt. Zu diesem Zweck werden mehrere Simulationen mit jeweils unterschiedlichen Workloads durchgeführt, und anschließend verglichen, ob sich die gemessenen Workloads statistisch signifikant unterscheiden. Zur Untersuchung der Ähnlichkeit der Workloads wird der Kolmogorov-Smirnov-Test eingesetzt, welcher nachfolgend beschrieben wird. Der Kolmogorov-Smirnov-Test wurde von Kolmogorov (1933) erstmals in einem italienischen Journal-Artikel veröffentlicht und später von Smirnov (1936) durch Berechnung wichtiger Tabellenwerte verbessert. Obwohl die ursprüngliche Arbeit die Verwendung als Test nicht vorsah, bildete sie die Grundlage für die Entwicklung von Tests der Anpassungsgüte, welchen die empirische Verteilungsfunktion zugrunde liegt (Stephens 1992, 5f). Dabei ist die empirische Verteilungsfunktion, auch Summenhäufigkeit genannt, definiert als ( ) Formel 1: Empirische Verteilungsfunktion Quelle: (Dehling/Haupt 2004, 197) Für zwei unabhängige Stichproben der Größe n respektive m nehme man an, dass F n (x) und G m (x) deren empirische Verteilungsfunktionen sind. Zusätzlich sei D m,n die größte absolute Differenz zwischen den Funktionen F n (x) und G m (x), also: ( ) ( ) Formel 2: Kolmogorov-Smirnov-Statistik für zwei Stichproben Quelle: (Stephens 1992, 7) Dann gilt die Nullhypothese, nach welcher beide Stichproben derselben Population entstammen, als angenommen, wenn gilt: ( ) ( ) ( ) ( ) Formel 3: Kolmogorov-Smirnov-Test für zwei Stichproben Quelle: (Stephens 1992, 4-7; Smirnov 1948, 279) 15

26 Die Werte für Φ(λ) sind dabei tabellarisch festgehalten; für ein Signifikanzniveau von 5% hat Φ(λ) den Wert 1,36 (Smirnov 1948, 280). Mithilfe dieses Tests kann festgestellt werden, ob sich zwei Stichproben statistisch signifikant unterscheiden. Wenn im Folgenden die beiden Workloads zweier Simulationen miteinander verglichen werden sollen, wird dieser Test für jede Systemfunktion der beiden Workloads durchgeführt; wird die Nullhypothese bei mindestens einer der Systemfunktionen verworfen, so wird davon ausgegangen, dass die Workloads sich unterscheiden, ansonsten gehören die Workloads derselben Population an. Validierung der Definition Nachfolgend wird die Validierung der Definition aus Abschnitt durchgeführt. Dazu werden mithilfe der Palladio-Bench mehrere Simulationen mit unterschiedlichen Workloads durchgeführt; anschließend wird für jedes Simulationsergebnis der Workload gemäß der Workload-Definition aus dem vorherigen Abschnitt gebildet, und schließlich mithilfe des Kolmogorov-Smirnov-Tests untersucht, ob die Workloads sich statistisch signifikant unterscheiden. Dabei werden sowohl Ergebnisse, die demselben Workload zugrunde liegen, als auch Ergebnisse unterschiedlicher Workloads verglichen. Wenn die verwendete Workload- Definition valide ist, dann ist zu erwarten, dass sich Ergebnisse mit demselben Workload nicht statistisch signifikant unterscheiden, während der Vergleich von Ergebnissen unterschiedlicher Workloads einen Unterschied mit statistischer Signifikanz nachweisen sollte. Neben diesem einfachen Vergleich soll geprüft werden, ob bei Ergebnissen, bei denen derselbe Workload, aber eine unterschiedliche Laufzeit zugrunde liegt, die Nullhypothese ebenfalls angenommen wird. Dafür wird jede Simulation mit drei unterschiedlichen Laufzeiten durchgeführt, und schließlich jedes Simulationsergebnis mit jedem anderen Simulationsergebnis verglichen. Zudem wird jede Simulation zwei Mal durchgeführt, um prüfen zu können, ob der Vergleich auch bei Ergebnissen funktioniert, welchen derselbe Workload und dieselbe Laufzeit zugrunde liegen. Als Grundlage für die Simulationen dient ein PCM-Modell des Benchmarks SPECjEnterprise 2010, dessen Usage Model bereits in Abbildung 4 vorgestellt wurde. Für den Kolmogorov- Smirnov-Test wurde das Signifikanzniveau 5% gewählt; damit wird die Nullhypothese akzeptiert, und die Workloads sind gleich, wenn der errechnete Wert bei jeder Systemfunktion unter 1,36 liegt. Jeder Simulationsdurchlauf wird, wie oben erläutert, variiert in Bezug auf die Laufzeit und den zugrundeliegenden Workload. Die Laufzeiten wurden auf Messungen (abgekürzt als 10k), Messungen (20k) und Messungen (600k) festgelegt. Es werden zwei verschiedene Workloads verwendet; während die Intensitätsparameter bei beiden gleich sind (Population von Nutzern und Think Time von 9,7 Sekunden), ist das Nutzerverhalten jeweils leicht unterschiedlich, wie in Tabelle 4 zu sehen ist. Workload 1 (WL1) Workload 2 (WL2) browse 50% 60% purchase 25% 20% manage 25% 20% Tabelle 4: Für die Validierung verwendete Workloads Quelle: Eigene Darstellung 16

27 Die Ergebnisse der Untersuchung sind in Tabelle 5 zu sehen, angegeben ist jeweils das Maximum der Testdurchläufe aller Systemfunktionen. Bei grün unterlegten Feldern wurde die Nullhypothese wie erwartet angenommen; bei rot unterlegten Feldern wurde die Nullhypothese wie erwartet abgelehnt; und bei gelb unterlegten Feldern wurde die Nullhypothese wider Erwarten angenommen oder abgelehnt. WL1 WL2 10k 20k 600k 10k 20k 600k WL1 10k 0,47 20k 1,48 0,62 600k 3,82 3,43 0,81 WL2 10k 1,30 2,26 4,85 0,56 20k 1,53 2,56 6,58 1,42 0,76 600k 3,83 4,31 24,30 4,41 3,79 0,79 Tabelle 5: Ergebnisse des KS-Tests für , und Messungen Quelle: Eigene Erhebung Bei Betrachtung der Ergebnisse fällt zunächst auf, dass die Unterscheidung der Workloads 1 und 2 in acht von neun Fällen (rote Felder) funktioniert hat. In einem Fall wurde die Nullhypothese fälschlicherweise angenommen, der errechnete Wert lag jedoch nur knapp unter dem kritischen Wert von 1,36. Anders sieht es hingegen aus, wenn dieselben Workloads verglichen wurden; hier wurde die Nullhypothese ausschließlich akzeptiert, wenn die Laufzeiten der Simulationen identisch waren (grüne Felder). Damit wurde derselbe Workload nur in sechs von zwölf Fällen richtig erkannt. Wenn die Laufzeiten identisch waren, lag der Vergleichswert jedoch immer deutlich unter dem kritischen Grenzwert. Bei näherer Untersuchung der Werte lässt sich zusätzlich zu den bereits getroffen Beobachtungen ein deutliches Gefälle feststellen. Betrachtet man nur die roten Felder, so sieht man, dass die Werte sowohl von links nach rechts als auch von oben nach unten hin zunehmen; der höchste Wert steht in der Ecke rechts unten. Die Äquivalenz von Workload 1 und Workload 2 bei jeweils Messungen wird mit 24,3 sehr deutlich abgelehnt, während die Nullhypothese akzeptiert wird, wenn identische Workloads mit jeweils Messungen miteinander verglichen werden. Dies deutet darauf hin, dass der Test mit zunehmender Stichprobengröße empfindlicher auf Unterschiede reagiert. Betrachtet man die gelben Felder, so kann schließlich noch festgehalten werden, dass die Nullhypothese am stärksten abgelehnt wird, wenn der Unterschied in den Laufzeiten am größten ist. Das fälschliche Akzeptieren oder Ablehnen der Nullhypothese bei niedrigen Laufzeiten sowie das Gefälle innerhalb der verschiedenen Bereiche deuten darauf hin, dass die niedrigen Laufzeiten die Ursache für die hohe Fehlerquote ist. In der Tat spielt bei Simulationen mit derart kurzen Laufzeiten ein Phänomen eine Rolle, welches in der Literatur als Ramp-Up - oder Start-Up -Phase bezeichnet wird (Georges et al. 2007, 65; Kounev 2005, 140). Demnach schwankt die Performance eines Systems stark, wenn das System gestartet wird, während sich nach einiger Zeit ein gewisses Gleichgewicht einstellt; daher sollten Messungen erst durchgeführt werden, wenn sich das System in einem stabilen Zustand befindet (Kounev 2005, 140). 17

28 Alternativ kann ein gewisser Teil der Messungen verworfen werden, um sicherzugehen, dass alle Messungen sich auf die stabile Performance des Systems beziehen. Da es in der Praxis oft nicht ganz einfach ist, festzustellen, ab wann sich das System in einem stabilen Zustand befindet, und da die Ramp-Up-Phase der Simulationsläufe unterschiedlich lang sein kann, werden an dieser Stelle keine Messungen verworfen. Stattdessen wird die Validierung ein zweites Mal durchgeführt, jedoch dieses Mal mit längeren Simulationslaufzeiten. Dies verringert den Einfluss der Ramp-Up-Phase auf das Ergebnis, da sie einen geringeren Anteil an der Gesamtlaufzeit hat, sodass mit einer Verbesserung der Ergebnisse durch längere Laufzeiten zu rechnen ist. Für die zweite Validierung wurden die Laufzeiten auf Messungen (abgekürzt als 600k), Messungen (900k) und Messungen (1200k) festgesetzt. Die Workloads entsprechen denen aus dem ersten Durchlauf. Das Ergebnis ist in Tabelle 6 zu sehen. WL1 WL2 600k 900k 1200k 600k 900k 1200k WL1 600k 0,81 900k 0,84 0, k 0,79 1,13 1,31 WL2 600k 24,3 26,92 28,63 0,79 900k 26,23 29,67 31,87 1,04 0, k 27,71 31,75 34,19 1,23 0,75 0,79 Tabelle 6: Ergebnisse des KS-Tests für , und 1,2 Mio. Messungen Quelle: Eigene Erhebung Bei der zweiten Validierung ist das Ergebnis wie erwartet. Die Nullhypothese wird in 100% der Fälle jeweils korrekt akzeptiert oder abgelehnt. Betrachtet man die Werte genauer, fallen hier allerdings teilweise große Schwankungen auf. So liegt der Wert von (WL1, 1200k; WL1, 1200k) mit 1,31 nur sehr knapp unter dem kritischen Grenzwert; andererseits liegt der dazugehörige Wert von Workload 2 mit 0,79 jedoch deutlich unter der Schwelle. Ähnlich verhält es sich mit den Werten (WL1, 1200k; WL1, 600k) und (WL2, 1200k; WL2, 600k). Die naheliegendste Erklärung dafür ist, dass diese Unterschiede entweder durch die Ramp-Up-Phase verursacht werden oder als statistische Schwankungen einzustufen sind. Neben diesen Schwankungen ist in den grünen Bereichen jedoch kein eindeutiges Muster bzgl. der Laufzeiten erkennbar. Im roten Bereich ist dagegen immer noch das Gefälle vorhanden, welches auch schon während der ersten Validierung auftrat; die Stärke der Ablehnung nimmt mit der Zahl der Messungen zu. Fazit Als Fazit lässt sich festhalten, dass die Workload-Definition aus Abschnitt valide ist und damit als Grundlage für das Datenmodell dienen kann, welches im nächsten Kapitel erläutert wird. Der Kolmogorov-Smirnov-Test hat wie erwartet bei identischen Workloads die Nullhypothese akzeptiert, während dieselbe bei unterschiedlichen Workloads verworfen wurde. Damit ist der Kolmogorov-Smirnov-Test auch ein mögliches Verfahren zum Vergleich von Workloads in den PMWT; da auch dort nur der Vergleich von Ergebnissen mit demselben 18

29 Workload möglich sein soll, ist auch für die PMWT die Implementierung eines statistischen Verfahrens notwendig. Ohne genauere Untersuchungen ist es an dieser Stelle allerdings nicht möglich, sich auf ein Verfahren festzulegen oder eine Empfehlung auszusprechen. Dazu müssen zuerst andere statistische Verfahren untersucht und in Bezug auf ihre Eignung evaluiert werden. Wenn ein Vergleich mithilfe des Kolmogorov-Smirnov-Tests auch möglich erscheint, so kann die starke Ablehnung von unterschiedlichen Workloads, wie sie in Tabelle 5 und Tabelle 6 gut sichtbar ist, auch zu Problemen beim Einsatz als Vergleichswerkzeug führen. Es besteht die Vermutung, dass der Test die Nullhypothese generell ablehnen wird, wenn die Workloads nicht fast identisch und die Größe der Stichproben sehr hoch ist. Da die PMWT Mess- und Simulationsergebnisse vergleichen sollen, welche naturgemäß keine exakt identischen Workloads haben, kann ein so strikter Test das Werkzeug komplett unbrauchbar machen. Daher wird auch im Simulation Data Service zunächst keine Funktion implementiert, um für einen gegebenen Simulationslauf direkt ähnliche Simulationsläufe zu finden; zunächst müssen weitere Untersuchungen stattfinden, welche Aufschluss darüber geben werden, ob der Kolmogorov-Smirnov-Test für solche Zwecke geeignet ist. Neben der Validierung der Workload-Definition wurde in Abschnitt 3.2 mithilfe des Literaturreviews festgestellt, dass eine Reduzierung der Simulationsergebnisse auf bestimmte Metriken oder Teile der Daten nicht sinnvoll ist. Nachdem somit in diesem Kapitel geklärt wurde, welche Ergebnisdaten und welche Workloaddaten für eine statistisch korrekte Evaluation von Performance-Modellen notwendig sind, dienen diese Ergebnisse als Grundlage für das nächste Kapitel, in welchem untersucht wird, wie all diese Daten in einem einheitlichen Datenmodell repräsentiert werden können. 19

30 Datenaustausch zwischen einer Performance- Simulationsumgebung und einer Performance-Analyseplattform Repräsentation von Performance-Daten Referenzmodelle Im vorherigen Kapitel wurde untersucht, welche Daten für eine Evaluation von Performance- Modellen benötigt werden. In diesem Kapitel wird dieses Wissen genutzt, um ein Datenmodell zu entwickeln, welches sowohl Simulations- als auch Messergebnisse repräsentieren kann. Prinzipiell ist es möglich, ein von Grund auf neues Datenmodell für diesen Zweck zu erstellen. Es gibt jedoch bereits Datenmodelle, welche eigens zur Speicherung von Messdaten konzipiert und kreiert wurden und als Grundlage für ein eigenes Modell genutzt werden können. Derartige Modelle nennt man Referenzmodelle. Nach Becker/Schütte (1997, 428) ist ein Referenzmodell das immaterielle Abbild der in einem realen oder gedachten betrieblichen Objektsystem verarbeiteten Informationen, das für Zwecke des Informationssystem- und Organisationsgestalters Empfehlungscharakter besitzt und als Bezugspunkt für unternehmensspezifische Informationsmodelle dienen kann. Während der Bearbeitung wurden zwei spezifische Referenzmodelle identifiziert, welche als Grundlage zur Erstellung eines eigenen Datenmodells dienen können: das Common Information Model (CIM) und das Structured Metrics Metamodel (SMM). Nachfolgend werden beide Modelle beschrieben. Anschließend werden ihre jeweiligen Vor- und Nachteile erörtert, um schließlich eines der beiden Modelle für die weitere Verwendung auszuwählen. Common Information Model CIM wurde von der Distributed Management Task Force (DMTF) entwickelt, einer Normungsorganisation verschiedener IT-Unternehmen, welcher u.a. Microsoft, Intel und HP angehören. Der Standard als solcher wurde bereits 1998 veröffentlicht und ist ein konzeptuelles Informationsmodell, welches alle für das Management von Informationssystemen wichtigen Daten repräsentiert, unabhängig von einer spezifischen Implementierung (Distributed Management Task Force 2013a). CIM besteht aus einer Reihe von Schemata, welche jeweils unterschiedliche Teile von Informationssystemen beschreiben und über das Core-Schema miteinander verknüpft sind. Die neueste Version des Schemas, , wurde im August 2013 veröffentlicht (Distributed Management Task Force 2013b). Für die Darstellung von Messdaten gibt es ein sog. Metrics Schema; eine Darstellung des grundlegenden Konzepts und der wichtigsten Klassen ist in Abbildung 7 zu sehen, während das gesamte Schema in Anhang A.1 zu finden ist. Die zentrale Einheit des Schemas ist die sog. UnitOfWork. In der ursprünglichen Definition des Modells diente diese Klasse zur Repräsentation der Antwortzeiten von Transaktionen, jedoch wurde die Definition später allgemein auf jegliche Arbeit ausgeweitet, welche ein messbares Ergebnis liefert (Distributed Management Task Force 2003, 10). Im aktuellen Modell könnte eine Antwortzeit im Attribut elapsedtime gespeichert werden; wenn eine eigene Metrik definiert wurde (MetricDefinition), 20

31 so wird der Messwert in der Assoziationsklasse UoWMetric abgelegt. Jedes UnitOfWork- Element beinhaltet dabei nur einen Messwert; die zugehörige UnitOfWorkDefinition spezifiziert genauer, um was für einen Messwert es sich handelt und welchem LogicalElement er zugeordnet ist. Eine weitere zentrale Rolle spielt die Assoziation SubUoW, welche die Korrelation von UnitOfWork-Elementen erlaubt (Distributed Management Task Force 2003, 12). So kann bspw. die Antwortzeit des Aufrufs einer bestimmten Funktion von einer Datenbankabfrage abhängen, welche in dieser Funktion durchgeführt wird. In diesem Fall wäre die Datenbankabfrage dann eine SubUoW der ursprünglichen UnitOfWork. Diese Art der Verknüpfung ist jedoch nicht für die Abbildung von sequentiellen Abläufen gedacht (Distributed Management Task Force 2003, 13). Schließlich existieren noch LogicalElements, durch welche es möglich ist, die UnitOfWork-Elemente mehreren Anwendungsbereichen zuzuordnen; so könnte eine UnitOfWork für eine Datenbankabfrage in mehreren Funktionen verwendet werden. Abbildung 7: Grundlegender Ansatz von CIM Quelle: In Anlehnung an (Distributed Management Task Force 2003, 12) 21

32 Structured Metrics Metamodel SMM wurde von der Object Management Group (OMG) entwickelt, einem Konsortium, welches bereits erfolgreiche Standards wie UML oder Common Object Request Broker Architecture (CORBA) veröffentlicht hat. SMM wurde 2012 veröffentlicht und ist damit ein sehr junger Standard. Im Gegensatz zu CIM bezieht es sich lediglich auf die Repräsentation von Messdaten und geht nicht auf weitere Teilbereiche von Informationssystemen ein. Eine Darstellung des grundlegenden Ansatzes von SMM ist in Abbildung 8 zu sehen. Eine Übersicht aller Kernklassen von SMM findet sich in Anhang A.2. Abbildung 8: Grundlegender Ansatz von SMM Quelle: In Anlehnung an (Object Management Group 2012, 7) Eine Beobachtung, im Modell Observation, ist dabei das zentrale Element des Modells. Zu einer Beobachtung gehört eine gewisse Zahl an ObservedMeasures, also beobachtbare Werte, welche ein Measure eingenommen hat. Ein Measure ist dabei eine festgelegte Metrik, z.b. die Lines of Code eines Software-Projekts oder die Antwortzeit. SMM hat dabei ein ausgeprägtes Modell zur Repräsentation von Measures (vgl. Anhang A.3 und A.4), in welchem sich Metriken als Aggregation von Basismetriken darstellen lassen. Zusätzlich können die Measure- Definitionen um Berechnungsmethoden erweitert werden, welche in Skriptsprachen wie O b- ject Constraint Language (OCL) oder XQuery angegeben werden. Dadurch besteht die Möglichkeit, Metriken allein mithilfe des Modells zu berechnen. Neben Measures gibt es auch Measurements, also Messungen, welche als konkrete Ausprägung einer Metrik interpretiert werden können. Es gibt auch verschiedene Arten von Measurements, welche verschiedene Werte beinhalten können, je nachdem, zu welcher Measure sie gehören; einfache Fließkommazahlen können mittels DimensionalMeasurements abgebildet werden. Schließlich ist jeder Messung auch ein Messobjekt zugeordnet; in SMM kann dabei jedes Meta Object Facility (MOF) Objekt als Messobjekt verwendet werden. 22

33 Auswahl eines Referenzmodells Nachfolgend muss eines der beiden Modelle ausgewählt werden, um als Grundlage für die Entwicklung eines eigenen Datenmodells zu dienen. Zu diesem Zweck werden die Vor- und Nachteile der jeweiligen Modelle im Detail erörtert. CIMs größter Vorteil ist, dass es ein sehr alter Standard ist. Aufgrund seines hohen Alters hat CIM eine hohe Verbreitung in vielen Unternehmen gefunden, was die Portabilität des Modells begünstigt; zudem kann dadurch davon ausgegangen werden, dass der Standard erprobt ist. Das zentrale Element, UnitOfWork, passt sehr gut zu den Messergebnissen, welche im Rahmen von Simulationen erhoben werden. Diese bestehen aus einem Zeitpunkt, zu welchem die Messung durchgeführt wurde, und dem Messwert selbst; dies lässt sich in CIM durch die Attribute starttime und elapsedtime oder durch Verwendung der Klasse UoWMetric sehr gut abbilden. CIM hat jedoch auch einige Nachteile. Durch sein hohes Alter hat CIM mit der Zeit zahlreiche Erweiterungen erfahren, welche vorgenommen wurden, um weitere Elemente von Informationssystemen innerhalb desselben Modells darstellen zu können; daher ist das gesamte CIM-Schema recht groß. Die zentrale Klasse des CIM-Schemas, ManagedElement, besitzt dadurch ebenfalls eine sehr große Zahl an Assoziationen. Diese Assoziationen werden auch im Metrics Schema verwendet, da alle Klassen direkt oder indirekt von ManagedElement erben, sodass das Modell unnötig aufgebläht wird; hier müsste evtl. eine Reduzierung des Modells auf notwendige Elemente stattfinden. Und schließlich hat CIM den Nachteil, dass sich eine sequentielle Reihe von Messwerten nicht mit der eigenen SubUoW-Konstruktion abbilden lässt; alle Messwerte sind einem LogicalElement zugeordnet. Dieses hat jedoch nicht die Semantik eines Messdurchlaufs, welche benötigt wird, um Simulationsläufe zu speichern, sondern vielmehr die eines Messobjekts; daher müsste ein solches Konzept hinzugefügt werden. SMM besitzt den Vorteil, dass es einzig und allein für die Repräsentation von Messdaten konzipiert wurde. Dadurch ist SMM im Gegensatz zu CIM auch wesentlich kompakter. Zudem hat SMM den Vorteil, dass es das Konzept eines Messdurchlaufs, welches CIM fehlt, in Form der zentralen Observation-Klasse beinhaltet. In der Form der ObservationScope- Klasse bietet SMM bereits von Haus aus eine Möglichkeit, um das Modell, welches die Grundlage einer Messung war, zu speichern. Weiterhin ermöglicht es SMM, neue Metriken durch seine extensive Measure-Hierarchie zu definieren; dies ist zwar auch in CIM durch die Verwendung der MetricDefinition-Klasse möglich, durch die Möglichkeit der Definition von aggregierten Metriken ist SMM in dieser Hinsicht allerdings noch mächtiger. Gleichzeitig ist dies auch ein Nachteil von SMM, da die Möglichkeiten zur dynamischen Berechnung von Metriken und die detaillierte Repräsentation von Metrik-Definitionen in einem Datenmodell, wie es für diese Arbeit benötigt wird, nicht notwendig sind. Daher kann auf einen großen Teil dieser Klassen verzichtet werden. Eine wesentliche Einschränkung ist, dass SMM von Haus aus keine Möglichkeit bietet, einem Measurement einen Zeitpunkt zuzuordnen; diese Möglichkeit besteht bei SMM nur für Observations und müsste daher nachgerüstet werden. Ein weiterer Nachteil von SMM ist die Verwendung von MOF-Elementen an verschiedenen Stellen, z.b. bei der Repräsentation von Messobjekten; sofern nicht bereits MOF verwendet wird, führt dies zu zusätzlichen Abhängigkeiten. Und schließlich hat SMM den Nachteil, dass es ein sehr junger und bisher kaum verbreiteter Standard ist. 23

34 Nach Abwägung der diversen Vor- und Nachteile wurde die Verwendung von SMM als Grundlage für ein eigenes Datenmodell beschlossen. Neben der Tatsache, dass bis auf die Darstellung von Messzeitpunkten alle wesentlichen Konzepte bereits enthalten sind, hat hier besonders auch das junge Alter des Standards eine wesentliche Rolle gespielt. Denn dadurch bietet sich für diese Arbeit die Chance, die Eignung von SMM für die Repräsentation von Messergebnissen, welche durch Performance-Modelle generiert wurden, zu zeigen. Anpassung des Referenzmodells Während SMM zwar ein geeigneter Kandidat für die Verwendung als Datenmodell ist, muss das Datenmodell dennoch angepasst werden, um eine Repräsentation aller notwendigen Konzepte zu ermöglichen. Bei allen Anpassungen wurde versucht, diese mittels Vererbung durchzuführen und das ursprüngliche Datenmodell so wenig wie möglich zu verändern, um die Kompatibilität zur Standardausprägung des SMM beizubehalten. Das finale Datenmodell ist in Abbildung 9 zu sehen. Dabei sind die Klassen, welche mit einer diagonalen Schraffur versehen sind, Teile des SMM; alle anderen Klassen sind eigene Ergänzungen. In dem Modell nicht dargestellt ist die abstrakte Klasse SmmElement; diese ist die Wurzelklasse des Modells und direkt oder indirekt Oberklasse aller in dem Modell vorhandenen Klassen. Dadurch erhält jede Klasse des Modells eine eindeutige Identifikationsnummer, einen optionalen Namen und eine optionale Beschreibung sowie die Möglichkeit, die Klassen durch Attribute und Annotationen zu erweitern (Object Management Group 2012, 15f). Die erste Ergänzung des SMM stellen die Klassen TimeMeasure und TimeMeasurement dar. Diese dienen dazu, den Zeitpunkt, während der eine Measurement stattgefunden hat, festzuhalten. Vor der hier dargestellten Lösung mittels eigener Klassen wurde zunächst versucht, die DimensionalMeasurement-Klasse mittels einer Attribut-Klasse um diese Funktionalität zu erweitern; dadurch wurde die für die Persistierung der Daten benötigte Zeit jedoch um ein Vielfaches erhöht, sodass eigene Klassen von DimensionalMeasurement abgeleitet wurden. Die Zeit wird dabei als Fließkommazahl im Attribut eventtime gespeichert. Eine zweite Ergänzung ist die Speicherung der Performance-Modelle. Es ist sinnvoll, zu jedem Simulationslauf gleichzeitig das Modell, welches die Ergebnisse erzeugt hat, zu speichern; dadurch ist später direkt ersichtlich, welche Modelle für welche Ergebnisse verantwortlich sind und es ermöglicht die einfache Wiederholung der Simulationen. Allerdings können die Modelle bisweilen sehr groß werden; daher sollte die redundante Persistierung der Modelle vermieden werden. Zu diesem Zweck wurde zunächst eine Klasse HashScope von ObservationScope abgeleitet, welche ein Performance-Modell eindeutig durch einen Hash identifiziert. Damit kann vor einer Persistierung geprüft werden, ob das Modell bereits vorhanden ist. Daraufhin wurde schließlich die konkrete Klasse PCMModelScope von HashScope abgeleitet, welche die einzelnen Elemente eines PCM-Modells persistiert. Diese sind das Usage Model, das Allocation Model, das System Model sowie die Resource Environment; dazu kommen noch mehrere Repository Modelle. Die Modelle, welche in PCM EMF-Objekte vorliegen, werden durch den Client in Extensible Markup Language (XML) umgewandelt und in der Datenbank als Character Large Objects (CLOB) persistiert. Wenn der Simulation Data Service um die Unterstützung für weitere Simulationswerkzeuge nachgerüstet wird, müssen entsprechend zusätzliche Klassen von HashScope oder ObservationScope abgeleitet werden, um die neuen Modelle darstellen zu können. 24

35 Abbildung 9: Datenmodell des Simulation Data Service Quelle: In Anlehnung an (Object Management Group 2012) 25

36 Die dritte Ergänzung des SMM ist die Repräsentation des Workloads. Wie in Kapitel 3 festgestellt wurde, muss zu jedem Simulationsdurchlauf auch der Workload festgehalten werden, der die Ergebnisse verursacht hat. Das Modell für die Repräsentation des Workloads wurde bereits in Abschnitt vorgestellt; bis auf die Umbenennung der Klasse Systemfunktion in EntryLevelSystemCall ist dieses Modell so exakt im Datenmodell des Simulation Data Service wiederzufinden. Allerdings wurde zusätzlich eine Trennung zwischen gemessenem Workload und modelliertem Workload vorgenommen. Denn während die Intensitätsparameter direkt dem Performance-Modell entnommen werden können und daher mit einer Assoziation zum ObservationScope an das Modell angebunden werden können, ist die zeitliche Verteilung der Aufrufe der Systemfunktionen, welche in der Workload-Definition durch die Batches dargestellt werden, nicht an das Performance-Modell gebunden. So können verschiedene Simulationsdurchläufe eine unterschiedliche Verteilung der Batches vorweisen, auch wenn ihnen dasselbe Modell zugrunde liegt, da der Workload gemessen wurde. Daher befindet sich der gemessene Workload auf der anderen Seite des Datenmodells, abgeleitet von der Klasse NamedMeasurand. Ein NamedMeasurand ist dabei von MofElement abgeleitet. Diese Klasse wurde nicht in Measurand umbenannt, um nicht zu stark vom ursprünglichen Modell abzuweichen, auch wenn kein MOF zur Repräsentation der Messobjekte verwendet wird. In der restlichen Arbeit wird jedoch von Measurand gesprochen. Die letzte Anpassung des Datenmodells betrifft die Klasse MofElement selbst. Diese ist in der Spezifikation des SMM der Klasse Measurement zugeordnet; im Datenmodell des Simulation Data Service ist sie stattdessen der Klasse ObservedMeasure zugeordnet. Dies ist die einzige Anpassung, bei welcher das Datenmodell der SMM-Spezifikation nicht erweitert, sondern geändert wurde. Daher weist die Klasse MofElement in der Abbildung auch eine andere Schraffur auf. Der Grund für diese Anpassung ist, dass bei einer Assoziation zu Measurement die Performance des implementierten Systems wesentlich gemindert wurde. Dies hängt mit der hohen Zahl an Messungen zusammen, welche durch einen einzelnen Simulationsdurchlauf erzeugt werden. Wird in der Palladio-Bench bspw. eine Simulation gestartet, welche nach Messungen abgebrochen wird, so enthält das Endergebnis in Summe über 1 Mio. Measurements; in der Praxis ist die Zahl der Messungen in der Regel noch wesentlich höher. Wird zu jeder dieser Measurements ein Measurand gespeichert, so wird die Anzahl der Felder, die in die Datenbank eingefügt werden müssen, verdoppelt. Zudem wird der Measurand bei der Übertragung der Daten jeder Measurement hinzugefügt; wenn die Messungen einer ObservedMeasure sich aber alle auf denselben Measurand beziehen, wird damit die Übertragung unnötig verzögert. Neben der Performance bei der Übertragung und beim Einfügen neuer Daten in die Datenbank erschwerte diese Konstruktion auch Abfragen in der Datenbank. Sollen bspw. alle EntryLevelSystemCalls einer Observation abgefragt werden, muss bei der Konstruktion gemäß der Spezifikation die komplette Reihe an Messungen auf mögliche EntryLevelSystemCall-Objekte untersucht werden. Eine solche Abfrage bei einem Simulationsdurchlauf mit einer Größe von Messungen benötigte daher mehr als zehn Sekunden. Durch die Änderung der Assoziation wird die Performance wesentlich verbessert, dieselbe Abfrage benötigte daraufhin weniger als eine Sekunde. Muss eine Instanz des Datenmodells standardmäßig vorliegen, ist immer noch eine einfache Umwandlung in das Referenzmodell 26

37 möglich; daher wurde beschlossen, die Änderung des Referenzmodells in Kauf zu nehmen und die Klasse MofElement stattdessen der Klasse ObservedMeasure zuzuordnen. Damit sind schließlich alle notwendigen Konzepte im Datenmodell enthalten. Somit ist es nun geeignet, um sowohl Simulationsergebnisse als auch die Performance-Modelle sowie den Workload, welche diese Ergebnisse erzeugt haben, zu repräsentieren. Das entwickelte Datenmodell dient als Grundlage der Datenbank und wird mittels Java Persistence API (JPA) implementiert; wie dies im Detail funktioniert, wird in Kapitel 5 näher erläutert. In den vorangegangenen Kapiteln wurde untersucht, welche Daten für einen Vergleich von Simulations- und Messergebnissen notwendig sind und wie diese in einem einheitlichen Datenmodell repräsentiert werden können. Da diese Fragen nun geklärt sind, muss schließlich noch ein Weg gefunden werden, um die Daten optimal vom Client zum Server übertragen zu können. Dies wird im folgenden Abschnitt untersucht. Übertragung von Performance-Daten Wahl eines Web Services In diesem Kapitel wird untersucht, welche Möglichkeiten es bei der Übertragung von Daten von einem Client zu einem Server gibt. Der Server soll dabei als Web Service realisiert werden; daher werden unterschiedliche Web Services untersucht und gegeneinander abgewogen. Wie in Abschnitt 2.2 bereits erläutert, wird der JBoss Application Server 7 als Java EE-Server verwendet. Zur Übertragung soll ein Web Service verwendet werden; JBoss verwendet eine angepasste Version von Apache CXF für die Bereitstellung von Web Services. Apache CXF bietet sowohl die Java API for XML Web Services (JAX-WS) als auch die Java API for RESTful Web Services (JAX-RS), um Web Services bereitzustellen (Apache Software Foundation o.j.). Nachfolgend werden beide Alternativen kurz beschrieben. JAX-WS ist ein Standard zur Integration von Unternehmensanwendungen mithilfe von Web Services (Pautasso et al. 2008, 805). Zentrales Element jedes JAX-WS Web Services ist die Web Services Description Language (WSDL) Definition; WSDL ist eine auf XML aufbauende Beschreibungssprache zur syntaktischen Definition von Interfaces (Pautasso et al. 2008, 806). In dieser werden neben den Methoden, die ein Webservice bietet, auch alle Datenstrukturen beschrieben, die zur Benutzung des Services notwendig sind. Zur Übertragung der Daten wird bei JAX-WS SOAP verwendet. SOAP ist ein Netzwerkprotokoll, welches ebenfalls auf XML basiert; eine SOAP-Nachricht besteht aus einem Envelope, welcher aufgeteilt ist in einen Header und einen Body. Der Header kann Informationen enthalten, die für das Routing oder die Konfiguration verwendet werden können; der Body enthält den eigentlichen Payload (Pautasso et al. 2008, 806). Die Kommunikation zwischen Client und Server kann über Nachrichten geschehen, oder, was häufiger der Fall ist, in Form von Remote Procedure Calls (RPCs) (Pautasso et al. 2008, 805). Es gibt verschiedene Protokolle, welcher zur Übertragung von SOAP-Nachrichten verwendet werden können, der Standard ist jedoch der Einsatz des Hypertext Transfer Protocol (HTTP). JAX-RS verwendet Representational State Transfer (REST) zur Kommunikation zwischen Client und Server. REST ist ein Architekturstyle, in welchem es sehr viele Ressourcen gibt, 27

38 die alle durch einen eigenen Uniform Resource Identifier (URI) identifiziert werden, und auf jede dieser Ressourcen nur mit vier grundlegenden Operationen zugegriffen werden kann: PUT, POST, GET und DELETE (Zur Muehlen et al. 2005, 19). Damit erfolgt die Kommunikation ausschließlich über RPCs. Die Kommunikation ist dabei zustandslos, der Service verwaltet keine Sessions. Die Nutzdaten werden meistens als XML übertragen, es sind jedoch auch andere Formate wie JavaScript Object Notation (JSON) oder Multipurpose Internet Mail Extensions (MIME) möglich (Pautasso et al. 2008, 811). Als Übertragungsprotokoll kann jedoch nur HTTP verwendet werden. Beide Implementierungen werden häufig verwendet, und da ein quantitativer Vergleich der Konzepte schwierig ist, ist die Diskussion über ihre Eignung oft durch persönliche Meinungen und Erfahrungen gekennzeichnet (Pautasso et al. 2008, 805). JAX-RS gilt als leichtgewichtiger und auch einfacher, da es lediglich vier Operationen gibt, und im Gegensatz zu JAX-WS die aufwendige Interface-Definition entfällt (Zur Muehlen et al. 2005, 22). Zudem gilt SOAP, welches bei JAX-WS verwendet wird, als schwergewichtig, da der SOAP Envelope und die Beschreibung mittels XML einen großen Overhead erzeugen. Ein Vorteil von JAX-WS ist jedoch, dass es durch die vielfältigen Möglichkeiten bei der Definition von WSDLs flexibler ist und dadurch komplexe Operationen hinter einer Fassade verbergen kann; dies setzt allerdings wiederum voraus, dass der Client die verfügbaren Operationen und ihre Semantik schon vorher kennt (Zur Muehlen et al. 2005, 24). JAX-RS verfolgt damit ein etwas anderes Paradigma als JAX-WS. Bei JAX-RS werden die bereitgestellten Ressourcen durch die URIs ein Teil des Webs, welche sich durch die Links zwischen den Ressourcen erforschen lassen, wie dies beim World Wide Web üblich ist; dagegen versteht JAX-WS das Web ausschließlich als Kommunikationsmedium, welches als Tunnel verwendet wird, wodurch die Services aber außerhalb des Webs bleiben (Pautasso et al. 2008, 808; Zur Muehlen et al. 2005, 11). Primär aufgrund der größeren Flexibilität bei der Definition der Interfaces wird für die Erstellung des Simulation Data Service in dieser Arbeit JAX-WS verwendet. Eine Verwendung von JAX-RS wäre allerdings ebenso möglich gewesen. Die evtl. schlechtere Performance durch die Verwendung von SOAP ist, wie später gezeigt werden wird, vernachlässigbar. Definition des Service-Interfaces Da JAX-WS für die Implementierung des Services gewählt wurde, ist die Erstellung einer WSDL-Definition essentiell. Generell gibt es dabei zwei mögliche Vorgehensweisen: topdown und bottom-up (Pautasso et al. 2008, 809). Während bei einer top-down-vorgehensweise mit der Erstellung einer WSDL-Definition begonnen wird und daraus später ein Codeskelett generiert wird, wird bei einer bottom-up-vorgehensweise von einem bereits vorhandenen Interface ausgegangen, welches anschließend in eine WSDL-Definition übersetzt wird. Im Folgenden wird der bottom-up-ansatz verfolgt, daher wird mit der Erstellung eines Interfaces begonnen. Bei der Konzeption eines Interfaces für den Simulation Data Service wird zunächst, ausgehend vom Datenmodell aus Abschnitt 4.1.5, der Ablauf zur Persistierung einer Modellinstanz nachvollzogen. Ausgehend von diesem Ablauf können dann die Methoden, welche für eine 28

39 Realisierung des Ablaufs notwendig sind, abgeleitet werden. Nachfolgend ein möglicher Ablauf: 1. Da die Observation das zentrale Element des Modells ist, muss dieses als erstes angelegt werden; ohne Observation-Objekt haben die anderen Objekte des Datenmodells keine Referenz, auf welche sie sich beziehen können. 2. Als nächstes wird das Performance-Modell gespeichert und der Observation zugeordnet. Dieser Schritt kann alternativ auch am Ende erfolgen. Er besteht aus drei Teilen: a. Es wird anhand des im Client berechneten Hashwertes geprüft, ob das Modell schon im Persistenzkontext enthalten ist. b. Falls das Modell noch nicht vorhanden ist, wird das Modell übertragen und gespeichert. c. Falls das Modell bereits vorhanden ist, muss im Persistenzkontext eine Verknüpfung der angelegten Observation mit dem vorhandenen Modell erfolgen. 3. Daraufhin wird ein ObservedMeasure-Objekt angelegt und der Observation zugeordnet. Dieses enthält bereits Referenzen auf die verwendete Measure und den Measurand, welche somit mitübertragen werden. Dieser Schritt wird für jeden Measurand des Simulationsergebnisses wiederholt. 4. Schließlich wird ein Measurement-Objekt angelegt und dem ObservedMeasure-Objekt zugeordnet. Dieser Schritt wird für jedes Measurement-Objekt der ObservedMeasure wiederholt. Auf Grundlage dieses Ablaufs wurde ein Interface für den Simulation Data Service erstellt, welches in der nachfolgenden Abbildung 10 dargestellt ist. Jeder der obigen Ablaufpunkte findet sich in exakt einer der aufgeführten Methoden wieder. Für den ersten Punkt existiert die Methode createobservation; für den zweiten Punkt gibt es die Methoden existshashscope, createobservationscope und addhashscopetoobservation; für den dritten Punkt gibt es die Methode createobservedmeasure; und für den letzten Punkt gibt es die Methode create- Measurement. Aus dem angegebenen Service-Interface generiert der JBoss Application Server bei der Ausführung nun automatisch die WSDL-Definition, welche die Methoden beinhaltet, die die WebMethod-Annotation haben. Zusätzlich zu den Methoden enthält die WSDL-Definition die Beschreibung aller Klassen, die durch das Interface referenziert werden. Damit ist bereits ein funktionstüchtiger Service vorhanden, der nur noch um die Implementierung des Interfaces ergänzt werden muss. Zur Verwendung in einem Client müssen noch sog. Stub-Klassen generiert werden, sodass die benötigten Entitäten auch im Client verwendet werden können. Dazu kann das Java-Tool wsimport benutzt werden, dass die Stub-Klassen automatisch aus der WSDL-Definition generiert. 29

40 public interface SimulationDataService { public long createobservation(observation public long createobservedmeasure(long observationid, ObservedMeasure public long createmeasurement(long observedmeasureid, Measurement public boolean existshashscope(string public void createobservationscope(long observationid, ObservationScope public void addhashscopetoobservation(long observationid, String hash); Abbildung 10: Interface des Simulation Data Service Quelle: Eigene Darstellung Reduzierung des HTTP- und TCP-Overheads Nachdem das Interface definiert wurde, wird nun untersucht, ob es Möglichkeiten gibt, die Übertragungszeit zu reduzieren. Dazu wird zunächst eine Messung durchgeführt, die Aufschluss darüber geben soll, wie lange der Vorgang zur Übertragung und Persistierung eines Simulationsdurchlaufs insgesamt dauert; sollte die Übertragung zu lange dauern, werden die generierten SOAP-Nachrichten analysiert, um Verbesserungsmöglichkeiten zu finden. Für die Messung wurde ein exemplarischer Simulationsdurchlauf verwendet, welcher nach Erreichen von Messungen gestoppt wurde und der in Summe ca. 1,4 Mio. Messungen besitzt. Grundlage der Messung war zunächst noch eine ältere Version des Datenmodells, in welcher der Measurand noch mit der Klasse Measurement assoziiert war. Der Client und der Server wurden bei der Messung auf zwei verschiedenen Rechnern ausgeführt, die Übertragung fand über ein lokales Funknetzwerk nach dem Standard n statt. Unter diesen Bedingungen dauerte der gesamte Vorgang mehr als 18 Stunden; nach dieser Zeit wurde die Messung schließlich abgebrochen. Um Möglichkeiten zur Optimierung zu finden, werden zunächst die SOAP-Nachrichten untersucht, die bei der Übertragung verschickt werden. Dazu wird das frei verfügbare Netzwerk- Analyse-Programm Wireshark verwendet. Aufgrund der enormen Dateigröße lässt sich jedoch nicht der Mitschnitt der Übertragung des gesamten Simulationsdurchlaufes analysieren, da der Arbeitsspeicher des verwendeten Rechners hierfür nicht ausreicht. Daher werden nur die Nachrichten eines einzelnen Measurands des Durchlaufs analysiert, welcher Messungen beinhaltet. Die SOAP-Nachrichten dieses Durchlaufs sind in Abbildung 11 dargestellt. 30

41 <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:createobservation xmlns:ns2=" <arg0> <tool>pcm</tool> <whenobserved> t15:39: :00</whenobserved> </arg0> </ns2:createobservation> </S:Body> </S:Envelope> <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:createobservedmeasure xmlns:ns2=" <arg0>1</arg0> <arg1> <measure xmlns:xsi=" xsi:type="ns2:timemeasure"> <name>responsetime</name> <visible>false</visible> </measure> </arg1> </ns2:createobservedmeasure> </S:Body> </S:Envelope> <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:createmeasurement xmlns:ns2=" <arg0>6026</arg0> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <measurand xsi:type="ns2:namedmeasurand"> <name>response Time of Call_browse0 <EntryLevelSystemCall id: _tvpegowieegf2- HmZLMMNA></name> </measurand> <value> </value> <eventtime> </eventtime> </arg1> </ns2:createmeasurement> </S:Body> </S:Envelope> Abbildung 11: Generierte SOAP-Nachrichten Quelle: Eigene Darstellung Zu sehen sind die SOAP-Nachrichten für die drei Aufrufe der Methoden createobservation (Zeile 1 bis 12), createobservedmeasure (Zeile 14 bis 29) und createmeasurement (Zeile 31 bis 49). Die Nachrichten enthalten neben dem XML-Overhead den Tool-Namen und das Beobachtungsdatum als Parameter für createobservation, die observationid und ein Measure- Objekt als Parameter für createobservedmeasure sowie eine observedmeasureid und ein 31

42 Measurement-Objekt für createmeasurement. Das Measurement-Objekt besteht neben dem Measurand aus einem value und einer eventtime. Da der untersuchte Measurand Messungen enthält, werden noch weitere createmeasurement-nachrichten derselben Größe versendet. Die Größe der gesamten Transmission Control Protocol (TCP)-Konversation beträgt laut Wireshark Bytes, das entspricht 8,0 MiB. Rechnet man dies auf einen praxisnahen Simulationsdurchlauf mit einer Größe von 1 Mio. Messungen um, ergibt dies eine hypothetische Übertragungsmenge von ca. 180 GiB. Die Größe aller Nachrichten des Aufrufs createmeasurement beträgt laut Wireshark Bytes, das entspricht 7,9 MiB. Zählt man die Zeichen der Nachricht, so ergibt das für Nachrichten eine Payload-Größe von Bytes oder 3,4 MiB, und damit einen durch HTTP und TCP verursachten Overhead von Bytes oder 4,5 MiB. Damit ist mit dem aktuellen Modell der Overhead größer als der Payload. Die Vermutung liegt nahe, dass die große Zahl an Aufrufen der Methode createmeasurement den hohen Overhead und damit die schlechte Performance erzeugt. Daher wird das Interface angepasst, um statt einzelnen Measurements eine ganze Liste an Measurements übertragen zu können. Eine verbesserte Version des Service-Interfaces ist in Abbildung 12 zu sehen public interface SimulationDataService { public long createobservation(observation public long createobservedmeasure(long observationid, ObservedMeasure public long createtimemeasurementcollection(long observedmeasureid, Collection<TimeMeasurement> public boolean existshashscope(string public void createobservationscope(long observationid, ObservationScope public void addhashscopetoobservation(long observationid, String hash); Abbildung 12: Verbessertes Interface des Simulation Data Service Quelle: Eigene Darstellung Die neu hinzugefügte Methode in Zeile 12, welche für das Persistieren einer Liste von Measurements genutzt wird, verwendet bewusst die Klasse TimeMeasurement als Typparameter und nicht etwa die abstrakte Klasse Measurement oder einen kovarianten Typparameter. Der 32

43 Grund hierfür ist, dass nach einer wiederholten Messung die Laufzeit immer noch mehrere Stunden betrug; nach näherer Untersuchung des Codes wurde die Persistierung von JPA dafür verantwortlich gemacht. Daher wurde die Methode in der Implementierung geändert, sodass die Messungen direkt in die Datenbank eingefügt werden und der Persistenzkontext von JPA übergangen wird. Für diese Vorgehensweise ist das Einfügen in die spezifische Datenbanktabelle der Klasse TimeMeasurement notwendig. Während der Ausführung kann aufgrund der Type Erasure von Java jedoch der Typparameter der übergebenen Collection nicht festgestellt werden. Damit kann mit einem abstrakten Typparameter zur Laufzeit nicht herausgefunden werden, in welche Datenbanktabelle die Daten eingefügt werden müssen. Aus diesem Grund wurde für das Interface eine spezifische Methode gewählt, auch wenn eine Methode mit abstraktem Typparameter wesentlich flexibler gewesen wäre. Nach Änderung der Implementierung und Hinzufügen der neuen Methode im Interface wird die Messung mit demselben exemplarischem Simulationsdurchlauf wiederholt. Bei diesem Anlauf ist die Performance wesentlich besser, im Schnitt benötigt die Übertragung und Persistierung des Durchlaufs 3 Minuten und 55 Sekunden. Die Gesamtmenge der zu übertragenden Daten beträgt nun nur noch 1,9 MiB; davon nimmt der durch HTTP und TCP verursachte Overhead 95 KiB ein. Die neue SOAP-Nachricht, welche jetzt beim Aufruf von createtimemeasurementcollection generiert wird, ist in der folgenden Abbildung 13 dargestellt <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:createtimemeasurementcollection xmlns:ns2=" <arg0>2</arg0> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <measurand xsi:type="ns2:namedmeasurand"> <name>response Time of Call_browse0 <EntryLevelSystemCall id: _tvpegowieegf2- HmZLMMNA ></name> </measurand <value> </value> <eventtime> </eventtime> </arg1> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <measurand xsi:type="ns2:namedmeasurand"> <name>response Time of Call_browse0 <EntryLevelSystemCall id: _tvpegowieegf2- HmZLMMNA ></name> </measurand> <value> </value> <eventtime> </eventtime> </arg1>... </ns2:createmeasurementcollection> </S:Body> </S:Envelope> Abbildung 13: SOAP-Nachricht des Aufrufs createtimemeasurementcollection Quelle: Eigene Darstellung 33

44 Reduzierung des Payloads Weitere Optimierungen durch Verbesserung des Interfaces sind an dieser Stelle nicht mehr möglich. Der durch HTTP und TCP verursachte Overhead ist durch die Übertragung einer Measurement-Liste bereits minimal. Stattdessen kann versucht werden, den Payload bei der Übertragung zu minimieren. Eine Möglichkeit dazu ist die Reduktion des Payloads durch Änderungen am Datenmodell; ein Beispiel für eine solche Änderung ist die Referenzierung des Measurands aus der ObservedMeasure-Klasse heraus, und nicht aus der Klasse Measurement. Diese Änderung wurde beim vorgestellten Datenmodell in Abschnitt bereits erläutert, die bisherigen Messungen fanden aber auf Grundlage einer älteren Version des Datenmodells statt. So ist an der SOAP-Nachricht in Abbildung 13 zu sehen, dass der Measurand in jedem Measurement-Objekt vorkommt, obwohl er für jedes dieser Objekte identisch ist. Dadurch wird sehr viel Platz für die Übertragung von redundanten Daten verschwendet. Wird das aktuelle Datenmodell verwendet, sehen die SOAP-Nachrichten für den Aufruf der Methode createtimemeasurementcollection wie in Abbildung 14 dargestellt aus <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:createmeasurementcollection xmlns:ns2=" <arg0>2</arg0> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <value> </value> <eventtime> </eventtime> </arg1> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <value> </value> <eventtime> </eventtime> </arg1> <arg1 xmlns:xsi= xsi:type="ns2:timemeasurement"> <value> </value> <eventtime> </eventtime> </arg1>... </ns2:createmeasurementcollection> </S:Body> </S:Envelope> Abbildung 14: Verbesserte SOAP-Nachricht für createtimemeasurementcollection Quelle: Eigene Darstellung Durch die Extraktion der Measurand-Referenz ist die Nachricht wesentlich kompakter; der durch Zählen der Zeichen bestimmte Payload liegt bei 906 KiB. Durch die Reduktion des Payloads wird auch die Anzahl der zur Übertragung benötigten Pakete reduziert, wodurch wiederum der Overhead sinkt; dieser beträgt bei der Messung 45 KiB. Die Übertragung des gesamten exemplarischen Simulationsdurchlaufs benötigt mit diesem Modell im Schnitt 1 Minute und 32 Sekunden, dabei werden ca. 216 MiB übertragen. Rechnet man dies erneut 34

45 auf einen praxisnahen Workload mit 1 Mio. Messungen um, ergibt dies immer noch eine Datenmenge von etwa 21 GiB, die dafür transferiert werden müssen. Eine letzte Möglichkeit zur Reduzierung des Payloads ist der Einsatz von Daten- Kompression. Es gibt verschiedene Verfahren, um die bei der Übertragung mittels HTTP versendeten Daten zu komprimieren; eines der am häufigsten verwendeten Verfahren ist gzip, welches den deflate-algorithmus zur Kompression der Daten verwendet. Der deflate- Algorithmus wurde von Phil Katz entwickelt und später als Request For Comments (RFC) Nummer 1951 von der Internet Engineering Task Force (IETF) veröffentlicht (Internet Engineering Task Force 1996). Er basiert auf dem Lempel-Ziv-Storer-Szymanski (LZSS)- Algorithmus (vgl. Storer/Szymanski 1982), welcher eine verbesserte Variante des bekannten Lempel-Ziv 77 (LZ77)-Algorithmus ist, und der Huffman-Kodierung (vgl. Huffman 1952). Der LZSS-Algorithmus dient dabei dazu, sich wiederholende Zeichenketten durch den Einsatz von Referenzen zu komprimieren; die anschließende Huffman-Kodierung optimiert die Anzahl der Bits, welche jede Referenz einnimmt, mittels Präfixcodes (Internet Engineering Task Force 1996). Wird gzip zur Kompression der obigen Nachrichten verwendet, ist davon auszugehen, dass die Kompression sehr gute Ergebnisse erzielt. Denn die Nachrichten enthalten sehr viele sich wiederholende Zeichenfolgen, welche durch den LZSS-Algorithmus eliminiert werden können. Das gzip-verfahren wird von einer großen Zahl von Bibliotheken und Umgebungen unterstützt, die Art und Weise der Aktivierung des Verfahrens ist jedoch unterschiedlich innerhalb der verschiedenen Umgebungen. Während es im Client-Plugin reicht, die HTTP- Header-Felder Accept-Encoding und Content-Encoding vor der Übertragung auf den Wert gzip zu setzen, muss bei JBoss ein sog. GZIPInInterceptor eingesetzt werden, um mit gzip komprimierte Datenströme verarbeiten zu können. Dieser ist nicht in JBossWS, der JBosseigenen Apache CXF-Variante, enthalten, jedoch in der Standardausführung von Apache CXF; daher muss zunächst Apache CXF aktiviert werden, z.b. durch den Einsatz einer entsprechenden JBoss Deployment Structure. Nach Aktivierung von gzip wurde die Messung schließlich erneut durchgeführt. Die Datenmenge bei der Übertragung des exemplarischen Measurands beträgt nun nur noch 49 KiB; dies ist die Größe der kompletten TCP-Konversation. Vor der Aktivierung von gzip wurden für den Measurand 951 KiB übertragen. Die Übertragung des gesamten Simulationsdurchlaufes, welche vor der Kompression etwa 220 MiB an Daten übertragen hat, wird mit aktivierter Kompression auf eine Datenmenge von 4,5 MiB reduziert; damit ergibt sich eine Kompressionsrate von etwa 98%. Der gesamte Vorgang der Übertragung und Persistierung des exemplarischen Simulationsdurchlaufes dauert nun durchschnittlich 1 Minute und 10 Sekunden, wovon etwas mehr Zeit für die Persistierung und nicht für die Übertragung aufgewendet wird. Werden diese Werte auf den hypothetischen, praxisnahen Simulationsdurchlauf mit 1 Mio. Messungen umgerechnet, so werden bei diesem Durchlauf 450 MiB an Daten übertragen; der Vorgang dauert etwa 2 Stunden. 35

46 Laufzeit Overhead Payload Σ Datenmenge Erster Test N/A 1 GiB 790 MiB 1,8 GiB Measurement-Liste 3min 55s 22 MiB 419 MiB 441 MiB Measurand 1min 32s 10 MiB 206 MiB 216 MiB gzip 1min 10s N/A N/A 4,5 MiB Tabelle 7: Ergebnisse der Optimierung der Übertragung Quelle: Eigene Erhebung Die Ergebnisse der Messungen sind noch einmal in Tabelle 7 zusammengefasst. Dabei ist in der ersten Spalte jeweils angegeben, welche Optimierung erfolgt ist, bevor die Messung durchgeführt wurde. Alle Angaben beziehen sich auf den exemplarischen Simulationsdurchlauf mit einer Größe von Messungen, die Angaben zur Datenmenge wurden bei den ersten beiden Messungen jeweils aus dem Measurand mit Messungen hochgerechnet. In Tabelle 8 findet sich eine Auflistung der Ergebnisse, welche für den praxisnahen Simulationsdurchlauf mit 1 Mio. Messungen hochgerechnet wurden. Laufzeit Datenmenge Erster Test N/A 180 GiB Measurement-Liste 6,5h 43 GiB Measurand 2,5h 21 GiB gzip 2h 450 MiB Tabelle 8: Hypothetische Ergebnisse für einen praxisnahen Simulationsdurchlauf Quelle: Eigene Erhebung Dies zeigt, dass die Verwendung von SOAP bzw. allgemein die Verwendung von XML keinen übermäßig negativen Einfluss auf die Performance der Anwendung hat, sofern eine Kompression der Daten stattfindet. Eine Datenkompression mittels gzip ist allerdings nicht immer sinnvoll einsetzbar, da Nachrichten, welche komprimiert werden sollen, eine gewisse Mindestgröße aufweisen sollten, um eine effektive Kompression zu erreichen. Zudem ist eine Kompression von Client Requests, wie sie in diesem Fall geschehen ist, eher unüblich, da dazu in der Regel vorher eine Abfrage stattfinden muss, ob der Server dies unterstützt. In diesem Fall wurde jedoch darauf verzichtet, da die Clients speziell für den Server programmiert werden; und da die Kompression so wichtig für die Funktionsfähigkeit des Services ist, können die Clients in diesem Fall stets davon ausgehen, dass der Server gzip-komprimierte Datenströme unterstützt. Dennoch zeigt das Beispiel, welchen großen Einfluss eine sorgfältige Planung und Optimierung des Service-Interfaces und des Datenmodells haben können. Dies ist besonders gut an dem Beispiel des hypothetischen, praxisnahen Simulationsdurchlaufes sichtbar: die Dauer der ersten Version zur Übertragung und Persistierung des Durchlaufs hätte in der Größenordnung von Tagen (wenn nicht Wochen) gelegen, da schon ein Durchlauf mit nur Messungen über 18 Stunden benötigte. Theoretisch hätte dabei eine Datenmenge von ca. 180 GiB übertragen werden müssen. Durch die verschiedenen Optimierungen sowohl des Overheads als auch des Payloads konnte dies letztendlich auf etwa 450 MiB und eine Dauer von knapp 2 Stunden reduziert werden; dies entspricht einer Reduktion der ursprünglichen Datenmenge um 99,8%. 36

47 Anteile der Verarbeitungszeit Kompression & Übertragung Persistierung Abbildung 15: Anteile der Verarbeitungszeit Quelle: Eigene Erhebung Abschließend ist in Abbildung 15 noch ein Kreisdiagramm dargestellt, welches die Anteile der Operationen an der Verarbeitungszeit beinhaltet. Grundlage der Berechnung sind die aktuellsten Versionen des Datenmodells und des Interfaces, durch welche die Laufzeit des exemplarischen Simulationsdurchlaufs bei durchschnittlich 1 Minute und 10 Sekunden liegt. Im Diagramm entspricht der blaue Teil dem Anteil, den die Kompression, Übertragung und Dekompression der Daten an der gesamten Verarbeitungszeit haben; dies entspricht 34 Sekunden oder 49%. Auf der linken Seite ist der Anteil dargestellt, welchen allein die Persistierung an der Verarbeitungszeit hat; dies entspricht 36 Sekunden oder 51%. Dies zeigt, dass beide Teile der Verarbeitung im aktuellen Modell relativ gleichwertig sind. Allerdings ist zu betonen, dass eine Optimierung der Kompression und Übertragung kaum noch möglich sein wird; auch wenn nur 4,5 MiB letzten Endes übertragen werden, so müssen doch knapp 220 MiB komprimiert und wieder dekomprimiert werden, damit die Übertragung vollständig ist. Dagegen kann die Zeit, welche für die Persistierung aufgewendet wird, durch den Einsatz eines richtigen Datenbankservers und weiterer systemspezifischer Optimierungen sicherlich noch weiter reduziert werden. Fazit In diesem Kapitel wurde zunächst in Abschnitt 4.1 ein Datenmodell entwickelt. Dazu wurden als erstes die beiden Alternativen für die Verwendung als Referenzmodell, CIM und SMM, beschrieben, und anschließend gegeneinander abgewogen. Aufgrund seiner etwas besseren Eignung wurde dabei SMM ausgewählt. Daraufhin wurde SMM als Grundlage für die Entwicklung eines eigenen Datenmodells verwendet; dabei wurden die fehlenden Konzepte wie die Repräsentation von Messzeitpunkten, Workloads und Performance-Modellen hinzugefügt. Im zweiten Teil dieses Kapitels wurde die Übertragung der Daten zwischen Client und Server betrachtet. Dazu wurden zunächst die beiden möglichen Alternativen bei der Implementierung von Web Services, JAX-WS und JAX-RS, beschrieben. Beide Alternativen wurden als gleichwertig bezeichnet, wegen der breiteren Konfigurationsmöglichkeiten wurde jedoch 37

48 JAX-WS als Standard für die Implementierung des Web Services ausgewählt. Danach wurde ein Interface für den Simulation Data Service entwickelt, aus welchem später die WSDL- Definition erstellt werden kann. Schließlich wurde untersucht, wie die Übertragung optimiert und damit die Übertragungszeit minimiert werden kann. Durch Anpassungen des Interfaces, des Datenmodells sowie durch Aktivierung von gzip-kompression konnte letztendlich eine erhebliche Reduktion sowohl des Overheads als auch des Payloads erzielt werden. Mit dem Ende dieses Kapitels wurde nun die letzte der drei Forschungsfragen, welche zu Beginn der Arbeit aufgestellt wurden, beantwortet. Im nächsten Kapitel wird schließlich betrachtet, welche konkreten Eigenschaften die Implementierung des Prototyps aufweist; insbesondere die technische Umsetzung des Datenmodells aus Abschnitt 4.1 wird dort behandelt. 38

49 Architektur des Prototyps Überblick Nachfolgend wird zunächst ein kurzer Überblick über die Architektur gegeben, die für die Entwicklung des Prototyps des Simulation Data Service verwendet wurde; anschließend werden konkrete Details der Implementierungen, Herausforderungen und Designentscheidungen behandelt. Der Prototyp des Simulation Data Service basiert auf der Client-Server-Architektur. Clients des Services sind dabei verschiedene Simulationswerkzeuge, welche ihre Simulationsergebnisse an den Service senden. Ein Teil der Entwicklung des Prototyps war die Implementierung eines Plugins für die Palladio-Bench, um die Funktionsfähigkeit des Services demonstrieren zu können; wie die konkrete Implementierung des Plugins gehandhabt wurde, wird in Abschnitt 5.3 näher erläutert. Der Simulation Data Service selbst läuft, wie in Kapitel 2 bereits erklärt wurde, als Web Service auf dem JBoss Application Server 7; als Datenbankmanagementsystem (DBMS) wird MySQL verwendet. Die Implementierung des Web Services und die Kommunikation mit den Clients erfolgt dabei auf Basis von JAX-WS, wie im vorangegangen Kapitel beschrieben. Da das Interface des Simulation Data Services bereits erörtert wurde, wird an dieser Stelle nicht weiter darauf eingegangen. Vielmehr wird im Folgenden beschrieben, wie die praktische Implementierung des theoretischen Datenmodells erfolgt ist. Zu diesem Zweck wird im kommenden Abschnitt die Java Persistence API beschrieben. Java Persistence API Grundlagen Zur Implementierung des Datenmodells, welches in Kapitel 4 entwickelt wurde, wird die Java Persistence API (JPA) eingesetzt. Ähnlich wie bei der Java EE-Spezifikation wird die JPA- Spezifikation von mehreren sog. Persistence Providern implementiert; in dieser Arbeit wird Hibernate verwendet. JPA dient dem Management von Persistenz in Java EE und Java SE und bietet diesen Plattformen ein Object-Relational Mapping (ORM) (Sun Microsystems 2009, 19). Der Zweck eines ORM ist die Abbildung von objektorientierten Strukturen in relationalen Datenbanken, wie sie in der Praxis in der Regel eingesetzt werden. Dazu werden Plain Old Java Objects (POJOs) verwendet, die um entsprechenden Annotationen erweitert werden. Die grundlegende Annotation von JPA ist die Entity-Annotation. Durch sie wird gekennzeichnet, dass eine Klasse Teil des ORM ist und persistiert werden soll. Dabei werden alle objektorientierten Konzepte unterstützt, welche normalerweise in relationalen Datenbanken nicht vorkommen, insbesondere Vererbung und Polymorphie (Sun Microsystems 2009, 22). Zusätzlich braucht jede Klasse eine ID, welche sie eindeutig identifiziert; dazu kann unter anderem die Id-Annotation verwendet werden. Existieren diese beiden Annotationen, kann eine Java-Klasse bereits persistiert werden; es gibt jedoch noch eine Vielzahl an weiteren Annotationen, mit denen das ORM präziser gesteuert werden kann. Insbesondere sind häufig die Annotation OneToOne, OneToMany bzw. ManyToOne und ManyToMany anzutreffen; diese 39

50 dienen der Spezifikation der Multiplizitäten von Assoziationen und steuern damit, wie die Referenzen zwischen zwei Objekten abgebildet werden. Ein Beispiel für eine mit JPA-Annotationen versehene Klasse findet sich in Abbildung = "observation") public class Observation extends SmmElement { } private String observer; private String tool; private Date = CascadeType.PERSIST) public Collection<ObservationScope> = CascadeType.REMOVE, fetch = FetchType.LAZY) public Collection<ObservedMeasure> observedmeasures;... Abbildung 16: Observation-Klasse mit JPA-Annotationen Quelle: Eigene Darstellung Im Beispiel ist die Klasse Observation abgebildet. Diese enthält vor der Klassen-Definition die Annotationen Entity, um sie als JPA Entity zu kennzeichnen, und Table, um den Namen der Datenbanktabelle, in welcher die Entität persistiert wird, festzulegen. Die Klasse besitzt keine Id-Annotation, da die ID aus der Oberklasse SmmElement vererbt wird. Zudem besitzt sie zwei Referenzen zu anderen Klassen, nämlich zu der Klasse ObservationScope und zu der Klasse ObservedMeasure. Diese sind mit einer ManyToMany-Annotation bzw. mit einer O- netomany-annotation annotiert, die die Multiplizität kennzeichnen. Zusätzlich ist bei beiden Referenzen der CascadeType angegeben; dieser sagt aus, ob Änderungen an einem Objekt an die referenzierten Objekten weitergegeben werden. Z.B. ist das Attribut scopes mit dem CascadeType PERSIST annotiert; dadurch wird bei der Persistierung des Observation-Objekts auch der ObservationScope persistiert, sofern das Observation-Objekt einen ObservationScope besitzt. Schließlich ist bei dem Attribut observedmeasures der FetchType angegeben; der FetchType LAZY drückt aus, dass das Attribut erst in den Persistenzkontext werden soll, wenn darauf zugegriffen wird. Durch die Verwendung von JPA wird eine Abstraktionsschicht erzeugt, sodass das Datenmodell unabhängig von einem spezifischen Datenbankmanagementsystem ist. Damit kann das zugrundeliegende DBMS ausgetauscht werden, ohne die Anwendung anpassen zu müssen. Der Zugriff auf Objekte erfolgt über den sog. EntityManager, der den Persistenzkontext verwaltet. Objekte können, sofern ihre ID vorliegt, direkt mithilfe der find-methode aus dem Persistenzkontext abgerufen werden; komplexere Abfragen sind mithilfe der Java Persistence Query Language (JPQL) möglich. JPQL ist vom Aufbau her stark an SQL angelehnt, welches in den meisten DBMS verwendet wird. Ein Beispiel für eine einfache JPQL-Abfrage ist in Abbildung 17 zu finden. 40

51 TypedQuery<MofElement> query = em.createquery( "SELECT m FROM Observation o JOIN " + "o.observedmeasures om JOIN om.measurand m" + " WHERE o.id = :observationid" + " AND m.name = :measurandname", MofElement.class); query.setparameter("observationid", observationid); query.setparameter("measurandname", measurandname); List<MofElement> measurands = query.getresultlist();... Abbildung 17: Beispiel für eine JPQL-Abfrage Quelle: Eigene Darstellung Im Beispiel wird eine Abfrage durchgeführt, um alle Measurands zu erhalten, welche einen bestimmten Namen haben und einer konkreten Observation-Instanz zugeordnet sind. Neben der Parametrisierung der Query durch die Felder observationid und measurandname fällt auf, dass im Gegensatz zu SQL die Joins über die Objekte selbst statt über die Fremdschlüssel durchgeführt werden. Zudem ist Vererbung selbstverständlich möglich; eine ähnliche Abfrage in SQL zu schreiben, würde eine größere Zahl komplexer Joins erfordern, um alle Unterklassen der Klasse MofElement abfragen zu können. JPQL und JPA erledigen die Umwandlung in SQL selbstständig. Die Performance solcher Abfragen hängt aber wesentlich davon ab, wie die Vererbung in der relationalen Datenbank umgesetzt ist. Die verschiedenen Möglichkeiten der Abbildung werden im nächsten Abschnitt beschrieben. Abbildung von Vererbung In JPA gibt es verschiedene Möglichkeiten zur Abbildung von Vererbung. Vererbung ist ein besonderes Thema, da es in relationalen Datenbanken von Haus aus keinen Mechanismus für Vererbung gibt. JPA bietet drei grundlegende Strategien zur Abbildung von Vererbung: Single Table, Joined Subclass und Table per Concrete Class (Sun Microsystems 2009, 56). Bei Single Table-Vererbung werden alle Klassen einer Vererbungshierarchie in einer Datenbanktabelle gespeichert. Diese Tabelle enthält alle Attribute aller Klassen der Hierarchie; folglich hat eine Zeile einer solchen Tabelle in der Regel sehr viele Null-Werte. Zusätzlich gibt es eine Unterscheidungsspalte, welche kennzeichnet, welcher der Unterklassen eine Tabellenzeile angehört. Single Table-Vererbung bietet den Vorteil, dass Abfragen, welche mehrere Klassen der Hierarchie betreffen, sehr schnell sind (Sun Microsystems 2009, 56); daher ist es die Standard-Strategie zur Abbildung von Vererbung. Bei Joined Subclass-Vererbung besitzt die Wurzelklasse einer Vererbungshierarchie eine eigene Tabelle, welche allerdings im Gegensatz zu Single Table-Vererbung nur die Attribute der Wurzelklasse als Felder enthält. Jede Unterklasse wird mit einer eigenen Tabelle abgebildet, welche neben dem Primärschlüssel nur die Attribute der jeweiligen Klasse enthält, also keines der geerbten Attribute. Diese Strategie hat den Nachteil, dass die Instanziierung einer Unterklasse mehrere Joins erfordert und damit sehr langsam ist (Sun Microsystems 2009, 56) Bei Table per Concrete Class-Vererbung erhält jede nicht-abstrakte Klasse der Vererbungshierarchie eine eigene Tabelle, welche alle Attribute enthält, die die Klasse besitzt, also auch 41

52 geerbte Attribute. Abstrakte Klassen werden nicht in der Hierarchie abgebildet. Dadurch erfordern Abfragen, welche die Hierarchie umfassen, in der Regel mehrere Joins und sind damit nicht sehr performant (Sun Microsystems 2009, 57). Welche der Strategien eingesetzt wird, hängt zum einen davon ab, wie die Klassenhierarchie aufgebaut ist, aber auch davon, welche Abfragen auf der Hierarchie durchgeführt werden. Für die Abbildung des Datenmodells des Simulation Data Service wurde die Table per Concrete Class-Strategie gewählt. Single Table-Vererbung ist für das Datenmodell nicht gut geeignet, da jede Klasse des Modells von der Klasse SmmElement erbt; dadurch besteht die Datenbank bei Verwendung dieser Strategie nur aus der Tabelle smmelement und einigen Join-Tabellen. Da besonders die Measurement-Klasse sehr viele Instanzen beinhalten wird, würde diese Tabelle nach der Persistierung von wenigen Simulationsdurchläufen schon so groß sein, dass das Auffinden anderer Objekte sehr lange dauern wäre. Joined Subclass-Vererbung ist ebenfalls nicht gut anwendbar, da dies zu einer zu großen Zahl an Joins führt. Wenn z.b. alle Measurements einer Observation abgefragt werden, müssen sehr viele Joins durchgeführt werden, da die Zuordnung zur ObservedMeasure in der abstrakten Klasse Measurement gespeichert ist, während der Wert der Measurement in der Klasse DimensionalMeasurement abgelegt ist, während der Zeitpunkt in der Klasse TimeMeasurement festgehalten ist. Daher würde die Verwendung der Joined Subclass-Strategie ebenfalls zu einer schlechten Performanz führen. Somit ist die Table per Concrete Class-Strategie die beste mögliche Lösung zur Abbildung der Vererbung des verwendeten Datenmodells in der Datenbank. Denn nur mit dieser Strategie sind die Measurements, die bei weitem den größten Teil der Daten ausmachen, getrennt von den restlichen Klassen und gleichzeitig schnell instantiierbar. Dafür muss der Nachteil in Kauf genommen werden, dass Abfragen, die mehrere Unterklassen umfassen, mehrere Joins benötigen; doch die Zahl solcher Abfragen wird beim verwendeten Datenmodell voraussichtlich gering sein, sodass der Trade-off in dieser Beziehung positiv ist. Probleme der Vererbungs- und Generationsstrategie Ein Nachteil der Table per Concrete Class-Strategie ist, dass sie bei Hibernate, dem verwendeten Persistence Provider, die Wahl des GenerationType bei generierten IDs einschränkt. Wie in Abschnitt beschrieben, dienen IDs dazu, jedes Objekt eindeutig identifizierbar zu machen. Häufig wird bei der Verwendung von IDs auch die Annotation GeneratedValue verwendet, um die ID durch den Persistence Provider generieren zu lassen; dadurch muss sich die Anwendung nicht um die Verwaltung der IDs kümmern. Die Annotation GenerationType steuert dann die Art und Weise, wie IDs generiert werden. Für MySQL-Datenbanken wird in der Regel der GenerationType IDENTITY verwendet; dieser wird auch verwendet, wenn der Typ auf AUTO gestellt wird. Durch den GenerationType IDENTITY wird die Generierung von IDs mithilfe eines ID-Feldes, das vom DBMS verwaltet wird, durchgeführt (Sun Microsystems 2009, 375). In MySQL erhält dabei das ID-Feld das Flag auto_increment und wird bei neuen Einträgen in die Tabelle automatisch durch MySQL inkrementiert. 42

53 Wird nun die Table per Concrete Class-Vererbungsstrategie verwendet, ist in Hibernate keine Verwendung des GenerationTypes IDENTITY mehr möglich (Hibernate Team 2013). Der Grund hierfür ist, dass alle Unterklassen einer Klassenhierarchie an Stelle der Wurzelklasse treten können; damit muss die ID eindeutig für die gesamte Klassenhierarchie sein, um Konflikte zu vermeiden. Daher ist keine ID-Verwaltung innerhalb der individuellen Klassen mehr möglich. Stattdessen kann der GenerationType TABLE verwendet werden. Wird der GenerationType TABLE verwendet, benutzt Hibernate eine eigene Datenbanktabelle zur Speicherung der hierarchieübergreifenden ID. Der GenerationType TABLE hat jedoch den Nachteil, dass die Performance von INSERT- Operationen darunter leidet. Wird mithilfe des EntityManagers ein neues Objekt in der Datenbank persistiert, würde normalerweise nur ein einziges INSERT-Statement ausgeführt werden, wenn das Objekt keine Referenzen in Join-Tabellen besitzt. Durch die Verwendung des GenerationType TABLE führt Hibernate zunächst ein SELECT-Statement aus, um die aktuelle ID aus der Datenbank auszulesen, daraufhin das INSERT-Statement und zum Schluss noch ein UPDATE-Statement, um die neue ID auch in der Datenbank zu aktualisieren. Damit wird die Zahl der Operationen effektiv verdreifacht. Während dies kein Problem darstellt, wenn das Einfügen neuer Objekte nicht zeitkritisch ist, ist dies für die Verwendung im Simulation Data Service sehr problematisch; selbst kleine Simulationsdurchläufe haben mehrere Millionen Messungen, welche alle in die Datenbank eingefügt werden müssen. Dies verschärft das Problem, dass mehrere Millionen einzelne INSERT-Operationen schon sehr inperformant sind, noch zusätzlich. Dieses Problem war auch die Ursache dafür, dass die Laufzeit der ersten Versuchsläufe in Abschnitt überdurchschnittlich hoch war. Effiziente Persistierung einer großen Zahl von Messungen Eine Lösung für dieses Problem ist die Verwendung von Batch INSERTs, also eine stapelweise Verarbeitung der INSERT-Operationen; so können mehrere Messungen mit einem einzigen INSERT-Befehl persistiert werden. Zu diesem Zweck wird beim Aufruf der Methode createtimemeasurementcollection, welche das Service-Interface bereitstellt, nicht Hibernate zur Persistierung der Messungen verwendet, sondern Java Database Connectivity (JDBC). JDBC stellt eine einheitliche Schnittstelle für den Zugriff auf relationale Datenbanken dar. Es stellt Methoden bereit, um eigene SQL-Anfragen in der Datenbank durchzuführen. Somit können mit JDBC Batch INSERTs umgesetzt werden, welche eine schnelle Persistierung einer großen Zahl von Messungen ermöglichen. Zu diesem Zweck wurde zunächst untersucht, was eine gute Batch-Größe für die Persistierung der Messungen ist. Denn umso mehr Messungen mit einem einzigen INSERT verarbeitet werden können, umso geringer sollte theoretisch die Zeit pro Messung sein. Um dies zu überprüfen, wurde ein Measurand mit einer großen Zahl an Messungen mittels JDBC persistiert. Dabei wurde iterativ die Batch-Größe verändert, beginnend von 0 und anschließender Inkrementierung in 100er-Schritten. Für jede INSERT-Query wurde die Dauer in Nanosekunden gemessen, die diese zur Persistierung benötigte. Das Ergebnis dieser Messung ist in Abbildung 18 zu sehen. 43

54 INSERT-Zeit / Messung 0,4 0,35 0,3 0,25 0,2 0,15 0,1 0, Abbildung 18: INSERT-Zeit pro Messung bei verschiedenen Batch-Größen Quelle: Eigene Erhebung Das Diagramm stellt die Zeit dar, die jeweils für eine INSERT-Operation benötigt wurde, in Relation zur Batch-Größe. Die ersten beiden Messungen sowie die letzten Messungen werden aufgrund von Ausreißern nicht angezeigt. Die Batch-Größe bewegt sich bis auf einige Ausreißer im Rahmen von 0,05 bis 0,1 Nanosekunden pro Messung. Die orange dargestellte lineare Regressionsgerade zeigt, dass die Annahme, dass die Zeit pro Messung mit steigender Batch-Größe sinkt, stimmt. Somit ist es für eine optimale Persistierung einer großen Zahl von Messwerten sinnvoll, eine möglichst große Batch-Größe zu verwenden. Bei der Ausführung trat bei einer Batch-Größe von knapp eine Exception auf, da das System nicht mehr genug Speicher hatte. Das Problem lag jedoch nicht am DBMS, sondern viel mehr am StringBuilder, welcher verwendet wird, um die Query zu bauen. Dieser verhält sich quasi entgegengesetzt im Vergleich zu den Ausführungszeiten der INSERT-Query; mit jedem weiteren String, welcher an die INSERT-Query angefügt wird, wird mehr Speicher benötigt, was bei einem Speichermangel zu höheren Ausführungszeiten führt. In der nachfolgenden Abbildung 19 ist ein Diagramm abgebildet, dass der Ausführungszeit der INSERT- Query die Ausführungszeit des StringBuilders pro Messung gegenüberstellt. Wie dabei gut zu sehen ist, ist die Zeit pro Messung des StringBuilders initial wesentlich niedriger als die Ausführungszeit der Query. Somit hat der StringBuilder bis zu einer Batch- Größe von ca Messungen keinen nennenswerten Anteil an der gesamten Ausführungszeit. Ab der Marke von etwa Messungen kommen deutliche Ausreißer nach oben hinzu, während die Ausführungszeit der Query davon unberührt bleibt. Mit steigender Batch-Größe nimmt die Häufigkeit der Ausreißer zu, bis schließlich bei etwa Messungen der Punkt 44

55 erreicht ist, an dem die Ausreißer keine Ausreißer mehr sind. Dabei ist auch zu sehen, dass ab etwa Messungen auch die Ausführungszeit der Query unter dem Speichermangel des Systems leidet. Bei etwa Messungen ist das System schließlich voll ausgelastet und kann den Speicherbedarf des StringBuilders nicht mehr bedienen, sodass es zum Abbruch kommt. 0,5 0,45 0,4 0,35 0,3 0,25 0,2 0,15 0,1 0, INSERT-Zeit / Messung StringBuilder-Zeit / Messung Abbildung 19: INSERT- und StringBuilder-Zeit pro Messung Quelle: Eigene Erhebung Es wäre zwar möglich gewesen, die Größe des Arbeitsspeichers, der Java zur Verfügung steht, zu erhöhen, um diesem Problem zu entgehen; doch dies hätte das Problem nur verschoben, da der Speichermangel dadurch lediglich später eingetreten wäre. Am grundlegenden Problem, welches in der Grafik gut sichtbar ist, ändert dies jedoch nichts: die Batch-Größe ist ein Trade-Off zwischen der Zeit, die durch das gleichzeitige Einfügen vieler Element in die Datenbank gewonnen wird, und der Zeit, die für die Vorbereitung des Einfügens verloren geht. Für das hier untersuchte System, an dem keinerlei Optimierungen vorgenommen wurden, scheint eine Batch-Größe von etwa Messungen ein guter Kompromiss zu sein, da die Ausreißer des StringBuilders bei dieser Marke nur recht sporadisch auftreten. Es ist jedoch nicht sinnvoll, zu versuchen, das hier untersuchte System zu optimieren und höhere Batch-Größen zu erreichen; dieses System unterscheidet sich wesentlich von einem Produktivsystem, welches für den Einsatz als Datenbankserver konzipiert wurde. Jegliche weiteren Optimierungen hängen wesentlich von den Parametern eines Systems ab und müssen daher für ein spezifisches System vollzogen werden. Zudem würde eine wissenschaftliche Untersuchung aller möglichen Parameter eines DBMS, durch welche eine Verbesserung der Ausführungszeit von INSERT-Queries erreicht werden kann, den Rahmen dieser Arbeit sprengen. 45

56 Mit der hier ermittelten Batch-Größe von Messungen kann aber zumindest eine einigermaßen effiziente Verarbeitung der Simulationsergebnisse erreicht werden, wie an den Messungen der Laufzeit in Abschnitt zu sehen ist. Die Performance des Simulation Data Service ist damit zumindest in einem akzeptablen Bereich; ausgehend davon können, wie oben beschrieben, systemspezifische Optimierungen durchgeführt werden, um weitere Performanceverbesserungen zu erreichen. Damit wurde die Funktionsweise des Prototyps des Simulation Data Service hinreichend betrachtet. Neben dem Service wurde, wie zu Beginn des Kapitels erwähnt, auch ein Client- Plugin für die Palladio-Bench entwickelt. Im Folgenden wird knapp auf die Architektur des Clients eingegangen. Architektur des Clients Die Palladio-Bench ist, wie bereits in Kapitel 2 erläutert, ein Plugin für die Java- Entwicklungsumgebung Eclipse. Daher wurde ein weiteres Plugin für Eclipse entwickelt, welches die Palladio-Bench erweitert und damit die Möglichkeit bietet, Simulationsergebnisse an den Simulation Data Service zu übertragen. Im Folgenden wird dieses Plugin als PMWT- Plugin bezeichnet. Bei der Entwicklung des PMWT-Plugins wurde besonderen Wert darauf gelegt, die Zahl der Änderungen am bestehenden Code der Palladio-Bench so gering wie möglich zu halten, um eine einfache Anpassung des Plugins an neue Palladio-Versionen zu ermöglichen. Daher wurde die Anbindung des Plugins an die Palladio-Bench mithilfe der sog. Workflow Engine von Palladio realisiert. Die Workflow Engine ist dabei eine Infrastruktur, welche verwendet werden kann, um sowohl simple als auch komplexe Jobs zu erstellen (Palladio Team 2013). Nachdem sie ursprünglich als Teil der Palladio-Bench entwickelt wurde, hat sie sich mittlerweile zu einem eigenständigen Projekt entwickelt, welches auch von anderen Software- Projekten verwendet wird (Palladio Team 2013). Durch die Verwendung der Workflow Engine ist eine nahtlose Integration in die Palladio- Bench möglich, indem sog. Workflow Hooks verwendet werden. An bestimmten Stellen im Code der Palladio-Bench werden dabei die vordefinierten Hooks aufgerufen, und alle Jobs, welche sich an einen der Hooks gehängt haben, werden ausgeführt. Das PMWT-Plugin bspw. hängt sich bei der Ausführung an den Hook simucom.after.simulation und wird dadurch jedes Mal aufgerufen, wenn eine Simulation beendet wird. Dadurch ist eine optimale Integration gegeben, da selbst komplexere Funktionalitäten der Palladio-Bench wie die Sensitivitätsanalyse nicht berücksichtigt werden müssen, da sie automatisch funktionieren. Der Hook ruft die selbstdefinierte Klasse PMWTJob auf, welche alle weiteren Jobs zur Übertragung der Simulationsergebnisse definiert und ausführt. Ein Code-Fragment dieser Definition ist in Abbildung 20 dargestellt. Darin ist zu sehen, dass für die Übertragung der Ergebnisse zunächst der aktuellste ExperimentRun aus dem Kontext geladen werden muss; anschließend wird die Verbindung zum Simulation Data Service hergestellt. Daraufhin wird zunächst ein Instanz der Observation-Klasse erzeugt und an den Server geschickt. Anschließend werden die Modelldaten übertragen, sofern sie noch nicht auf dem Server vorhanden sind. Schließlich werden alle ObservedMeasures erstellt und daraufhin mit den Measurements übertragen. 46

57 // Create all the jobs this.logger.info("sending simulation results to PMWT"); this.addjob(new LoadNewestExperimentRunJob(ctx)); this.addjob(new EstablishConnectionToSDSJob(ctx)); this.addjob(new SendObservationJob(ctx)); this.addjob(new SendModelsJob(ctx)); this.addjob(new SendObservedMeasuresJob(ctx)); // RUN! super.execute(monitor); Abbildung 20: Code-Fragment des PMWTJobs Quelle: Eigene Darstellung Die Version der Palladio-Bench, auf deren Grundlage das PMWT-Plugin entwickelt wurde, ist die Version In dieser ist noch nicht die neue Workflow Engine 2.0 enthalten; diese bietet zusätzliche neue Features. So lassen sich bspw. sowohl sequentielle als auch parallel abgearbeitete Jobs erstellen; wenn das PMWT-Plugin auf eine neue Version der Palladio- Bench aktualisiert wird, kann so einfach geprüft werden, ob eine parallele Übertragung der Simulationsergebnisse die Performance verbessert oder verschlechtert. Ganz ohne Änderungen am vorhandenen Code funktioniert das PMWT-Plugin nicht. Es gibt eine Reihe an Konfigurationseinstellungen, welche eine detaillierte Kontrolle über das Plugin geben; so lässt sich das Plugin bspw. einfach aktivieren oder deaktivieren oder die Adresse des Servers anpassen. Für diese Konfigurationseinstellungen mussten die Konfigurationsklassen von SimuCom geändert werden. Die Änderungen beschränken sich jedoch auf 2 Pakete, sodass bei einer Versionsaktualisierung nicht viel Code angepasst werden muss. Abbildung 21: Screenshot der Konfiguration des PMWT-Plugins Quelle: Eigene Darstellung 47

58 Ein Screenshot des Konfigurationsdialoges findet sich in der Abbildung 21. Darin sind zunächst die verschiedenen Simulationseinstellungen der Palladio-Bench zu sehen. Im unteren Teil des Fensters befindet sich der Bereich Performance Management Work Tools. Dieser enthält zunächst eine Checkbox, mit welcher die Übertragung von Simulationsergebnissen an den Simulation Data Service einfach aktiviert bzw. deaktiviert werden kann. Über den Konfigurationsparameter WSDL URL kann die Adresse des Servers bei Bedarf einfach angepasst werden, indem der Uniform Resource Locator (URL) der WSDL-Definition angegeben wird. Mithilfe des Parameters Maximum Batch Size kann gesteuert werden, wie viele Messungen höchstens auf einmal verschickt werden sollen. Und schließlich existiert ein Feld, mit dem die Kompression der Daten mittels gzip aktiviert bzw. deaktiviert werden kann. Zur einfachen Installation des Plugins wurde ein Eclipse Feature erstellt, welches den Code des Plugins beinhaltet. Die beiden Pakete, welche für die Konfigurationseinstellungen angepasst werden mussten, werden als Eclipse Feature Patch ausgeliefert. Über den Eclipse- Menüpunkt Install New Software kann das PMWT-Plugin so mit wenigen Klicks installiert werden. 48

59 Fazit Zusammenfassung Im Rahmen dieser Arbeit wurde ein Web Service entwickelt, der für die Übertragung und Persistierung von Simulationsergebnissen verantwortlich ist. Dazu wurde in Kapitel 3 untersucht, welche Daten speziell für den Vergleich von Performance-Simulations- und Messergebnissen notwendig sind. Das Ergebnis war, dass eine Reduktion der Daten im Rahmen einer statistisch rigorosen Evaluation nicht sinnvoll ist, und dass zudem der Workload notwendig ist, um feststellen zu können, ob zwei Ergebnisse vergleichbar sind. Daraufhin wurde ein Workload-Modell entwickelt, welches mithilfe des Kolmogorov-Smirnov-Tests erfolgreich validiert wurde. Auf Basis dieser Daten wurde in Abschnitt 4.1 ein Datenmodell auf Basis von SMM entwickelt, das alle für die Evaluation von Performance-Modellen notwendigen Daten beinhaltet. Dazu wurde das SMM um eigene Konstruktionen zur Repräsentation von Messzeitpunkten, Performance-Modellen und Workloads erweitert. Anschließend wurde in Abschnitt 4.2 zunächst untersucht, welche unterschiedlichen Arten von Web Services es gibt und welche dieser Typen für die Implementierung des Simulation Data Service geeignet sind. Daraufhin wurde ein Interface für den Service auf Grundlage von JAX-WS und dem zuvor erstellten Datenmodell erstellt. Dieses Interface sowie die Übertragung an sich wurden schließlich mithilfe von Netzwerk-Analysen optimiert, um eine minimale Übertragungszeit zu erreichen. Abschließend wurde in Kapitel 5 auf die Architektur des Prototyps eingegangen, speziell auf die Implementierung des Datenmodells mithilfe von JPA. Ausblick Der im Rahmen dieser Arbeit entwickelte Simulation Data Service ist die Grundlage für die Entwicklung der Performance Management Work Tools. Das Ziel der PMWT ist letztendlich die Vereinfachung der Evaluation von Performance-Modellen sowie die einfache Verwaltung von Simulations- und Messergebnissen, welche mithilfe unterschiedlicher Werkzeuge erhoben wurden. Um dieses Ziel zu erreichen, ist jedoch noch weitere Arbeit notwendig; neben der Entwicklung des Load-Test Data Service und des Model Evaluation Tools, welche aktuell bereits stattfindet, kann auch der Simulation Data Service weiterentwickelt werden. So ist eine wichtige Aufgabe die systemspezifische Optimierung der Persistierung von Simulationsergebnissen, welche in Kapitel 5 erläutert wurde, um die Performance des Systems weiter zu steigern und damit die Nutzbarkeit zu erhöhen. Weiterhin muss untersucht werden, welche statistischen Verfahren für einen Vergleich von Workloads geeignet sind; wie in Kapitel 3 dargelegt wurde, sollte der Simulation Data Service auch in der Lage sein, zu einem Simulationsergebnis ähnliche Simulationsergebnisse auf Grundlage des Vergleichs der Workloads zu liefern. Um dies erreichen zu können, muss geprüft werden, ob der Kolmogorov-Smirnov- Test, welcher für die Validierung der entwickelten Workload-Definition verwendet wurde, auch für den Vergleich von Workloads verschiedener Simulationswerkzeuge oder sogar den Vergleich von Workloads von Simulations- und Lasttestwerkzeugen geeignet ist. Neben diesen spezifischen Aufgaben gibt es viele weitere Teilbereiche der PMWT, welche noch in Planung sind und zusätzliche Services bieten werden. Werden all diese Ziele erreicht, so besitzen die PMWT die Möglichkeit, die Erstellung, Verwendung, Verwaltung und Auswertung von Performance-Modellen wesentlich zu vereinfachen. 49

60 Zusätzlich zu den Beiträgen für die PMWT liegt der Wert dieser Arbeit auch in der Verwendung von SMM für die Repräsentation von Simulationsergebnissen, welche mithilfe von Performance-Modellen erhoben wurden; dadurch eröffnet diese Arbeit Möglichkeiten für weitere Anwendungen von SMM in der Performance-Forschung, welche wiederum in Verbesserungen der Nutzbarkeit resultieren können. Und dadurch hat diese Arbeit sowohl einen theoretischen als auch praktischen Beitrag dazu geleistet, dass Performance-Modelle in Zukunft nicht mehr nur von Wissenschaftlern benutzt werden; einen Beitrag zur Verbesserung und Verbreitung von Performance-Modellen, sodass sie helfen können, viele der heutigen Probleme in der Software-Entwicklung zu lösen. 50

61 Literaturverzeichnis Apache Software Foundation (o.j.): Apache CXF Project Website. zugegriffen am Balsamo, S.; di Marco, A.; Inverardi, P.; Simeoni, M. (2004): Model-Based Performance Prediction in Software Development: A Survey. In: Software Engineering, IEEE Transactions on, Band 30 (2004) Nr. 5, S Becker, J.; Schütte, R. (1997): Referenz-Informationsmodelle für den Handel: Begriff, Nutzen und Empfehlungen für die Gestaltung und unternehmensspezifische Adaption von Referenzmodellen. In: Wirtschaftsinformatik 97. Hrsg. Springer 1997, S Becker, S. (2008): Coupled model transformations for QoS enabled component-based software design. Diss., Carl von Ossietzky University of Oldenburg Becker, S.; Grunske, L.; Mirandola, R.; Overhage, S. (2006): Performance Prediction of Component-Based Systems. In: Architecting Systems with Trustworthy Components (Band 3938). Hrsg.: Reussner, R.; Stafford, J.; Szyperski, C. Springer Berlin Heidelberg 2006, S Becker, S.; Koziolek, H.; Reussner, R. (2007): Model-Based Performance Prediction with the Palladio Component Model. Vorgestellt in: Proceedings of the 6th international workshop on Software and performance, S Becker, S.; Koziolek, H.; Reussner, R. (2009): The Palladio component model for modeldriven performance prediction. In: Journal of Systems and Software, Band 82 (2009) Nr. 1, S Brosig, F.; Kounev, S.; Krogmann, K. (2009): Automated Extraction of Palladio Component Models from Running Enterprise Java Applications. Vorgestellt in: Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools, S. 10. Brown, A.W.; Wallnau, K.C. (1998): The Current State of CBSE. In: Software, IEEE, Band 15 (1998) Nr. 5, S Buzen, J.P. (1971): Queueing Network Models of Multiprogramming. Master's Thesis, Harvard Chen, S.; Liu, Y.; Gorton, I.; Liu, A. (2005): Performance prediction of component-based applications. In: Journal of Systems and Software, Band 74 (2005) Nr. 1, S Dehling, H.; Haupt, B. (2004): Einführung in die Wahrscheinlichkeitstheorie und Statistik, Springer, Berlin Distributed Management Task Force (2003): CIM Metrics Model White Paper. zugegriffen am

62 Distributed Management Task Force (2013a): CIM Frequently Asked Questions. zugegriffen am Distributed Management Task Force (2013b): CIM Schema: Version zugegriffen am Franks, G.; Al-Omari, T.; Woodside, M.; Das, O.; Derisavi, S. (2009): Enhanced Modeling and Solution of Layered Queueing Networks. In: Software Engineering, IEEE Transactions on, Band 35 (2009) Nr. 2, S Georges, A.; Buytaert, D.; Eeckhout, L. (2007): Statistically Rigorous Java Performance Evaluation. In: ACM SIGPLAN Notices, Band 42 (2007) Nr. 10, S Gilly, K.; Brosig, F.; Nou, R.; Kounev, S.; Juiz, C. (2012): Online Prediction: Four Case Studies. In: Resilience Assessment and Evaluation of Computing Systems. Hrsg. Springer 2012, S Gradl, S. (2012): Performance-Modellierung und Simulation eines SAP-ERP-Systems. Diss., Technische Universität München Hibernate Team (2013): Hibernate Reference Documentation. zugegriffen am Huffman, D.A. (1952): A Method for the Construction of Minimum-Redundancy Codes. In: Proceedings of the IRE, Band 40 (1952) Nr. 9, S Internet Engineering Task Force (1996): RFC DEFLATE Compressed Data Format Specification version zugegriffen am Kobayashi, H.; Mark, B.L. (2009): System Modeling and Analysis: Foundations of System Performance Evaluation. (1 Aufl.), Pearson Education International Kolmogorov, A.N. (1933): Sulla determinazione empirica di una legge di distribuzione. In: Giornale dell Istituto Italiano degli Attuari, Band 4 (1933) Nr. 1, S Kounev, S. (2005): Performance Engineering of Distributed Component-Based Systems. Diss., Technische Universität Darmstadt Kounev, S. (2006): Performance Modeling and Evaluation of Distributed Component-Based Systems Using Queueing Petri Nets. In: Software Engineering, IEEE Transactions on, Band 32 (2006) Nr. 7, S Koziolek, H. (2010): Performance Evaluation of Component-based Software Systems: A Survey. In: Performance Evaluation, Band 67 (2010) Nr. 8, S Koziolek, H.; Becker, S.; Happe, J. (2007): Predicting the Performance of Component- Based Software Architectures with different Usage Profiles. In: Software Architectures, Components, and Applications. Hrsg. Springer 2007, S

63 Lavenberg, S. (1983): Computer Performance Modeling Handbook (Band 4), Academic Press Inc Mayer, M. (2013): Performance-Modellierung und Simulation eines SAP-Netweaver-Portal- Systems. Diss., Technische Universität München Menascé, D.A.; Almeida, V.A.F.; Dowdy, L.W. (1994): Capacity Planning and Performance Modeling: From Mainframes to Client-Server Systems, Prentice-Hall, Inc Noorshams, Q.; Bruhn, D.; Kounev, S.; Reussner, R. (2013): Predictive Performance Modeling of Virtualized Storage Systems using Optimized Statistical Regression Techniques. Vorgestellt in: Proceedings of the ACM/SPEC international conference on performance engineering, S Object Management Group (2005a): UML Profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE). 6, zugegriffen am Object Management Group (2005b): UML Profile for Schedulability, Performance, and Time Specification. zugegriffen am Object Management Group (2012): Structed Metrics Metamodel (SMM). zugegriffen am Oracle (2013): Java Platform, Enterprise Edition (Java EE) Specification, v7. zugegriffen am Palladio Team (2013): Palladio Workflow Engine - SDQ Wiki. zugegriffen am Palladio Team (o.j.): Palladio Simulator Website. zugegriffen am Pautasso, C.; Zimmermann, O.; Leymann, F. (2008): RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision. Proceedings of the 17th international conference on World Wide Web (S ). Beijing, China: ACM. Reussner, R. (2001): Parametrisierte Verträge zur Protokolladaption bei Software- Komponenten, Logos Berlin Reussner, R.; Becker, S.; Happe, J.; Koziolek, H.; Krogmann, K.; Kuperberg, M. (2007): The Palladio Component Model (Interner Bericht 21). Universität Karlsruhe (TH), Sauer, C.H.; MacNair, E.A. (1983): Simulation of Computer Communication Systems, Prentice Hall Professional Technical Reference Smirnov, N.V. (1936): Sur la distribution de w2. In: CR Acad. Sci. Paris, Band 202 (1936), S

64 Smirnov, N.V. (1948): Table for Estimating the Goodness of Fit of Empirical Distributions. In: The Annals of Mathematical Statistics, Band 19 (1948) Nr. 2, S Smith, C.U. (2007): Introduction to Software Performance Engineering: Origins and Outstanding Problems. In: Formal Methods for Performance Evaluation (Band 4486). Hrsg.: Bernardo, M.; Hillston, J. Springer Berlin Heidelberg 2007, S Snavely, A.; Carrington, L.; Wolter, N.; Labarta, J.; Badia, R.; Purkayastha, A. (2002): A Framework for Performance Modeling and Prediction. Vorgestellt in: Supercomputing, ACM/IEEE 2002 Conference. Stephens, M.A. (1992): An Appreciation of Kolmogorov's 1933 Paper (Technical Report 453). Stanford University, Storer, J.A.; Szymanski, T.G. (1982): Data Compression via Textual Substitution. In: J. ACM, Band 29 (1982) Nr. 4, S Sun Microsystems (2009): JSR 317: Java Persistence API, Version zugegriffen am Woodside, M.; Franks, G.; Petriu, D.C. (2007): The Future of Software Performance Engineering Future of Software Engineering (S ): IEEE Computer Society. Wu, P. (2003): A Performance Model for a Network of Prototype Software Routers. Master's Thesis, Carleton University Zur Muehlen, M.; Nickerson, J.V.; Swenson, K.D. (2005): Developing web services choreography standards the case of REST vs. SOAP. In: Decision Support Systems, Band 40 (2005) Nr. 1, S

65 Anhang 55

66 Anhang A Datenmodelle Anhang A.1 CIM Metrics Schema Abbildung 22: CIM Metrics Schema Quelle: (Distributed Management Task Force 2013b) 56

67 Anhang A.2 SMM Kernklassen Abbildung 23: SMM Kernklassen Quelle: (Object Management Group 2012, 9) 57

68 Anhang A.3 SMM Measures Abbildung 24: SMM Measure Klassendiagramm Quelle: (Object Management Group 2012, 12) 58