Embed Size (px)
Citation preview
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 Per-
formance-Analyseplattform
Markus Dlugi
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
Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe.
Garching b. München, den 16.12.2013 ________________________
Ort, Datum Unterschrift
III
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, Simulationsergeb-
nisse 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ögli-
chen soll. Neben dem Service wird zudem ein exemplarischer Client für ein spezifisches Si-
mulationswerkzeug entwickelt, um die Funktionsfähigkeit des Services zu demonstrieren.
Zunächst muss dafür untersucht werden, welche Daten für einen Vergleich von Simulations-
und Messergebnissen notwendig sind; dies geschieht durch ein Literaturreview, das statisti-
sche Verfahren bei der Performance Evaluation untersucht. Anschließend wird eine Work-
load-Definition aufgestellt, welche mithilfe des Kolmogorov-Smirnov-Tests validiert wird.
Mit diesen Daten wird daraufhin ein Datenmodell auf Grundlage des Structured Metrics Me-
tamodel (SMM) gebaut und mithilfe von JPA auf einem JBoss Application Server implemen-
tiert. 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, Work-
load, 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 Ser-
vice 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 specif-
ic 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 simu-
lation 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 appli-
cation server using JPA. Ultimately, possibilities for sending the data to the server are re-
viewed; 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
IV
Inhaltsverzeichnis
Zusammenfassung ............................................................................................................... III
Abbildungsverzeichnis........................................................................................................ VI
Tabellenverzeichnis ............................................................................................................VII
Abkürzungsverzeichnis ................................................................................................... VIII
1 Einleitung ......................................................................................................................... 1
1.1 Motivation ................................................................................................................... 1
1.2 Struktur der Arbeit .................................................................................................... 2
2 Grundlagen ...................................................................................................................... 4
2.1 Performance-Modelle................................................................................................. 4
2.1.1 Allgemeines........................................................................................................... 4
2.1.2 Palladio Component Model................................................................................... 5
2.2 Java EE........................................................................................................................ 6
3 Evaluation von Performance-Modellen .................................................................... 8
3.1 Grundlagen der Evaluation....................................................................................... 8
3.2 Auswahl notwendiger Daten ..................................................................................... 8
3.3 Workload................................................................................................................... 11
3.3.1 Bedeutung von Workload.................................................................................... 11
3.3.2 Workload im Palladio Component Model .......................................................... 11
3.3.3 Definition von Workload .................................................................................... 12
3.3.4 Kolmogorov-Smirnov-Test ................................................................................. 15
3.3.5 Validierung der Definition .................................................................................. 16
3.4 Fazit ........................................................................................................................... 18
4 Datenaustausch zwischen einer Performance-Simulationsumgebung und
einer Performance-Analyseplattform ............................................................................. 20
4.1 Repräsentation von Performance-Daten................................................................ 20
4.1.1 Referenzmodelle.................................................................................................. 20
4.1.2 Common Information Model .............................................................................. 20
4.1.3 Structured Metrics Metamodel............................................................................ 22
4.1.4 Auswahl eines Referenzmodells ......................................................................... 23
4.1.5 Anpassung des Referenzmodells......................................................................... 24
4.2 Übertragung von Performance-Daten.................................................................... 27
4.2.1 Wahl eines Web Services .................................................................................... 27
4.2.2 Definition des Service-Interfaces ........................................................................ 28
4.2.3 Reduzierung des HTTP- und TCP-Overheads .................................................... 30
4.2.4 Reduzierung des Payloads................................................................................... 34
V
4.3 Fazit ........................................................................................................................... 37
5 Architektur des Prototyps .......................................................................................... 39
5.1 Überblick ................................................................................................................... 39
5.2 Java Persistence API ................................................................................................ 39
5.2.1 Grundlagen .......................................................................................................... 39
5.2.2 Abbildung von Vererbung................................................................................... 41
5.2.3 Probleme der Vererbungs- und Generationsstrategie.......................................... 42
5.2.4 Effiziente Persistierung einer großen Zahl von Messungen................................ 43
5.3 Architektur des Clients ............................................................................................ 46
6 Fazit ................................................................................................................................. 49
6.1 Zusammenfassung .................................................................................................... 49
6.2 Ausblick..................................................................................................................... 49
Literaturverzeichnis ............................................................................................................ 51
Anhang ................................................................................................................................... 55
Anhang A Datenmodelle .............................................................................................. 56
VI
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 ..................................................................... 12
Abbildung 5: Klassendiagramm der Workload-Definition ...................................................... 13
Abbildung 6: Beispielhaftes Objektdiagramm der Workload-Definition ................................ 14
Abbildung 7: Grundlegender Ansatz von CIM ........................................................................ 21
Abbildung 8: Grundlegender Ansatz von SMM ...................................................................... 22
Abbildung 9: Datenmodell des Simulation Data Service......................................................... 25
Abbildung 10: Interface des Simulation Data Service ............................................................. 30
Abbildung 11: Generierte SOAP-Nachrichten......................................................................... 31
Abbildung 12: Verbessertes Interface des Simulation Data Service ........................................ 32
Abbildung 13: SOAP-Nachricht des Aufrufs createTimeMeasurementCollection ................. 33
Abbildung 14: Verbesserte SOAP-Nachricht für createTimeMeasurementCollection ........... 34
Abbildung 15: Anteile der Verarbeitungszeit .......................................................................... 37
Abbildung 16: Observation-Klasse mit JPA-Annotationen ..................................................... 40
Abbildung 17: Beispiel für eine JPQL-Abfrage....................................................................... 41
Abbildung 18: INSERT-Zeit pro Messung bei verschiedenen Batch-Größen......................... 44
Abbildung 19: INSERT- und StringBuilder-Zeit pro Messung ............................................... 45
Abbildung 20: Code-Fragment des PMWTJobs ...................................................................... 47
Abbildung 21: Screenshot der Konfiguration des PMWT-Plugins.......................................... 47
Abbildung 22: CIM Metrics Schema 2.38.0 ............................................................................ 56
Abbildung 23: SMM Kernklassen............................................................................................ 57
Abbildung 24: SMM Measure Klassendiagramm.................................................................... 58
Abbildung 25: SMM Collective Measures Klassendiagramm................................................. 59
VII
Tabellenverzeichnis
Tabelle 1: Statistische Verfahren in wissenschaftlichen Publikationen..................................... 9
Tabelle 2: Performance-Metriken in wissenschaftlichen Publikationen.................................. 10
Tabelle 3: Beispielhafte Zahl von Systemaufrufen .................................................................. 14
Tabelle 4: Für die Validierung verwendete Workloads ........................................................... 16
Tabelle 5: Ergebnisse des KS-Tests für 10.000, 20.000 und 600.000 Messungen .................. 17
Tabelle 6: Ergebnisse des KS-Tests für 600.000, 900.000 und 1,2 Mio. Messungen ............. 18
Tabelle 7: Ergebnisse der Optimierung der Übertragung ........................................................ 36
Tabelle 8: Hypothetische Ergebnisse für einen praxisnahen Simulationsdurchlauf ................ 36
VIII
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
IX
RPC Remote Procedure Call
SPE Software Performance Engineering
TCP Transmission Control Protocol
UML Unified Modeling Language
UML-MARTE UML Profile for Modeling and Analysis of Real-Time and Embedded
systems
UML-SPT UML Profile for Schedulability, Performance, and Time Specification
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML Extensible Markup Language
1
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 wur-
den, 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 Langu-
age (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 Eva-
luation stellt eine der größten Herausforderungen und zugleich einen der kritischen Erfolgs-
faktoren 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 verschiede-
nen 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 Simulationser-
gebnisse verschiedener Performance-Werkzeuge empfangen und einheitlich in einer Daten-
bank 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 Funktions-
fä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 Per-
formance-Modellen in der industriellen Praxis zu ermöglichen.
2
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 ver-
schiedener 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 her-
vorgeht, existiert daneben zum einen der Load-Test Data Service, welcher analog zum Simu-
lation 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 Ergeb-
nisse einer Simulation extrahiert, aufbereitet und an den Service schickt,
2. die Konzeption und Entwicklung des Simulation Data Services, inkl. einem Datenmo-
dell, 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 formu-
liert. Diese beinhalten die wissenschaftlichen Fragestellungen, die im Laufe der Arbeit be-
antwortet werden sollen. Jede der Fragen gehört dabei zu einem der drei oben aufgeführten
Bestandteile:
3
1. Welche Daten sind für den Vergleich von Performance-Simulations- und -Mess-
ergebnissen relevant?
2. Wie können die in Forschungsfrage 1 gefundenen Daten in einem einheitlichen For-
mat 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äu-
tert. Danach wird in Kapitel 3 „Evaluation von Performance-Modellen“ die erste Forschungs-
frage behandelt; konkret wird untersucht, welche Daten für eine Evaluation von Performance-
Modellen notwendig sind und wie sich Workloads darstellen lassen. In Kapitel 4 „Datenaus-
tausch zwischen einer Performance-Simulationsumgebung und einer Performance-
Analyseplattform“ wird zunächst in Abschnitt 4.1 die zweite Forschungsfrage behandelt. Da-
zu wird untersucht, welche Möglichkeiten es zur Repräsentation von Messdaten gibt; an-
schließ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 Ka-
pitel 5 „Architektur des Prototyps“ auf die konkreten Eigenschaften der Implementierung,
speziell im Bereich der Persistenz, eingegangen. Schließlich werden in Kapitel 6 „Fazit“ zu-
sammenfassend die Ergebnisse präsentiert und ein Ausblick auf mögliche Erweiterungen ge-
geben.
4
Grundlagen
Performance-Modelle
Allgemeines
Ein Performance-Modell ist ein Abbild eines realen oder gedachten Software-Systems, wel-
ches 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 tref-
fen 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 Ressourcen-
nutzung und der Durchsatz.
Performance-Modelle wurden in den 1970er Jahren entwickelt. 1971 wurde erstmals der Ein-
satz von QNs zur Repräsentation von Performance-Modellen eingesetzt (Buzen 1971). Seither
wurden viele verschiedene Möglichkeiten zur Erstellung von Performance-Modellen entwi-
ckelt. Einerseits existieren Modelle, welche größtenteils analytisch gelöst werden, um Aussa-
gen über die Performance treffen zu können; die wichtigsten Vertreter dieser Kategorie sind
QNs, stochastische Prozessalgebren und stochastische Petri-Netze (Balsamo et al. 2004, 298-
302). 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 ana-
lytische Verfahren in der Regel genauer und wesentlich schneller sind als Simulationen, ha-
ben 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 unter-
teilt 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än-
gige und austauschbare Bausteine, welche eine klar definierte Funktion erfüllen
(Brown/Wallnau 1998, 38). Ein großer Teil der modernen Software-Systeme arbeitet kompo-
nentenbasiert (Chen et al. 2005, 35). Bei solchen Systemen beeinflusst die Architektur die
Performance wesentlich. Allerdings sind Änderungen an der Architektur nach der Implemen-
tierung 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 Editi-
on (Java EE). Diese Infrastruktur beeinflusst die Performance der Komponenten, was bei ei-
ner Evaluation mitberücksichtigt werden muss (Chen et al. 2005, 36). Zwar lassen sich
derartige Systeme auch mittels klassischer QNs oder stochastischer Prozessalgebren modellie-
ren, 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.
5
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 typi-
schen Entwickler-Teams, indem es die Spezifikation des Systems in mehrere Modelle unter-
teilt, 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, so-
dass 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 Mode-
ling 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 Mo-
delle 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 Si-
mulation ein Queueing Network zugrunde (Becker 2008, 109).
6
Java EE
Die Java Platform, Enterprise Edition ist die Spezifikation einer Middleware-Plattform, wel-
che 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, wel-
che den Applikationen eine Laufzeitumgebung und verschiedene Dienste zur Verfügung stel-
len. 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 Con-
tainer und der Enterprise Java Beans (EJB) Container dargestellt. Der Applet Container ist für
7
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 kommunizie-
ren. 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 Daten-
bank. 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 ab-
gelegt 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 implemen-
tieren. 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.
8
Evaluation von Performance-Modellen
Grundlagen der Evaluation
Für eine korrekte Verwendung von Performance-Modellen ist deren Verifikation und Validie-
rung 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 Vali-
dierung, 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 model-
lierten 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 Evalua-
tion vorgenommen, welche wiederum als Grundlage für Änderungen am Modell dient, wo-
raufhin 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 Per-
formance-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 Referenz-
systems 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 Me-
thode 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 vor-
her 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 Untersuchun-
gen 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. „good-
ness-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
9
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 vor-
rangig 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 Verfah-
ren benötigt werden und damit bei einer Übertragung von Ergebnissen an den Simulation Da-
ta Service mitberücksichtigt werden müssen.
Zu diesem Zweck wurde ein Literaturreview durchgeführt, das eine Auswahl an wissenschaft-
lichen 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 predic-
tion“, „software performance model evaluation“, „software performance model validation“
und ähnlichen Kombinationen durchsucht. Die dabei gefundenen Publikationen dienten wei-
terhin als Grundlage für die Suche nach ähnlichen Publikationen derselben Forschungsgrup-
pen. Dies führte schließlich zu einer Auswahl von zwölf wissenschaftlichen Publikationen,
welche eine Evaluation von Performance-Modellen mittels Vergleich von Ergebnissen bein-
halten.
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 an-
dere 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 Ergeb-
nissen zu erschließen. Die Ergebnisse der Untersuchung finden sich in Tabelle 1. Dabei kenn-
zeichnet 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 / PDF1 / CDF2 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)
10
Aus der Tabelle ist ersichtlich, dass ein sehr großer Teil der Publikationen den Vergleich mit-
hilfe des arithmetischen Mittels durchführt, d.h. es werden die Mittelwerte einer oder mehre-
rer 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 Verteilungs-
funktionen wird etwas häufiger durchgeführt; die formalisierte Variante in Form des Kolmo-
gorov-Smirnov-Tests wurde allerdings nur einmal dokumentiert. Fasst man die tiefergehen-
tiefergehenden 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 tieferge-
hende 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 arithmeti-
schen 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 unterlie-
gen (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 übertra-
gen 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 Ant-
wortzeiten 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 Perfor-
mance-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.
11
Zusammenfassend kann gesagt werden, dass alle Ergebnisdaten, die bei einer Simulation ent-
stehen, ü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 wur-
de, 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 Sys-
tem 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 Wor-
kload.
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 festzu-
halten, der Grundlage dieser Ergebnisse war; nur so kann festgestellt werden, ob zwei Ergeb-
nisse 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 be-
schreibt, und den sog. Intensitätsparametern, welche im Modell als Workload bezeichnet wer-
den (Becker et al. 2007, 57). Die Beschreibung des Nutzerverhaltens erfolgt mithilfe von
modifizierten UML Aktivitätsdiagrammen, welche neben den Funktionen, die ein Nutzer auf-
ruft, 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 Intensi-
tätsparameter wird von der Klassifizierung des Workloads bestimmt. Im Allgemeinen werden
Workloads wie folgt klassifiziert:
12
- Offene Workloads sind durch eine Arrival-Rate, welche üblicherweise als λ bezeich-
net wird, gekennzeichnet. Diese drückt aus, wie viele Nutzer auf das System pro Zeit-
einheit zugreifen (Kounev 2005, 136).
- Geschlossene Workloads haben im Gegensatz dazu eine fixe Population, welche aus-
drü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 „Dea-
lerships-Driver Workload“. In dem rechten Kasten ist der Workload dargestellt; in diesem
Fall handelt es sich um einen geschlossenen Workload mit einer Population von 2.000 Nut-
zern und einer Think Time von 9,7 Sekunden. Links davon ist das ScenarioBehaviour abge-
bildet. 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 „iDealerDri-
ver.manage“ mit Wahrscheinlichkeiten von jeweils 25%.
Definition von Workload
Wie in der Workload-Definition des PCM Usage Models zu sehen ist, reicht es, einen Work-
load 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-
13
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ätspara-
meter 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 ge-
schlossener 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 Mo-
dell dient die Klasse Systemfunktion dabei lediglich dazu, die Anzahl der Aufrufe, die diese
spezifische Funktion im gesamten Simulationszeitraum erfahren hat, zu speichern. Dies er-
folgt 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 ge-
speichert, 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 Funktio-
nen „browse“, „purchase“ und „manage“. Es wurde eine Simulation mit einer Simulationszeit
14
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 10.000 5.000 5.000 20.000
purchase 5.000 2.500 2.500 10.000
manage 5.000 2.500 2.500 10.000
Tabelle 3: Beispielhafte Zahl von Systemaufrufen
Quelle: Eigene Darstellung
Aus der Tabelle lässt sich entnehmen, dass die Funktion browse im Zeitabschnitt 1 genau
10.000 Mal aufgerufen wurde, während die Funktionen purchase und manage im selben Zeit-
raum jeweils nur halb so oft aufgerufen wurden. Betrachtet man die Summe der Aufrufe, las-
sen sich Wahrscheinlichkeiten analog zu den stochastischen Ergänzungen des PCM Usage
Models ausdrücken: die Funktion browse wird mit einer Wahrscheinlichkeit von 50% aufge-
rufen, während die Funktionen purchase und manage nur mit jeweils 25-prozentiger Wahr-
scheinlichkeit aufgerufen werden. Die Aufteilung in Zeitabschnitte dient als zusätzliches
Unterscheidungskriterium, wenn zwei Verteilungen sich zwar in der Summe der Aufrufe äh-
neln, aber im Zeitverlauf unterscheiden. So wäre eine Verteilung, bei der browse in den drei
Zeitabschnitten die Aufrufe 5.000, 5.000 und 10.000 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
15
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 Vali-
dierung dieser Definition durchgeführt.
Kolmogorov-Smirnov-Test
Im Folgenden muss nachgewiesen werden, dass eine Definition des Workloads mittels Inten-
sitätsparametern und Nutzerverhalten, welches durch die Anzahl der Systemaufrufe im zeitli-
chen Verlauf beschrieben wird, einen Workload identifiziert und damit den Vergleich von
Workloads zulässt. Zu diesem Zweck werden mehrere Simulationen mit jeweils unterschied-
lichen Workloads durchgeführt, und anschließend verglichen, ob sich die gemessenen Work-
loads 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 italieni-
schen Journal-Artikel veröffentlicht und später von Smirnov (1936) durch Berechnung wich-
tiger 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 Fn(x) und
Gm(x) deren empirische Verteilungsfunktionen sind. Zusätzlich sei Dm,n die größte absolute
Differenz zwischen den Funktionen Fn(x) und Gm(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 entstam-
men, als angenommen, wenn gilt:
√
( ) ( )
√
∑ ( ) ( )⁄
Formel 3: Kolmogorov-Smirnov-Test für zwei Stichproben
Quelle: (Stephens 1992, 4-7; Smirnov 1948, 279)
16
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 mindes-
tens 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 3.3.2 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 unter-
scheiden. 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 unter-
schiedlicher Workloads einen Unterschied mit statistischer Signifikanz nachweisen sollte.
Neben diesem einfachen Vergleich soll geprüft werden, ob bei Ergebnissen, bei denen dersel-
be Workload, aber eine unterschiedliche Laufzeit zugrunde liegt, die Nullhypothese ebenfalls
angenommen wird. Dafür wird jede Simulation mit drei unterschiedlichen Laufzeiten durch-
gefü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 Lauf-
zeit 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 akzep-
tiert, und die Workloads sind gleich, wenn der errechnete Wert bei jeder Systemfunktion un-
ter 1,36 liegt. Jeder Simulationsdurchlauf wird, wie oben erläutert, variiert in Bezug auf die
Laufzeit und den zugrundeliegenden Workload. Die Laufzeiten wurden auf 10.000 Messun-
gen (abgekürzt als 10k), 20.000 Messungen (20k) und 600.000 Messungen (600k) festgelegt.
Es werden zwei verschiedene Workloads verwendet; während die Intensitätsparameter bei
beiden gleich sind (Population von 2.000 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
17
Die Ergebnisse der Untersuchung sind in Tabelle 5 zu sehen, angegeben ist jeweils das Ma-
ximum der Testdurchläufe aller Systemfunktionen. Bei grün unterlegten Feldern wurde die
Nullhypothese wie erwartet angenommen; bei rot unterlegten Feldern wurde die Nullhypothe-
se 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 10.000, 20.000 und 600.000 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 Nullhy-
pothese 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 vergli-
chen 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 Ver-
gleichswert jedoch immer deutlich unter dem kritischen Grenzwert.
Bei näherer Untersuchung der Werte lässt sich zusätzlich zu den bereits getroffen Beobach-
tungen 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 600.000 Messungen wird mit 24,3 sehr deutlich abgelehnt, während die Nullhypo-
these akzeptiert wird, wenn identische Workloads mit jeweils 600.000 Messungen miteinan-
der verglichen werden. Dies deutet darauf hin, dass der Test mit zunehmender Stich-
probengröß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 Lauf-
zeiten 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 durchge-
führt werden, wenn sich das System in einem stabilen Zustand befindet (Kounev 2005, 140).
18
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 Va-
lidierung ein zweites Mal durchgeführt, jedoch dieses Mal mit längeren Simulationslaufzei-
ten. 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 600.000 Messungen (abgekürzt als 600k), 900.000 Messungen (900k) und 1.200.000
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,82
1200k 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,94
1200k 27,71 31,75 34,19 1,23 0,75 0,79
Tabelle 6: Ergebnisse des KS-Tests für 600.000, 900.000 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 dazu-
gehö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 nahe-
liegendste 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 Laufzei-
ten 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 3.3.2 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 Nullhy-
pothese akzeptiert, während dieselbe bei unterschiedlichen Workloads verworfen wurde. Da-
mit 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
19
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üs-
sen zuerst andere statistische Verfahren untersucht und in Bezug auf ihre Eignung evaluiert
werden. Wenn ein Vergleich mithilfe des Kolmogorov-Smirnov-Tests auch möglich er-
scheint, 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üh-
ren. 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 Litera-
turreviews festgestellt, dass eine Reduzierung der Simulationsergebnisse auf bestimmte Met-
riken 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ächs-
te Kapitel, in welchem untersucht wird, wie all diese Daten in einem einheitlichen Datenmo-
dell repräsentiert werden können.
20
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 Datenmo-
dell 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 erstel-
len. Es gibt jedoch bereits Datenmodelle, welche eigens zur Speicherung von Messdaten kon-
zipiert 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 Re-
ferenzmodell „das immaterielle Abbild der in einem realen oder gedachten betrieblichen Ob-
jektsystem verarbeiteten Informationen, das für Zwecke des Informationssystem- und
Organisationsgestalters Empfehlungscharakter besitzt und als Bezugspunkt für unternehmens-
spezifische 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 Informa-
tion 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 Nor-
mungsorganisation verschiedener IT-Unternehmen, welcher u.a. Microsoft, Intel und HP an-
gehö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, 2.38.0, 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 Re-
präsentation der Antwortzeiten von Transaktionen, jedoch wurde die Definition später allge-
mein 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),
21
so wird der Messwert in der Assoziationsklasse UoWMetric abgelegt. Jedes UnitOfWork-
Element beinhaltet dabei nur einen Messwert; die zugehörige UnitOfWorkDefinition spezifi-
ziert 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 Korre-
lation von UnitOfWork-Elementen erlaubt (Distributed Management Task Force 2003, 12).
So kann bspw. die Antwortzeit des Aufrufs einer bestimmten Funktion von einer Datenbank-
abfrage abhängen, welche in dieser Funktion durchgeführt wird. In diesem Fall wäre die Da-
tenbankabfrage 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)
22
Structured Metrics Metamodel
SMM wurde von der Object Management Group (OMG) entwickelt, einem Konsortium, wel-
ches bereits erfolgreiche Standards wie UML oder Common Object Request Broker Architec-
ture (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 Dar-
stellung 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 Metri-
ken als Aggregation von Basismetriken darstellen lassen. Zusätzlich können die Measure-
Definitionen um Berechnungsmethoden erweitert werden, welche in Skriptsprachen wie Ob-
ject Constraint Language (OCL) oder XQuery angegeben werden. Dadurch besteht die Mög-
lichkeit, 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ßkom-
mazahlen 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.
23
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 Mo-
dells 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 gesam-
te 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 er-
ben, sodass das Modell unnötig aufgebläht wird; hier müsste evtl. eine Reduzierung des Mo-
dells auf notwendige Elemente stattfinden. Und schließlich hat CIM den Nachteil, dass sich
eine sequentielle Reihe von Messwerten nicht mit der eigenen SubUoW-Konstruktion abbil-
den 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 wer-
den.
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. Zu-
dem 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ög-
lichkeit 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 Stel-
len, 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.
24
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 Kon-
zepte zu ermöglichen. Bei allen Anpassungen wurde versucht, diese mittels Vererbung durch-
zufü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 ver-
sehen 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 Annota-
tionen 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, festzu-
halten. 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 je-
dem Simulationslauf gleichzeitig das Modell, welches die Ergebnisse erzeugt hat, zu spei-
chern; dadurch ist später direkt ersichtlich, welche Modelle für welche Ergebnisse
verantwortlich sind und es ermöglicht die einfache Wiederholung der Simulationen. Aller-
dings können die Modelle bisweilen sehr groß werden; daher sollte die redundante Persistie-
rung 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 PCMModelS-
cope von HashScope abgeleitet, welche die einzelnen Elemente eines PCM-Modells persis-
tiert. Diese sind das Usage Model, das Allocation Model, das System Model sowie die
Resource Environment; dazu kommen noch mehrere Repository Modelle. Die Modelle, wel-
che in PCM EMF-Objekte vorliegen, werden durch den Client in Extensible Markup Langu-
age (XML) umgewandelt und in der Datenbank als Character Large Objects (CLOB)
persistiert. Wenn der Simulation Data Service um die Unterstützung für weitere Simulations-
werkzeuge nachgerüstet wird, müssen entsprechend zusätzliche Klassen von HashScope oder
ObservationScope abgeleitet werden, um die neuen Modelle darstellen zu können.
25
Abbildung 9: Datenmodell des Simulation Data Service
Quelle: In Anlehnung an (Object Management Group 2012)
26
Die dritte Ergänzung des SMM ist die Repräsentation des Workloads. Wie in Kapitel 3 fest-
gestellt 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 3.3.3 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ätspara-
meter direkt dem Performance-Modell entnommen werden können und daher mit einer Asso-
ziation 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 verschie-
dene Simulationsdurchläufe eine unterschiedliche Verteilung der Batches vorweisen, auch
wenn ihnen dasselbe Modell zugrunde liegt, da der Workload gemessen wurde. Daher befin-
det 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 Perfor-
mance 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 10.000
Messungen abgebrochen wird, so enthält das Endergebnis in Summe über 1 Mio. Measure-
ments; 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 Obser-
vedMeasure 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 Da-
ten in die Datenbank erschwerte diese Konstruktion auch Abfragen in der Datenbank. Sollen
bspw. alle EntryLevelSystemCalls einer Observation abgefragt werden, muss bei der Kon-
struktion gemäß der Spezifikation die komplette Reihe an Messungen auf mögliche EntryLe-
velSystemCall-Objekte untersucht werden. Eine solche Abfrage bei einem Simulations-
durchlauf mit einer Größe von 10.000 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
27
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 Daten-
modell dient als Grundlage der Datenbank und wird mittels Java Persistence API (JPA) im-
plementiert; 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 Simula-
tions- und Messergebnissen notwendig sind und wie diese in einem einheitlichen Datenmo-
dell 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 wer-
den; 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 aufbauen-
de Beschreibungssprache zur syntaktischen Definition von Interfaces (Pautasso et al. 2008,
806). In dieser werden neben den Methoden, die ein Webservice bietet, auch alle Datenstruk-
turen beschrieben, die zur Benutzung des Services notwendig sind. Zur Übertragung der Da-
ten 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 Nach-
richten 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,
28
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 Kommuni-
kation ausschließlich über RPCs. Die Kommunikation ist dabei zustandslos, der Service ver-
waltet 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 Meinun-
gen und Erfahrungen gekennzeichnet (Pautasso et al. 2008, 805). JAX-RS gilt als leichtge-
wichtiger 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 Envelo-
pe 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 „erfor-
schen“ 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 Erstel-
lung 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: top-
down und bottom-up (Pautasso et al. 2008, 809). Während bei einer top-down-Vor-
gehensweise 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 vor-
handenen 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, ausge-
hend 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
29
Realisierung des Ablaufs notwendig sind, abgeleitet werden. Nachfolgend ein möglicher Ab-
lauf:
1. Da die Observation das zentrale Element des Modells ist, muss dieses als erstes ange-
legt 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 zugeord-
net. 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 ge-
speichert.
c. Falls das Modell bereits vorhanden ist, muss im Persistenzkontext eine Ver-
knüpfung der angelegten Observation mit dem vorhandenen Modell erfolgen.
3. Daraufhin wird ein ObservedMeasure-Objekt angelegt und der Observation zugeord-
net. Dieses enthält bereits Referenzen auf die verwendete Measure und den Mea-
surand, 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 existsHashSco-
pe, 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 Aus-
fü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 gene-
riert 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.
30
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 Auf-
schluss 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 10.000 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 Übertra-
gung fand über ein lokales Funknetzwerk nach dem Standard 802.11n statt. Unter diesen Be-
dingungen 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 un-
tersucht, 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 je-
doch 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 6.020 Mes-
sungen beinhaltet. Die SOAP-Nachrichten dieses Durchlaufs sind in Abbildung 11 dargestellt.
@WebService
public interface SimulationDataService {
@WebMethod
public long createObservation(Observation observation);
@WebMethod
public long createObservedMeasure(long observationId,
ObservedMeasure observedMeasure);
@WebMethod
public long createMeasurement(long observedMeasureId,
Measurement measurement);
@WebMethod
public boolean existsHashScope(String hash);
@WebMethod
public void createObservationScope(long observationId,
ObservationScope observationScope);
@WebMethod
public void addHashScopeToObservation(long observationId,
String hash);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
31
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 Be-
obachtungsdatum als Parameter für createObservation, die observationId und ein Measure-
Objekt als Parameter für createObservedMeasure sowie eine observedMeasureId und ein
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:createObservation
xmlns:ns2="http://service.sds.performance.fortiss.org/">
<arg0>
<tool>PCM</tool>
<whenObserved>2013-10-27T15:39:04.603+01:00</whenObserved>
</arg0>
</ns2:createObservation>
</S:Body>
</S:Envelope>
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:createObservedMeasure
xmlns:ns2="http://service.sds.performance.fortiss.org/">
<arg0>1</arg0>
<arg1>
<measure xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" 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="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:createMeasurement
xmlns:ns2="http://service.sds.performance.fortiss.org/">
<arg0>6026</arg0>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<measurand xsi:type="ns2:namedMeasurand">
<name>Response Time of Call_browse0
<EntryLevelSystemCall id: _tvpegOWIEeGF2-
HmZLMMNA></name>
</measurand>
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
</ns2:createMeasurement>
</S:Body>
</S:Envelope>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
32
Measurement-Objekt für createMeasurement. Das Measurement-Objekt besteht neben dem
Measurand aus einem value und einer eventTime. Da der untersuchte Measurand 6.020 Mes-
sungen enthält, werden noch 6.119 weitere createMeasurement-Nachrichten derselben Größe
versendet.
Die Größe der gesamten Transmission Control Protocol (TCP)-Konversation beträgt laut
Wireshark 8.344.774 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 hypotheti-
sche Übertragungsmenge von ca. 180 GiB.
Die Größe aller 6.020 Nachrichten des Aufrufs createMeasurement beträgt laut Wireshark
8.325.591 Bytes, das entspricht 7,9 MiB. Zählt man die Zeichen der Nachricht, so ergibt das
für 6.020 Nachrichten eine Payload-Größe von 3.593.940 Bytes oder 3,4 MiB, und damit ei-
nen durch HTTP und TCP verursachten Overhead von 4.731.651 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.
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 Measu-
rements genutzt wird, verwendet bewusst die Klasse TimeMeasurement als Typparameter und
nicht etwa die abstrakte Klasse Measurement oder einen kovarianten Typparameter. Der
@WebService
public interface SimulationDataService {
@WebMethod
public long createObservation(Observation observation);
@WebMethod
public long createObservedMeasure(long observationId,
ObservedMeasure observedMeasure);
@WebMethod
public long createTimeMeasurementCollection(long
observedMeasureId,
Collection<TimeMeasurement> measurement);
@WebMethod
public boolean existsHashScope(String hash);
@WebMethod
public void createObservationScope(long observationId,
ObservationScope observationScope);
@WebMethod
public void addHashScopeToObservation(long observationId,
String hash);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
33
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 Datenbankta-
belle 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 abs-
traktem 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 Persis-
tierung des Durchlaufs 3 Minuten und 55 Sekunden. Die Gesamtmenge der zu übertragen-
den 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 crea-
teTimeMeasurementCollection generiert wird, ist in der folgenden Abbildung 13 dargestellt.
Abbildung 13: SOAP-Nachricht des Aufrufs createTimeMeasurementCollection
Quelle: Eigene Darstellung
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:createTimeMeasurementCollection
xmlns:ns2="http://service.sds.performance.fortiss.org/">
<arg0>2</arg0>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<measurand xsi:type="ns2:namedMeasurand">
<name>Response Time of Call_browse0
<EntryLevelSystemCall id: _tvpegOWIEeGF2-
HmZLMMNA ></name>
</measurand
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<measurand xsi:type="ns2:namedMeasurand">
<name>Response Time of Call_browse0
<EntryLevelSystemCall id: _tvpegOWIEeGF2-
HmZLMMNA ></name>
</measurand>
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
...
</ns2:createMeasurementCollection>
</S:Body>
</S:Envelope>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
34
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 Än-
derungen 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 4.1.5 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 ak-
tuelle Datenmodell verwendet, sehen die SOAP-Nachrichten für den Aufruf der Methode cre-
ateTimeMeasurementCollection wie in Abbildung 14 dargestellt aus.
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
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:createMeasurementCollection
xmlns:ns2="http://service.sds.performance.fortiss.org/">
<arg0>2</arg0>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
<arg1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:type="ns2:timeMeasurement">
<value>11.461257</value>
<eventTime>21.161257</eventTime>
</arg1>
...
</ns2:createMeasurementCollection>
</S:Body>
</S:Envelope>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
35
auf einen praxisnahen Workload mit 1 Mio. Messungen um, ergibt dies immer noch eine Da-
tenmenge 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 ver-
sendeten 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 Ein-
satz 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ön-
nen. Das gzip-Verfahren wird von einer großen Zahl von Bibliotheken und Umgebungen un-
terstü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 JBoss-
eigenen 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 ent-
sprechenden JBoss Deployment Structure.
Nach Aktivierung von gzip wurde die Messung schließlich erneut durchgeführt. Die Daten-
menge 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 Simulationsdurchlau-
fes, 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 Kompressi-
onsrate von etwa 98%. Der gesamte Vorgang der Übertragung und Persistierung des exemp-
larischen 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.
36
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 Simulationsdurch-
lauf mit einer Größe von 10.000 Messungen, die Angaben zur Datenmenge wurden bei den
ersten beiden Messungen jeweils aus dem Measurand mit 6.020 Messungen hochgerechnet. In
Tabelle 8 findet sich eine Auflistung der Ergebnisse, welche für den praxisnahen Simulati-
onsdurchlauf 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 kei-
nen ü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 die-
sem 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ön-
nen die Clients in diesem Fall stets davon ausgehen, dass der Server gzip-komprimierte Da-
tenströme unterstützt.
Dennoch zeigt das Beispiel, welchen großen Einfluss eine sorgfältige Planung und Optimie-
rung 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 10.000 Messungen
über 18 Stunden benötigte. Theoretisch hätte dabei eine Datenmenge von ca. 180 GiB über-
tragen 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%.
37
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 ak-
tuellsten 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 Se-
kunden oder 49%. Auf der linken Seite ist der Anteil dargestellt, welchen allein die Persistie-
rung 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 Ent-
wicklung 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
34
36
Anteile der Verarbeitungszeit
Kompression & Übertragung Persistierung
38
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 Be-
ginn der Arbeit aufgestellt wurden, beantwortet. Im nächsten Kapitel wird schließlich betrach-
tet, welche konkreten Eigenschaften die Implementierung des Prototyps aufweist; ins-
besondere die technische Umsetzung des Datenmodells aus Abschnitt 4.1 wird dort behandelt.
39
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 wer-
den 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 Simulationsergeb-
nisse an den Service senden. Ein Teil der Entwicklung des Prototyps war die Implementie-
rung 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 Datenbank-
managementsystem (DBMS) wird MySQL verwendet. Die Implementierung des Web Ser-
vices 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 Fol-
genden beschrieben, wie die praktische Implementierung des theoretischen Datenmodells
erfolgt ist. Zu diesem Zweck wird im kommenden Abschnitt die Java Persistence API be-
schrieben.
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 relationa-
len 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 gekenn-
zeichnet, 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 An-
notationen, mit denen das ORM präziser gesteuert werden kann. Insbesondere sind häufig die
Annotation OneToOne, OneToMany bzw. ManyToOne und ManyToMany anzutreffen; diese
40
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 16.
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 ObservationSco-
pe 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 Datenmo-
dell 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 ver-
waltet. 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.
@Entity
@Table(name = "observation")
public class Observation extends SmmElement {
private String observer;
private String tool;
private Date whenObserved;
@ManyToMany(cascade = CascadeType.PERSIST)
public Collection<ObservationScope> scopes;
@OneToMany(cascade = CascadeType.REMOVE, fetch =
FetchType.LAZY)
public Collection<ObservedMeasure> observedMeasures;
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
41
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 Unterklas-
sen 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: Sin-
gle Table, Joined Subclass und Table per Concrete Class (Sun Microsystems 2009, 56).
Bei Single Table-Vererbung werden alle Klassen einer Vererbungshierarchie in einer Daten-
banktabelle 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 Ta-
bellenzeile angehört. Single Table-Vererbung bietet den Vorteil, dass Abfragen, welche meh-
rere 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 ei-
gene 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 abgebil-
det, 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 Vererbungs-
hierarchie eine eigene Tabelle, welche alle Attribute enthält, die die Klasse besitzt, also auch
...
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();
...
1
2
3
4
5
6
7
8
9
10
11
12
42
geerbte Attribute. Abstrakte Klassen werden nicht in der Hierarchie abgebildet. Dadurch er-
fordern 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 Mo-
dells von der Klasse SmmElement erbt; dadurch besteht die Datenbank bei Verwendung die-
ser 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 Per-
sistierung von wenigen Simulationsdurchläufen schon so groß sein, dass das Auffinden ande-
rer 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 abstrak-
ten Klasse Measurement gespeichert ist, während der Wert der Measurement in der Klasse
DimensionalMeasurement abgelegt ist, während der Zeitpunkt in der Klasse TimeMeasure-
ment 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 Strate-
gie 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 voraussicht-
lich 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 verwen-
deten Persistence Provider, die Wahl des GenerationType bei generierten IDs einschränkt.
Wie in Abschnitt 5.2.1 beschrieben, dienen IDs dazu, jedes Objekt eindeutig identifizierbar zu
machen. Häufig wird bei der Verwendung von IDs auch die Annotation GeneratedValue ver-
wendet, 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.
43
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 Kon-
flikte zu vermeiden. Daher ist keine ID-Verwaltung innerhalb der individuellen Klassen mehr
möglich. Stattdessen kann der GenerationType TABLE verwendet werden. Wird der Genera-
tionType TABLE verwendet, benutzt Hibernate eine eigene Datenbanktabelle zur Speiche-
rung 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 Da-
tenbank 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 Simu-
lation Data Service sehr problematisch; selbst kleine Simulationsdurchläufe haben mehrere
Millionen Messungen, welche alle in die Datenbank eingefügt werden müssen. Dies ver-
schärft das Problem, dass mehrere Millionen einzelne INSERT-Operationen schon sehr inper-
formant sind, noch zusätzlich. Dieses Problem war auch die Ursache dafür, dass die Laufzeit
der ersten Versuchsläufe in Abschnitt 4.2.3 ü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 stapel-
weise Verarbeitung der INSERT-Operationen; so können mehrere Messungen mit einem ein-
zigen 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 ei-
ner großen Zahl von Messungen ermöglichen.
Zu diesem Zweck wurde zunächst untersucht, was eine gute Batch-Größe für die Persistie-
rung 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 über-
prü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 Inkre-
mentierung 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 Abbil-
dung 18 zu sehen.
44
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 Aus-
reißer im Rahmen von 0,05 bis 0,1 Nanosekunden pro Messung. Die orange dargestellte line-
are 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 21.000 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 nachfol-
genden 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. 7.000 Messungen keinen nennenswerten Anteil an der gesamten Ausführungs-
zeit. Ab der Marke von etwa 7.000 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 20.000 Messungen der Punkt
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
0,4
1 1600 3200 4800 6400 8000 9600 11200 12800 14400 16000 17600
INSERT-Zeit / Messung
45
erreicht ist, an dem die Ausreißer keine Ausreißer mehr sind. Dabei ist auch zu sehen, dass ab
etwa 18.000 Messungen auch die Ausführungszeit der Query unter dem Speichermangel des
Systems leidet. Bei etwa 21.000 Messungen ist das System schließlich voll ausgelastet und
kann den Speicherbedarf des StringBuilders nicht mehr bedienen, sodass es zum Abbruch
kommt.
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 verscho-
ben, 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 wur-
den, scheint eine Batch-Größe von etwa 10.000 Messungen ein guter Kompromiss zu sein, da
die Ausreißer des StringBuilders bei dieser Marke nur recht sporadisch auftreten. Es ist je-
doch 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 Produk-
tivsystem, 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 Untersu-
chung aller möglichen Parameter eines DBMS, durch welche eine Verbesserung der Ausfüh-
rungszeit von INSERT-Queries erreicht werden kann, den Rahmen dieser Arbeit sprengen.
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
0,4
0,45
0,5
200 1800 3400 5000 6600 8200 9800 11400 13000 14600 16200 17800 19400 21000
INSERT-Zeit / Messung StringBuilder-Zeit / Messung
46
Mit der hier ermittelten Batch-Größe von 10.000 Messungen kann aber zumindest eine eini-
germaßen effiziente Verarbeitung der Simulationsergebnisse erreicht werden, wie an den
Messungen der Laufzeit in Abschnitt 4.2.4 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 Per-
formanceverbesserungen zu erreichen.
Damit wurde die Funktionsweise des Prototyps des Simulation Data Service hinreichend be-
trachtet. 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 mittler-
weile 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 Integra-
tion gegeben, da selbst komplexere Funktionalitäten der Palladio-Bench wie die Sensitivitäts-
analyse nicht berücksichtigt werden müssen, da sie automatisch funktionieren.
Der Hook ruft die selbstdefinierte Klasse PMWTJob auf, welche alle weiteren Jobs zur Über-
tragung der Simulationsergebnisse definiert und ausführt. Ein Code-Fragment dieser Definiti-
on 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.
47
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 3.4.0. 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 Konfigurations-
klassen von SimuCom geändert werden. Die Änderungen beschränken sich jedoch auf 2 Pa-
kete, sodass bei einer Versionsaktualisierung nicht viel Code angepasst werden muss.
Abbildung 21: Screenshot der Konfiguration des PMWT-Plugins
Quelle: Eigene Darstellung
// 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);
1
2
3
4
5
6
7
8
9
10
48
Ein Screenshot des Konfigurationsdialoges findet sich in der Abbildung 21. Darin sind zu-
nä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 Konfi-
gurationsparameter „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 ange-
passt werden mussten, werden als Eclipse Feature Patch ausgeliefert. Über den Eclipse-
Menüpunkt „Install New Software…“ kann das PMWT-Plugin so mit wenigen Klicks instal-
liert werden.
49
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 unter-
sucht, welche Daten speziell für den Vergleich von Performance-Simulations- und Mess-
ergebnissen notwendig sind. Das Ergebnis war, dass eine Reduktion der Daten im Rahmen
einer statistisch rigorosen Evaluation nicht sinnvoll ist, und dass zudem der Workload not-
wendig ist, um feststellen zu können, ob zwei Ergebnisse vergleichbar sind. Daraufhin wurde
ein Workload-Modell entwickelt, welches mithilfe des Kolmogorov-Smirnov-Tests erfolg-
reich 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 notwendi-
gen 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 erho-
ben 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 Simulations-
ergebnissen, 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 Simulati-
onsergebnis ä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 die-
sen spezifischen Aufgaben gibt es viele weitere Teilbereiche der PMWT, welche noch in Pla-
nung 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.
50
Zusätzlich zu den Beiträgen für die PMWT liegt der Wert dieser Arbeit auch in der Verwen-
dung von SMM für die Repräsentation von Simulationsergebnissen, welche mithilfe von Per-
formance-Modellen erhoben wurden; dadurch eröffnet diese Arbeit Möglichkeiten für weitere
Anwendungen von SMM in der Performance-Forschung, welche wiederum in Verbesserun-
gen der Nutzbarkeit resultieren können. Und dadurch hat diese Arbeit sowohl einen theoreti-
schen als auch praktischen Beitrag dazu geleistet, dass Performance-Modelle in Zukunft nicht
mehr nur von Wissenschaftlern benutzt werden; einen Beitrag zur Verbesserung und Verbrei-
tung von Performance-Modellen, sodass sie helfen können, viele der heutigen Probleme in der
Software-Entwicklung zu lösen.
51
Literaturverzeichnis
Apache Software Foundation (o.J.): Apache CXF Project Website. http://cxf.apache.org/,
zugegriffen am 14.12.2013.
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. 295-310.
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. 427-448.
Becker, S. (2008): Coupled model transformations for QoS enabled component-based software design. Diss., Carl von Ossietzky University of Oldenburg 2008.
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. 169-192.
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. 54-65.
Becker, S.; Koziolek, H.; Reussner, R. (2009): The Palladio component model for model-
driven performance prediction. In: Journal of Systems and Software, Band 82 (2009) Nr. 1, S. 3-22.
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. 37-46.
Buzen, J.P. (1971): Queueing Network Models of Multiprogramming. Master's Thesis, Harvard 1971.
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. 35-43.
Dehling, H.; Haupt, B. (2004): Einführung in die Wahrscheinlichkeitstheorie und Statistik, Springer, Berlin 2004.
Distributed Management Task Force (2003): CIM Metrics Model White Paper.
http://www.dmtf.org/sites/default/files/standards/documents/DSP0141.pdf, zugegriffen am 14.12.2013.
52
Distributed Management Task Force (2013a): CIM Frequently Asked Questions. http://dmtf.org/about/faq/cim_faq, zugegriffen am 14.12.2013.
Distributed Management Task Force (2013b): CIM Schema: Version 2.38.0. http://dmtf.org/standards/cim/cim_schema_v2380, zugegriffen am 14.12.2013.
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. 148-161.
Georges, A.; Buytaert, D.; Eeckhout, L. (2007): Statistically Rigorous Java Performance Evaluation. In: ACM SIGPLAN Notices, Band 42 (2007) Nr. 10, S. 57-76.
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. 185-202.
Gradl, S. (2012): Performance-Modellierung und Simulation eines SAP-ERP-Systems. Diss., Technische Universität München 2012.
Hibernate Team (2013): Hibernate Reference Documentation.
http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html/, zugegriffen am 14.12.2013.
Huffman, D.A. (1952): A Method for the Construction of Minimum-Redundancy Codes. In: Proceedings of the IRE, Band 40 (1952) Nr. 9, S. 1098-1101.
Internet Engineering Task Force (1996): RFC 1951 - DEFLATE Compressed Data Format
Specification version 1.3. http://tools.ietf.org/html/rfc1951, zugegriffen am 14.12.2013.
Kobayashi, H.; Mark, B.L. (2009): System Modeling and Analysis: Foundations of System Performance Evaluation. (1 Aufl.), Pearson Education International 2009.
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. 83-91.
Kounev, S. (2005): Performance Engineering of Distributed Component-Based Systems.
Diss., Technische Universität Darmstadt 2005.
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. 486-502.
Koziolek, H. (2010): Performance Evaluation of Component-based Software Systems: A
Survey. In: Performance Evaluation, Band 67 (2010) Nr. 8, S. 634-658.
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. 145-163.
53
Lavenberg, S. (1983): Computer Performance Modeling Handbook (Band 4), Academic Press Inc 1983.
Mayer, M. (2013): Performance-Modellierung und Simulation eines SAP-Netweaver-Portal-Systems. Diss., Technische Universität München 2013.
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. 1994.
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. 283-294.
Object Management Group (2005a): UML Profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE). http://www.omg.org/cgi-bin/doc?realtime/2005-2-
6, zugegriffen am 14.12.2013.2013.
Object Management Group (2005b): UML Profile for Schedulability, Performance, and Time Specification. http://www.omg.org/cgi-bin/doc?formal/2005-01-02, zugegriffen
am 14.12.2013.2013.
Object Management Group (2012): Structed Metrics Metamodel (SMM).
http://www.omg.org/spec/SMM/1.0/PDF, zugegriffen am 14.12.2013.
Oracle (2013): Java™ Platform, Enterprise Edition (Java EE) Specification, v7. https://java.net/downloads/javaee-spec/JavaEE_Platform_Spec_FR_candidate.pdf,
zugegriffen am 14.12.2013.
Palladio Team (2013): Palladio Workflow Engine - SDQ Wiki.
http://sdqweb.ipd.kit.edu/wiki/Palladio_Workflow_Engine, zugegriffen am 14.12.2013.
Palladio Team (o.J.): Palladio Simulator Website. http://www.palladio-
simulator.com/de/tools/, zugegriffen am 09.12.2013.
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. 805-814). Beijing, China: ACM.
Reussner, R. (2001): Parametrisierte Verträge zur Protokolladaption bei Software-
Komponenten, Logos Berlin 2001.
Reussner, R.; Becker, S.; Happe, J.; Koziolek, H.; Krogmann, K.; Kuperberg, M.
(2007): The Palladio Component Model (Interner Bericht 21). Universität Karlsruhe (TH), 2007.
Sauer, C.H.; MacNair, E.A. (1983): Simulation of Computer Communication Systems,
Prentice Hall Professional Technical Reference 1983.
Smirnov, N.V. (1936): Sur la distribution de w2. In: CR Acad. Sci. Paris, Band 202 (1936),
S. 449.
54
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. 279-281.
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. 395-428.
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, 1992.
Storer, J.A.; Szymanski, T.G. (1982): Data Compression via Textual Substitution. In: J. ACM, Band 29 (1982) Nr. 4, S. 928-951.
Sun Microsystems (2009): JSR 317: Java™ Persistence API, Version 2.0. http://download.oracle.com/otndocs/jcp/persistence-2.0-fr-eval-oth-JSpec/, zugegriffen am 14.12.2013.
Woodside, M.; Franks, G.; Petriu, D.C. (2007): The Future of Software Performance Engineering. 2007 Future of Software Engineering (S. 171-187): IEEE Computer
Society.
Wu, P. (2003): A Performance Model for a Network of Prototype Software Routers. Master's Thesis, Carleton University 2003.
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. 9-29.
55
Anhang
56
Anhang A Datenmodelle
Anhang A.1 CIM Metrics Schema 2.38.0
Abbildung 22: CIM Metrics Schema 2.38.0
Quelle: (Distributed Management Task Force 2013b)
57
Anhang A.2 SMM Kernklassen
Abbildung 23: SMM Kernklassen
Quelle: (Object Management Group 2012, 9)
58
Anhang A.3 SMM Measures
Abbildung 24: SMM Measure Klassendiagramm
Quelle: (Object Management Group 2012, 12)
59
Anhang A.4 SMM Collective Measures
Abbildung 25: SMM Collective Measures Klassendiagramm
Quelle: (Object Management Group 2012, 32)
