FAKULTÄT FÜR INFORMATIK

DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Master’s  Thesis in Finanz- & Informationsmanagement

Abbildung von Ressourcen-Profilen für Unternehmens- anwendungen durch Performance-Modelle

Kilian Wischer

FAKULTÄT FÜR INFORMATIK

DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Master’s  Thesis in Finanz- & Informationsmanagement

Abbildung von Ressourcen-Profilen für Unternehmens- anwendungen durch Performance-Modelle

Representing Resource Profiles for Enterprise Applica-tions using Performance Models

Bearbeiter: Kilian Wischer Aufgabensteller: Prof. Dr. Helmut Krcmar Betreuer: Andreas Brunnert Abgabedatum: 15. Januar 2014

II

Erklärung

Ich versichere, dass ich diese Master’s  Thesis selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe.

München, den 15. Januar 2014 Kilian Wischer

III

Danksagung

An dieser Stelle möchte ich mich bei all jenen bedanken, die mich bei der Erstellung der vor-liegenden Arbeit sowohl fachlich als auch persönlich unterstützt haben.

Zunächst möchte ich mich bei Prof. Dr. Helmut Krcmar für die Ermöglichung und Förderung dieser Arbeit bedanken.

Besonderer Dank gilt Andreas Brunnert, der durch seine exzellente Betreuung maßgeblich zum Ergebnis dieser Arbeit beigetragen hat.

Weiterhin möchte ich mich bei der fortiss GmbH für die Bereitstellung der notwendigen IT-Infrastruktur bedanken. An dieser Stelle gilt mein Dank auch den Mitarbeitern der Forschungs-gruppe  „Information Systems“, für das angenehme Arbeitsumfeld sowie die konstruktiven Dis-kussionen.

Mein ganz besonderer Dank gilt meiner Familie, die nicht nur bei der Erstellung dieser Arbeit geholfen hat, sondern mir in all den Jahren in jeglicher Hinsicht unterstützend zur Seite stand.

IV

Zusammenfassung

Vor Einführung einer neuen Unternehmensanwendung stellt sich die Frage, welche Hardware benötigt wird, um eine bestimmte Performance, wie Antwortzeiten und Durchsatzraten, zu er-reichen. In Zeiten stetig steigender Energiekosten ist zudem interessant, wie sich der Energie-verbrauch eines Rechenzentrums durch eine neue Unternehmensanwendung erhöht. Für die Beantwortung dieser Fragen erarbeitet diese Arbeit das Konzept eines Ressourcen-Profils einer Unternehmensanwendung. Das Ressourcen-Profil ist ein Modell, welches die Performance so-wie den Ressourcen- und Energiebedarf einer Unternehmensanwendung abbildet. Diese Metri-ken sind abhängig von einer konkreten Hardwareinfrastruktur und dem Benutzerverhalten. In einem idealen Prozess wird das Ressourcen-Profil einmalig vom Softwarehersteller angefertigt und an den Kunden ausgehändigt. Der Kunde spezifiziert seine Hardwareinfrastruktur und sein Benutzerverhalten und kann dadurch die Performance und den Ressourcen- und Energiebedarf der Anwendung in seinem kundenspezifischen Umfeld analysieren. Performance-Modelle sind bereits in der Lage, die Performance und den Ressourcenbedarf von Anwendungssystemen zu prognostizieren. Damit ein Performance-Modell als Ressourcen-Profil dienen kann, ist Voraus-setzung, dass die Softwarearchitektur, die Hardwarearchitektur und das Benutzerverhalten ge-trennt voneinander modelliert werden können. Wichtig ist, dass der modellierte Ressourcen-bedarf Anwendung zwischen zwei Hardwarearchitekturen skaliert werden kann. Das Palladio Component Model (PCM) erfüllt diese Voraussetzungen. Soll ein PCM-Modell als Ressour-cen-Profil agieren, muss ein initial vom Softwarehersteller angefertigtes PCM-Modell auf die Hardwarearchitektur des Kunden angepasst werden. Im initialen PCM-Modell ist der Ressour-cenbedarf der in der Softwarearchitektur modellierten Anwendungsroutinen relativ zur Verar-beitungsgeschwindigkeit der Hardwareressourcen spezifiziert. Diese Arbeit schlägt vor, die Verarbeitungsgeschwindigkeit der Hardwareressourcen im kundenspezifischen Modell anhand von Benchmark-Ergebnissen anzupassen. Dazu wird sowohl für die entsprechende Hardware-ressource beim Softwarehersteller, als auch beim Kunden ein Hardware-Benchmark durchge-führt. Durch den Vergleich der Benchmark-Ergebnisse kann die Verarbeitungsgeschwindigkeit der Hardwareressource im kundenspezifischen PCM-Modell entsprechend skaliert werden. Da PCM keine Funktionalität besitzt, den Energiebedarf eines Anwendungssystems zu prognosti-zieren, wird PCM um das Modellierungselement eines linearen Leistungsaufnahme-Modells erweitert. Das Leistungsaufnahme-Modell prognostiziert die Leistungsaufnahme eines Servers auf Basis der Auslastung spezifizierter Hardwareressourcen. Ein Leistungsaufnahme-Modell kann in einer Kalibrierungsphase für einen Server generiert werden. Dabei werden die Hard-wareressourcen in unterschiedlicher Intensität belastet und gleichzeitig die Leistungsaufnahme des Servers gemessen. Eine lineare Regression auf diesen Messwerten generiert das Leistungs-aufnahme-Modell. Durch Anpassen eines initialen PCM-Modells auf die kundenspezifische Hardwareinfrastruktur und durch Hinzufügen des Leistungsaufnahme-Modells erhält man ein kundenspezifisches Ressourcen-Profil der Unternehmensanwendung. Dieses Konzept eines Ressourcen-Profils auf Basis von PCM wird anhand der Benchmark-Anwendung SPECjEnter-prise2010 evaluiert. Dazu wird ein initiales PCM-Modell für die Anwendung auf einem AMD-basierten Server erstellt und auf einen Intel-basierten Server angepasst. Für beide PCM-Modelle wird ein Leistungsaufnahme-Modell hinzugefügt. Beide Modelle können die Leis-tungsaufnahme des jeweiligen Servers mit einer Abweichung zwischen 10 und 20 % zu den realen Messwerten prognostizieren. Die Antwortzeiten, der Durchsatz und die Auslastung des Prozessors kann in den meisten Fällen mit einer Abweichung unter 10 % prognostiziert werden.

Stichworte: Ressourcen-Profil, Performance Modellierung, Palladio Component Model, Res-sourcenbedarf, Energiebedarf, Unternehmensanwendung

V

Inhaltsverzeichnis

Erklärung ...................................................................................................................... II

Danksagung ................................................................................................................. III

Zusammenfassung....................................................................................................... IV

Inhaltsverzeichnis ........................................................................................................ V

Abbildungsverzeichnis .............................................................................................. VII

Tabellenverzeichnis.................................................................................................. VIII

Formelverzeichnis ....................................................................................................... IX

Anhangsverzeichnis ..................................................................................................... X

Abkürzungsverzeichnis .............................................................................................. XI

1 Einleitung .............................................................................................................. 1

1.1 Forschungsfragen ..................................................................................................... 2

1.2 Aufbau der Arbeit .................................................................................................... 3

2 Ressourcen-Profile für Unternehmensanwendungen ....................................... 6

2.1 Begriffsklärung ......................................................................................................... 6

2.2 Ressourcen- und Energiebedarf eines Anwendungssystems ................................ 8

2.3 Struktur des Ressourcen-Profils ........................................................................... 10

2.4 Anwendungsgebiete für ein Ressourcen-Profil .................................................... 11

3 Performance-Modelle als Basistechnologie für ein Ressourcen-Profil ......... 13

3.1 Performance-Modell-Typen .................................................................................. 14

3.2 Bewertungsschema ................................................................................................. 16

3.3 Queuing Network Model (QNM) .......................................................................... 18

3.3.1 Java Modelling Tools (JMT) ............................................................................ 19 3.3.2 SPE•ED ............................................................................................................ 22

3.4 Layered Queuing Network Model (LQNM) ........................................................ 23

3.4.1 Layered Queuing Network Solver (LQNS) ..................................................... 24 3.4.2 Component Based Modeling Language (CBML) ............................................ 27 3.4.3 UML-to-LQNM ............................................................................................... 28

3.5 Queuing Petri Net Model (QPNM) ....................................................................... 30

3.6 Palladio Component Model (PCM) ...................................................................... 33

3.7 Ansätze aus der Praxis ........................................................................................... 38

3.8 Zusammenfassung und Wahl des Performance-Metamodells ........................... 40

4 Abbildung des Energiebedarfs im Palladio Component Model .................... 44

VI

4.1 Leistungsaufnahme-Modell ................................................................................... 44

4.2 Generierung des Leistungsaufnahme-Modells .................................................... 46

4.3 Integration des Leistungsaufnahme-Modells in das PCM-Metamodell............ 48

4.3.1 Erweiterung des PCM-Metamodells ................................................................ 48 4.3.2 Erweiterung der Simulationsumgebungen ....................................................... 50

5 Transfer eines PCM-Modells zwischen zwei Hardwarearchitekturen ......... 52

5.1 Anpassung der Hardwareressourcen gemäß Benchmark-Ergebnissen ............ 53

5.2 Voraussetzungen für die Transferierbarkeit eines PCM-Modells .................... 55

6 Das Palladio Component Model als Ressourcen-Profil .................................. 57

7 Evaluation ........................................................................................................... 60

7.1 SPECjEnterprise2010-Benchmark ....................................................................... 60

7.1.1 Benchmark-Architektur .................................................................................... 60 7.1.2 Orders Domain ................................................................................................. 61 7.1.3 Benchmark-Driver ............................................................................................ 62

7.2 Versuchsumgebung ................................................................................................ 63

7.3 Erzeugung und Anpassung des Ressourcen-Profils ............................................ 66

7.4 Erstellung der Leistungsaufnahme-Modelle ........................................................ 69

7.5 Vergleich der Mess- und Simulationsergebnisse ................................................. 73

7.5.1 Aufbau der Evaluation ..................................................................................... 73 7.5.2 Evaluation des initialen PCM-Modells ............................................................ 75 7.5.3 Evaluation des angepassten PCM-Modells ...................................................... 77

8 Zusammenfassung und Ausblick ...................................................................... 80

8.1 Zusammenfassung .................................................................................................. 80

8.2 Ausblick ................................................................................................................... 83

Literaturverzeichnis ................................................................................................... 85

Anhang ......................................................................................................................... 93

VII

Abbildungsverzeichnis

Abbildung 1: Aufbau der Arbeit ................................................................................................ 4 Abbildung 2: Typische Architektur eines Anwendungssystems im betrieblichen Kontext ....... 7 Abbildung 3: Einflussfaktoren auf die Performance und den Ressourcen- und Energiebedarf eines Anwendungssystems ......................................................................................................... 9 Abbildung 4: Das Ressourcen-Profil ........................................................................................ 10 Abbildung 5: Anwendungsgebiete für ein Ressourcen-Profil .................................................. 11 Abbildung 6: Performance-Modell .......................................................................................... 13 Abbildung 7: Abstraktionsgrad von Performance-Modellen ................................................... 17 Abbildung 8: Queuing Network Model ................................................................................... 19 Abbildung 9: Java Modelling Tools ......................................................................................... 20 Abbildung 10: Layered Queuing Network Model ................................................................... 24 Abbildung 11: Queuing Petri Net Model ................................................................................. 30 Abbildung 12: Teilmodelle des Palladio Component Models ................................................. 33 Abbildung 13: PCM – Repository Model mit RDSEFF .......................................................... 34 Abbildung 14: PCM – System Model ...................................................................................... 35 Abbildung 15: PCM – Resource Environment Model ............................................................. 35 Abbildung 16: PCM – Allocation Model ................................................................................. 36 Abbildung 17: PCM – Usage Model ........................................................................................ 36 Abbildung 18: Wirkungszusammenhänge beim Energieverbrauch einer Anwendung ........... 44 Abbildung 19: Integration des Leistungsaufnahme-Modells in das PCM-Metamodell .......... 48 Abbildung  20:  Anlegen  des  „Power  Consumption  Models“  im  XML-basierten Editor .......... 49 Abbildung  21:  Graphische  Repräsentation  des  „Power  Consumption  Models“ ...................... 50 Abbildung 22: Erweiterung der Simulationsumgebung ........................................................... 51 Abbildung 23: Power Sensor mit Power Sensor Report .......................................................... 51 Abbildung 24: Abbildung des Ressourcenbedarfs mit PCM ................................................... 52 Abbildung 25: Anpassung eines PCM-Modells an kundenspezifische Hardwareinfrastruktur (einfaches Szenario) ................................................................................................................. 53 Abbildung 26: Anpassung eines PCM-Modells an kundenspezifische Hardwareinfrastruktur (komplexes Szenario) ............................................................................................................... 55 Abbildung 27: PCM als Ressourcen-Profil .............................................................................. 57 Abbildung 28: SPECjEnterprise2010 – Anwendungsarchitektur ............................................ 61 Abbildung 29: SPECjEnterprise 2010 – Orders Domain ......................................................... 62 Abbildung 30: Versuchsumgebung .......................................................................................... 63 Abbildung 31: Generiertes Resource Environment Model ...................................................... 67 Abbildung 32: Initiales Resource Environment Model ............................................................ 67 Abbildung 33: Angepasstes Resource Environment Model .................................................... 69 Abbildung 34: Lineare Regression auf den Messdaten des AMD-basierten Servers .............. 71 Abbildung 35: Lineare Regression auf den Messdaten des Intel-basierten Servers ................ 72 Abbildung 36: SPECjEnterprise2010 – Usage Model ............................................................. 73

VIII

Tabellenverzeichnis

Tabelle 1: Übersicht der untersuchten Performance-Metamodelle .......................................... 42 Tabelle 2: Übersicht der untersuchten Fallstudien zu den Performance-Metamodellen ......... 43 Tabelle 3: Messergebnisse des Kalibrierungslaufs für die Modellgenerierung ....................... 47 Tabelle 4: Initialer AMD-basierter Hardwareserver ................................................................ 64 Tabelle 5: Intel-basierter Ziel-Hardwareserver ........................................................................ 65 Tabelle 6: Load-Driver Server ................................................................................................. 66 Tabelle 7: Vergleich der gemessenen und simulierten Antwortzeiten und Durchsatzzahlen auf dem AMD-basierten Server ..................................................................................................... 76 Tabelle 8: Vergleich der gemessenen und simulierten CPU-Auslastung und Leistungsaufnahme des AMD-basierten Servers ..................................................................................................... 76 Tabelle 9: Vergleich der gemessenen und simulierten Antwortzeiten und Durchsatzzahlen auf dem Intel-basierten Server ....................................................................................................... 78 Tabelle 10: Vergleich der gemessenen und simulierten CPU-Auslastung und Leistungsaufnahme des Intel-basierten Servers ....................................................................... 78 Tabelle 11: Vergleich der beiden Leistungsaufnahme-Modelle für den AMD- und den Intel-basierten Server ........................................................................................................................ 79

IX

Formelverzeichnis

Formel 1: Berechnung des Energieverbrauchs ........................................................................... 8 Formel 2: Ratio Modeling Technique ...................................................................................... 39 Formel 3: Lineares Leistungsaufnahme-Modell eines Servers ................................................ 45 Formel 4: Beispiel eines Leistungsaufnahme-Modells ............................................................ 46 Formel 5: Skalierung der Processing Rate ............................................................................... 54 Formel 6: Leistungsaufnahme-Modell des AMD-basierten Servers ........................................ 71 Formel 7: Leistungsaufnahme-Modell des Intel-basierten Servers .......................................... 72 Formel 8: Berechnung des relativen Fehlers ............................................................................ 75

X

Anhangsverzeichnis

Anhang 1: SPEC CPU2006 Benchmark-Ergebnis des AMD-basierten Servers ..................... 93 Anhang 2: SPEC CPU2006 Benchmark-Ergebnis des Intel-basierten Servers ....................... 94

XI

Abkürzungsverzeichnis

AS Application Server CBML Component Based Modeling Language CPU Central Processing Unit, Prozessor CSV Comma-separated values CORBA Common Object Request Broker Architecture RDSEFF Resource Demanding Service Effect Specifications DB Datenbank DBMS Datenbankmanagementsystem EDF Enterprise Data Fabric EJB Enterprise Java Bean EMF Eclipse Modeling Framework ERP Enterprise Resource Planning FF Forschungsfrage HDD Hard Disk Drive, Festplattenspeicher HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IPMI Intelligent Platform Management Interface Java EE Java Enterprise Edition JDBC Java Database Connectivity JMS Java Message Service JMT Java Modelling Tools JPA Java Persistence API JSP JavaServer Pages JVM Java Virtual Machine LQNM Layered Queuing Network Model LQNS Layered Queuing Network Solver NET Network, Netzwerk PCM Palladio Component Model QNM Queuing Network Model QPME Queuing Petri Net Modeling Environment QPNM Queuing Petri Net Model RAM Random Access Memory, Arbeitsspeicher SAPS SAP Application Performance Standard SPA Stochastic Process Algebra SPE Software Performance Engineering SPEC Standard Performance Evaluation Corporation UML Unified Modeling Language XML Extensible Markup Language

1

1 Einleitung

Vor der Einführung einer neuen Unternehmensanwendung ist es schwierig abzuschätzen, wel-che Hardwareinfrastruktur für den Betrieb der Anwendung bereitgestellt werden muss, um eine bestimmte Performance, also gewisse Antwortzeiten oder Durchsatzraten, zu erzielen. So stellt sich z.B. ein potentieller Kunde eines Softwareherstellers die Frage, ob die bereits existierende Hardwareinfrastruktur ausreichend ist, oder ob zusätzliche Hardware benötigt wird, um die Un-ternehmensanwendung zufriedenstellend betreiben zu können. Im Grunde möchte der Kunde wissen, welche Anforderungen eine Unternehmensanwendung an die Hardwareressourcen ei-nes Servers stellt. Für Einzelbenutzer-Anwendungen, wie Textverarbeitungsprogramme oder Computerspiele, geben die Softwarehersteller meistens die Systemvoraussetzungen an. Die Systemvoraussetzungen beinhalten u.a. die Mindestanforderungen an die Geschwindigkeit be-stimmter Hardwareressourcen, wie dem Prozessor (CPU), dem Arbeitsspeicher (RAM) oder der Festplatte (HDD), um den Bedarf der Anwendung an diese Ressourcen zu erfüllen und damit eine bestimmte Performance zu gewährleisten. Der Bedarf einer Anwendung an be-stimmte Hardwareressourcen wird im Folgenden als Ressourcenbedarf bezeichnet. Eine derar-tige Beschreibung wäre auch für Unternehmensanwendungen nützlich. Es ist aber nicht so ein-fach, den Ressourcenbedarf für Unternehmensanwendungen, die von mehreren Benutzern gleichzeitig benutzt werden, im Vorhinein zu bestimmen. Denn der konkrete Bedarf einer Un-ternehmensanwendung hängt im Gegensatz zu Einzelbenutzer-Anwendungen von mehreren Faktoren ab. So haben u.a. die Anzahl der Benutzer und deren Benutzerverhalten maßgeblichen Einfluss auf den Ressourcenbedarf und damit auf die Performance eines Anwendungssystems. Der Ressourcenbedarf einer Anwendung kann auch nicht unabhängig von der konkreten Hard-wareressource bestimmt werden, denn zwei verschiedene Prozessortypen benötigen z.B. trotz gleicher Prozessorfrequenz unterschiedlich viel Zeit, einen Algorithmus auszuführen. Auf-grund der vielen Abhängigkeiten kann ein Softwarehersteller keine allgemeingültigen Informa-tionen über den Ressourcenbedarf seiner Unternehmensanwendung für den Kunden bereit-stellen.

Neben der Frage der notwendigen Hardware für eine Unternehmensanwendung und der entste-henden Kosten für deren potentiell notwendige Neuanschaffung ist auch der Energiebedarf ei-nes Anwendungssystems eine interessante Information für einen Kunden. Denn neben den Anschaffungskosten für neue Hardware ist auch der Energieverbrauch einer der Hauptkosten-treiber in Rechenzentren (Greenberg et al. 2008, 68). Rechenzentrumsbetreiber unternehmen große Anstrengungen, den Energieverbrauch und die damit verbundenen Kosten zu senken (Fan/Weber/Barroso 2007, 14; Rivoire et al. 2007, 39). Wie der Ressourcenbedarf ist aber auch der Energiebedarf einer Anwendung abhängig von den konkreten Hardwareressourcen und von der durch die Benutzer erzeugten Last.

Wie dargestellt, sind der Ressourcenbedarf und die sich daraus ergebende Performance sowie der Energieverbrauch einer Unternehmensanwendung wichtige Informationen für einen Kun-den. Der Softwarehersteller kann diese Informationen aber aufgrund der geschilderten Abhän-gigkeiten nicht allgemeingültig für alle Kunden bereitstellen. Um diese Problematik zu lösen, entwickelt diese Arbeit das Konzept eines Ressourcen-Profils einer Unternehmensanwendung.

2

Das Ressourcen-Profil ist ein parametrisierbares Modell, welches den Ressourcen- und Ener-giebedarf einer Unternehmensanwendung in Abhängigkeit zur Hardwareinfrastruktur und der Anzahl an Benutzer und deren Benutzerverhalten abbildet. Ein Softwarehersteller kann dieses Modell einmalig erstellen und für die Kunden bereitstellen. Die Kunden können mit diesem Modell den Ressourcen- und Energiebedarf der Anwendung in ihrem kundenspezifischen Um-feld analysieren.

In Kapitel 1.1 wird dargestellt, welche Forschungsfragen im Zusammenhang mit dem Ressour-cen-Profil in dieser Arbeit beantwortet werden. Kapitel 1.2 zeigt den Aufbau der Arbeit.

1.1 Forschungsfragen Die Arbeit beantwortet die drei im Folgenden vorgestellten Forschungsfragen.

Forschungsfrage 1: Welche Ansätze existieren in der Literatur und in der Praxis, den Ressour-cen- und Energiebedarf von serverbasierten Unternehmensanwendungen, die von mehreren Nutzern parallel verwendet werden, zu beschreiben?

Performance-Modelle sind in der Lage, die Performance und den Ressourcenbedarf einer An-wendung in Abhängigkeit einer spezifizierten Last zu prognostizieren. Sie werden nach den Regeln von Performance-Metamodellen erstellt. Zur Beantwortung dieser Forschungsfrage wird anhand einer Literaturrecherche nach Metamodellen gesucht, die es erlauben, den Res-sourcen- und Energiebedarf einer Unternehmensanwendung in Abhängigkeit einer bestimmten Nutzerlast in einem Modell abzubilden. Des Weiteren wird ein Bewertungsschema ausgearbei-tet, nach dem die einzelnen Performance-Metamodelle auf die Eignung zur Repräsentation ei-nes Ressourcen-Profils untersucht werden. Da das Ressourcen-Profil einen hohen praktischen Nutzen hat, wird im Rahmen dieser Forschungsfrage auch untersucht, wie Softwarehersteller versuchen den Kunden bei der Analyse des Ressourcen- und Energiebedarf ihrer Unterneh-mensanwendung zu helfen. Insbesondere wird untersucht inwiefern dort parametrisierbare Mo-delle zur Analyse des Ressourcen- und Energiebedarfs zum Einsatz kommen.

Forschungsfrage 2: Wie kann der Energiebedarf von Unternehmensanwendungen in einem auf Performance-Modellen basierenden Ressourcen-Profil abgebildet werden?

Durch die Beantwortung der ersten Forschungsfrage stellt sich heraus, dass keines der unter-suchten Performance-Metamodelle die Möglichkeit vorsieht, den Energiebedarf eines Anwen-dungssystems abzubilden. Zur Beantwortung der obigen Forschungsfrage soll daher ein Kon-zept entwickelt werden, wie der Energiebedarf auf Basis eines Performance-Modells abgebildet werden kann. Im speziellen wird ein Konzept erarbeitet und implementiert, welches Perfor-mance-Modelle auf Basis des Palladio Component Models (PCM) (Becker/Koziolek/Reussner 2009) um die Funktionalität zur Abbildung des Energieverbrauchs erweitert. Da das Ressour-cen-Profil ein Austauschmedium zwischen Softwarehersteller und Kunde ist, muss in diesem Zusammenhang auch beantwortet werden, wie ein Ressourcen-Profil konkret durch ein PCM-Modells realisiert werden kann.

3

Forschungsfrage 3: Wie genau kann die Simulation auf Basis des erweiterten Performance-Modells den Energiebedarf der realen Unternehmensanwendung abbilden?

Damit ein solches Ressourcen-Profil in der Praxis Verwendung finden kann, muss es eine hohe Genauigkeit aufweisen. Die Prognose des Ressourcen- und Energiebedarfs einer Anwendung sollte also mit einer zufriedenstellenden Präzision der Realität entsprechen. Durch die Beant-wortung dieser Forschungsfrage soll daher evaluiert werden, welche Präzision mit dem in der zweiten Forschungsfrage entwickelten Ansatz eines Ressourcen-Profils erreicht werden kann. Insbesondere wird evaluiert, wie genau der Energiebedarf eines Anwendungssystems mit dem erweiterten PCM-Modell prognostiziert werden kann. Dazu soll ein Ressourcen-Profil auf Ba-sis von PCM für die Benchmark-Anwendung SPECjEnterprise2010 (SPEC 2010a) erstellt wer-den und die Simulationsergebnisse mit den realen Messergebnissen verglichen werden.

1.2 Aufbau der Arbeit Zur Bearbeitung der Forschungsfragen ist  diese  Arbeit  in  Anlehnung  an  den  „Design Science“-Prozess von Pfeffers et al. (2006, 89-92) aufgebaut. Diese Arbeit fasst die ursprünglich sechs Phasen zu vier Phasen zusammen. Die erste Phase ist die Problem- und Zielbeschreibung. Hier-bei wird das bestehende Problem beschrieben, welches durch die Arbeit gelöst werden soll. Ausgehend von der Problembeschreibung wird das Ziel der Arbeit formuliert. Der Weg zur Zielerreichung wird in der zweiten Phase, der Konzeptions- und Entwicklungsphase, beschrie-ben. Die dritte Phase in dieser Arbeit ist die Demonstrations- und Evaluationsphase. Hier wird die entwickelte Lösung anhand einer Fallstudie getestet und evaluiert, inwiefern das angestrebte Ziel erreicht wurde. In der vierten Phase werden die Ergebnisse zusammengefasst und weiterer Forschungsbedarf aufgezeigt.

In Abbildung 1 ist der Aufbau der Arbeit in Anlehnung an diesen Prozess abgebildet. Zusätzlich ist dargestellt, in welchen Kapiteln die jeweiligen Forschungsfragen (FF) behandelt werden.

4

Abbildung 1: Aufbau der Arbeit Quelle: In Anlehnung an (Gradl 2012, 11)

Kapitel 1 motiviert die Notwendigkeit einer Beschreibung des Ressourcen- und Energiebedarfs einer Unternehmensanwendung.

In Kapitel 2 werden zunächst die begrifflichen Grundlagen gelegt, die zum Verständnis der restlichen Arbeit benötigt werden. Anschließend wird gezeigt, warum es so schwierig ist, den Ressourcen- und Energiebedarf einer Unternehmensanwendung zu bestimmen, indem die ver-schiedenen Einflussfaktoren dargestellt werden. Das Kapitel zeigt auch, wie ein Ressourcen-Profil diese Einflussfaktoren in einem Modell, welches zwischen einem Softwarehersteller und einem Kunden ausgetauscht werden kann, abbilden soll. Um die Nützlichkeit eines solchen Ressourcen-Profils aufzuzeigen, werden verschiedene Anwendungsfälle demonstriert.

Kapitel 3 beantwortet die erste Forschungsfrage. Dazu wird gezeigt, dass Performance-Mo-delle sich als grundlegende Technologie eines Ressourcen-Profils eignen. Das Kapitel geht auf die grundlegende Theorie der Performance-Modelle ein und erklärt, dass Performance-Modelle nach den Regeln eines Performance-Metamodells erstellt werden. Um die Eignung eines Per-formance-Metamodells zur Repräsentation eines Ressourcen-Profils zu analysieren, erarbeitet

1. Einleitung

2. Das Ressourcen-Profil

Problem- und Zielbeschreibung

Konzeption und Entwicklung 3. Performance-Modelle

als Ressourcen-Profile FF 1

4. Abbildung des Energiebedarfs in PCM

5. Transformation eines PCM-Modells

6. PCM als Ressourcen-Profil

FF 2

7. Evaluation FF 3

8. Zusammenfassung und Ausblick

Demonstration und Evaluation

Kommunikation

5

das Kapitel ein Bewertungsschema. Auf Basis dieses Bewertungsschemas werden mehrere Per-formance-Metamodelle untersucht. Auf Grundlage dieser Untersuchung trifft das Kapitel eine Auswahl eines Performance-Metamodells, mit dem das Konzept des Ressourcen-Profils in den weiteren Kapiteln weiterverfolgt wird. Es wird sich für das Palladio Component Model (PCM) entschieden.

Da PCM keine Funktionalität besitzt, den Energiebedarf eines Anwendungssystems zu prog-nostizieren, wird PCM in Kapitel 4 um das Modellierungselement eines linearen Leistungsauf-nahme-Modells erweitert. Dazu wird das Konzept des Leistungsaufnahme-Modells erläutert und gezeigt, wie ein solches Modell in einem Kalibrierungslauf generiert werden kann. An-schließend wird auf die Erweiterung des PCM-Metamodells und dessen Simulationsumgebung eingegangen. Damit beantwortet dieses Kapitel den ersten Teil der zweiten Forschungsfrage, wie der Energiebedarf in einem PCM-Modell abgebildet werden kann.

Da das Ressourcen-Profil ein austauschbares Modell zwischen Softwarehersteller und Kunden sein soll, wird in Kapitel 5 gezeigt, wie ein vom Softwarehersteller initial erstelltes PCM-Modell seiner Unternehmensanwendung auf die Hardwareinfrastruktur eines Kunden angepasst werden kann. Damit beantwortet dieses Kapitel den zweiten Teil der zweiten Forschungsfrage, wie ein PCM-Modell als Austauschmedium, also als Ressourcen-Profil, dienen kann.

Nachdem in Kapitel 4 und 5 die Grundlagen für ein Ressourcen-Profil auf Basis von PCM gelegt wurden, wird in Kapitel 6 der Gesamtprozess zwischen Softwarehersteller und Kunde erläutert. Dabei wird gezeigt, welche PCM-Teilmodelle der Softwarehersteller und der Kunde erstellen müssen und wie bestimmte Teilmodelle angepasst werden müssen. Somit trägt dieses Kapitel zusammenfassend zur Beantwortung der zweiten Forschungsfrage bei.

In Kapitel 7 wird das Konzept eines Ressourcen-Profils auf Basis von PCM anhand einer Fall-studie evaluiert und damit die dritte Forschungsfrage beantwortet. Dazu wird ein PCM-Modell der Benchmark-Anwendung SPECjEnterprise2010 auf einer initialen Hardwareinfrastruktur erstellt und das Modell auf eine Ziel-Hardwareinfrastruktur angepasst. Für beide PCM-Modelle werden die Simulationsergebnisse mit den realen Messergebnissen verglichen.

Kapitel 8 fasst die Ergebnisse dieser Arbeit zusammen und geht auf weiteren Forschungsbedarf ein.

6

2 Ressourcen-Profile für Unternehmensanwendungen

Dieses Kapitel stellt das Konzept eines Ressourcen-Profils für eine Unternehmensanwendung vor. Dazu zeigt zunächst Kapitel 2.1 auf, welche Arten von Unternehmensanwendungen be-trachtet werden, für die das Ressourcen-Profil konzipiert wird. Des Weiteren legt das Kapitel 2.1 die begrifflichen Grundlagen dar, die für das Verständnis der weiteren Arbeit notwendig sind. Kapitel 2.2 erläutert, welche Abhängigkeiten bei der Betrachtung der Performance und des Ressourcen- und Energiebedarfs eines Anwendungssystems zwischen der Hardwareinfra-struktur und der darauf laufenden Software bestehen. Das Ressourcen-Profil muss diese Ab-hängigkeiten in geeigneter Form abbilden. Die Grundidee und die Funktionsweise des Ressourcen-Profils einer Unternehmensanwendung wird daher in Kapitel 2.3 dargelegt. Kapi-tel 2.4 geht auf verschiedene Anwendungsfälle für ein solches Ressourcen-Profil ein.

2.1 Begriffsklärung Um ein einheitliches Verständnis über die verwendeten Fachbegriffe zu schaffen, geht dieses Kapitel auf die wichtigsten Begriffe im Zusammenhang mit dem Ressourcen-Profil ein. Zu-nächst wird geklärt, welche Arten von Unternehmensanwendungen betrachtet werden. An-schließend werden die Begriffe Anwendungskomponente, Ressource, Ressourcenbedarf, Energiebedarf und Performance geklärt.

Unternehmensanwendung und Anwendungssystem Die betrachteten Unternehmensanwendungen sind serverbasierte Anwendungen, die von meh-reren Endbenutzern gleichzeitig genutzt werden können. Abbildung 2 zeigt eine typische Ar-chitektur eines Anwendungssystems, wie es in dieser Arbeit betrachtet wird. Die Unter-nehmensanwendung wird dabei in mehreren Schichten auf mehreren Servern, die über eine Netzwerkverbindung miteinander verbunden sind, installiert. Typischerweise gibt es in der Da-tenhaltungsschicht einen oder mehrere Datenbankserver, die für die Speicherung von Informa-tionen zuständig sind. Darauf aufbauend gibt es die Businessschicht, welche die Anwendungslogik beinhaltet. Die Präsentationsschicht ist für die Aufbereitung der Daten für den Benutzer zuständig und bildet die Benutzerschnittstelle zu der dahinterliegenden Business- und Datenhaltungsschicht. Die Nutzer greifen durch lokale Clients über das Netzwerk auf das Anwendungssystem zu. Zwischen den einzelnen Schichten können Load Balancer geschaltet werden, welche die Last durch die Benutzeraufrufe auf die Server verteilt. Bei den betrachteten Unternehmensanwendungen   handelt   es   sich   also   nicht   um   reine   „Batch“-Verarbeitungspro-gramme, sondern um Anwendungen für Endbenutzer.

Nach Schwarzer/Krcmar (2010, 11) sind die Begriffe Anwendungssoftware (kurz Anwendung) und Anwendungssystem zu unterscheiden. Eine Anwendung bezeichnet den reinen Programm-code ohne Hardware. Ein Anwendungssystem bezieht sich auf die Gesamtheit aus Soft- und Hardware. Eine Anwendung besteht aus vielen Anwendungsroutinen, die bestimmte Teilfunk-tionalitäten implementieren. Die Begriffe Anwendungsroutine, Methode oder Operation wer-den bedeutungsgleich verwendet. Anwendungsroutinen können ineinander verschachtelt sein und sich gegenseitig aufrufen.

7

Abbildung 2: Typische Architektur eines Anwendungssystems im betrieblichen Kontext Quelle: Eigene Darstellung

Anwendungskomponente Anwendungskomponenten, auch Softwarekomponenten genannt, kapseln Anwendungsrouti-nen in einer logisch geschlossenen Einheit und implementieren eine bestimmte Funktionalität einer Gesamtanwendung. Softwarekomponenten bieten die implementierte Funktionalität über Schnittstellen nach außen an und können von anderen Komponenten aufgerufen werden. Soge-nannte komponentenbasierte Anwendungssysteme werden aus verschiedenen Softwarekompo-nenten zusammengesetzt (Szyperski 2002, 3-4).

Ressourcen und Ressourcenbedarf Unter dem Begriff Ressourcen versteht diese Arbeit Hardwareressourcen oder auch Hardware-komponenten. Hardwareressourcen sind die in einem Server verbauten Bauteile wie Prozessor (CPU), Arbeitsspeicher (RAM) oder Festplattenspeicher (HDD). Auch die Netzwerkverbin-dung (NET) zwischen den Hardwareservern ist eine Hardwareressource. Die genannten Hard-wareressourcen zeichnen sich durch eine begrenzte Kapazität aus und können daher bei der Ausführung von konkurrierendem Programmcode zu Wartezeiten führen, was sich auf die Per-formance des Anwendungssystems auswirkt (Woodside/Franks/Petriu 2007).

Der Ressourcenbedarf einer Unternehmensanwendung bezieht sich auf die Auslastung der ein-zelnen Hardwareressourcen, welche durch die Anwendung beansprucht werden. So kann z.B. der Prozessor eines Servers eine durchschnittliche Auslastung von 50 % aufweisen, was bedeu-tet, dass der Prozessor in der Hälfte der Zeit des betrachteten Zeitraums durch die Anwendung in Anspruch genommen worden ist. Die HDD-Auslastung bezeichnet z.B. den Anteil des Zeit-raums, in dem die HDD mit Lese- und Schreiboperationen beschäftigt ist. Der Term Ressour-cenbedarf einer Unternehmensanwendung subsumiert die Auslastungs-Metriken der einzelnen in der Hardwarearchitektur vorhandenen Hardwareressourcen.

Benutzer Business-schicht

Präsentations-schicht

Datenhaltungs-schicht

LoadBalancer

Anwendungssystem

8

Energiebedarf Die Begriffe Energiebedarf und Energieverbrauch einer Unternehmensanwendung werden be-deutungsgleich verwendet. Eine Anwendung ist ein immaterielles Gut und verbraucht daher keine Energie. Die Hardwareinfrastruktur, auf der die Anwendung installiert ist, hat aber einen gewissen Energiebedarf. Wie schon dargestellt, besteht die typische Architektur einer Unter-nehmensanwendung aus mehreren Hardwareservern. Der Energieverbrauch einer Anwendung bezeichnet den gesamten Energieverbrauch der Hardwareinfrastruktur und bezieht damit alle Hardwareserver mit ein. Der Energieverbrauch der Client-Computer, auf denen die Anwender auf die Unternehmensanwendung zugreifen, wird nicht zum Energieverbrauch der Unterneh-mensanwendung hinzugezählt.

Der Energieverbrauch (𝐸) eines einzelnen Servers errechnet sich durch dessen Leistungsauf-nahme (𝑃), gemessen in Watt (W), multipliziert mit der betrachteten Zeitspanne (𝑡), z.B. ge-messen in Stunden (h). Dieser Zusammenhang ist in Formel 1 dargestellt.

𝐸 = 𝑃 ∗ 𝑡 Formel 1: Berechnung des Energieverbrauchs

Hat ein Server eine durchschnittliche Leistungsaufnahme von 200 Watt in einem Zeitraum von 5 Stunden, errechnet sich ein Energieverbrauch von 1 kWh (200  𝑊   ∗  5  ℎ  /  1000   =  1  𝑘𝑊ℎ). Bei einem derzeitigen Strompreis von ca. 0,15   €/kWh   (nach   Steuern)   für   Industriekunden (BDEW 2013, 42) würden für den betrachteten Zeitraum von 5 Stunden Energiekosten in Höhe dieser 0,15 €  anfallen.

Performance Unter dem Begriff Performance betrachtet diese Arbeit die aus Benutzersicht wahrgenommene Antwortzeit und den Durchsatz eines Anwendungssystems. Die Antwortzeit misst dabei die Zeitspanne von dem Zeitpunkt, an dem der Benutzer eine bestimmte Anwendungsroutine auf-ruft, bis zu dem Zeitpunkt, wo die Anwendung eine Antwort dem Anwender zurückliefert (Menascé et al. 2004, 3). Die Kennzahl des Durchsatzes gibt an, wie viele Aufrufe einer be-stimmten Anwendungsroutine in einem gewählten Zeitraum durch das Anwendungssystem ver-arbeitet werden (Menascé et al. 2004, 3-5).

2.2 Ressourcen- und Energiebedarf eines Anwendungssystems Wie schon in Kapitel 1 dargestellt, ist es für serverbasierte Anwendungssysteme sehr schwierig, die Performance sowie den Ressourcen- und Energiebedarf zu bestimmen, denn es gibt mehrere Einflussfaktoren, welche diese Metriken beeinflussen. Diese Einflussfaktoren sind schematisch in Abbildung 3 dargestellt und werden im Folgenden erläutert.

9

Abbildung 3: Einflussfaktoren auf die Performance und den Ressourcen- und Energiebedarf eines Anwendungssystems Quelle: In Anlehnung an (Koziolek 2010, 636)

Hardwareinfrastruktur Wie in Kapitel 2.1 erläutert, werden die betrachteten Unternehmensanwendungen über mehrere Server verteilt und in einem Netzwerk betrieben. Die Hardwareinfrastruktur hat daher einen maßgeblichen Einfluss auf die Performance sowie den Ressourcen- und Energiebedarf des An-wendungssystems. Werden durch eine vom Benutzer initiierte Anwendungsroutine große Da-tenmengen zwischen den einzelnen Servern ausgetauscht, hat die Datenübertragungsrate des Netzwerks zusammen mit dessen Latenzzeit einen großen Einfluss auf die vom Benutzer beo-bachtete Antwortzeit sowie den Durchsatz des Anwendungssystems. So dauert z.B. das Über-tragen einer bestimmten Datenmenge in einem Netzwerk mit einer Datenübertragungsrate von 10 Mbit/s ca. 10 mal so lange wie in einem Netzwerk mit einer Datenübertragungsrate von 100 Mbit/s. Der Ressourcenbedarf einer einzelnen Ausführung einer Anwendungsroutine, z.B. die benötigte Zeit des Prozessors zur Verarbeitung eines Algorithmus oder die benötigte Zeit für einen Festplattenzugriff, ist abhängig von der speziellen Hardwarekonfiguration des Ser-vers, auf dem der Algorithmus verarbeitet wird. Zum Beispiel braucht eine gleiche Datenban-kabfrage auf einem Datenbankserver mit hoher Datenrate der Festplatte weniger Zeit als auf einem Datenbankserver mit niedriger Datenrate bei sonst gleichen Bedingungen. Isoliert be-trachtet führt diese eine Ausführung der Anwendungsroutine auf dem schnelleren Datenbank-server zu schnelleren Antwortzeiten, einem höheren Durchsatz und zu einer geringeren Ressourcenauslastung des Anwendungssystems.

Implementierung Der Energiebedarf einer isoliert betrachteten Ausführung einer Anwendungsroutine ist abhän-gig von deren konkreten Implementierung sowie dem Energieverbrauch der Hardware, auf dem die Routine läuft. So führt ein effizient implementierter Algorithmus, der im Gegensatz zu ei-nem ineffizienten Algorithmus weniger Prozessorzeit in Anspruch nimmt, in der Regel zu ei-nem geringeren Energieverbrauch, wenn er auf dem gleichen Prozessor ausgeführt wird. Der gleiche Algorithmus benötigt aber auf verschiedenen Prozessoren, z.B. differierende Pro-zessorfrequenz der Prozessoren, eine unterschiedliche Prozessorzeit. Somit hat der Algorithmus auf unterschiedlichen Prozessoren einen unterschiedlichen Energieverbrauch. Natürlich ist die Ausführungszeit eines Algorithmus auch abhängig von den Inputparametern. So benötigt z.B. ein Sortieralgorithmus bei der Sortierung von 10 Objekten weniger Prozessorzeit als bei der Sortierung von 100 Objekten.

Anwendungssystem

Hardware-infrastruktur

Nutzerprofil

Implementierung

10

Nutzerprofil Bei einer Unternehmensanwendung darf man aber nicht die Ausführung einzelner Anwen-dungsroutinen isoliert betrachten. Die durchschnittliche Antwortzeit einer Anwendungsroutine ist abhängig von der Gesamtlast, die auf dem Anwendungssystem herrscht. Die Last eines An-wendungssystems ist durch die Abarbeitung vieler simultaner Anwendungsroutinen determi-niert, welche durch die Anfragen der Endbenutzer ausgelöst werden. Ist z.B. die Kapazität eines Prozessors durch den Aufruf vieler gleichzeitiger Anwendungsroutinen ausgelastet, führt dies zu Wartezeiten an diesem Prozessor und dadurch insgesamt zu höheren Antwortzeiten. Die Performance sowie der Ressourcen- und Energiebedarf eines Anwendungssystems ist daher entscheidend davon abhängig, wie viele Benutzer mit der Anwendung interagieren. 100 simul-tane Benutzer erzeugen in der Regel eine höhere Last auf dem Anwendungssystem als 10. Durch die daraus erzeugte Ressourcenauslastung kommt es zu höheren Antwortzeiten, einem geringeren Gesamtdurchsatz und einem höheren Energiebedarf des Anwendungssystems. Das Nutzerverhalten, also wie die Benutzer mit der Anwendung interagieren, beeinflusst ebenfalls die Performance und den Ressourcen- und Energiebedarf eines Anwendungssystems. Ein Be-nutzer, der nur selten mit der Anwendung interagiert, erzeugt weniger Last, als ein Anwender, der sehr häufig die Anwendung benutzt.

Zusammenfassend sind der Durchsatz, die durchschnittliche Antwortzeit, die Ressourcenaus-lastung und der Energieverbrauch eines Anwendungssystems abhängig von der Hardwareinf-rastruktur, der Implementierung der Anwendung, der Anzahl der Nutzer sowie deren Benutzer-verhalten.

2.3 Struktur des Ressourcen-Profils Wie in Kapitel 2.2 beschrieben, kann man den Ressourcen- und Energiebedarf und die Perfor-mance nur im Zusammenhang von Anwendungssystemen, folglich dem Zusammenspiel von Hard- und Software und der Anwendungsbenutzer bestimmen. Das Ressourcen-Profil soll aber eine Aussage über den Ressourcen- und Energieverbrauch einer Unternehmensanwendung, ergo der reinen Software, treffen. Das Ressourcen-Profil ist deshalb ein parametrisierbares Mo-dell, welches den Ressourcen- und Energiebedarf einer Anwendung in Abhängigkeit der Hard-wareinfrastruktur und der Anzahl an Benutzern und deren Benutzerverhalten abbildet. Abbildung 4 zeigt eine schematische Darstellung des Ressourcen-Profils.

Hardwareinfrastruktur

Benutzeranzahl

Benutzerverhalten

Resourcenauslastung

Energieverbrauch

Antwortzeiten

Durchsatz

Ressourcen-Profil

INPUT OUTPUT

Abbildung 4: Das Ressourcen-Profil Quelle: Eigene Darstellung

11

Durch die Spezifikation der Inputparameter des Ressourcen-Profils, also die Anzahl an Nutzern und deren Verhalten sowie die zu untersuchende Hardwareinfrastruktur, können die abhängi-gen Outputparameter, also der Ressourcen- und Energieverbrauch sowie die Antwortzeiten und der Durchsatz, bestimmt werden.

In einem idealen Prozess wird das Ressourcen-Profil einer Anwendung, ergo die Abbildung der oben gezeigten Abhängigkeiten, einmalig vom Softwarehersteller angefertigt und dem Kunden in geeigneter Form zur Verfügung gestellt. Für die Kundenbereitstellung bietet sich eine für diesen Zweck angefertigte Clientanwendung oder die Bereitstellung als Webanwendung an.

2.4 Anwendungsgebiete für ein Ressourcen-Profil Ein Ressourcen-Profil mit den in Kapitel 2.3 gezeigten Eigenschaften hat viele potentielle An-wendungsgebiete. Einige Anwendungsfälle sind in Abbildung 5 dargestellt. Diese und weitere Anwendungsfälle werden im Folgenden näher ausgeführt.

Investitionsentscheidung

Vertrags-/Vergütungsmodell

Kapazitäts-management

Interne Kostenrechnung

Kunde

IT-AbteilungGeschäfts-bereich

Software-hersteller

Cloud-Anbieter

Abbildung 5: Anwendungsgebiete für ein Ressourcen-Profil Quelle: Eigene Darstellung

Wenn ein Kunde an einer neuen Unternehmensanwendung interessiert ist, kann er vom Soft-warehersteller das entsprechende Ressourcen-Profil anfordern und zu Evaluierungszwecken nutzen. So kann er das Ressourcen-Profil als eine Komponente in seiner Investitionsentschei-dung einsetzen. Der Kunde setzt als Inputparameter die erwartete Benutzerzahl, das erwartete Benutzerverhalten und die Hardwareinfrastruktur in das Ressourcen-Profil ein und evaluiert dadurch den Ressourcen- und Energiebedarf sowie die zu erwartende Performance des Anwen-dungssystems. Dadurch findet er heraus, ob seine Hardwareinfrastruktur ausreichend ist, um die Anwendung zufriedenstellend zu betreiben und wie sich der Betrieb der Anwendung auf die Energiekosten auswirkt. Wenn die zu erwartende Performance nicht den Anforderungen des Kunden entspricht, muss dieser leistungsstärkere Hardware bereitstellen. Bei der Entschei-dung über eine neue Hardware für die betrachtete Anwendung kann das Ressourcen-Profil ebenfalls behilflich sein. Durch das Ressourcen-Profil kann der Kunde verschiedene Hardware-konfigurationen hinsichtlich der zu erwartenden Performance, der Ressourcenauslastung und des Energieverbrauchs vergleichen und die für die betrachtete Anwendung wirtschaftlichste

12

Hardware auswählen. Hat der Kunde die Auswahl zwischen mehreren gleichwertigen Unter-nehmens-anwendungen, d.h. Anwendungen mit gleichem Funktionsumfang, kann auf Basis der Ressourcen-Profile eine Auswahlentscheidung hinsichtlich der genannten Kriterien getroffen werden.

Wurde die Unternehmensanwendung gekauft und beim Kunden in Betrieb genommen, kann das Ressourcen-Profil bei der internen Kostenrechnung zwischen der IT-Abteilung, die für den Betrieb der Anwendung verantwortlich ist, und der Geschäftsbereiche, welche auf das Anwen-dungssystem zugreifen, behilflich sein. Mit Hilfe des Ressourcen-Profils kann man den durch-schnittlichen Ressourcen- und Energieverbrauch auf die einzelnen Geschäftsbereiche, den einzelnen Anwender oder den einzelnen Aufruf einer Anwendungsroutine herunterbrechen. Brandl/Bichler/Ströbel (2007) zeigen, wie ein auf den Aufruf einer einzelnen Anwendungsrou-tine heruntergebrochener Ressourcenverbrauch genutzt werden kann, um eine transparente Kostenallokation auf die einzelnen Geschäftsbereiche zu bewerkstelligen. Die Kosten werden dabei auf die Geschäftsbereiche gemäß ihrem Anteil des Ressourcenverbrauchs am gesamten Ressourcenverbrauch aufgeteilt.

Wenn ein Kunde die Anwendung nicht selber betreiben will, sondern diese Aufgabe einem Cloud-Anbieter überlässt, kann das Ressourcen-Profil der ausgelagerten Anwendung als Grundlage bei der Vertragsgestaltung zwischen beiden Parteien dienen. Durch die Beliebtheit von Cloud-Computing-Diensten, steigt auch das Bedürfnis an einer nutzungsabhängigen Kos-tenabrechnung (Brandl/Bichler/Ströbel 2007, 92). Ähnlich wie im oben beschriebenen Anwen-dungsfall des Ressourcen-Profils für die interne Kostenrechnung, können Kunde und Cloud-Anbieter auf Basis des Ressourcen-Profils ein Vergütungsmodell vereinbaren, welches die an-fallende Vergütung direkt vom tatsächlichen Ressourcen- und Energieverbrauch abhängig macht. Mit Hilfe des Ressourcen-Profils können sowohl Kunde als auch Cloud-Anbieter die vorrausichtlich anfallenden Kosten abschätzen.

Vor und nach der Bereitstellung einer Anwendung für den produktiven Betrieb kann das Res-sourcen-Profil bei der Kapazitätsplanung helfen. Z.B. können bei Zukauf eines Unternehmens und den dadurch erhöhten Benutzerzahlen auf dem Anwendungssystem die Effekte auf die Per-formance und den Ressourcen- und Energiebedarf evaluiert werden und entsprechende Schluss-folgerungen hinsichtlich der potentiellen Aufrüstung der Hardware gezogen werden.

13

3 Performance-Modelle als Basistechnologie für ein Ressourcen-Profil

Die Disziplin  des  „Software Performance Engineerings“ (SPE) beschäftigt sich mit der Perfor-mance und dem Ressourcenbedarf von Anwendungssystemen (Woodside/Franks/Petriu 2007, 172). In der SPE-Literatur gibt es zwei grundsätzliche Ansätze für die Untersuchung der Per-formance und des Ressourcenbedarfs eines Anwendungssystems. Zum einen gibt es messba-sierte Ansätze, welche die entsprechenden Metriken bei einem laufenden Anwendungssystem messen. Zum anderen gibt es modellbasierte Ansätze, welche die Anwendungssysteme durch abstrakte Modelle abbilden und die Performance- und Ressourcenbedarfs-Metriken durch die Analyse dieser Modelle ermitteln.

Messbasierte Ansätze setzen voraus, dass die Hardware sowie die installierte Software zur Ver-fügung stehen. Dies widerspricht dem Zweck des in Kapitel 2 vorgestellten Ressourcen-Profils, da das Ressourcen-Profil die Performance sowie den Ressourcen- und Energiebedarf einer An-wendung unabhängig von der Hardwareinfrastruktur abbildet. Messbasierte Ansätze werden deshalb nicht weiter betrachtet.

Bei den modellbasierten Ansätzen kommen sogenannte Performance-Modelle zum Einsatz. Abbildung 6 zeigt den Aufbau eines Performance-Modells.

Abbildung 6: Performance-Modell Quelle: (Brunnert/Vögele 2012)

Ein Performance-Modell modelliert das zu untersuchende Anwendungssystem. Dazu bildet es die schon in Kapitel 2.2 gezeigten Einflussparameter auf die Performance und den Ressourcen-verbrauch eines Anwendungssystems ab. In einem Performance-Modell wird die Softwarear-chitektur der Anwendung, die Hardwareinfrastruktur, auf der die Anwendung läuft, der Ressourcenverbrauch der modellierten Anwendungsroutinen auf dieser Hardwareinfrastruktur und das Nutzerverhalten modelliert. Durch geeignete Lösungsverfahren (analytische Lösung oder Simulation) wird die Performance sowie der Ressourcenbedarf des modellierten Anwen-dungssystems unter einer durch das modellierte Benutzerverhalten spezifizierten Last be-stimmt. Die Analyse des Energiebedarfs eines Anwendungssystems ist noch nicht verbreitet.

Performance-Modelle eignen sich als grundlegende Technologie zur Erstellung eines Ressour-cen-Profils einer Unternehmensanwendung. Der Softwarehersteller erstellt ein Performance-

Performance-Modell

Ressourcen-verbrauch

Software-architektur

Hardware-infrastruktur

Nutzer-verhalten

Analytische Lösung /

Simulation

Antwortzeiten

Durchsatz

Ressourcen-bedarf

14

Modell seiner Anwendung auf einer ihm verfügbaren Hardwareinfrastruktur. Diese Hardware-infrastruktur wird im Folgenden als initiale Hardwareinfrastruktur bezeichnet. Der Kunde er-hält dieses Performance-Modell und ersetzt im Modell die initiale Hardwareinfrastruktur durch seine Ziel-Hardwareinfrastruktur. Zusätzlich passt der Kunde den Ressourcenverbrauch der einzelnen Anwendungsroutinen entsprechend der Ziel-Hardwareinfrastruktur an. Des Weiteren modelliert er das zu erwartende Nutzerverhalten. Somit erhält er ein Performance-Modell für sein kundenspezifisches Anwendungssystem.

Performance-Modelle werden auf Basis eines Metamodells erstellt. Kapitel 3 schafft einen Überblick über modellbasierte Ansätze zur Vorhersage der Performance und des Ressourcen-bedarfs von Anwendungssystemen im betrieblichen Kontext und untersucht deren Eignung zur Repräsentation eines Ressourcen-Profils. Dazu zeigt Kapitel 3.1 auf Basis von Untersuchungen anderer Autoren auf, in welche grundsätzlichen Typen Performance-Metamodelle eingeteilt werden. Kapitel 3.2 beschreibt anschließend, nach welchem Bewertungsschema die in den Ka-piteln 3.3 bis 3.6 untersuchten Performance-Metamodelle analysiert werden. Kapitel 3.7 unter-sucht Ansätze aus der Praxis und zeigt, wie Softwarehersteller den Kunden bei der Analyse der Performance und des Ressourcenbedarfs ihrer Unternehmensanwendung helfen. Das Kapitel 3.8 fasst die Ergebnisse übersichtlich zusammen und trifft eine Entscheidung für ein Perfor-mance-Metamodell, mit dem das Konzept des Ressourcen-Profils weiterverfolgt wird.

3.1 Performance-Modell-Typen Performance-Modelle werden nach den Regeln eines Metamodells erstellt. Verschiedene Ar-beiten, welche im Folgenden näher vorgestellt werden, haben sich mit der Analyse von Perfor-mance-Metamodellen beschäftigt. Diese Untersuchungen zeigen, dass Performance-Meta-modelle in verschiedene Typen eingeteilt werden können.

Balsamo et al. (2004) legen bei ihrer Untersuchung einen Schwerpunkt auf die Eignung von Performance-Modellen zur Unterstützung des Softwareentwicklungsprozesses. Die Arbeit un-terscheidet Metamodelle, die auf Queuing Network Models, Stochastic Process Algebras oder Petri Nets basieren. Die Studie untersucht die Metamodelle dahingehend, zu welchem Zeit-punkt im Softwareentwicklungszyklus die jeweiligen Ansätze einsetzbar sind und inwiefern diese durch Softwarewerkzeuge unterstützt werden.

Becker et al. (2006) konzentrieren sich in ihrer Arbeit auf die Prognose der Performance und des Ressourcenbedarfs von komponentenbasierten Anwendungssystemen (siehe Begriffserklä-rung in Kapitel 2.1). Die Untersuchung von modellbasierten Ansätzen macht aber nur einen kleinen Teil der Studie aus. Daneben betrachtet die Arbeit auch messbasierte und qualitative Ansätze, welche für das Konzept des Ressourcen-Profils nicht relevant sind. Die Autoren be-werten Performance-Metamodelle danach, wie gut die Abhängigkeiten in einem Anwendungs-system (siehe Kapitel 2.2) abgebildet werden können und wie gut die Prognosefähigkeit ist. Dabei verzichten die Autoren auf eine Kategorisierung der Performance-Metamodelle nach be-stimmten Modelltypen.

Koziolek (2010) untersucht auch Performance-Metamodelle für die Evaluation von komponen-tenbasierten Anwendungssystemen. Die Arbeit ordnet, ähnlich zur Arbeit von Balsamo et al.

15

(2004), die Performance-Metamodelle in klassische Metamodelltypen ein. Der Fokus der Un-tersuchung liegt auf der Bewertung der Ausdrucksfähigkeit der jeweiligen Modellierungsspra-che. Denn es zeigt sich, dass bei einigen Performance-Metamodellen zwischen der Modellie-rungssprache und dem eigentlichen Performance-Modell, welches zur Evaluation der Perfor-mance eines Anwendungssystems verwendet wird, unterschieden werden muss. Einerseits gibt es Performance-Metamodelle, welche die klassischen Modelltypen direkt implementieren, d.h. der Benutzer modelliert ein Anwendungssystem direkt nach den auf dem klassischen Perfor-mance-Modelltyp basierenden Modellierungsartefakten. Andererseits existieren Performance-Metamodelle, welche eine separate Modellierungssprache zur Erstellung eines Modells eines Anwendungssystems definieren und, davon ausgehend, eine Modelltransformation zu einem klassischen Performance-Modelltyp implementieren. Diese separaten Modellierungssprachen bauen wiederum oft auf anderen bekannten Modellierungssprachen, wie z.B. die Unified Mo-deling Language (UML), auf.

Das Buch von Cortellessa/Di Marco/Inverardi (2011) erklärt die Grundlagen der Modellierung von Performance-Modellen und gibt einen Überblick über die aus der Sicht der Autoren wich-tigsten Modelltypen und einiger Performance-Metamodelle. Dabei unterscheidet die Arbeit, ähnlich wie bei Balsamo et al. (2004), die Typen Queuing Network, Layered Queuing Network, Stochastic Petri Nets und Stochastic Process Algebras. Eine Bewertung einzelner Performance-Metamodelle nimmt die Arbeit allerdings nicht vor.

Die in dieser Arbeit durchgeführte Untersuchung übernimmt die Grundidee der Kategorisie-rung von Performance-Metamodellen nach den klassischen Performance-Modelltypen. Die Analyse der oben beschriebenen Untersuchungen ergibt, dass Performance-Metamodelle grundsätzlich in die Typen

Queuing Networks und deren Erweiterungen Stochastic Process Algebras Petri Nets und deren Erweiterungen und proprietäre Metamodelle, die nicht auf den vorherigen drei Typen basieren,

eingeteilt werden können. Diese Arbeit setzt den Fokus auf die Untersuchung der Eignung eines Performance-Metamodells zur Repräsentation eines Ressourcen-Profils und sucht deshalb Me-tamodelle, die sich zur Modellierung von Unternehmensanwendungen eignen und zu denen Fallstudien existieren, welche die Anwendung des Metamodells zeigen. Durch diese Filterung ergibt sich, dass sich die in dieser Arbeit vorgestellten Performance-Metamodelle in die Meta-modelltypen

Queuing Networks (Kapitel 3.3), Layered Queuing Networks (Kapitel 3.4), Queuing Petri Nets (Kapitel 3.5) und proprietäre Metamodelle, mit dem Palladio Component Model als alleinigem Ver-

treter (Kapitel 3.6),

einteilen lassen. Zu Stochastic Process Algebras konnten im Rahmen dieser Arbeit keine ge-eigneten Performance-Metamodelle gefunden werden. Das nächste Kapitel zeigt das Bewer-tungsschema, nach welchem die in diesen Kategorien gefundenen Metamodelle ausgewertet werden.

16

3.2 Bewertungsschema Im Gegensatz zu den in Kapitel 3.1 vorgestellten Untersuchungen nimmt diese Untersuchung nur Performance-Metamodelle auf, die sich für die Abbildung von Unternehmensanwendungen eignen und zu denen Fallstudien existieren, in denen das Metamodell für die Modellierung einer konkreten Unternehmensanwendung angewendet wurde. Wie in Kapitel 2.1 dargestellt, werden in dieser Arbeit nur Anwendungssysteme betrachtet, die von Endanwendern benutzt werden. Deshalb werden im Folgenden auch nur Performance-Metamodelle berücksichtigt, welche die Modellierung des Benutzerverhaltens unterstützen. Diese Arbeit untersucht die gefundenen Performance-Metamodelle geordnet nach den in Kapitel 3.1 gezeigten Modelltypen. Dazu geht die Arbeit in den folgenden Kapiteln zunächst kurz auf die Grundzüge des klassischen Perfor-mance-Modelltyps ein. Anschließend werden die zur jeweiligen Kategorie gehörenden Perfor-mance-Metamodelle nach den Kriterien

des Lösungsverfahrens, des möglichen Abstraktionsgrades der Modellierung, der abbildbaren Hardwareressourcen und der Möglichkeit zur Abbildung des Ener-

gieverbrauchs, der Möglichkeit der modularen Modellierung von Softwarearchitektur, Hardwarein-

frastruktur sowie des Benutzerprofils, und den Fallstudien, welche das Performance-Metamodell anwenden,

untersucht. Auf diese einzelnen Kriterien wird im Folgenden näher eingegangen.

Lösungsverfahren: Analytisch oder Simulation Durch bestimmte Lösungsverfahren kann aus den Performance-Modellen die Performance, der Ressourcenbedarf und potentiell der Energiebedarf des modellierten Anwendungssystems er-mittelt werden. Dabei wird zwischen analytischen und simulationsbasierten Lösungsverfahren unterschieden (Balsamo et al. 2004, 296). Analytische Lösungsverfahren werten die Perfor-mance-Modelle mit Hilfe von mathematischen Verfahren, die meistens auf Markov-Ketten be-ruhen, aus. Simulationsbasierte Lösungsverfahren simulieren das im Modell abgebildete An-wendungssystem und werten die entsprechenden Metriken während des Simulationslaufs aus. Analytische Lösungsverfahren sind in der Regel schneller als simulationsbasierte, haben aber den Nachteil, dass Performance-Modelle mit hoher Komplexität nicht mehr gelöst werden kön-nen (Woodside/Franks/Petriu 2007, 180).

Abstraktionsgrad der Modellierung Modelle sind immer eine Abstraktion der Realität (Hansen/Neumann 2001, 251). Performance-Metamodelle unterscheiden sich aber im möglichen Abstraktionsgrad. D.h., wie detailliert kann ein Performance-Modell ein Anwendungssystem auf Basis der Modellierungsregeln des Meta-modells abbilden. Je detaillierter ein Performance-Modell ein Anwendungssystem modelliert, desto detaillierter können die Performance-Metriken ausgewertet werden. Die Abstufungen der Abstraktionsgrade, nach denen diese Arbeit die Performance-Metamodelle einteilt, sind in Ab-bildung 7 dargestellt.

17

SystemServerknoten

Anfrageklassen

Komponenten

Methoden

Detailgrad

Abbildung 7: Abstraktionsgrad von Performance-Modellen Quelle: Eigene Darstellung

So kann ein Performance-Metamodell nur einen sehr hohen Abstraktionsgrad ermöglichen und ein konkretes Performance-Modell kann ein Anwendungssystem nur als eine einzige große Ein-heit  („Black  Box“),  mit  Performance- und Ressourcen-/Energiecharakteristika, abbilden. Aus Performance-Modellen auf dem Abstraktionsgrad von Servern wird ersichtlich, dass eine An-frage eines Benutzers auf mehreren Hardwareservern verarbeitet wird. Das Modell unterschei-det aber noch nicht zwischen verschiedenartigen Anwendungsroutinen, sondern bildet die gesamte Softwarearchitektur, aggregiert in einer einzigen Anwendungsroutine, welche auf den jeweils modellierten Servern einen gewissen Ressourcenbedarf hat, ab. Ein Abstraktionsgrad tiefer bilden die Performance-Modelle verschiedenartige Benutzeranfragen in sogenannten An-frageklassen ab. Das Performance-Modell aggregiert also die Softwarearchitektur in mehrere Anfrageklassen, die auf den modellierten Servern jeweils einen individuellen Ressourcenbedarf ausweisen. Auf der Abstraktionsebene von Komponenten wird aus dem Modell ersichtlich, dass eine Anwendung aus mehreren Softwarekomponenten zusammengesetzt ist (siehe Begriffser-klärung in Kapitel 2.1) und deren Schnittstellen einen eigenen Ressourcenbedarf spezifizieren. Auf dem niedrigsten Abstraktionsgrad erlaubt das Performance-Metamodell die Zerlegung ei-nes Anwendungssystems in beliebig kleine Methoden und Verarbeitungsschritte.

Abbildbare Hardwareressourcen und Möglichkeit zur Abbildung des Energieverbrauchs Das Ressourcen-Profil einer Unternehmensanwendung soll Aufschluss über den Ressourcen- und Energiebedarf einer Unternehmensanwendung geben. Diese Arbeit analysiert deshalb, wel-che Hardwareressourcen ein Performance-Modell auf Basis des untersuchten Metamodells ab-bilden kann. Außerdem wird untersucht, ob das Performance-Metamodell die Möglichkeit bietet, den Energieverbrauch eines Anwendungssystems abbilden und auswerten zu können.

Modellierungsart: Monolithische oder modulare Modellierung Damit sich ein Performance-Metamodell als Repräsentation eines Ressourcen-Profils eignet, sollte das Metamodell die voneinander unabhängige Modellierung der Softwarearchitektur, der Hardwareinfrastruktur und des Benutzerverhaltens ermöglichen. Wie in der Einführung von Kapitel 3 erläutert, kann ein Performance-Modell dann als Ressourcen-Profil agieren, wenn der Softwarehersteller die Softwarearchitektur modelliert und der Kunde anschließend das Modell

18

mit seiner Hardwareinfrastruktur und seinem Benutzerverhalten ergänzen kann. Sind die Hard-wareinfrastruktur und die Softwarearchitektur in einem Modell eng miteinander gekoppelt, ist es nur sehr schwer möglich, das Modell von der initialen Hardwareinfrastruktur, die der Soft-warehersteller modelliert, zu einer kundenspezifischen Ziel-Hardwareinfrastruktur zu ändern. Diese Arbeit wertet die untersuchten Performance-Metamodelle danach aus, ob die darauf ba-sierenden Performance-Modelle ein Anwendungssystem in einem monolithischen Modell ab-bilden oder ob die Performance-Modelle die einzelnen Aspekte der Softwarearchitektur, der Hardwareinfrastruktur und des Nutzerverhaltens modular zu einem Gesamtmodell zusammen-setzen.

Fallstudien Um die Praxistauglichkeit der Performance-Metamodelle einzuschätzen, werden die zum je-weiligen Metamodell gefundenen Fallstudien vorgestellt. Diese Fallstudien entwickeln typi-scherweise ein konkretes Performance-Modell für ein spezifisches Anwendungssystem und vergleichen die Modellergebnisse mit realen Messergebnissen, um die Prognosegenauigkeit zu demonstrieren. Neben der Betrachtung der Prognosegenauigkeit evaluiert diese Arbeit die Fall-studien ebenfalls nach den oben für die Performance-Metamodelle gezeigten Kriterien. Es wird für jede Fallstudie untersucht, welcher Abstraktionsgrad für die Modellierung gewählt wurde, welches Lösungsverfahren angewendet wurde, welche Hardwareressourcen abgebildet wurden und ob eine Betrachtung des Energieverbrauchs der modellierten Anwendung vorgenommen wurde.

3.3 Queuing Network Model (QNM) Queuing Network Models (QNM) bilden ein Anwendungssystem mit Hilfe von sogenannten Servicestationen, die über Kanten miteinander verbunden sind, ab. Ein Benutzer initiiert eine Anfrage, welche durch das Netzwerk der Servicestation navigiert und eine bestimmte Zeit an jeder Servicestation benötigt, um verarbeitet zu werden. Eine Servicestation besteht dabei aus sogenannten Servern und einer Warteschlange. Die Server verarbeiten die Anfragen mit einer bestimmten Geschwindigkeit. Sind die Server einer Servicestation beschäftigt, reihen sich die Anfragen in der Warteschlange ein und werden nach einer spezifizierten  „Scheduling“-Strate-gie von den Servern abgearbeitet. Menascé et al. (2004, 32-41) zeigen in ihrem Buch, wie durch relativ einfache Gleichungen Performance-Metriken für ein QNM errechnet werden können. Abbildung 8 zeigt ein Beispiel eines QNMs.

19

CPU1

HDD

Nutzer

NET

CPU2

Servicestation

Warteschlange

Server

Anfrage

0,6

0,4

Abbildung 8: Queuing Network Model Quelle: Eigene Darstellung

Das QNM zeigt eine Servicestation, welche die Generierung von Benutzeranfragen abbildet. Die Anfragen werden zunächst von einer Servicestation, die eine CPU mit 2 Kernen darstellt, bearbeitet. Anschließend müssen die Anfragen entweder von der Festplatte behandelt werden oder es erfolgt ein Netzwerkzugriff.

Im Folgenden werden zwei Performance-Metamodelle, die auf QNM aufbauen, untersucht und darauf aufbauende Fallstudien gezeigt.

3.3.1 Java Modelling Tools (JMT)

Dieses Kapitel stellt die Software „Java Modelling Tools“ (JMT) (Bertoli/Casale/Serazzi 2009a, 2009b) stellvertretend für viele Metamodelle, welche die QNM-Theorie direkt und ohne weitere Abstraktionsschicht implementieren, vor. So pflegt Hlynka (2013) auf seiner Webseite eine Liste von zahlreichen weiteren QNM-Softwarepaketen. Zu den ausgereiftesten und auf-grund der Verfügbarkeit einer graphischen Benutzeroberfläche benutzerfreundlichsten Anwen-dungen gehören neben JMT noch die beiden Anwendungen PEPSY-QNS (Kirschnick 1994; Bazan/Bolch/German 2006) und SHARPE (Hirel et al. 2000), wobei die letzteren Anwendun-gen nicht mehr aktiv weiterentwickelt werden.

JMT stellt eine graphische Benutzeroberfläche zur Verfügung, um ein QNM zu modellieren. Daneben bietet JMT aber auch eine textuelle Schnittstelle an, bei der QNMs in XML-Dateien (Extensible Markup Language) definiert werden können. Abbildung 9 zeigt ein QNM, welches mit der graphischen Benutzeroberfläche angelegt wurde.

20

Abbildung 9: Java Modelling Tools Quelle: Eigene Darstellung

Lösungsverfahren Um die Performance und den Ressourcenverbrauch eines Anwendungssystems zu analysieren, bietet JMT sowohl analytische als auch simulationsbasierte Lösungsverfahren für die Auswer-tung eines QNMs an.

Abstraktionsgrad JMT eignet sich nicht für eine detaillierte Abbildung der Softwarearchitektur. Mit JMT können nur einzelne Anwendungsroutinen in Anfrageklassen gebündelt und deren Ressourcenver-brauch an den einzelnen Hardwareressourcen, abgebildet durch Servicestationen, modelliert werden.

Hardwareressourcen und Energie Mit JMT kann man keine expliziten Hardwareressourcen, wie eine CPU, modellieren. Wie be-reits erwähnt, bietet das QNM-Metamodell die Möglichkeit der Modellierung von Servicesta-tionen. Durch diese Servicestationen lassen sich implizit die gängigsten Hardwareressourcen, wie CPU, HDD, RAM oder das Netzwerk, modellieren. Die Modellierung des Energiebedarfs eines Anwendungssystems ist mit JMT nicht möglich.

Modellierungsart JMT ist eine direkte Implementierung der QNM-Theorie. Als einzige Abstraktionsschicht dar-über implementiert JMT eine graphische Benutzeroberfläche. Daher ist JMT nur begrenzt als Basistechnologie eines Ressourcen-Profils geeignet. Die Softwarearchitektur und die Hard-wareinfrastruktur können in JMT nur in einem monolithischen Modell gemeinsam abgebildet werden. Zwar können die Ressourcenbedarfe einzelner Anfrageklassen von einer initialen Hardwareressource auf eine Ziel-Hardwareressource angepasst werden, aber die Hardwareinf-rastruktur kann nicht grundlegend, z.B. von einer Architektur mit einem Datenbankserver auf eine Architektur mit zwei Datenbankservern, geändert werden. Für das Benutzerverhalten gibt es keine vom restlichen Modell separierte Modellierungsmöglichkeit. Die Anzahl an Benutzer

21

bzw. Anfragen wird in JMT durch eine Servicestation ohne Warteschlange modelliert. Das Be-nutzerverhalten wird durch Verzweigungen mit entsprechenden Wahrscheinlichkeiten abgebil-det (siehe Abbildung 8).

Fallstudien F1. In der Fallstudie von Rolia et al. (2009) wird ein „Enterprise  Resource  Planning“-System (ERP) als QNM mit JMT modelliert. Das Modell bildet die Softwarearchitektur des ERP-Systems grob in drei Anfrageklassen ab. Die Hardwareinfrastruktur besteht aus einem Hard-wareserver, wobei das Performance-Modell nur die CPU als Hardwareressource abbildet. Eine Energiebetrachtung des ERP-Systems findet nicht statt. Die Fallstudie ermittelt die Ressour-cenauslastung und die Antwortzeiten des modellierten ERP-Systems bei variierender Benut-zeranzahl mit Hilfe des analytischen Lösungsverfahrens von JMT und vergleicht die Ergebnisse mit realen Messergebnissen. Das Modell konnte die CPU-Auslastung mit einem maximalen Fehler von 10 % vorhersagen. Bei der Vorhersage der Antwortzeiten traten allerdings häufiger Abweichungen von bis zu über 70 % zu den Messwerten auf. Die gleiche Arbeit modelliert deshalb das ERP-System auch als Layered Queuing Network Model (LQNM) mittels des Lay-ered Queuing Network Solvers (LQNS) (siehe Kapitel 3.4.1). Dieses Modell führte zu besseren Vorhersageergebnissen. Näheres zu diesem Modell zeigt die Fallstudie F6 im Kapitel 3.4.1.

F2. Li/Casale/Ellahi (2010) modellieren ebenfalls ein QNM eines ERP-Systems mit JMT. Im Gegensatz zur Fallstudie F1 besitzt das Performance-Modell einen höheren Abstraktionsgrad. Das Modell bildet die Softwarearchitektur aggregiert in einer einzigen Anfrageklasse ab. Das QNM modelliert einen Hardwareserver, wobei die CPU als Servicestation abgebildet wird. Die Fallstudie vergleicht die ermittelten Ergebnisse für die CPU-Auslastung und Antwortzeiten aus der Simulation des QNM mit Messergebnissen des realen ERP-Systems. Für den Vergleich zwischen Modell- und Messergebnissen wurde die Anzahl der Benutzer stabil gehalten. Die Hardwarekonfiguration, insbesondere die Anzahl der CPUs, wurde variiert. Der Fehler bei der Vorhersage der CPU-Auslastung und der Antwortzeiten betrug in den meisten Fällen weniger als 15 %. Aufbauend auf diesem QNM erstellt die Arbeit ein Kostenmodell, welches die Kosten für den Betrieb des ERP-Systems abbildet. Eine Komponente dieses Kostenmodells ist die Be-trachtung des Energieverbrauchs. Das Kostenmodell bildet den Energieverbrauch des ERP-Systems in Abhängigkeit zur CPU-Auslastung des Hardwareservers ab. In der Fallstudie wurde allerdings kein Vergleich zwischen Modell- und Messergebnissen bezüglich des Energiever-brauchs durchgeführt.

F3. Wie anfangs erwähnt, stellt dieses Kapitel JMT stellvertretend für mehrere Performance-Metamodelle, die auf der QNM-Theorie aufbauen, vor. Kounev/Buchmann (2003a) modellie-ren in ihrer Fallstudie ein QNM mit dem PEPSY-QNS Metamodell. Bei der untersuchten An-wendung handelt   es   sich   um   die   von   der   „Standard Performance Evaluation Corporation“  (SPEC) entwickelte Benchmark-Unternehmensanwendung SPECjAppServer2002 (SPEC 2002), eine Vorgängerversion des aktuellen SPECjEnterprise2010-Benchmarks (SPEC 2010a). SPECjAppServer2002 implementiert eine Anwendung für das Lieferketten-Management eines typischen Fertigungsbetriebs. Die Fallstudie modelliert die Softwarearchitektur in fünf ver-schiedenen Anfrageklassen. Die Hardwareinfrastruktur besteht aus einem Datenbankserver und mehreren in einem Cluster angeordnete Applikationsserver. Im QNM werden die CPUs der

22

Applikationsserver und des Datenbankservers modelliert. Für den Datenbankserver bildet das Modell zusätzlich noch die Ressource HDD ab, deren Auslastung aber anschließend nicht ana-lysiert wird. Das analytische Lösungsverfahren von JMT prognostiziert die Antwortzeiten, den Durchsatz und die CPU-Auslastung des Anwendungssystems. Die Fallstudie untersucht nicht den Energieverbrauch. Für unterschiedliche Szenarien, variierendes Benutzerverhalten und va-riierende Anzahl an Applikationsservern, werden die Vorhersageergebnisse des jeweiligen QNM mit realen Messergebnissen verglichen. Das Modell kann den Durchsatz des Anwen-dungssystems mit einer Abweichung unter 2 % prognostizieren. Die prognostizierten Antwort-zeiten besitzen in den meisten Fällen einen relativen Fehler von unter 20 %. Die Abweichung bei der Prognose der CPU-Auslastung der Applikations- und des Datenbankservers beträgt we-niger als 10 %.

3.3.2 SPE•ED

Smith ist mit seinem Standardwerk (Smith 1990) der Pionier der modellbasierten Perfor-manceanalyse von Anwendungssystemen im Entwicklungsstadium. Im Zuge dessen hat er das Performance-Metamodell SPE•ED entwickelt (Smith/Williams 1997). In SPE•ED wird der Ab-lauf einer Anwendung in sogenannten Ausführungsgraphen (in der englischen Originalarbeit als „Execution  Graphs“ bezeichnet) abgebildet. Ein Ausführungsgraph modelliert typischer-weise die einzelnen Verarbeitungsschritte einer Anwendungsroutine, welche durch einen Be-nutzer initiiert werden kann. Zu jedem Verarbeitungsschritt wird der Bedarf an Softwareres-sourcen, z.B. die Anzahl an notwendigen Datenbankabfragen, spezifiziert. In einer separaten „Overhead“-Matrix wird zu jeder Softwareressource der jeweilige Bedarf an einer spezifizier-ten Hardwareressource abgebildet. So wird z.B. die benötigte Zeit für die Verarbeitung einer Datenbankabfrage auf der gewählten CPU modelliert. Das somit spezifizierte Modell wird zur Auswertung in ein QNM transformiert.

Lösungsverfahren Für das aus der Transformation entstehende QNM bietet SPE•ED  eine Kombination von ana-lytischen und simulationsbasierten Lösungsverfahren an (Cortellessa/Di Marco/Inverardi 2011, 155). Es können die Antwortzeiten sowie die Hardwareressourcenauslastung des modellierten Anwendungssystems evaluiert werden.

Abstraktionsgrad In SPE•ED  wird die Softwarearchitektur durch die beschriebenen Ausführungsgraphen model-liert. Ausführungsgraphen können wiederum aus Sub-Ausführungsgraphen bestehen. Somit lässt sich die Anwendung beliebig detailliert modellieren. Smith/Williams (1997, 137) merken allerdings an, dass sie SPE•ED  entwickelt haben, um einfachere Modelle zu lösen, welche in frühen Phasen der Softwareentwicklung entstehen. Der mögliche Abstraktionsgrad wird im Rahmen dieser Arbeit daher auf die Ebene von Komponenten festgelegt.

Hardwareressourcen und Energie Das SPE•ED  Metamodell sieht keine expliziten Hardwareressourcen vor, sondern bietet nur das  generische  Konzept  der  „Overhead“-Matrix zur Modellierung dieser Ressourcen an. In der „Overhead“-Matrix lassen sich grundsätzlich alle Hardwareressourcen modellieren, an denen

23

ein Verarbeitungsschritt des Anwendungsablaufs Zeit für die Verarbeitung benötigt. Dafür kommen die typischen Hardwareressourcen wie CPU, HDD, RAM oder das Netzwerk in Be-tracht. SPE•ED bietet keine Möglichkeit zur Evaluation des Energiebedarfs an.

Modellierungsart SPE•ED   ist eigentlich dafür bestimmt, Anwendungssysteme, die noch in der Entwicklungs-phase sind, abzubilden. SPE•ED lässt sich aber grundsätzlich auch für existierende Software-systeme nutzen (Cortellessa/Di Marco/Inverardi 2011, 156). SPE•ED  ermöglicht eine getrennte Modellierung der Softwarearchitektur in den Ausführungsgraphen und der Hardwareinfrastruk-tur  in  der  „Overhead“-Matrix. Für jeden Ausführungsgraphen wird die Ankunftsrate von Auf-rufen spezifiziert und somit das Benutzerverhalten abgebildet. Durch diese modulare Art der Modellierung eignet sich SPE•ED als Repräsentation eines Ressourcen-Profils.

Fallstudien F4. Die Fallstudie von Smith/Williams (2000) modelliert ein Flugbuchungsportal mit SPE•ED. Die Ausführungsgraphen modellieren die Softwarearchitektur auf der Abstraktionsebene von Komponenten. Die Hardwareinfrastruktur besteht aus mehreren über ein Netzwerk verbunde-nen Servern. Das Performance-Modell bildet die Hardwareressourcen CPU, HDD und das Netzwerk ab. Das von SPE•ED  zur Verfügung gestellte Lösungsverfahren bestimmt die Ant-wortzeiten sowie die Ressourcenauslastung der modellierten Hardwareressourcen. Dabei wurde das Modell einmal für einen einzelnen Benutzer und anschließend für 750 simultane Benutzer analysiert. Die Fallstudie vergleicht leider nicht die Vorhersagergebnisse aus dem Modell mit realen Messergebnissen.

F5. In einer weiteren Fallstudie modellieren Smith/Williams (1998) einen Webshop mit Hilfe des  SPE•ED-Metamodells. Das Performance-Modell modelliert das Anwendungssystem wie in Fallstudie F4 auf dem Abstraktionsgrad von Komponenten. Bei den Hardwareressourcen be-rücksichtigt das Modell nur die CPU des modellierten Hardwareservers. Die Fallstudie wertet die Antwortzeiten und die CPU-Auslastung nur für einen einzigen Benutzer aus und vergleicht die Modellergebnisse nicht mit Messergebnissen.

Da die gefunden Fallstudien F4 und F5 keinen Vergleich zwischen Vorhersage- und realen Messergebnissen machen, kann die Vorhersagegenauigkeit von  SPE•ED  nicht beurteilt werden. Dieser Umstand rührt wahrscheinlich daher, dass, wie schon erwähnt, SPE•ED  eigentlich als ein Unterstützungswerkzeug bei der Entwicklung von Anwendungssystemen konzipiert und nicht für die Analyse von fertigen Anwendungssystemen entwickelt wurde.

3.4 Layered Queuing Network Model (LQNM) Layered Queuing Network Models (LQNM) sind eine populäre Erweiterung von QNMs und wurden im Umfeld der Carleton Universität entwickelt (Franks et al. 1995; Rolia/Sevcik 1995; Woodside et al. 1995). LQNMs bestehen  aus  „Tasks“,  welche  sowohl  Hardwareserver  als auch sogenannte Softwareserver repräsentieren können. Softwareserver sind logische Einheiten ei-nes Anwendungssystems, welche mehrere Operationen zur Verfügung stellen und besitzen, wie Hardwareressourcen, eine begrenzte Kapazität (z.B. bestimmte Anzahl an Threads eines Da-tenbankmanagementsystems (DBMS)). „Tasks“  haben einen Wartebereich für ankommende

24

Anfragen, die nicht sofort bearbeitet werden können und spezifizieren eine  „Scheduling“-Stra-tegie, nach  welcher  der  „Task“ die Anfragen abarbeitet. Die verschiedenen Operationen, die ein  „Task“ anbietet, werden als „Entries“ bezeichnet.  „Entries“  eines  „Tasks“ können wiederum „Entries“  von  anderen  „Tasks“  aufrufen. Dadurch kann ein LQNM die Applikationslogik eines Anwendungssystems beliebig komplex abbilden. „Entries“  spezifizieren  den  Bedarf  an  einer  bestimmten Hardwareressource, welche in einem LQNM durch „Host  Processors“  modelliert werden. Ein  „Host  Processor“  kann  z.B.  eine  CPU  modellieren und besitzt, wie bei QNM, eine Warteschlange und eine „Scheduling“-Strategie. Als  zusätzliches  Attribut  hat  ein  „Host  Pro-­cessor“  die  sogenannte  „Speed  Ratio“,  mit  welcher  der  Ressourcenbedarf  eines  „Entries“  ska-­liert werden kann, wenn z.B. von einer langsamen CPU auf eine schnellere CPU gewechselt wird. LQNMs bilden das Benutzerverhalten über einen eigenständigen  „Task“ ab. Eine detail-lierte Beschreibung aller Modellierungsartefakte des LQNM-Konzeptes gibt Woodside (2013). Abbildung 10 zeigt ein Beispiel eines LQNMs.

Abbildung 10: Layered Queuing Network Model Quelle: In Anlehnung an (Woodside 2013, 3; Gradl 2012, 31)

Das LQNM zeigt ein sehr vereinfacht modelliertes Shopsystem, das von 200 Benutzern gleich-zeitig benutzt wird. Die Benutzer üben alle drei Sekunden die von der Web-Applikation bereit-gestellte Operation browse oder buy aus. Diese Operationen führen zu Aufrufen auf dem darunterliegenden DBMS. Sowohl die Web-Applikation als auch das DBMS werden auf dem-selben Hardwareserver ausgeführt, dessen CPU mit 8 Kernen im LQNM abgebildet ist. Das Modell bildet ebenfalls die zur Verarbeitung der einzelnen Operationen benötigte Zeit auf der modellierten CPU ab.

3.4.1 Layered Queuing Network Solver (LQNS)

Der Layered Queuing Network Solver (LQNS), in der ersten Version entwickelt von Franks et al. (1995), ist die direkte Implementierung des oben vorgestellten LQNM-Ansatzes. LQNS bie-tet keine graphische Benutzeroberfläche zur Modellierung von LQNMs an, sondern ist ein rei-nes Kommandozeilen-Tool. Ein LQNM wird dabei in einer XML-Datei (Maly 2004) spezifi-ziert und von LQNS verarbeitet.

25

Lösungsverfahren LQNS kann die Performance und den Ressourcenverbrauch eines modellierten Anwendungs-systems durch ein analytisches Lösungsverfahren oder durch eine Simulation prognostizieren (Franks et al. 2013).

Abstraktionsgrad LQNMs wurden u.a. dafür konzipiert, Anwendungssysteme detaillierter modellieren zu können als in klassischen QNMs. LQNMs können durch  die  Modellierungsartefakte  der  „Tasks“  und  „Entries“,  die  wiederum  andere  „Entries“  aufrufen  können,  ein  Anwendungssystem  beliebig  komplex modellieren.

Hardwareressourcen und Energie LQNS bietet keine explizit vordefinierten Hardwareressourcen an. Über das Modellierungsele-ment des „Host  Processors“  kann  jede  beliebige  Hardwareressource  modelliert  werden,  die  eine  gewisse Zeit für die Verarbeitung einzelner Anfragen benötigt. Dadurch können sich die An-fragen in einem Wartebereich anstauen. LQNS ermöglicht also die Modellierung der gängigs-ten Hardwareressourcen, wie CPU, HDD, RAM und das Netzwerk.

Modellierungsart Performance-Modelle auf Basis von LQNS sind nur begrenzt geeignet, um ein Ressourcen-Profil zu repräsentieren. LQNS ermöglicht zwar den Ressourcenverbrauch  einzelner  „Entries“  über  das  Attribut  der  „Speed  Ratio“  des  „Hosting  Processors“  von  einem  initialen  Hardware-­server auf einen Zielhardwareserver zu skalieren. Aber mit LQNS kann die Softwarearchitek-tur, die Hardwareinfrastruktur und das Benutzerverhalten nicht voneinander getrennt modelliert werden. Diese drei Aspekte sind in einer monolithischen XML-Datei miteinander verwoben. Bei einer größeren Änderung der Hardwareinfrastruktur müsste das gesamte Modell aufwendig geändert werden.

Fallstudien F6. Wie in der Fallstudie F1 zu JMT erwähnt (siehe Kapitel 3.3.1) bilden Rolia et al. (2009) einmal ein ERP-System mit JMT und einmal mit LQNS ab. Die Kriterien des Lösungsverfah-rens, des Abstraktionsgrades, der Abbildung von Hardwareressourcen und der untersuchten Performance- und Ressourcenbedarfs-Metriken haben die gleiche Ausprägung wie in der Be-trachtung der Fallstudie F1 zu JMT. Aber die Fallstudie F6 hat festgestellt, dass unter der Aus-nutzung verschiedener Modellierungsartefakte von LQNM,  wie  z.B.  Kapazitäten  von  „Tasks“  oder  asynchrone  bzw.  synchrone  Aufrufe  zwischen  „Tasks“,  die Ergebnisse aus dem LQNM die Realität besser widerspiegeln als die Ergebnisse aus dem QNM.

F7. Petriu et al. (2000) untersuchen die Performance und den Ressourcenverbrauch eines CORBA (Common Object Request Broker Architecture) basierten Anwendungssystems. Dazu implementiert die Fallstudie eine synthetische Anwendung, die auf vier verschiedenen Hard-wareservern läuft. Das LQNM modelliert diese vier Hardwareserver als eigenständige „Tasks“  mit  nur  einem  „Entry“. Zu  jedem  dieser  Server  wurde  die  CPU  als  „Host  Processor“  abgebildet. Ein  eigenständiger  „Task“  bildet  das Benutzerprofil ab. Das analytische Lösungsverfahren von

26

LQNS prognostiziert die Auslastung der CPU und die Antwortzeiten bei unterschiedlicher Be-nutzeranzahl. Die Fallstudie vergleicht diese Ergebnisse mit realen Messergebnissen. Der Un-terschied zwischen den durch das LQNM ermittelten Metriken und den Messergebnissen lag in den meisten Fällen unter 12 %. Eine Energiebetrachtung findet nicht statt.

F8. Qin et al. (1996) entwickeln in ihrer Arbeit ein Verfahren für die automatische Generierung eines LQNMs für verteilte Systeme, die  auf  Basis  der  „Distributed  Computing  Environment  (DCE)“-Technologie implementiert wurden. Dazu muss die Anwendung instrumentalisiert werden, d.h., im Anwendungscode müssen bestimmte Veränderungen vorgenommen werden, damit die Anwendung Informationen über ihren Ressourcenverbrauch, z.B. benötigte CPU-Zeit, aufzeichnet. Diese Instrumentalisierung ist allerdings noch ein manueller Prozess und er-fordert Expertenwissen. Aus den durch die Instrumentation aufgezeichneten Metriken generiert das entwickelte Verfahren ein LQNM, welches anschließend durch LQNS ausgewertet werden kann. Das generierte LQNM bildet die Schnittstellen zwischen verschiedenen Anwendungs-komponenten ab. Als Hardwareressourcen kann das Verfahren die CPU, die HDD und das Netzwerk im generierten LQNM abbilden. Die Modellgenerierung bildet keine Energieeigen-schaften des Anwendungssystems ab. Zu Demonstrationszwecken führt die Fallstudie eine au-tomatische Modellgenerierung für ein sehr kleines selbstentwickeltes Anwendungssystem, bestehend aus einem Hardwareserver, durch. Das durch LQNS zur Verfügung gestellte analy-tische Lösungsverfahren analysiert anschließend das Anwendungssystem für eine unterschied-liche Anzahl an Benutzern und einer variierenden Konfiguration der Anwendung. Allerdings variiert die Benutzeranzahl in dieser Fallstudie nur zwischen 1 und 10, was für eine Unterneh-mensanwendung sehr wenig ist. Der Vergleich der Modellergebnisse mit realen Messergebnis-sen zeigt, dass das Modell die Antwortzeiten des Anwendungssystems mit weniger als 15 % Abweichung prognostizieren kann. Auf die Auslastung der modellierten Hardwareressourcen wurde bei der Analyse nicht eingegangen.

F9. Tiware/Mynampati (2006) modellieren die Benchmark-Anwendung SPECjAppServer2001 (SPEC 2001) als LQNM mit LQNS. SPECjAppServer2001 implementiert eine Anwendung für das Lieferketten-Management eines typischen Fertigungsbetriebs. Diese Fallstudie setzt auf der Fallstudie F13 von Kounev/Buchmann (2003b) auf, welche die Anwendung SPECjAppSer-ver2001 als Queuing Petri Net Model (QPNM) modellieren und die Modellergebnisse in meh-reren Testszenarien mit realen Messergebnissen vergleichen. Die Testszenarien unterscheiden sich in einem unterschiedlichen Abstraktionsgrad der Modelle und unterschiedlicher Hardware-konfiguration. Auf die Details dieser Fallstudie zu LQNS wird an dieser Stelle verzichtet, da sich der Abstraktionsgrad der Modelle (Server und Anfrageklassen), die modellierten Ressour-cen (CPU und HDD) und die nicht vorhandene Energiebetrachtung analog zu den Modellen der ursprünglichen Fallstudie F13 (Kounev/Buchmann 2003b) verhalten (siehe Kapitel 3.5). Das Hauptergebnis dieser Fallstudie ist, dass LQNMs auf Basis von LQNS zu gleich guten Progno-seergebnissen führen wie die QPNMs aus der Original-Studie. Die Prognosen der Performance- und Ressourcenauslastungs-Metriken weichen in den meisten Fällen nicht mehr als 15 % von den realen Messergebnissen ab.

F10. Die Arbeit von Tiwari/Nair (2010) zeigt, wie ein LQNM von einer initialen Hardwarein-frastruktur auf eine Ziel-Hardwareinfrastruktur transformiert werden kann. Dazu schlägt die Arbeit   vor,   den   Ressourcenbedarf   der   einzelnen   „Entries“   mittels   des   „SPEC   CPU2006“-

27

Benchmarks (SPEC 2006a) zu skalieren. Der Benchmark wird dazu auf dem initialen und fina-len Hardwareserver ausgeführt und der Ressourcenverbrauch gemäß den Benchmark-Ergebnis-sen im Modell angepasst. Hat ein  „Entry“  im LQNM für den initialen Server einen CPU-Bedarf von 30 ms und der finale Hardwareserver erreicht einen doppelt so hohen Benchmarkwert wie der initiale Server, wird im angepassten LQNM der Ressourcenbedarf für  diesen  „Entry“  auf 15 ms gesenkt. Zur  Skalierung  des  Ressourcenverbrauchs  der  „Entries“  bietet  ein LQNM die Möglichkeit  zur  Spezifizierung  einer  „Speed  Ratio“  der  modellierten  Hardwareressource  (siehe Kapitel 3.4). Diese Möglichkeit verwendet dieser Ansatz aber nicht, sondern passt jeden „Entry“  einzeln an. Die Fallstudie evaluiert den gezeigten Ansatz anhand der Demoanwendung „iBATIS JPetStore“   (Begin 2013), welche einen Webshop für Haustiere implementiert. Die Anwendung wird dazu auf einem Applikations- und einem Datenbankserver installiert. Das LQNM modelliert die Anwendung auf der Abstraktionsebene von Servern, in dem es die beiden Server  als  einzelne  „Tasks“  mit  jeweils  nur  einem  „Entry“  abbildet. Als Hardwareressourcen bildet das Modell jeweils die CPU der beiden Server ab. Die Fallstudie passt das LQNM von einer initialen Hardwareinfrastruktur auf drei verschiedene Ziel-Hardwareinfrastrukturen an, wobei immer der Applikationsserver ausgetauscht wurde. Zur Simulation der LQNMs benutzen die Autoren eine selbstentwickelte Software, welche nicht öffentlich verfügbar ist, aber dem vorgestellten LQNS ähnelt (Tiwari/Kashyap 2011, 500). Die Fallstudie vergleicht für die ver-schiedenen Hardwarekonfigurationen die Simulationsergebnisse für die CPU-Auslastung der Server, sowie Antwortzeiten und Durchsatz mit realen Messergebnissen. Die Last auf dem An-wendungssystem wurde für diesen Vergleich gering gehalten. Die Modelle konnten die CPU-Auslastung der verschiedenen Applikationsserver mit maximal 26 %, die Antwortzeiten mit maximal 20 % und den Durchsatz mit maximal 13 % Abweichung prognostizieren.

3.4.2 Component Based Modeling Language (CBML)

Die Component Based Modeling Language (CBML) (Wu/Woodside 2004) ist eine Erweiterung zu dem im LQNS (siehe Kapitel 3.4.1) spezifizierten XML-Schema für LQNMs. CBML be-trachtet  „Tasks“  als  Softwarekomponenten  und  dessen  „Entries“  als  die  Schnittstellen  dieser  Komponenten. Mit  CBML  lassen  sich  „Tasks“  unabhängig  voneinander   in   separaten XML-Dateien definieren und anschließend zu einem Gesamtmodell zusammensetzen. Ein mit CBML modellierter „Task“  definiert  über  die  „Entries“, welche Schnittstellen die Komponente anbie-tet. Außerdem wird abgebildet, welche Schnittstellen die „Entries“ von anderen Komponenten benötigen. Nur wenn die Schnittstellen zwischen den Komponenten übereinstimmen, kann CBML diese zu einem Gesamtmodell zusammensetzen. Die  „Host  Processors“ der modellier-ten „Tasks“, werden in einer separaten XML-Datei spezifiziert. CBML generiert aus den ver-schiedenen XML-Dateien ein vollständiges LQNM, welches anschließend mit LQNS gelöst werden kann (siehe Kapitel 3.4.1).

Lösungsverfahren Das aus CBML generierte LQNM entspricht dem durch LQNS definierten XML-Schema. Dadurch kann CBML auf die von LQNS zur Verfügung gestellten analytischen und simulati-onsbasierten Lösungsverfahren zurückgreifen.

Abstraktionsgrad Durch die Modellierung von „Tasks“ in separaten XML-Dateien ist es noch einfacher als bei LQNS, ein Anwendungssystem in beliebiger Detailtiefe zu modellieren.

28

Hardwareressourcen und Energie CBML  definiert  keine  expliziten  Hardwareressourcen  für  die  „Host  Processors“.  Da das finale Modell den Modellierungsregeln von LQNS entspricht, kann CBML die gängigsten Hardwa-reressourcen abbilden. CBML sieht keine Möglichkeit zur Abbildung des Energieverbrauchs eines Anwendungssystems vor.

Modellierungsart CBML bietet durch das Konzept der verschiedenen XML-Dateien  für  die  „Tasks“  und  deren „Host  Processors“  die  Möglichkeit, die Softwarearchitektur unabhängig von der Hardwarein-frastruktur zu modellieren und ist daher als Repräsentation eines Ressourcen-Profils geeignet. Der Softwarehersteller kann die Komponenten seiner Unternehmensanwendung durch ver-schiedene  „Tasks“  in mehreren XML-Dateien modellieren. Der Kunde spezifiziert in einer se-paraten XML-Datei die Hardwareressourcen, auf denen die jeweilige Komponente ausgeführt wird. Das Benutzerverhalten wird durch  einen  eigenständigen  „Task“  und somit auch in einer separaten XML-Datei modelliert. CBML führt die verschiedenen modularen XML-Dateien zu einem gesamten LQNM zusammen. Das finale Modell kann der Kunde mit LQNS zur Evalua-tion seines Anwendungssystems verwenden.

Fallstudie F11. Xu et al. (2005) zeigen in ihrer Arbeit, wie Softwarekomponenten, die auf Basis von Enterprise Java Beans (EJB) implementiert wurden, als LQNM abgebildet werden können. Dazu entwickeln die Autoren Templates für die verschiedenen Arten von EJBs, z.B. Stateful oder Stateless Session Beans. Die erarbeiteten Templates basieren aber noch auf der „Java Enterprise Edition“ 1.4 (Java EE) und sind somit etwas veraltet. Zur Evaluation der Templates modelliert die Fallstudie mit CBML die Java EE-Demoanwendung   „Duke’s   Bank“ (Sun Microsystems 2005) und vergleicht die Modellergebnisse anschließend mit realen Messergeb-nissen. Dazu wurden die verschiedenen Softwarekomponenten der Anwendung in separaten XML-Dateien auf Basis der LQNM-Templates abgebildet. Das Modell stellt dabei die Soft-warekomponenten sehr detailliert auf dem Abstraktionsgrad von einzelnen Methoden dar. Die Hardwareinfrastruktur besteht aus einem Anwendungs- und einem Datenbankserver. Das er-stellte CBML-Modell bildet die beiden Server sowie deren CPUs ab. Für den Vergleich zwi-schen den analytischen Modellergebnissen und den realen Messergebnissen wird die Benutzeranzahl zwischen 1 und 20 variiert. Das Modell konnte die Antwortzeiten mit einem maximalen Fehler von 25 % vorhersagen. Die Modellergebnisse für die CPU-Auslastungen wurden nicht mit Messergebnissen verglichen.

3.4.3 UML-to-LQNM

Die  „Unified  Modeling  Language“  (UML)  ist die Standard-Modellierungssprache in der Soft-wareentwicklung. Es gibt mehrere Ansätze, die aus UML-Modellen über eine Modelltransfor-mation LQNMs erzeugen. Die Erläuterungen in diesem Kapitel beziehen sich auf den durch Gu/Petriu (2002) initial konzipierten und in weiteren Arbeiten (Petriu/Woodside 2004; Gu/Petriu 2005) weiterentwickelten Modelltransformations-Ansatz. D'Ambrogio (2005) erar-beitete einen ähnlichen Ansatz.

29

Für die Modellierung eines Anwendungssystems werden die drei UML-Diagrammtypen Kol-laborationsdiagramm, Deploymentdiagramm und Aktivitätsdiagramm verwendet. Das Kolla-borationsdiagramm modelliert die grobe Softwarearchitektur des Anwendungssystems, welche aus verschiedenen Softwarekomponenten besteht. Die Modelltransformation übersetzt jede die-ser  Softwarekomponenten  in  einen  „Task“  des  LQNMs. Das Deploymentdiagramm spezifiziert das Mapping zwischen den Softwarekomponenten und den Hardwareressourcen. Die Transfor-mation  bildet  die  Hardwareressourcen  aus  dem  Deploymentdiagramm  als  die  „Host  Proces-­sors“  eines  „Tasks“  im  LQNM  ab.   In mehreren Aktivitätsdiagrammen können die durch die Anwendung implementierten Anwendungsroutinen modelliert und somit die Softwarearchitek-tur detailliert abgebildet werden. Die Aktivitätsdiagramme bilden die von den Softwarekompo-nenten implementierten Algorithmen und das Zusammenspiel der Komponenten ab. Die Modelltransformation zu einem LQNM erzeugt aus den Aktivitätsdiagrammen die  „Entries“  der  „Tasks“,  deren  Ressourcenbedarfe  und  die  Aufrufe  zwischen  den  „Entries“. Durch die Ak-tivitätsdiagramme wird auch das Benutzerverhalten modelliert. Das durch die Modelltransfor-mation erzeugte LQNM kann anschließend mit LQNS evaluiert werden (siehe Kapitel 3.4.1).

Lösungsverfahren Die Modelltransformation erstellt aus den UML-Modellen ein LQNM, welches mit LQNS kompatibel ist. Daher stehen bei diesem Ansatz die durch LQNS implementierten analytischen und simulationsbasierten Lösungsverfahren zur Verfügung.

Abstraktionsgrad Die Kollaborations- und Aktivitätsdiagramme ermöglichen die Modellierung der Softwarear-chitektur in beliebiger Detailtiefe.

Hardwareressourcen und Energie Die UML-Deploymentdiagramme besitzen keine vordefinierten Hardwareressourcen, auf wel-che die Softwarekomponenten referenzieren, sondern bieten nur ein generisches Modellelement dafür an. Die Modelltransformation übersetzt die im Deploymentdiagramm definierten Hard-wareressourcen  zu  „Host  Processors“  im  LQNM. Daher kann der gezeigte Modelltransforma-tionsansatz die verbreitesten Hardwareressourcen wie CPU, HDD, RAM oder das Netzwerk, abbilden.

Modellierungsart Wie gezeigt, wird die Softwarearchitektur in einem Kollaborationsdiagramm und mehreren Ak-tivitätsdiagrammen abgebildet. Die Hardwareinfrastruktur wird separat in einem Deployment-diagramm definiert. Durch diese Modularität eignet sich der gezeigte Ansatz zur Repräsentation eines Ressourcen-Profils. Der Kunde bekommt die Kollaborations- und Aktivitätsdiagramme vom Softwarehersteller und modelliert seine kundenspezifische Hardwareinfrastruktur im Deploymentdiagramm. In den Aktivitätsdiagrammen kann der Kunde die erwartete Anzahl an Aufrufen der modellierten Anwendungsroutinen spezifizieren und somit sein Benutzerverhal-ten abbilden.

30

Fallstudie F12. Die Fallstudie von Petriu/Shen (2002) wendet den gezeigten Ansatz auf ein unternehmens-weites Dokumentenverwaltungssystem an. Die modellierten Aktivitätsdiagramme bilden die Softwarearchitektur sehr detailliert auf Methodenebene ab. Die Hardwareinfrastruktur besteht aus einem Hardwareserver. Das Deploymentdiagramm modelliert dazu als Hardwareressour-cen zwei HDDs und das Netzwerk. Die Fallstudie untersucht dabei nicht den Energieverbrauch des Anwendungssystems. Die Autoren zeigen das nach der Transformation der UML-Modelle entstehende LQNM. Dieses LQNM wird anschließend leider nicht weiter ausgewertet, um Per-formance- und Ressourcenverbrauchs-Metriken zu erhalten. Es kann also nicht direkt die Prog-nosegenauigkeit dieses Ansatzes bewertet werden. Da allerdings das finale Modell den Modellierungsregeln des Metamodells LQNS entspricht, können die dort gezeigten Fallstudien als Anhaltspunkt für die Vorhersagegenauigkeit herangezogen werden (siehe Kapitel 3.4.1).

3.5 Queuing Petri Net Model (QPNM) Queuing Petri Net Models (QPNM) sind eine Kombination von QNMs (siehe Kapitel 3.3) und Petri Netzen (Bause 1993). Ein klassisches Petri Netz besteht aus Plätzen und Transitionen, die über Kanten miteinander verbunden sind. Plätze können sogenannte Marken enthalten, welche über die Transitionen wiederum zu anderen Plätzen transferiert werden. Dadurch wird in einem Petri-Netz der aktuelle Zustand eines Systems und dessen Zustandsänderung abgebildet. In ei-nem QPNM kann ein Platz eine Warteschlange enthalten, die bereits aus der QNM-Theorie bekannt ist (siehe Kapitel 3.3). Die Marken definieren die Zeitspanne, die sie an bestimmten Plätzen benötigen, um verarbeitet zu werden. Wenn eine Marke nun durch eine Transition in einen Platz transferiert wird, landet sie zunächst in der Warteschlange und wird nach einer de-finierten „Scheduling“-Strategie verarbeitet und in der Lagerstelle des Platzes abgelegt. Von der Lagerstelle wird die Marke anschließend wieder weitertransferiert. Abbildung 11 zeigt ein beispielhaftes QPNM für ein Anwendungssystem.

Abbildung 11: Queuing Petri Net Model Quelle: Eigene Darstellung

31

Das QPNM modelliert ein Datenbankanwendungssystem, an das die Benutzer verschiedene Anfragen stellen können. Ein separater Platz bildet die Benutzer ab. Die verschiedenen Farben der Marken repräsentieren die unterschiedlichen Anfragen, welche die Benutzer an das Anwen-dungssystem stellen können. Das QPNM modelliert die CPU und die HDD des Datenbankser-vers als eigene Plätze, an denen die Benutzeranfragen eine gewisse Verarbeitungszeit beanspruchen.

Queuing Petri Net Modeling Environment (QPME) Um QPNMs toolbasiert zu modellieren und auszuwerten, hat Bause zunächst die Software HiQPN entwickelt (Bause/Buchholz/Kemper 1995). HiQPN wird aber seit längerer Zeit nicht mehr weiterentwickelt und ist nur noch auf alten Systemen lauffähig (Kounev/Dutz/Buchmann 2006, 115). HiQPN implementierte nur ein analytisches Lösungsverfahren, welches umfang-reiche QPNMs nicht mehr lösen konnte. Um diesen Mangel zu beheben, wurde die Software Queuing Petri Net Modeling Environment (QPME) entwickelt (Kounev/Spinner/Meier 2010; Kounev/Dutz 2009; Spinner/Kounev/Meier 2012). QPME ist eine Java-basierte Anwendung und auf den meisten Computersystemen lauffähig. QPME bietet eine graphische Benutzerober-fläche, um QPNMs zu erstellen und auszuwerten.

Lösungsverfahren Um Performance- und Ressourcenverbrauchs-Metriken aus den QPNMs zu erhalten, imple-mentiert QPME ein simulationsbasiertes Lösungsverfahren.

Abstraktionsgrad Die Marken in einem QPNM können verschiedene Anfrageklassen und deren Ressourcenver-brauch an den jeweiligen Hardwareressourcen, modelliert als Plätze, abbilden. Die Abbildung von Softwarekomponenten und deren Schnittstellen ist nicht möglich.

Hardwareressourcen und Energie QPME erlaubt die Abbildung aller Hardwareressourcen, deren Verhalten sich durch eine War-teschlange mit einem bestimmten „Scheduling“-Verhalten ausdrücken lassen. Dazu zählen CPU, HDD, RAM und das Netzwerk. QPME bietet keine speziell vorgefertigten Hardwareres-sourcen an und implementiert keine Möglichkeit zur Abbildung und Evaluation des Energie-verbrauchs eines Anwendungssystems.

Modellierungsart QPME ist nicht geeignet, ein Ressourcen-Profil zu repräsentieren, da ein Anwendungssystem in einem monolithischen Performance-Modell abgebildet wird. QPME bietet keine getrennte Modellierung der Softwarearchitektur, der Hardwarearchitektur und des Benutzerverhaltens an.

Fallstudien An dieser Stelle werden sowohl Fallstudien für QPME als auch für HiQPN vorgestellt, da beide Performance-Metamodelle auf QPNMs basieren.

32

F13. Kounev/Buchmann (2003b) erstellen auf Basis des Metamodells HiQPN ein QPNM der Benchmark-Unternehmensanwendung SPECjAppServer2001 (SPEC 2001). In der Fallstu-die F3 haben die gleichen Autoren diese Anwendung, allerdings in einer neueren Version (SPECjAppServer2002), schon als QNM abgebildet und die Modellergebnisse mit realen Mes-sergebnissen verglichen (Kounev/Buchmann 2003a). Kapitel 3.3.1 zeigt diese Fallstudie F3 und beschreibt auch die Benchmark-Anwendung in größerer Detailierung. Die hier behandelte Fallstudie zu HiQPN beschränkt sich auf die Modellierung der Teilanwendung der "Order Entry Application“. Die Anwendung läuft dabei auf einem Applikations- und einem Datenbankser-ver. Zur Evaluation von HiQPN modelliert die Fallstudie das Anwendungssystem dreimal auf jeweils einem unterschiedlichen Abstraktionsgrad. Die Modelle bilden in allen drei Szenarien als Hardwareressourcen die CPU des Applikations- und Datenbankservers als Plätze mit War-teschlange und "Scheduling"-Verhalten ab. Für den Datenbankserver wurde zusätzlich noch die HDD modelliert. Im ersten Szenario bildet das Modell die unterschiedlichen Benutzeranfragen unter einer einzigen Anfrageklasse, also einer Marke im QPNM, ab. Im zweiten Szenario sollte das QPNM die Softwarearchitektur genauer modellieren und bildet daher mehrere Anfrageklas-sen ab. Allerdings bekamen die Autoren bei der Auswertung des QPNM ein Problem, da das Modell zu komplex für das analytische Lösungsverfahren von HiQPN war. Deshalb verein-fachten sie das Modell, indem sie einzelne Aspekte, wie z.B. den "Connection-Pool" der Da-tenbank, aus dem Modell herausnahmen. Im dritten Szenario wurde die Hardwareinfrastruktur geändert, so dass mehrere Applikationsserver in einem Cluster betrieben wurden. Für alle drei Szenarien vergleicht die Fallstudie die Modellergebnisse für die Auslastung der CPUs der Ser-ver und die Antwortzeiten mit realen Messergebnissen. Die Prognosewerte wichen in den meis-ten Fällen weniger als 15 % von den Messwerten ab. Die Last, spezifiziert durch die Anzahl der Benutzer, wurde in allen drei Szenarien konstant gehalten.

F14. Um die Leistungsfähigkeit von QPME zu demonstrieren, erstellt Kounev (2006) ein QPNM für die Benchmark-Anwendung SPECjAppServer2004 (SPEC 2004) und vergleicht die Modellergebnisse mit den realen Messergebnissen. SPECjAppServer2004 ist eine Weiterent-wicklung der schon vorgestellten Vorgängerversionen und hat einiges an Komplexität zugelegt (Su et al. 2005). Die Anwendung ist rund um das Geschäftsszenario eines Automobilherstellers entwickelt worden. Die Anwendung umfasst dabei fast die gesamte Wertschöpfungskette, aus-gehend von den Automobilhändlern, über die Produktion bis zu dem Lieferantenmanagement. In der Fallstudie besteht die Hardwarearchitektur aus einem Cluster von Applikationsservern und einem Datenbankserver. Ein Load Balancer verteilt die Anfragen auf die verschiedenen Applikationsserver. Das QPNM modelliert jeweils die CPU des Load Balancers, der Applika-tionsserver und des Datenbankservers. Zusätzlich bildet das Modell die HDD des Datenbank-servers ab. Die Softwarearchitektur wurde aggregiert in fünf Anfrageklassen abgebildet. Die Fallstudie simuliert das erstellte QPNM mit QPME für eine unterschiedliche Anzahl an Benut-zern und Applikationsservern und vergleicht die Modellergebnisse mit realen Messergebnissen. Die Abweichungen zwischen Simulationsergebnissen und Messergebnissen für die Auslastung der Ressourcen und den Antwortzeiten lag in fast allen Fällen unter 10 %.

F15. Kounev et al. (2011) modellieren ein QPNM einer Implementierung  der  „GemFire  Enter-­prise Data Fabric (EDF)“ (VMware 2013). Bei dieser Anwendung handelt es sich um ein Sys-tem, bei  dem  Daten  verteilt  auf  mehrere  Server  in  einer  Art  „Peer-to-Peer“-Netzwerk gespei-

33

chert und über eine Schnittstelle zur Verfügung gestellt werden. Benutzer können Daten in der EDF ablegen und wieder abrufen. Mit QPME erstellt die Fallstudie ein Modell einer EDF, be-stehend aus 4 bzw. 6 beteiligten Servern. Zu jedem dieser Server bilden die Modelle die CPU ab. Außerdem berücksichtigen die Modelle die Netzwerkverbindung zwischen den einzelnen Servern. Die Softwarearchitektur wurde aggregiert in zwei Anfrageklassen (Daten ablegen und Daten abrufen) modelliert. Anschließend simuliert die Fallstudie die QPNMs unter moderater und unter schwerer Last (50 bzw. 70 % Auslastung der CPUs der jeweiligen Server) und ver-gleicht die Modellergebnisse mit den realen Messergebnissen. Die Auslastung der CPUs und des Netzwerks konnte in allen Fällen mit einer Abweichung unter 10 % prognostiziert werden. Die Abweichungen bei der Prognose der Antwortzeiten waren leicht höher.

3.6 Palladio Component Model (PCM) Das Palladio Component Model (PCM) (Reussner et al. 2011) ist ein Performance-Metamodell, welches nicht auf einem klassischen Performance-Modell-Typ basiert. PCM wurde entwickelt, um modellbasiert die Performance und den Ressourcenbedarf von komponentenbasierten An-wendungssystemen zu prognostizieren. Ein Anwendungssystem wird in PCM durch fünf ver-schiedene Modelltypen, welche sich gegenseitig referenzieren, modelliert. Abbildung 12 zeigt die einzelnen Modelltypen und deren gegenseitigen Referenzen. Auf die einzelnen Modellty-pen wird im Folgenden näher eingegangen.

Allocation Model

Resource Environment Model

System Model

Usage Model

Repository Model

Referenz

Abbildung 12: Teilmodelle des Palladio Component Models Quelle: Eigene Darstellung

Das  „Repository  Model“  und  das  „System  Model“  bilden  die  Softwarearchitektur  eines  An-­wendungssystems ab. Im “Repository  Model”  werden die Softwarekomponenten abgebildet. Zu einer Komponente können die Schnittstelle, welche die Softwarekomponente nach außen anbietet und die Schnittstellen welche sie von anderen Komponenten benötigt, modelliert wer-

34

den. „Resource Demanding Service Effect Specifications“  (RDSEFF)  modellieren  die  Imple-­mentierung dieser Schnittstellen. Ein RDSEFF bildet eine Anwendungsroutine  über  “Internal  Actions” und  „External Call Actions“,  welche  über  Kanten  miteinander  verbunden  sind, ab. Eine  „Internal  Action“  kann den Ressourcenbedarf an einer bestimmten Hardwareressource, welche im  „Resource  Environment  Model“  modelliert  ist, spezifizieren. Der Ressourcenbedarf gibt an,  wie  viele  Arbeitseinheiten  eine  Hardwareressource  benötigt,  um  die  „Internal  Action“  zu verarbeiten. Eine  Hardwareressource  spezifiziert  im  „Resource  Environment  Model“, wie viele Arbeitseinheiten diese pro Sekunde abarbeiten kann. „External  Call  Actions“  bilden  Auf-­rufe zu Schnittstellen anderer Komponenten ab. Zur Modellierung des Kontrollflusses stehen Modellelemente wie Verzweigungen oder Wiederholungen zur Verfügung. Abbildung 13 zeigt ein Beispiel eines  „Repository  Models“  mit  dazugehöriger  RDSEFF.

Repository Model

Resource Demanding Service Effect Specification (RDSEFF)

Abbildung 13: PCM – Repository Model mit RDSEFF Quelle: In Anlehnung an (Brunnert/Vögele/Krcmar 2013, 80)

Das  „Repository  Model“  ist in Abbildung 13 links zu sehen und zeigt die zwei Komponenten ComponentA und ComponentB mit ihren jeweils angebotenen Schnittstellen. Man sieht, dass die ComponentA die Schnittstelle IComponentB benötigt. Das RDSEFF, in Abbildung 13 rechts, zeigt die von ComponentA zur Verfügung gestellte Operation operationA. Die „Internal  Actions“   spezifizieren jeweils den Bedarf an den Hardwareressourcen CPU und HDD. Das RDSEFF modelliert eine Verzweigung, deren Äste mit bestimmter Wahrscheinlichkeit ausge-führt werden. Wird der rechte Ast ausgeführt, wird die von ComponentB zur Verfügung ge-stellte Operation operationC in einer Schleife aufgerufen.

Das „System  Model“  setzt die im  „Repository  Model“  abgebildeten Komponenten durch Ver-knüpfen der modellierten Schnittstellen zu einer Gesamtanwendung zusammen. Das  „System  Model“  definiert auch, welche Schnittstellen direkt durch die Endanwender angesteuert werden können. Abbildung 14 zeigt ein „System  Model“.  

35

Abbildung 14: PCM – System Model Quelle: Eigene Darstellung

Das  „System  Model“  zeigt,  dass  ComponentA auf die Schnittstelle von ComponentB zugreift. Die von ComponentA angebotene Schnittstelle wird nach außen zur direkten Benutzung durch die Endanwender angeboten.

Das  „Resource  Environment  Model“  bildet  die Hardwareinfrastruktur eines Anwendungssys-tems ab. „Ressource  Container“  repräsentieren Hardwareserver und werden  über  „Linking  Res-­sources“, welche die Netzwerkverbindung zwischen Servern abbilden, miteinander verbunden. Die  Hardwareressourcen  CPU  und  HDD  können  einem  „Resource  Container“  mittels dem Mo-dellelement  „Processing  Resource  Specification“  hinzugefügt  werden. Eine Hardwareressource in PCM besitzt ein definiertes „Scheduling“-Verhalten, eine Multiplizität („Number  of  Repli-­cas“)   und eine Verarbeitungsgeschwindigkeit („Processing   Rate“). Die Verarbeitungsge-schwindigkeit gibt an, wie viele Arbeitseinheiten die Ressource innerhalb einer Sekunde ver-arbeiten kann. Abbildung 15 zeigt ein  ein  „Resource Environment Model“.

Abbildung 15: PCM – Resource Environment Model Quelle: Eigene Darstellung

Das „Resource  Environment  Model“  zeigt zwei Server, die über ein Netzwerk miteinander ver-bunden sind. Für beide Server wurden jeweils die CPU und die HDD modelliert, welche jeweils eine  „Processing  Rate“  von  1000  besitzen.

36

Das „Allocation  Model“  definiert  auf  welchen  Hardwareservern  des  „Resource  Environment  Models“, die im „Repository  Model“  modellierten  und  im  „System  Model“  zusammengesetz-ten Softwarekomponenten ausgeführt werden. Das „Allocation  Model“  verknüpft also die Soft-warearchitektur mit der Hardwareinfrastruktur. Abbildung 16 zeigt  ein  „Allocation  Model“.

Abbildung 16: PCM – Allocation Model Quelle: Eigene Darstellung

Das  „Allocation  Model“  in  diesem  Beispiel ordnet ComponentA dem Server1 und die Compo-nentB dem Server2 zu.

Das  „Usage  Model“  ist  in  PCM  für  die  Abbildung  des  Benutzerverhaltens zuständig. „System  Call  Actions“  spezifizieren, welche Schnittstellen des Anwendungssystems durch die Benutzer aufgerufen werden können. Das  „Usage  Model“  definiert, wie viele Benutzer mit dem Anwen-dungssystem gleichzeitig interagieren und welche Wartezeit zwischen deren einzelnen Aufru-fen liegt. Abbildung 17 zeigt  ein  „Usage  Model“.

Abbildung 17: PCM – Usage Model Quelle: Eigene Darstellung

Dieses „Usage  Model“  spezifiziert, dass ein Nutzer mit 60 % Wahrscheinlichkeit die Operation operationA und mit 40 % Wahrscheinlichkeit die Operation operationB der Komponente Com-ponentA aufruft. Zwischen zwei Aufrufen benötigt der einzelne Benutzer 9,7 Sekunden Be-denkzeit, in denen er keine weitere Operation ausführt. Insgesamt interagieren 1500 Benutzer mit dem Anwendungssystem.

37

Palladio-Bench Die Palladio-Bench (Becker/Koziolek/Reussner 2009, 13-15) implementiert das PCM-Metamodell. Die Palladio-Bench ist eine auf der Eclipse Platform (Eclipse 2013) basierende Anwendung, mit der über graphische Editoren konkrete Instanzen des PCM-Metamodells er-stellt werden können.

Lösungsverfahren Die Palladio-Bench bietet mehre Lösungsverfahren an, um mittels eines PCM-Modells die Per-formance- und die Ressourcenauslastungs-Metriken eines Anwendungssystems zu prognosti-zieren. Das voreingestellte Lösungsverfahren ist die prozessorientierte Simulationsumgebung SimuCom (Becker 2008, 109-200). Daneben implementiert die Palladio-Bench auch die ereig-nisorientierte Simulationsumgebung EventSim (Merkle/Henss 2011). Auf eine Erklärung der Unterschiede zwischen prozess- und ereignisorientierter Simulation wird an dieser Stelle ver-zichtet. Die Palladio-Bench ermöglicht auch die analytische Lösung von PCM-Modellen.

Abstraktionsgrad In PCM werden die  Komponenten  im  „Repository  Model“  abgebildet.  Die  einzelnen  Operati-­onen der Komponenten können detailliert in den RDSEFFs modelliert werden. Für die Model-lierung des Kontrollflusses einer Operation stehen mehrere Modellierungsartefakte wie Schleifen und Verzweigungen zur Verfügung. Auch können Aufrufe von Operationen anderer Komponenten modelliert werden. Die Palladio-Bench bietet also die Möglichkeit, PCM-Mo-delle in einer sehr hohen Detailtiefe bis zum Abstraktionsgrad von Methoden zu modellieren.

Hardwareressourcen und Energie Das „Resource  Environment  Model“  ermöglicht die Modellierung der CPU und HDD eines Hardwareservers und kann die Netzwerkverbindung zwischen zwei Servern abbilden. Der RAM kann derzeit nicht modelliert werden.

Modellierungsart Die Palladio-Bench kann die Softwarearchitektur im  „Repository“  und  „System  Model“, die Hardwareinfrastruktur im  „Allocation  Model“  und das Benutzerverhalten im  „Usage  Model“  in gesonderten Teilmodellen abbilden. Das „Allocation  Model“ verknüpft die Softwarearchi-tektur mit der Hardwareinfrastruktur. Durch Anpassung der „Processing  Rate“  einer  Hardware-ressource kann der Ressourcenbedarf,  welcher  in  den  „Internal  Actions“  spezifiziert  ist, zwi-schen verschiedenen Hardwareservern skaliert werden. Durch die modulare Modellierungsart und die einfache Skalierung des Ressourcenverbrauchs ist PCM bzw. die Palladio-Bench als Repräsentation eines Ressourcen-Profils geeignet.

Fallstudien F16. Brosig/Huber/Kounev (2011) entwickeln in ihrer Arbeit einen halbautomatischen Ansatz, um ein PCM-Modell für eine Java EE-Anwendung zu generieren, welche auf einem Oracle WebLogic Application Server läuft. Über die Monitoring-Daten des Application Servers gene-riert der entwickelte Ansatz eine Instanz eines PCM-Modells auf dem Abstraktionsgrad von Komponenten. Allerdings sind in diesem Prozess noch einige manuelle Schritte durch den Be-nutzer, wie die Abgrenzung einzelner Softwarekomponenten der betrachteten Java EE-

38

Anwendung, notwendig. Die Arbeit evaluiert ihren Ansatz anhand der Benchmark-Anwendung SPECjEnterprise2010 (SPEC 2010a). SPECjEnterprise2010 ist der Nachfolger von SPECjApp-Server2004 (SPEC 2004) und die aktuellste Version der Java EE-Benchmark-Anwendung. Es wurde ein PCM-Modell von der Anwendung SPECjEnterprise2010, welche auf einem Cluster von Java EE-Applicationservern und einem Datenbankserver installiert wurde, generiert. Das Modell berücksichtigt als Hardwareressourcen jeweils die CPU der modellierten Hardwareser-ver. Die Fallstudie vergleicht für unterschiedliche Szenarien (geringe bis hohe Benutzerlast und unterschiedliche Anzahl an Applicationserver) die Simulationsergebnisse der CPU-Auslastung und der Antwortzeiten aus dem PCM-Modell mit realen Messergebnissen. In den meisten Fäl-len konnte das PCM-Modell die CPU-Auslastung der Server und die Antwortzeiten mit weniger als 20 % Abweichung prognostizieren. Nur in einem Szenario mit 8 Applicationserver und ho-her Benutzerlast wurden Abweichungen bei den Antwortzeiten von über 50 % festgestellt.

F17. Brunnert/Vögele/Krcmar (2013) stellen in ihrer Arbeit auch einen Ansatz zur automati-schen Generierung eines PCM-Modells von einem laufenden Java EE-Anwendungssystem vor. Im Gegensatz zur Arbeit von Brosig/Huber/Kounev (2011) aus Fallstudie F16 sind hierbei kaum manuelle Eingriffe notwendig. Bis  auf  das  „Usage  Model“  werden  alle  PCM-Teilmodelle automatisch generiert. Außerdem ist der Ansatz nicht auf einen speziellen Typ von Java EE-Applicationserver begrenzt, sondern funktioniert mit allen Applicationservern, welche die Java EE-Spezifikation (DeMichiel/Shannon 2013) erfüllen. Der entwickelte Modellgenerierungsan-satz zeichnet über die in der Java EE-Spezifikation definierten Technologien der Servlet Filter und EJB Interceptor sowohl Benutzeraufrufe als auch interne Aufrufe zwischen Softwarekom-ponenten des Anwendungssystems inklusive deren CPU-Bedarfe auf. Aus den gesammelten Daten generiert der Ansatz anschließend ein PCM-Modell des Anwendungssystems, welches die Softwarearchitektur des Anwendungssystems auf der Abstraktionsebene von Komponenten abbildet. Die Arbeit evaluiert ihren Ansatz ebenfalls anhand einer Teilanwendung des SPECjEnterprise2010-Benchmarks (SPEC 2010a). Dazu wurde die Anwendung inklusive Da-tenbank auf einem virtualisierten Server installiert und ein PCM-Modell generiert. Das Benut-zerverhalten  wurde  im  „Usage  Model“  gemäß  der im Benchmark definierten Regeln abgebildet. Die Arbeit vergleicht die Simulationsergebnisse des PCM-Modells für eine variierende Anzahl an Benutzern mit realen Messergebnissen. Das Modell konnte die CPU-Auslastung des Servers mit weniger als 10 % Abweichung prognostizieren. Der Durchsatz des Anwendungssystems konnte mit einer Abweichung von unter 2 % sehr genau vorhergesagt werden. Die Abweichun-gen bei der Prognose der Antwortzeiten betrug maximal 20 %.

3.7 Ansätze aus der Praxis Dieses Kapitel gibt einen Überblick darüber, wie Hersteller von Unternehmensanwendungen den Ressourcenverbrauch ihrer Anwendung beschreiben und den Kunden zur Verfügung stel-len. Ansätze, die den Energieverbrauch einer Unternehmensanwendung ausweisen, konnten im Rahmen dieser Arbeit nicht gefunden werden. Die gefundenen Ansätze dienen den Kunden als Hilfsmittel beim Kapazitätsmanagement. Dabei soll den Kunden geholfen werden, die notwen-dige Hardware zu bestimmen, um die Unternehmensanwendung unter den kundenspezifischen Gegebenheiten, z.B. der Benutzeranzahl, betreiben zu können. Wie Kapitel 2.4 zeigt, ist das Kapazitätsmanagement auch ein Anwendungsfall des Ressourcen-Profils.

39

Ein verbreiteter Ansatz ist die Definition einer oder mehrerer Referenzarchitekturen auf der die Anwendung im Optimalfall installiert werden soll. Die Softwarehersteller führen Lasttests auf diesen Referenz-Anwendungssystemen durch. Bei diesen Lasttests wird eine bestimmte Anzahl an konkurrierenden Nutzern und deren Verhalten simuliert. Die Benutzeranzahl wird solange erhöht, bis das Anwendungssystem gewisse Vorgaben, wie z.B. die maximale Antwortzeit, nicht mehr erfüllen kann. Die Ergebnisse dieser Tests werden den Kunden zur Verfügung ge-stellt. Die Ergebnisse zeigen, wie viele Benutzer das getestete Anwendungssystem maximal unterstützt. Sie weisen allerdings meistens nicht den genauen Ressourcenbedarf, z.B. die durch-schnittliche CPU-Auslastung, für diese Anzahl an Benutzern aus. Ein großer Nachteil dieses Ansatzes ist, dass der Kunde keine Ergebnisse für seine spezifische Hardwareinfrastruktur und sein Benutzerverhalten erhält. Er kann die Ergebnisse aus den Lasttests auf den Referenzarchi-tekturen daher nur als groben Anhaltspunkt für den Ressourcenbedarf einer Anwendung in sei-nem kundenspezifischen Umfeld verwenden. Beispiele für diesen Ansatz finden sich u.a. für die Portal- und Kollaborationssoftware Liferay (Liferay 2013) oder die  „Portal-Middleware“  WebLogic Portal (Oracle 2008). In den genannten Beispielen werden die Ergebnisse aus den Lasttests in statischen Tabellen den Kunden zur Verfügung gestellt.

Für manche Unternehmensanwendungen stellen Softwarehersteller auch einfache mathemati-sche Modelle zur Berechnung des Ressourcenverbrauchs einer Anwendung auf einer Referenz-Hardwarearchitektur zur Verfügung. Softwarehersteller stellen diese Modelle dem Kunden meistens als Excel-Tabellen zur Verfügung. Der Kunde kann darin, je nach Komplexität des Modells, verschiedene Parameter, z.B. Anzahl der Benutzer und deren grobes Benutzerverhal-ten, definieren. Typischerweise berechnen diese Modelle anschließend, wie viele von den im Modell hinterlegten Hardwareservern benötigt werden, um die durch den Benutzer spezifizierte Last bewältigen zu können. Außerdem prognostizieren manche dieser Modelle die durch-schnittliche Auslastung bestimmter Hardwareressourcen. Beispiele für diese Art von Modellen in parametrisierbaren Excel-Tabellen finden sich u.a. für die Videokonferenzanwendung Lync (Microsoft 2013) oder die  „Enterprise  Mobility  Management“-Software BlackBerry Enterprise Service 10 (BlackBerry 2013). Diese Modelle basieren häufig auf einfachen mathematischen Zusammenhängen, wie der in der Arbeit von Cook/Dudar/Shallahamer (2001) erarbeiteten  „Ra-­tio  Modeling  Technique“. Formel 2 zeigt diesen Modellansatz.

𝑁 ∗ 𝑈 =   𝐶𝑅

Formel 2: Ratio Modeling Technique

Die Variable 𝑁 entspricht der Anzahl der im Modell abgebildeten Hardwareressource mit einer gewünschten Auslastung 𝑈. Die Variable 𝐶 entspricht der Anzahl an konkurrierenden Anfra-gen einer bestimmten Anfrageklasse. 𝑅 ist eine Maßzahl, die das Verhältnis zwischen Anfra-geklasse und Hardwareressource ausdrückt und für einen Hardwareserver durch Messungen eines Produktivsystems oder durch Lasttests bestimmt werden kann. Die Funktionsweise dieses Modells wird an einem kurzen Beispiel erläutert. Das beispielhafte Modell bildet nur eine An-frageklasse 𝐶 ab. Der Kunde spezifiziert die Anzahl der konkurrierenden Anfragen mit 150. Der Softwarehersteller hat für die Verhältniszahl 𝑅 durch Lasttests auf einem festgelegten

40

Hardwareserver den Wert 1,5 ermittelt. Wenn die gewünschte CPU-Auslastung 𝑈 50 % betra-gen soll, kann das Modell nach der benötigten Anzahl an Servern 𝑁 aufgelöst werden. Man kommt zu dem Ergebnis, dass zur Bewältigung der 150 konkurrierenden Anfragen 2 Hardware-server mit jeweils 50 % CPU-Auslastung notwendig sind. Der Vorteil dieses Ansatzes ist, dass der Kunde Ergebnisse speziell für sein Benutzerprofil bekommt. Nachteile dabei sind, dass die Modelle keine Flexibilität bei der Spezifikation der Hardwareinfrastruktur besitzen und nur für eine spezielle Referenz-Hardwarearchitektur erstellt werden. Durch die einfachen mathemati-schen Zusammenhänge innerhalb dieser Art von Modellen können diese auch nur Ergebnisse mit niedriger Präzision liefern (Cook/Dudar/Shallahamer 2001, 1).

Der SAP Quick Sizer (SAP 2013b) versucht die Abhängigkeit eines Modells von einer Refe-renz-Hardwarearchitektur zu umgehen. Der SAP Quick Sizer ist eine Webanwendung zur Er-mittlung der optimalen Hardwareinfrastruktur für ein neues SAP-Anwendungssystem und benutzt dabei ähnliche mathematische Zusammenhänge wie im vorher gezeigten Ansatz (Missbach/Hoffmann 2000, 70-100). Der Kunde kann in dieser Webanwendung die erwartete Anzahl gleichzeitig agierender Nutzer für die verschiedenen Module der Anwendung spezifi-zieren. Der SAP Quick Sizer berechnet daraus im Gegensatz zu dem vorherigen Ansatz nicht die optimale Anzahl eines Referenz-Servers oder dessen Hardwareressourcenauslastung, son-dern einen Benchmarkwert („SAP  Application  Performance  Standard“  (SAPS)), welchen ein Server erreichen muss, um die SAP-Anwendung betreiben zu können. Der SAPS-Benchmark bewertet primär die Leistungsfähigkeit der CPU eines Servers und vernachlässigt andere Hard-wareressourcen (Gradl 2012, 25-26). Da der SAPS-Benchmark bei Hardwareherstellern weit verbreitet ist (SAP 2013a), kann ein Kunde auf Basis des errechneten Benchmarkwertes einen ausreichend dimensionierten Hardwareserver wählen. Dieser Ansatz ist unabhängig von einer bestimmten Hardwarearchitektur und vom kundenspezifischen Nutzerverhalten. Die Präzision des Ansatzes kann auf Grund der einfachen mathematischen Zusammenhänge und der Kritik am SAPS-Benchmark, dass dieser keine realitätsnahen Ergebnisse liefert (Bögelsack 2012, 81-82), als niedrig bewertet werden.

3.8 Zusammenfassung und Wahl des Performance-Metamodells Die vorangegangenen Kapitel zeigen unterschiedliche Performance-Metamodelle und untersu-chen diese hinsichtlich der Eignung ein Ressourcen-Profil zu repräsentieren (siehe Kapitel 2). Tabelle 1 stellt die untersuchten Performance-Metamodelle und die Ausprägungen der jeweils zum Metamodell untersuchten Kriterien dar. Die Tabelle 2 zeigt die zu den verschiedenen Me-tamodellen untersuchten Fallstudien. Die Vielzahl der Fallstudien und deren Evaluationsergeb-nisse zeigen, dass Performance-Modelle grundsätzlich sehr gut geeignet sind, um die Perfor-mance eines Anwendungssystems sowie dessen Ressourcenbedarf abzubilden. Performance-Modelle bieten sich daher als Basistechnologie für ein Ressourcen-Profil an. Die Untersuchun-gen der Ansätze aus der Praxis haben gezeigt, dass es vereinzelt Ansätze gibt, die eine Unter-nehmensanwendung in einem Modell abbilden, um den Kunden bei der Wahl der Hardwarein-infrastruktur zu helfen. Die untersuchten Ansätze weisen aber Schwächen hinsichtlich der Ge-nauigkeit der Ergebnisse und der teilweisen Abhängigkeit von einer bestimmten Hardware-

41

architektur auf. Im Rahmen dieser Arbeit wurde sich dafür entschieden, das Konzept des Res-sourcen-Profils mit Hilfe von PCM und der Palladio-Bench weiterzuverfolgen. Im Folgenden werden die Gründe für die Wahl von PCM dargestellt.

Die wichtigste Eigenschaft, damit ein Performance-Metamodell als Ressourcen-Profil agieren kann, ist die Möglichkeit zur modularen Zusammenstellung eines Performance-Modells (siehe Kapitel 3.2). PCM erfüllt neben SPE•ED, CBML und UML-to-LQNM diese Prämisse.

Es hat sich gezeigt, dass keines der untersuchten Performance-Metamodelle die Abbildung des Energieverbrauchs eines Anwendungssystems vorsieht. Folgerichtig hat auch keine der gefun-denen Fallstudien, mit Ausnahme der Fallstudie F2, den Energieverbrauch der untersuchten Anwendungssysteme betrachtet. Da der Energieverbrauch einer Unternehmensanwendung aber eine wichtige Information für einen Kunden darstellt, soll das in Kapitel 2 vorgestellte Ressour-cen-Profil auch den Energieverbrauch einer Unternehmensanwendung abbilden können. Die Palladio-Bench  ist  „Open  Source“  und  basiert  auf  der  in  der  Softwareentwicklung  bewährten  Eclipse Plattform. Die Palladio-Bench lässt sich daher leicht um eine Funktionalität zur Abbil-dung des Energieverbrauchs eines Anwendungssystems erweitern. Die Softwaretools zu SPE•ED, CBML oder UML-to-LQNM sind nicht frei verfügbar und der Quellcode ist nicht offengelegt. Eine Erweiterung dieser Performance-Metamodelle ist daher nicht möglich.

Die Palladio-Bench unterstützt bis auf den RAM die Modellierung der gängigsten Hardware-ressourcen. Alle anderen Performance-Metamodelle haben diese Einschränkung nicht. Bei der Untersuchung der Fallstudien zeigt sich aber, dass die CPU die am häufigsten abgebildete Hard-wareressource ist und der RAM bei keiner der untersuchten Fallstudien modelliert wurde. Da-her scheint es, dass der RAM bei der Untersuchung von Unternehmensanwendungen vernach-nachlässigt werden kann. Deshalb spricht diese Einschränkung nicht grundsätzlich gegen die Wahl von PCM bzw. der Palladio-Bench als Repräsentation eines Ressourcen-Profils.

PCM ist sehr ausdrucksmächtig und unterstützt dadurch einen sehr hohen Detailgrad in der Modellierung eines Anwendungssystems. Der Ersteller eines Ressourcen-Profils auf Basis von PCM kann dadurch frei entscheiden welchen Abstraktionsgrad er bei der Modellierung einer Unternehmensanwendung wählt.

Für die Analyse der PCM-Modelle stehen sowohl analytische auch als simulationsbasierte Lö-sungsverfahren zur Verfügung. Die Fallstudien F16 und F17 zeigen, dass die standardmäßige Simulationsumgebung der Palladio-Bench sehr genaue Werte für die Performance- und Res-sourcenverbrauchs-Metriken liefern kann.

Einer der Hauptgründe für die Wahl von PCM ist auch die hohe Expertise, die im Umfeld dieser Arbeit zu PCM zur Verfügung stand.

42

Met

a-M

odel

l Ty

p Lö

sung

s-

verf

ahre

n A

bstr

aktio

ns-

grad

H

ardw

are-

ress

ourc

en

Ener

gie

Mod

ellie

rung

s-ar

t Q

uelle

JMT

QN

M

Ana

lytis

ch,

Sim

ulat

ion

Anf

rage

klas

sen

CPU

, HD

D,

RA

M, N

ET

Nei

n M

onol

ithis

ch

(Ber

toli/

Cas

ale/

Sera

zzi

2009

a, 2

009b

) PE

PSY

-QN

S Q

NM

A

naly

tisch

, Si

mul

atio

n A

nfra

gekl

asse

n C

PU, H

DD

, R

AM

, NET

N

ein

Mon

olith

isch

(K

irsch

nick

199

4;

Baz

an/B

olch

/Ger

man

200

6)

SPE•ED

Q

NM

A

naly

tisch

, Si

mul

atio

n K

ompo

nent

en

CPU

, HD

D,

RA

M, N

ET

Nei

n M

odul

ar

(Sm

ith/W

illia

ms 1

997)

LQN

S LQ

NM

A

naly

tisch

, Si

mul

atio

n M

etho

den

CPU

, HD

D,

RA

M, N

ET

Nei

n M

onol

ithis

ch

(Fra

nks e

t al.

1995

)

CB

ML

LQN

M

Ana

lytis

ch,

Sim

ulat

ion

Met

hode

n C

PU, H

DD

, R

AM

, NET

N

ein

Mod

ular

(W

u/W

oods

ide

2004

)

UM

L-to

-LQ

NM

LQ

NM

A

naly

tisch

, Si

mul

atio

n M

etho

den

CPU

, HD

D,

RA

M, N

ET

Nei

n M

odul

ar

(Gu/

Petri

u 20

02;

Petri

u/W

oods

ide

2004

; G

u/Pe

triu

2005

) Q

PME

QPN

M

Sim

ulat

ion

Anf

rage

klas

sen

CPU

, HD

D,

RA

M, N

ET

Nei

n M

onol

ithis

ch

(Kou

nev/

Dut

z 20

09;

Kou

nev/

Spin

ner/M

eier

201

0;

Spin

ner/K

oune

v/M

eier

201

2)

HiQ

PN

QPN

M

Ana

lytis

ch

Anf

rage

klas

sen

CPU

, HD

D,

RA

M, N

ET

Nei

n M

onol

ithis

ch

(Bau

se/B

uchh

olz/

Kem

per

1995

) Pa

lladi

o-B

ench

PC

M

Ana

lytis

ch,

Sim

ulat

ion

Met

hode

n C

PU, H

DD

, N

ET

Nei

n M

odul

ar

(Bec

ker/K

ozio

lek/

Reu

ssne

r 20

09)

Tabe

lle 1

: Übe

rsic

ht d

er u

nter

such

ten

Perf

orm

ance

-Met

amod

elle

Q

uelle

: Eig

ene

Erhe

bung

42

43

Fall-

stud

ie

Met

a-M

odel

l Lö

sung

s-

verf

ahre

n A

bstr

aktio

nsgr

ad

Har

dwar

e-

ress

ourc

en

Ener

gie

Que

lle

F1

JMT

Ana

lytis

ch

Anf

rage

klas

sen

CPU

N

ein

(Rol

ia e

t al.

2009

) F2

JM

T Si

mul

atio

n Se

rver

C

PU

Ja

(Li/C

asal

e/El

lahi

201

0)

F3

PEPS

Y-Q

NS

Ana

lytis

ch

Anf

rage

klas

sen

CPU

, HD

D

Nei

n (K

oune

v/B

uchm

ann

2003

a)

F4

SPE•ED

A

naly

tisch

Si

mul

atio

n K

ompo

nent

en

CPU

, HD

D, N

ET

Nei

n (S

mith

/Will

iam

s 200

0)

F5

SPE•ED

A

naly

tisch

Si

mul

atio

n K

ompo

nent

en

CPU

N

ein

(Sm

ith/W

illia

ms 1

998)

F6

LQN

S A

naly

tisch

A

nfra

gekl

asse

n C

PU

Nei

n (R

olia

et a

l. 20

09)

F7

LQN

S A

naly

tisch

Se

rver

C

PU

Nei

n (P

etriu

et a

l. 20

00)

F8

LQN

S A

naly

tisch

K

ompo

nent

en

CPU

, HD

D, N

ET

Nei

n (Q

in e

t al.

1996

) F9

LQ

NS

Ana

lytis

ch

Serv

er,

Anf

rage

klas

sen

CPU

, HD

D

Nei

n (T

iwar

i/Myn

ampa

ti 20

06)

F10

Ähn

lich

zu L

QN

S Si

mul

atio

n Se

rver

C

PU

Nei

n (T

iwar

i/Nai

r 201

0)

F11

CB

ML

Ana

lytis

ch

Met

hode

n C

PU

Nei

n (X

u et

al.

2005

) F1

2 U

ML-

to-L

QN

M

- M

etho

den

HD

D, N

ET

Nei

n (P

etriu

/She

n 20

02)

F13

HiQ

PN

Ana

lytis

ch

Serv

er,

Anf

rage

klas

sen

CPU

, HD

D

Nei

n (K

oune

v/B

uchm

ann

2003

b)

F14

QPM

E Si

mul

atio

n A

nfra

gekl

asse

n C

PU, H

DD

N

ein

(Kou

nev

2006

) F1

5 Q

PME

Sim

ulat

ion

Anf

rage

klas

sen

CPU

, NET

N

ein

(Kou

nev

et a

l. 20

11)

F16

Palla

dio-

Ben

ch

Sim

ulat

ion

Kom

pone

nten

C

PU

Nei

n (B

rosi

g/H

uber

/Kou

nev

2011

) F1

7 Pa

lladi

o-B

ench

Si

mul

atio

n K

ompo

nent

en

CPU

N

ein

(Bru

nner

t/Vög

ele/

Krc

mar

201

3)

Tabe

lle 2

: Übe

rsic

ht d

er u

nter

such

ten

Falls

tudi

en z

u de

n Pe

rfor

man

ce-M

etam

odel

len

Que

lle: E

igen

e Er

hebu

ng

43

44

4 Abbildung des Energiebedarfs im Palladio Component Model

Wie das Kapitel 1 gezeigt hat, ist der Energieverbrauch ein großer Kostentreiber in Rechenzen-tren. Das Ressourcen-Profil einer Unternehmensanwendung soll daher neben der Performance und dem Ressourcenbedarf auch eine Aussage über den Energiebedarf einer Unternehmensan-wendung treffen (siehe Kapitel 2). Die Untersuchung verschiedener Performance-Metamodelle in Kapitel 3 zeigt, dass zum Zeitpunkt der Erstellung dieser Arbeit kein Performance-Metamo-dell bekannt ist, welches den Energiebedarf der abzubildenden Anwendung berücksichtigt. Auch das PCM-Metamodell sieht keine Möglichkeit zur Abbildung des Energieverbrauchs vor. Dieses Kapitel erweitert daher das PCM-Metamodell um die Funktionalität, den Energiever-brauch eines Anwendungssystems, bestehend aus Hard- und Software, abbilden zu können. Die Erweiterung  sieht  vor,  dass  in  PCM  einem  „Resource  Container“  (i.e.  Hardwareserver)  ein  li-­neares Leistungsaufnahme-Modell hinzugefügt werden kann. Kapitel 4.1 erläutert das Konzept des Leistungsaufnahme-Modells. Kapitel 4.2 zeigt die Generierung eines solchen Leistungs-aufnahme-Modells in einer Kalibrierungsphase. Kapitel 4.3 zeigt die Integration des Leistungs-aufnahme-Modells in das PCM-Metamodell. Außerdem geht Kapitel 4.3 auf die Erweiterung der Palladio-Bench Software ein, um den Energieverbrauch einer Anwendung auf Basis eines PCM-Modells zu prognostizieren.

4.1 Leistungsaufnahme-Modell Um den Energieverbrauch einer Anwendung zu bestimmen, muss man den Energieverbrauch der Hardware, auf dem die Anwendung läuft, betrachten. Abbildung 18 verdeutlich die Wir-kungszusammenhänge.

Abbildung 18: Wirkungszusammenhänge beim Energieverbrauch einer Anwendung Quelle: Eigene Darstellung

Anwendung

Hardware-ressourcen

Netzteil

Hardware-ressourcenHardware-ressourcen

benutzt

Leistungsauf-nahme

Server

Leistungsauf-nahme

45

Eine Anwendung verbraucht nicht unmittelbar Energie, sondern benutzt Hardwareressourcen, um eine bestimmte Aufgabe, z.B. die Berechnung von betriebswirtschaftlichen Kennzahlen, durchzuführen. Diese Hardwareressourcen wiederum beziehen elektrische Leistung von dem im Server verbauten Netzteil. Die Leistungsaufnahme einzelner Hardwareressourcen kann da-bei abhängig vom Grad der Beanspruchung durch die Software sein. Der Grad der Beanspru-chung spiegelt sich wieder in der Kennzahl der Ressourcen-Auslastung, wie z.B. der CPU-Auslastung. Ist die Leistungsaufnahme des Servers bekannt, kann über den in Formel 1 gezeig-ten Zusammenhang der Energieverbrauch des Servers für einen bestimmten Betrachtungszeit-raum berechnet werden.

Rivoire/Ranganathan/Kozyrakis (2008) untersuchen in ihrer Arbeit unterschiedliche Modelle, welche die Leistungsaufnahme eines Servers, also die Leistungsaufnahme am Netzteil des Ser-vers, über die Auslastungs-Metriken der Hardwareressourcen prognostizieren. Dazu haben die Autoren unterschiedliche Modelle für unterschiedliche Hardwareumgebungen generiert und die prognostizierten Werte der Modelle mit realen Messergebnissen verglichen. Die Arbeit kommt zu  dem  Ergebnis,  dass  solche  „High-Level“-Modelle generell zu sehr genauen Ergebnissen füh-ren. In den durchgeführten Tests lag der durchschnittliche Fehler bei allen Modellen unter 10 %. Eine Arbeit von Fan/Weber/Barroso (2007) zeigt, dass sogar lineare Modelle, welche die Leis-tungsaufnahme eines Servers nur in Abhängigkeit der CPU-Auslastung modellieren, zu sehr guten Vorhersagewerten führen.

Die Untersuchung der verschiedenen Performance-Metamodelle in Kapitel 3 zeigt, dass diese die Auslastung der gewöhnlichsten Hardwareressourcen abbilden können. Die zu den Perfor-mance-Metamodellen untersuchten Fallstudien zeigen eine hohe Genauigkeit bei der Prognose dieser Auslastungs-Metriken. Auch die Palladio-Bench bzw. deren Simulationsumgebungen (SimuCom und EventSim) sind geeignet, die Auslastung von Hardwareressourcen zu prognos-tizieren. Daher liegt es unter Berücksichtigung der oben gezeigten Wirkungszusammenhänge nahe, den Energieverbrauch einer Unternehmensanwendung über die Auslastung der model-lierten Hardwareressourcen zu approximieren und das PCM-Metamodell dahingehend zu er-weitern.

Diese Arbeit schlägt vor, die Leistungsaufnahme eines Servers in einem linearen Regressions-Modell abzubilden. Die Leistungsaufnahme des Servers wird dabei als abhängige Variable 𝑃 durch die unabhängigen Variablen der verschiedenen Ressourcenauslastungen 𝑢 erklärt. Die Formel 3 zeigt die Grundstruktur des linearen Leistungsaufnahme-Modells.

𝑃 = 𝐶 +   𝐶 ∗ 𝑢

Formel 3: Lineares Leistungsaufnahme-Modell eines Servers

Die Konstante 𝐶 entspricht dabei der Leistungsaufnahme des Servers in der Ruhephase, also wenn keine Last auf dem Server liegt. Die Faktoren 𝐶 bestimmen den Einfluss einer Hard-wareressource an der Gesamtleistungsaufnahme eines Servers.

46

Formel 4 zeigt ein Leistungsaufnahme-Modell, um die Anwendung eines Leistungsaufnahme-Modells zu illustrieren.

𝑃 = 200 + 300 ∗ 𝑢 + 50 ∗ 𝑢

Formel 4: Beispiel eines Leistungsaufnahme-Modells

Bei diesem linearen Modell ist die Leistungsaufnahme des Servers durch die CPU- und HDD-Auslastung abgebildet. Die Grundleistungsaufnahme ohne Last beträgt 200 Watt. Jeder zusätz-liche Prozentpunkt in der CPU-Auslastung trägt 3 Watt zur Gesamtleistungsaufnahme des Ser-vers bei. Jeder Prozentpunkt in der Kennzahl der HDD-Auslastung erhöht die Leistungsaufnahme des Servers um 0,5 Watt. Wie in Kapitel 3.6 beschrieben, kann ein PCM Modell die Ressourcenauslastung der modellierten Ressourcen prognostizieren. Wenn in dem gezeigten Beispiel das PCM-Modell eine durchschnittliche CPU-Auslastung von 50 % und eine HDD-Auslastung von 20 % vorhersagt, kann mittels des Modells aus Formel 4 eine durch-schnittliche Leistungsaufnahme des Servers von 360 Watt (200 + 300 ∗ 0,5 + 50 ∗ 0,2 =  360  ) berechnet werden. Betrachtet man einen Simulationszeitraum von 5 Stunden kann mittels der Gleichung in Formel 1 ein Energieverbrauch von 1,8 kWh (360  𝑊   ∗ 5  ℎ  /  1000 =  1,8  𝑘𝑊ℎ) berechnet werden.

Das folgende Kapitel 4.2 zeigt die Erstellung eines konkreten Leistungsaufnahme-Modells mit-tels linearer Regressionsanalyse. Kapitel 4.3 zeigt die Integration dieses Leistungsaufnahme-Modells in das PCM-Metamodell.

4.2 Generierung des Leistungsaufnahme-Modells Die lineare Regressionsanalyse ist ein statistisches Verfahren, welches versucht, eine abhängige Variable (die Leistungsaufnahme des Servers) durch eine oder mehrere unabhängige Variablen (die Auslastung der Hardwareressourcen) zu erklären. Die lineare Regressionsanalyse ermittelt dabei die Regressionskoeffizienten 𝐶 aus Formel 3.

Um durch lineare Regression ein Leistungsaufnahme-Modell zu erstellen, müssen die Leis-tungsaufnahme des Servers und die gleichzeitig herrschenden Auslastungs-Metriken der be-trachteten Hardwareressourcen gemessen werden. Für die Beschaffung dieser Messergebnisse schlägt vorliegende Arbeit als systematisches Verfahren eine sogenannte Kalibrierungsphase vor. Diese basiert auf den Grundideen von Economou et al. (2006). In der Kalibrierungsphase werden die einzelnen Hardwareressourcen, welche im Leistungsaufnahme-Modell abgebildet werden sollen, unabhängig voneinander mit unterschiedlicher Intensität für eine bestimmte Zeitspanne ausgelastet. Zeitgleich wird die Leistungsaufnahme des Servers gemessen. Der Ka-librierungslauf kann z.B. die CPU-Auslastung in 10 % Schritten von 0 % bis 100 % erhöhen, während er die HDD-Auslastung auf 0 % belässt. Anschließend variiert der Kalibrierungslauf die HDD-Auslastung und lässt die CPU in der Ruhephase. Während der Kalibrierungsphase werden gleichzeitig die Auslastungs-Metriken und die Leistungsaufnahme des Servers gemes-sen. Dadurch erhält man eine Liste von Messergebnissen, wie sie Tabelle 3 beispielhaft dar-stellt.

47

Leistung CPU-Auslastung HDD-Auslastung 225 W 10 % 0 % 220 W 10 % 0 % 235 W 10 % 0 % 250 W 20% 0 % 265 W 20 % 0 % … … … 220 W 0 % 50 % 235 W 0 % 50 % 225 W 0 % 50 % 230 W 0 % 60 % 235 W 0 % 60 % … … …

Tabelle 3: Messergebnisse des Kalibrierungslaufs für die Modellgenerierung Quelle: Eigene Tabelle

Mittels statistischer Softwarepakete kann eine lineare Regressionsanalyse auf diesen Messwer-ten durchgeführt werden, um ein lineares Modell zu erhalten, das die Leistungsaufnahme des Servers in Korrelation zur Auslastung der gemessenen Hardwareressourcen setzt. Das Verfah-ren der linearen Regression versucht dabei den Fehlerwert, den das Modell beim Einsetzen der gemessenen unabhängigen Variablen produziert, zu minimieren. Deshalb ist darauf zu achten, dass zu jeder Auslastungsstufe der jeweiligen Hardwareressource die gleiche Anzahl an Mess-werten vorliegt, weil ansonsten das bei der linearen Regression erstellte Modell gegenüber den Auslastungsstufen mit mehr Messwerten verzerrt ist. Formel 4 zeigt ein beispielhaftes Modell, das sich nach einer linearen Regression auf den obigen Messwerten aus Tabelle 3 ergeben könnte.

Um die Hardwareressourcen eines Servers auszulasten, kann z.B. auf Linux-Umgebungen das Kommandozeilenprogramm lookbusy (Carraway 2013) verwendet werden. Lookbusy lastet die Hardwareressourcen CPU, HDD und RAM mit einer vorher definierten Intensität aus. Um die tatsächliche Hardwareressourcenauslastung zu kontrollieren und zu messen kann auf Linux Systemen z.B. das Kommandozeilenprogramm sysstat (Godard 2013) genutzt werden. Ein ex-ternes Leistungsmessgerät kann die Leistungsaufnahme des Servers ermitteln. Moderne Server im Unternehmensumfeld besitzen meist schon Hardwaresensoren, welche die Leistungsauf-nahme des Servers messen. Der Server stellt die Messdaten dieser Sensoren meist über die „Intelligent  Platform  Management  Interface  (IPMI)“-Schnittstelle (Intel 2013) für einen exter-nen Zugriff zur Verfügung. Da nicht jeder Server die gleiche Konfiguration hinsichtlich Be-triebssystem und angebotener Schnittstelle zur Leistungsmessung besitzt, muss die Kalibrierungsphase immer speziell auf den jeweiligen Server abgestimmt sein. Sie ist damit nur eingeschränkt generalisierbar.

48

4.3 Integration des Leistungsaufnahme-Modells in das PCM-Metamodell Dieses Kapitel zeigt die Integration des im Kapitel 4.1 erarbeiteten Leistungsaufnahme-Modells in das PCM-Metamodell. Die Erweiterung basiert auf der Palladio-Bench Version 3.4.

Das PCM-Metamodell, sowie die Palladio-Bench basieren technisch auf dem Eclipse Modeling Framework (EMF) (Becker 2008, 35). Mit dem EMF-Framework lässt sich ein Metamodell spezifizieren. Anschließend wird aus dem Metamodell mit Hilfe von EMF eine Eclipse An-wendung generiert, in der man mit den von EMF generierten Model-Editoren konkrete Instan-zen dieses Metamodells erstellt. Das Grundgerüst der Palladio-Bench besteht also aus dem mit EMF spezifizierten PCM-Metamodell und der daraus generierten Eclipse Anwendung. Die durch EMF generierten Modell-Editoren ermöglichen die Erstellung und Editierung einer XML-Baumstruktur. Für eine bessere Benutzerfreundlichkeit implementiert die Palladio-Bench zusätzlich noch graphische Editoren zur Erstellung von konkreten Instanzen des PCM-Metamodells. Außerdem implementiert die Palladio-Bench mehrere Simulationsumgebungen (SimuCom und EventSim), die die konkreten PCM-Instanzen zur Simulation der modellierten Anwendung benutzen.

Zunächst zeigt Kapitel 4.3.1, wie das mit EMF spezifizierte PCM-Metamodell um das Leis-tungsaufnahme-Modell aus Kapitel 4.1 erweitert wird. Anschließend zeigt Kapitel 4.3.2 die Erweiterung der Simulationsumgebungen zur Berechnung des Energiebedarfs mit Hilfe des Leistungsaufnahme-Modells.

4.3.1 Erweiterung des PCM-Metamodells

Das Metamodell in EMF ist im  sogenannten  „Ecore“-Format  spezifiziert.  „Ecore“  ist  ein  XML-Format und repräsentiert im Grunde eine Teilmenge von UML-Klassendiagrammen. Abbil-dung 19 zeigt den für die Erweiterung relevanten Ausschnitt aus dem PCM-Metamodell als UML-Klassendiagramm.

Abbildung 19: Integration des Leistungsaufnahme-Modells in das PCM-Metamodell Quelle: Eigene Darstellung

49

Die Hardwareserver werden in PCM im  „Resource  Environment  Model“  als  „Resource  Con-­tainer“  abgebildet  (siehe  Kapitel  3.6). Ein  „Resource  Container“  kann  mehrere  „Processing  Re-­source Specifications“   enthalten,   was   den   Hardwareressourcen   des   modellierten   Servers  entspricht. Um  die  Leistungsaufnahme  eines  Servers  in  PCM  abzubilden,  kann  nun  ein  „Re-­source  Container“  zusätzlich  noch  ein  „Power  Consumption  Model“  beinhalten.  Das  „Power  Consumption  Model“  repräsentiert  das  in  Kapitel  4.1 gezeigte Leistungsaufnahme-Modell. Das „Power  Consumption  Model“  hat  dazu  das Attribut  „constant“, welches der Konstante 𝐶 aus der Formel 3 entspricht. Um den Einfluss der Hardwareressourcen (𝐶  ∗  𝑢 )  im  „Power  Con-­sumption  Model“  abzubilden,  kann  diese  eine  Liste  von  „Power  Consumption  Components“  beinhalten.  Ein  „Power  Consumption  Component“  hat  eine  Referenz  auf die Hardwareresource (i.e.  „Processing  Resource  Specification“),  auf  deren Auslastungs-Metrik (𝑢 ) sie sich bezieht und spezifiziert den dazugehörigen Regressionskoeffizienten (𝐶 ). Aus diesem erweiterten PCM-Metamodell wird eine neue Eclipse-Anwendung generiert, mit der eine konkrete PCM-Instanz mit Leistungsaufnahme-Modell erstellt werden kann.

Abbildung 20 zeigt, wie ein Anwender mit Hilfe des von EMF generierten XML-basierten Edi-tors  das  „Power  Consumption  Model“  im  „Resource  Environment  Model“  für  eine  konkrete  PCM-Instanz anlegen kann. In Abbildung 21 wird das   „Power  Consumption  Model“   in  der  graphischen  Repräsentation  des  „Resource  Environment  Model“  vorgestellt. Auf die Imple-mentierung einer graphischen  Darstellung  des  „Power  Consumption  Model“  wurde  allerdings  im Rahmen dieser Arbeit verzichtet. Somit steht dem Anwender in der aktuellen Version nur der vom EMF generierte XML-basierte Modeleditor zur Verfügung.

Abbildung 20:  Anlegen  des  „Power  Consumption  Models“  im  XML-basierten Editor Quelle: Eigene Darstellung

50

Abbildung 21:  Graphische  Repräsentation  des  „Power  Consumption  Models“ Quelle: Eigene Darstellung

Das modellierte „Resource  Environment  Model“ zeigt einen Server mit den Hardwareressour-cen CPU und HDD. Der Server enthält ein Leistungsaufnahme-Modell in Form des oben be-schriebenen „Power   Consumption  Models“.   Das   abgebildete   „Power   Consumption  Model“  entspricht dem Leistungsaufnahme-Modell aus Formel 4 (𝑃  =  200   +  300 ∗  𝑢  +  50   ∗  𝑢 ). Das  Attribut  „constant“  (𝐶 )  des  „Power  Consumption  Models“  besitzt den Wert 200. Das  „Power  Conumption  Model“  enthält  zwei  „Power  Consumption  Components“.  Das  Power Consumption Component 1 (𝐶  ∗  𝑢 ) bezieht sich auf die modellierte Hardwareressource der CPU und besitzt den Faktor 300. Das Power Consumption Component 2 modelliert den Einfluss der HDD (𝐶  ∗  𝑢 ) und spezifiziert daher den Faktor 50.

4.3.2 Erweiterung der Simulationsumgebungen

Um den Energieverbrauch einer Anwendung mit der Palladio-Bench zu prognostizieren, wer-den die beiden Simulationsumgebungen SimuCom und EventSim erweitert. Der grobe Simula-tionsablauf wird im Folgenden anhand von SimuCom erläutert. Der Standard-Simulator der Palladio-Bench ist SimuCom und implementiert einen prozessorientierten Simulationsansatz. SimuCom generiert aus dem vom Benutzer erstellten PCM-Modell ein ablauffähiges Java-Pro-gramm, welches die modellierte Anwendung simuliert (Becker 2008, 109-200). Die Grundlage der Simulation bilden simulierte Hardwareressourcen, welche im PCM-Modell  durch  „Proces-sing  Resource  Specifications“  abgebildet  werden.  Die  Simulation  startet  für  jeden  im  „Usage  Model“  modellierten  User  einen  Thread,  der das modellierte System durchläuft. Aus dem spe-zifizierten Ressourcenbedarf der Anwendungsroutinen und der Kapazität der Hardwareressour-cen berechnet SimuCom die Antwortzeiten und die Ressourcenauslastung des modellierten Anwendungssystems. Die Ergebnisse werden in sogenannten Sensoren gespeichert und können am Ende eines Simulationslaufs vom Benutzer in der Palladio-Bench angezeigt und ausgewer-tet werden. Neben den Sensoren, welche die Antwortzeiten der im Repository modellierten

51

Ressourcen speichern, gibt es Sensoren, welche die Auslastung der Hardwareressourcen spei-chern. Abbildung 22 zeigt die konzeptionelle Erweiterung der Simulationsumgebung.

Abbildung 22: Erweiterung der Simulationsumgebung Quelle: In Anlehnung an (Brunnert/Vögele 2012)

Der Kern der Simulation bleibt unangetastet. Die Simulationsumgebung berechnet, wie oben beschrieben, den Ressourcenbedarf der einzelnen Hardwareressourcen. Die implementierte Er-weiterung von SimuCom bzw. EventSim liest nach Abschluss der Simulation die Auslastung der Hardwareressourcen aus dem entsprechenden Sensor aus. Die Erweiterung berechnet an-schließend durch Anwendung des im PCM-Modell spezifizierten Leistungsaufnahme-Modells die durchschnittliche Leistungsaufnahme und speichert das Ergebnis in einem neuen „Power  Sensor“. Unter Berücksichtigung des Simulationszeitraums können mit dem in Formel 1 dar-gestellten Zusammenhang der Energieverbrauch der Server und schließlich die Stromkosten berechnet werden. Die Erweiterung legt für die Berechnung der Stromkosten einen durch-schnittlichen Preis  von  0,15  €/kWh  zu Grunde (BDEW 2013, 42). Für die Anzeige des „Power Sensors“ in der Palladio-Bench implementiert diese Arbeit einen „Power  Sensor Report“, der die Kennzahlen der durchschnittlichen Leistungsaufnahme, der Simulationszeit, der Energie-aufnahme und der daraus resultierenden Kosten übersichtlich darstellt. Abbildung 23 zeigt links den  implementierten  „Power  Sensor“  sowie  rechts  den  daraus  generierten  „Power  Sensor Re-port“  in  der  Palladio-Bench.

Abbildung 23: Power Sensor mit Power Sensor Report Quelle: Eigene Darstellung

Erweitertes PCM-Modell

Simulation(SimuCom, EventSim)

Ressourcenbedarf

500 Watt2 Stunden1 kWh0,15 €

Ø

52

5 Transfer eines PCM-Modells zwischen zwei Hardwarearchi-tekturen

Wie in Kapitel 2 beschrieben, muss ein Ressourcen-Profil die Performance und den Ressour-cen-/Energiebedarf einer Anwendung unabhängig von einer speziellen Hardwareinfrastruktur abbilden können. Kapitel 3.6 zeigt, dass man mit PCM die Softwarearchitektur und die Hard-wareinfrastruktur in separaten Teilmodellen abbilden kann. Das  „Repository  Model“  und  das  „System   Model“   bilden die Softwarearchitektur, das   „Ressource   Environment   Model“   die Hardwarearchitektur ab. Der  Ressourcenbedarf  einzelner  im  „Repository  Model“  abgebildeten  Anwendungsroutinen kann aber nicht unabhängig von der  im  „Resource  Environment Model“  abgebildeten Hardwareressource definiert werden. Dies verdeutlicht Abbildung 24.

Abbildung 24: Abbildung des Ressourcenbedarfs mit PCM Quelle: Eigene Darstellung

Der Ressourcenbedarf wird in der Regel spezifiziert als die Zeit, die eine Operation benötigt, um von einer Hardwareressource verarbeitet werden zu können (Menascé et al. 2004, 35). Die Abbildung 24 zeigt die  „Internal  Action“ einer im  „Repository  Model“  modellierten Software-komponente. Diese weist einen CPU-Bedarf von 0,231 Arbeitseinheiten  auf.  Über  das  „Allo-­cation  Model“   wurde   dieser   Ressourcenbedarf   auf   die   im   „Resource   Environment  Model“  modellierte CPU zugeordnet. Die modellierte CPU hat eine  „Processing  Rate“  von  1000.  Das  heißt jeder modellierte CPU-Kern kann 1000 Arbeitseinheiten innerhalb eines Zeitfensters von 1 Sekunde abarbeiten. Da  eine  „Internal  Action“  immer  nur  von  einem  CPU-Kern verarbeitet werden kann, können die benötigten 0,231 Arbeitseinheiten auch als die auf der CPU benötigte Zeit von 231 Millisekunden (ms) interpretiert werden. Diese Art der Modellierung des Ressour-cenbedarfs wird auch in den in Kapitel 3.6 vorgestellten PCM-Modellgenerierungsansätzen (Brosig/Huber/Kounev 2011; Brunnert/Vögele/Krcmar 2013) angewendet.

Der Softwarehersteller muss also ein initiales PCM-Modell seiner Anwendung auf Basis einer spezifischen Hardwareinfrastruktur erstellen. Damit der Kunde, im Sinne des Ressourcen-Pro-fils, das PCM-Modell für die Analyse der Anwendung auf seiner kundenspezifischen Hard-wareumgebung nutzen kann, muss der Ressourcenbedarf der einzelnen Anwendungsroutinen auf diese Hardwareumgebung möglichst unkompliziert angepasst werden können. Kapitel 5.1 zeigt, wie der Kunde über Hardware-Benchmark-Ergebnisse  die  „Processing  Rate“  einer  Hard-­wareressource für seine Hardwareumgebung berechnen kann. Das anschließende Kapitel 5.2 zeigt, welche Voraussetzungen das initiale PCM-Modell erfüllen muss, damit der Kunde dieses

53

mit Hilfe des Verfahrens zur Skalierung der  „Processing  Rate“ auf seine Hardwareinfrastruktur anpassen kann.

5.1 Anpassung der Hardwareressourcen gemäß Benchmark-Ergebnissen Wie in Abbildung 24 dargestellt,  werden  die  Ressourcenbedarfe  relativ  zur  „Processing  Rate“  der jeweiligen Hardwareressource spezifiziert. Diese Arbeit empfiehlt aufgrund dieser Abhän-gigkeit, den Ressourcenbedarf einzelner Anwendungsroutinen durch die Skalierung der  „Pro-­cessing   Rate“   der Hardwareressourcen an die kundenspezifische Hardwareinfrastruktur anzupassen. Es wird dabei der Vorschlag von Menascé/Almeida (2002, 269-272) verfolgt, der den Ressourcenbedarf von Anwendungsroutinen durch Benchmark-Ergebnisse zwischen zwei unterschiedlich leistungsstarken Hardwareressourcen desselben Typs, z.B. zwischen einer langsamen und einer schnellen CPU, linear skaliert. Daher wird empfohlen, die  „Processing  Rate“   einer  Hardwareressource  mittels  Benchmark-Ergebnissen von einer initialen auf eine kundenspezifische Hardwareressource zu skalieren.

Um das Grundkonzept der Skalierung zu erläutern, wird im Folgenden von dem in Abbildung 25 gezeigten vereinfachten Szenario ausgegangen.

Abbildung 25: Anpassung eines PCM-Modells an kundenspezifische Hard-wareinfrastruktur (einfaches Szenario) Quelle: Eigene Darstellung

Das initiale PCM-Modell besteht aus drei Softwarekomponenten, die einen gewissen Ressour-cenbedarf bezüglich der CPU und der HDD spezifizieren. Der Softwarehersteller hat diesen Ressourcenbedarf auf Basis eines ihm zur Verfügung stehenden Hardwareservers bestimmt.

54

Deshalb  ordnet  das  „Allocation  Model“  des initialen PCM-Modells auch alle drei Komponen-ten diesem Hardwareserver zu. Die CPU und die HDD dieses  Servers  besitzen  eine  „Processing  Rate“  von  1000. Der Kunde erhält nun dieses PCM-Modell und passt dieses auf seine Hard-wareinfrastruktur an. In diesem Szenario wird davon ausgegangen, dass der Kunde die Anwen-dung auch nur  auf  einem  Hardwareserver  laufen  lassen  möchte.  Daher  muss  das  „Allocation Model“  nicht  geändert werden. Es muss  aber  die  „Processing  Rate“  der  CPU  und  HDD  ange-passt werden, um der unterschiedlichen Leistungsstärke der Hardwareressourcen des initialen und des Ziel-Servers Rechnung zu tragen.

Um die Leistungsfähigkeit zweier Hardwareressourcen vergleichen zu können, wird die An-wendung breit anerkannter Hardware-Benchmarks empfohlen. So kann z.B. die Leistungsfä-higkeit der CPU über den SPEC CPU2006 Benchmark (SPEC 2006a) analysiert werden. Die Leistungsfähigkeit einer HDD kann z.B. über die Benchmark-Suite PCMark 8 (Futuremark 2013) getestet werden. Um  die  „Processing  Rate“  einer  Hardwareressource  anzupassen, muss ein geeigneter Benchmark für die initiale und kundenspezifische Hardwareressource durchge-führt werden. Die  „Processing  Rate“  der  Ziel-Hardwareressource (𝑟 ) kann dann mittels der Benchmark-Ergebnisse der initialen Hardwareressource (𝑏 ), der kundenspezifischen Hardwareressource (𝑏 ) und  der  initialen  „Processing  Rate“ (𝑟 ) gemäß der Gleichung in Formel 5 berechnet werden.

𝑟 =  𝑏𝑏 ∗ 𝑟

Formel 5: Skalierung der Processing Rate

In dem Beispielszenario aus Abbildung 25 hat die initiale CPU einen Benchmark-Ergebnis von 50 und die kundenspezifische CPU ein Ergebnis von 40 erreicht. Durch Anwendung der Formel 5 kann  eine  „Processing  Rate“  von  800   (50  /  4  0   ∗  1000   =  800) für die kundenspezifische CPU errechnet werden. Die HDD des initialen Servers erreichte ein Benchmark-Ergebnis von 100 und die kundenspezifische HDD ein Ergebnis von  90.  Dadurch  ergibt  sich  eine  „Processing  Rate“  von  900  (90/100  *  1000  =  900).

Bei der Auswahl eines CPU-Benchmarks sollte darauf geachtet werden, dass dieser die Leis-tung eines einzelnen CPU-Kerns  misst.  Denn  die  „Processing  Rate“  gibt  die  Leistung eines einzelnen Kerns an. Der SPEC CPU2006 Benchmark erfüllt diese Eigenschaft.

Wenn auf standardisierte und weitverbreitete Benchmarks, z.B. dem SPEC CPU2006 Bench-mark zurückgegriffen wird, muss der Kunde nicht unbedingt den Benchmark auf seinem Hard-wareserver ausführen. Die Benchmark-Anbieter stellen in der Regel die Benchmark-Ergebnisse der verbreitetsten Hardwaresysteme zur Verfügung. So können z.B. ca. 5000 SPEC CPU2006 Benchmark-Ergebnisse eingesehen werden (SPEC 2006b). Dadurch kann ein PCM-Modell auch für den in Kapitel 2.4 gezeigten Anwendungsfall eingesetzt werden, wenn der Kunde eine Investitionsentscheidung für eine neue Anwendung treffen will und noch keine passende Hard-wareinfrastruktur besitzt.

55

5.2 Voraussetzungen für die Transferierbarkeit eines PCM-Modells Das Kapitel 5.1 hat an einem sehr einfachen Szenario gezeigt, wie über Benchmark-Ergebnisse ein PCM-Modell von einer initialen auf eine kundenspezifische Hardwareinfrastruktur ange-passt werden kann. Dabei bestand die initiale sowie Ziel-Hardwareinfrastruktur jeweils nur aus einem Server, auf dem alle Softwarekomponenten ausgeführt werden. Dieses Kapitel zeigt an-hand einer komplexeren initialen und kundenspezifischen Hardwareinfrastruktur, dass ein ini-tiales PCM-Modell gewisse Voraussetzungen erfüllen muss, um auf eine kundenspezifische Hardwareinfrastruktur adaptiert werden zu können. Abbildung 26 zeigt das in diesem Kapitel betrachtete Szenario.

Abbildung 26: Anpassung eines PCM-Modells an kundenspezifische Hardwarein-frastruktur (komplexes Szenario) Quelle: Eigene Darstellung

Die Softwarearchitektur besteht wieder aus drei Komponenten. Das „Allocation Model“ des initialen PCM-Modells ordnet ComponentA und ComponentB dem Server ServerI1 und Com-ponentC dem Server ServerI2 zu. Die Komponenten spezifizieren jeweils einen Ressourcenbe-darf  bezüglich  der  CPU  und  HDD  des  jeweiligen  Hardwareservers.  Die  „Processing  Rate“  aller  Hardwareressourcen ist auf 1000 fixiert. Der Kunde erhält dieses PCM-Modell und passt es auf seine Hardwareinfrastruktur an. Auch der Kunde besitzt zwei Server, die über ein Netzwerk miteinander verbunden sind. Die Zuordnung der Komponenten auf die Server soll aber geändert werden. Dazu  passt  er  das  „Allocation  Model“  an  und  ordnet  ComponentA und ComponentC dem Server ServerT1 und ComponentB dem Server ServerT2 zu. Die  „Processing  Rate“  der  Hardwareressourcen passt er gemäß der Benchmark-Ergebnisse, wie in Kapitel 5.1 gezeigt, an. Diese freie Platzierung der Softwarekomponenten durch den Kunden ist aber nur möglich, wenn die Server im initialen PCM-Modell die gleichen sind. Wenn im initialen Modell der Ressourcenbedarf von ComponentC auf Basis einer anderen CPU als der Ressourcenbedarf von ComponentA modelliert wurde, ist es im kundenspezifischen Modell nicht möglich, den Res-sourcenbedarf beider  Komponenten  durch  Anpassung  der  „Speed  Ratio“  zu  skalieren.

56

Wenn das PCM-Modell auch zur Untersuchung der Netzwerkverbindung dienen soll, muss im initialen PCM-Modell der Bedarf an der Netzwerkressource für jeden Aufruf zwischen jegli-chen Komponenten modelliert sein. D.h., im initialen PCM-Modell aus Abbildung 26 muss auch der Bedarf an der Netzwerkressource bei Aufrufen zwischen ComponentA und Compo-nentB spezifiziert sein, obwohl diese Komponenten im initialen Modell auf dem gleichen Hard-wareserver ausgeführt werden. Nur dann ist es möglich, dass der Kunde die Allokation der Komponenten auf die Server ändern kann.

Ein initiales PCM-Modell muss also zwei Voraussetzungen erfüllen. Der Softwarehersteller muss bei der initialen Erstellung eines PCM-Modells darauf achten, dass beim Einsatz mehrerer Hardwareserver in allen die gleichen Hardwareressourcen verbaut sind. Wenn zusätzlich die Netzwerkverbindung durch das PCM-Modell analysiert werden soll, muss der Netzwerkbedarf bei allen Aufrufen zwischen den Softwarekomponenten modelliert werden.

57

6 Das Palladio Component Model als Ressourcen-Profil

Wie in Kapitel 2.2 beschrieben, soll ein Ressourcen-Profil ein austauschbares Modell zwischen einem Softwarehersteller und einem Kunden sein, um die Performance und den Ressourcen- und Energiebedarf einer Unternehmensanwendung im kundenspezifischen Umfeld analysieren zu können. Kapitel 3.6 hat gezeigt, dass sich PCM durch seine Modularität grundsätzlich als Basistechnologie eines solchen Ressourcen-Profils eignet. Da PCM nicht in der Lage ist den Energiebedarf einer Unternehmensanwendung abzubilden, wurde in Kapitel 4 das PCM-Meta-modell um diese Funktionalität erweitert. Kapitel 5 zeigt, wie ein PCM-Modell auf verschie-dene Hardwareinfrastrukturen angepasst werden kann. Dieses Kapitel gibt einen Überblick über den gesamten Prozess zwischen Softwarehersteller und Kunden bei der Erstellung eines Res-sourcen-Profils auf Basis eines PCM-Modells. Der Softwarehersteller erstellt ein initiales PCM-Modell seiner Unternehmensanwendung und übergibt dieses an den Kunden. Der Kunde kann dieses PCM-Modell dann an seine kundenspezifische Umgebung anpassen und zur Ana-lyse der Unternehmensanwendung verwenden. Abbildung 27 zeigt eine schematische Darstel-lung dieses Prozesses, welcher im Folgenden näher erläutert wird.

Allocation Model

Resource Environment Model

System Model

Usage Model

Repository Model

Benchmark-Ergebnisse

Softwarehersteller

Allocation Model

Resource Environment Model mit Power Consumption Model

System Model

Repository Model

Benchmark-Ergebnisse

Adaption

Adaption

Übernahme

Übernahme

Kunde

Abbildung 27: PCM als Ressourcen-Profil Quelle: Eigene Darstellung

58

Kapitel 3.6 zeigt die verschiedenen Teilmodelle des PCM-Metamodells.  Das  „Repository  Mo-­del“  und  das  „System  Model“  bilden  die  Softwarekomponenten  und  deren  Zusammenspiel,  also  die Softwarearchitektur eines  Anwendungssystems,  ab.  Die  „RDSEFFs“  des  „Repository  Mo-­dels“  bilden  die  Ressourcenbedarfe  der  einzelnen  Operationen  einer  Softwarekomponente  ab.  Diese Arbeit gibt keine detaillierte Anleitung, wie ein Softwarehersteller diese Modelle anzu-fertigen hat. In der Literatur finden sich mehrere Ansätze für die Erstellung dieser beiden Teil-modelle. So gibt es einerseits die in Kapitel 3.6 gezeigten Verfahren, ein PCM-Modell einer Anwendung automatisch zu generieren (Brosig/Huber/Kounev 2011; Brunnert/Vögele/Krcmar 2013). Andererseits kann ein PCM-Modell auch auf Basis von Software-Design-Modellen, z.B. UML-Aktivitätsdiagrammen, erstellt werden (Brunnert et al. 2013). Welche Auswertungsmög-lichkeiten später auf Basis eines PCM-Modells möglich sind, hängt vom Detailgrad der Model-lierung ab. Die Auslastung einer Hardwareressource kann nur evaluiert werden, wenn diese in den RDSEFFs abgebildet ist. Wenn im Ressourcen-Profil die Netzwerkverbindung zwischen mehreren Servern berücksichtigt werden soll, muss der Softwarehersteller darauf achten, dass er  im  „Repository  Model“  für  jeden  Aufruf  zwischen  zwei  Softwarekomponenten  den  Bedarf  an der Netzwerkressource modelliert (siehe Kapitel 5.2). Der  Kunde  kann  das  „Repository  Mo-­del“  und  das  „System  Model“  ohne  Veränderungen  übernehmen.

Das  „Resource  Environment  Model“  bildet  die  Hardwarearchitektur  eines  Anwendungssystems  ab. Wie in Kapitel 5 erläutert, wird der Ressourcenbedarf einzelner Anwendungsroutinen im „Repository  Model“  in  Abhängigkeit  zu  den  Hardwareressourcen  im  „Resource  Environment Model“  spezifiziert.  Die Zuordnung der Softwarekomponenten zu den Hardwareservern erfolgt über  das  „Allocation  Model“.  Der Softwarehersteller muss also im initialen PCM-Modell die Hardwareinfrastruktur modellieren, auf deren Basis er die Ressourcenbedarfe der Anwen-dungsroutinen erhoben hat. Basiert das initiale PCM-Modell auf mehreren Hardwareservern, muss der Softwarehersteller sicherstellen, dass die Hardwareserver identisch sind oder zumin-dest identische Hardwareressourcen besitzen. Ansonsten ist, wie in Kapitel 5.2 beschrieben, eine Anpassung des PCM-Modells auf eine kundenspezifische Hardwareinfrastruktur nicht ohne Probleme möglich.

Für  die  im  „Resource  Environment  Model“  modellierten  Hardwareressourcen  muss  der  Soft-­warehersteller Hardware-Benchmarks durchführen. Bei der Auswahl des Benchmarks sollte der Softwarehersteller darauf achten, dass dieser allgemein anerkannt ist und idealerweise schon viele Benchmark-Ergebnisse für die herkömmlichsten Produkte eines Hardwareressourcentyps veröffentlicht sind. Der Softwarehersteller übergibt dem Kunden die Benchmark-Ergebnisse, das  „Resource  Environment  Model“  und  das  „Allocation  Model“.  Der Kunde muss auf seiner Hardwareinfrastruktur die gleichen Hardware-Benchmarks wie der Softwarehersteller durch-führen. Durch den Vergleich der Benchmark-Ergebnisse der initialen und der kundenspezifi-schen Hardware kann der Kunde, wie in Kapitel 5.1 gezeigt, die Leistung der Hardware-ressourcen   im   „Resource   Environment  Model“   anpassen.   Kann   der   Kunde   den   Hardware-Benchmark nicht anwenden, kann er stattdessen auf schon veröffentlichte Benchmark-Ergeb-nisse der betrachteten Hardware zurückgreifen.

Zur Analyse des Energiebedarfs der Unternehmensanwendung auf der kundenspezifischen Hardware muss der Kunde das  „Resource  Environment  Model“  um  eine  oder  mehrere  „Power  

59

Consumption  Models“  erweitern. Wie in Kapitel 4 gezeigt, muss der Kunde für jeden model-lierten Hardwareserver ein Leistungsaufnahme-Modell durch eine Kalibrierungsphase generie-ren und  dem  „Resource  Environment  Model“  hinzufügen.

Für ein komplettes PCM-Modell  fehlt  dem  Kunden  noch  das  „Usage  Model“.  Das  „Usage  Mo-­del“  bildet  die  Anzahl  der  Benutzer  und  deren  Benutzerverhalten  ab.  Bei der Modellierung des Benutzerverhaltens kann der Kunde nur auf die Anwendungsroutinen zurückgreifen, die der Softwarehersteller  im  „System  Model“  für  den  direkten Zugriff durch die Benutzer berücksich-tigt hat. Die Modellierung eines Benutzerverhaltens für ein Anwendungssystem, welches noch nicht beim Kunden im Einsatz ist, ist nicht trivial. Das Benutzerverhalten kann z.B. durch Ex-perteninterviews abgeschätzt werden (Brunnert et al. 2013, 34). Auf eine genauere Betrachtung der Thematik der Abschätzung des Nutzerverhaltens wird im Rahmen dieser Arbeit verzichtet.

Wenn alle Schritte des geschilderten Prozesses durchgeführt sind, erhält der Kunde ein kom-plett spezifiziertes PCM-Modell, welches auf seine kundenspezifische Umgebung angepasst ist. Mit Hilfe des PCM-Modells kann der Kunde nun die Performance und den Ressourcen- und Energiebedarf der Unternehmensanwendung auf seiner Hardwareinfrastruktur und unter Be-rücksichtigung seines Benutzerverhaltens analysieren.

60

7 Evaluation

Das Kapitel 6 zeigt, wie ein Ressourcen-Profil auf Basis von PCM realisiert werden kann. Dazu ist PCM in Kapitel 4 um die Fähigkeit zur Abbildung des Energiebedarfs eines Anwendungs-systems erweitert worden. Kapitel 5 zeigt die Transformation eines PCM-Modells zwischen zwei Hardwarearchitekturen. Dieses Kapitel evaluiert den in Kapitel 6 entwickelten Ansatz an-hand der Benchmark-Anwendung SPECjEnterprise20101 (SPEC 2010a). Dazu stellt Kapitel 7.1 zunächst den SPECjEnterprise2010-Benchmark vor. Kapitel 7.2 erläutert die Hardwareinf-rastruktur, auf der SPECjEnterprise2010 aufgesetzt wird und geht auf die Konfiguration der beteiligten Anwendungen ein. In Kapitel 7.3 wird ein PCM-Modell dieser Benchmark-Anwen-dung auf einem initialen Hardwareserver erzeugt und anschließend für einen finalen Hardware-server angepasst. In Kapitel 7.4 wird für beide PCM-Modelle ein Leistungsaufnahme-Modell generiert und den PCM-Modellen hinzugefügt. Kapitel 7.5 vergleicht die Simulationsergeb-nisse der Modelle unter variierender Benutzerlast mit realen Messergebnissen.

7.1 SPECjEnterprise2010-Benchmark SPECjEnterprise2010 ist ein Java EE-Benchmark zur Messung der Performance von Java EE-basierten Anwendungssystemen im betrieblichen Kontext (SPEC 2010b). Der Benchmark spe-zifiziert dazu eine Java EE-Anwendung, einen Benchmark-Driver und einen Emulator, die die Last auf dem Anwendungssystem generieren und einen Datensatz bereitstellen, der für einen Benchmark-Lauf notwendig ist (Brunnert/Vögele/Krcmar 2013, 81). Kapitel 7.1.1 zeigt zu-nächst die Gesamtarchitektur des SPECjEnterprise2010-Benchmarks. Der Benchmark besteht aus mehreren Teilanwendungen. Kapitel 7.1.2 geht detailliert auf die Teilanwendung  der  „Or-­ders  Domain“ ein, für die in dieser Evaluation ein Ressourcen-Profil erstellt wird. Kapitel 7.1.3 zeigt den Benchmark-Driver von SPECjEnterprise2010, der während eines Benchmark-Laufs die Benutzer simuliert, die  mit  der  „Orders  Domain“ interagieren und somit die Last auf dem Anwendungssystem erzeugen.

7.1.1 Benchmark-Architektur

Die Anwendung implementiert einen Geschäftsprozess, der sich über die gesamte Wertschöp-fungskette eines Automobilherstellers erstreckt. Die Abbildung 28 zeigt die grobe Architektur der Anwendung.

1 SPECjEnterprise ist ein Markenzeichen der Standard Performance Evaluation Corp. (SPEC). Die SPECjEnter-prise2010-Ergebnisse oder -Erkenntnisse in dieser Arbeit wurden nicht von SPEC überprüft oder akzeptiert. Daher können die Ergebnisse aus dieser Arbeit nicht mit den offiziell veröffentlichten SPEC-Ergebnissen verglichen werden. Die offizielle Webseite für SPECjEnterprise2010 ist unter folgender Adresse verfügbar: http://www.spec.org/jEnterprise2010.

61

Abbildung 28: SPECjEnterprise2010 – Anwendungsarchitektur Quelle: In Anlehnung an (SPEC 2010b)

Die Anwendung wurde auf Basis der Java EE 5-Spezifikation (Shannon 2006) implementiert und läuft daher innerhalb eines Java EE Application Servers, welcher diese Spezifikation um-setzt. Die Anwendung besteht aus den drei Teilanwendungen:  „Orders  Domain“,  „Manufac-­turing  Domain“  und  „Supplier  Domain“.  Automobilhändler  können  in  der  „Orders  Domain“  Automobile  kaufen  und  verkaufen.  Die  „Orders  Domain“  implementiert  dazu  eine  Webanwen-­dung, auf der die Automobilhändler über einen Browser, also über das Hypertext Transfer Pro-tocol (HTTP), zugreifen können. Der Benchmark implementiert einen Benchmark-Driver, der die Automobilhändler in einem Benchmark-Lauf simuliert. Durch das Kaufen und Verkaufen in  der  „Orders  Domain“  wird  eine  Nachfrage  an  Automobilen  in  der  „Manufacturing  Domain“  erzeugt.  Die  „Manufacturing  Domain“  simuliert  die  Herstellung  der  Automobile  an  mehreren  Produktionsorten. Die einzelnen Produktionsorte kommunizieren über Web Services und EJB-Calls  mit  der  „Manufacturing  Domain“.  Der Benchmark-Driver simuliert in einem Benchmark-Lauf  die  verschiedenen  Produktionsstandorte  und  deren  Kommunikation  mit  der  „Manufac-­turing  Domain“.  Für  die  Produktion  der  Automobile  in  der  „Manufacturing  Domain“  werden  Teile  benötigt,  die  von  der  „Supplier  Domain“  bereitgestellt  werden.  Dazu  emuliert  der Bench-mark  Zulieferer,  welche  die  Teile  an  die  „Supplier  Domain“  liefern. Die Zulieferer kommuni-zieren  über  Web  Services  mit  der  „Supplier  Domain“. Die drei gezeigten Teilanwendungen des Benchmarks kommunizieren untereinander über die Java Message Service-Schnittstelle (JMS) und greifen auf eine gemeinsame relationale Datenbank mittels der Java Database Connectivity (JDBC) Datenbankschnittstelle zu.

7.1.2 Orders Domain

Für die Evaluation des Konzepts eines Ressourcen-Profils auf Basis von PCM konzentriert sich diese  Arbeit  auf  die  Teilanwendung  der  „Orders  Domain“ und dessen Benchmark-Driver. Denn die   „Orders  Domain“   ist   die   einzige  Teilanwendung, die von realen Endanwendern benutzt

Benchmark-Driver

HTTP

Browse,Manage,Purchase

System Under Test (SUT)

Java EE Application Server

EJB / Web Services

Emulator

SuppliersWeb Services

SupplierDomain

JMSLarge Orders

JMS Fulfilled Orders

Create, Process,Complete

Web Services

Purchase Order

Delivery

Database

Dealerships

Manufacturing Sites

Orders Domain

Manufacturing Domain

JMSRequisition

JMS Delivery

JDBC

62

wird. Sie entspricht damit dem in Kapitel 2.1 vorgestellten Typ von Unternehmensanwendung, der in dieser Arbeit betrachtet wird. Um  die  Teilanwendung  der  „Orders  Domain“  separat  zu  betrachten, wird  die  Kommunikation  der  „Orders  Domain“  mit  den  anderen  beiden  Teilanwen-­dungen deaktiviert. Abbildung 29 zeigt  die  „Orders  Domain“  im  größeren  Detail.

Abbildung 29: SPECjEnterprise 2010 – Orders Domain Quelle: (Brunnert/Vögele/Krcmar 2013, 10)

Technisch  ist  die  „Orders  Domain“  umgesetzt auf Basis von Java Servlets, JavaServer Pages (JSP), Enterprise Java Beans (EJB) und Entitätsklassen gemäß der Java Persistence API (JPA). Die Anwendung implementiert ein Servlet, das alle HTTP-Anfragen der Automobilhändler ini-tial entgegennimmt. Das Servlet leitet die Anfragen an die EJBs weiter, welche die Geschäfts-logik zur Verarbeitung der jeweiligen Anfrage implementieren. Die EJBs kommunizieren mit der Datenbank über die JPA-Entitäten, welche das Datenbankschema abbilden. Ist eine Anfrage durch die Geschäftslogik verarbeitet, leitet das Servlet die Anfrage zu einer JSP weiter, welche die Benutzeransicht in Form einer Webseite generiert, die an den Benutzer ausgeliefert wird.

7.1.3 Benchmark-Driver

Der SPECjEnterprise2010-Benchmark implementiert einen Benchmark-Driver, der die Durch-führung eines Benchmark-Laufs steuert. Da sich diese  Arbeit  auf  die  „Orders  Domain“  kon-­zentriert, wird im Folgenden auch nur auf diesen Teil des Benchmark-Drivers eingegangen. Technisch setzt der Benchmark-Driver auf Faban (Faban 2013), einem Performance- und Last-test-Tool, auf. Der Benchmark-Driver läuft als eigenstände Java-Anwendung auf einem von der  „Orders  Domain“  getrennten Server. Während eines Benchmark-Laufs simuliert der Bench-mark-Driver  die  Automobilhändler,  welche  die  „Orders  Domain“  benutzen.  Dazu  kann  im  Dri-­ver die Anzahl der Benutzer festgelegt werden, die der Driver simulieren soll. Für jeden Benutzer erstellt der Benchmark-Driver einen eigenständigen Thread, der mit der Anwendung interagiert. Der Benchmark-Driver definiert dafür drei verschiedene Geschäftstransaktionen, die ein Benutzer ausführen kann. Die drei Transaktionen  sind  „Browse“,  „Manage“  und  „Purch-ase“.  Die  „Browse“-Transaktion spiegelt das Durchsuchen des Katalogs an verfügbaren Auto-mobilen des Automobilherstellers wieder. Die   „Purchase“-Transaktion definiert den Kauf-prozess von Automobilen durch den Benutzer.  Die  „Manage“-Transaktion bildet den Verkauf von Automobilen oder den Abbruch von Aufträgen ab. Jede dieser drei Geschäftstransaktionen

System Under Test (SUT)

Java Application Server

Database

Benchmark-Driver

Dealerships Orders Domain

Orders Domain

Java Server Pages (JSP)

JPA Entities

StatelessEJBsHTTP

JDBC

JDBC

HTTP

1. 2. 3.

4.

Servlet

63

besteht aus mehreren untergeordneten HTTP-Anfragen, welche die simulierten Automobil-händler in einem Benchmark-Lauf  an  die  „Orders  Domain“  schicken.  Der Benchmark definiert die Wahrscheinlichkeiten, mit der ein Benutzer eine Geschäftstransaktion ausführt. Ein simu-lierter Benutzer führt zu 50 %  die  „Browse“-Transaktion und zu jeweils 25 %  die  „Manage“- und  „Purchase“-Transaktion aus.

7.2 Versuchsumgebung Das Kapitel 7.1 zeigt die Architektur des SPECjEnterprise2010-Benchmarks. Im Speziellen wurde  die  Teilanwendung  der  „Orders  Domain“  gezeigt,  für  die  in  dieser  Evaluation  ein  Res-sourcen-Profil auf einem initialen Server erstellt und für einen Ziel-Server angepasst wird. Um die Prognosefähigkeit des Ressourcen-Profils zu evaluieren, werden die Simulationsergebnisse der PCM-Modelle für die Anwendung auf dem jeweiligen Hardwareserver mit den realen Mes-sergebnissen verglichen. Dieses Kapitel gibt einen Überblick über die für diese Evaluation auf-gesetzte Versuchsumgebung. Dazu zeigt Abbildung 30 eine schematische Darstellung des Versuchsaufbaus.

Abbildung 30: Versuchsumgebung Quelle: Eigene Darstellung

IBM System X3755M3

IBM System X3755M3

Virtueller Server (VM Ware ESXi 5.0.0)

openSuse 12.3

Benchmark-Driver

openSuse 12.2

AS

AS

AS

DB

DB

DB

AS

AS

AS

DB

DB

DB

LoadBalancer

IBM System X3550M3

openSuse 12.3

AS

AS

AS

DB

DB

DB

AS

AS

AS

DB

DB

DB

Load-Driver Server

Initialer Server

Ziel Server

64

Die in Kapitel 7.1.2 vorgestellte „Orders  Domain“  wird auf zwei dezidierten Hardwareservern aufgesetzt. Die Konfiguration des initialen AMD-basierten Servers zeigt Tabelle 4. Die Konfi-gurationsdetails des Intel-basierten Ziel-Servers zeigt Tabelle 5. In dem initialen Server sind vier AMD Opteron 6172 Prozessoren mit jeweils 12 Kernen und einer Geschwindigkeit von 2.1 Gigahertz (GHz) verbaut. Um zu große Leistungs-Unterschiede der CPUs zwischen dem initialen Server und dem Ziel-Server zu vermeiden, wurde beim initialen Server die Anzahl der Kerne pro CPU-Socket auf vier reduziert. Somit besitzt der AMD-basierte Server insgesamt 16 CPU-Kerne. Der Ziel-Server besitzt zwei Intel Xeon E5645 Prozessoren mit jeweils 6 Kernen und einer Geschwindigkeit von 2.4 GHz. Die Hyper-Threading Technologie der Intel CPUs wurde für diese Evaluation deaktiviert. Auf beiden Servern läuft das openSuse Betriebssystem mit 64 Bit. Auf dem initialen Server ist die openSuse 12.2 und auf dem Ziel-Server open-Suse 12.3 installiert. Die Java EE-Anwendung  der  „Orders  Domain“ wird auf beiden Servern innerhalb eines JBoss Application Server (AS) 7.1.1 ausgeführt. Für die relationale Datenbank (DB) wird die dateibasierte Datenbank Apache Derby DB in Version 19.9.1.0 verwendet. So-wohl der Application Server als auch die Datenbank werden innerhalb der gleichen Java Virtual Machine (JVM) ausgeführt. Um die beiden Hardwareserver während eines Benchmark-Laufs voll  auslasten  zu  können  ist  die  „Orders  Domain“  in  einem  vertikalen  Cluster  aufgesetzt. Bei einem vertikalen Cluster werden mehrere Application Server Instanzen auf einem Server be-trieben. In dieser Versuchsumgebung besteht das Cluster auf beiden Servern aus 6 Application Server Instanzen. Die Instanzen greifen nicht auf eine gemeinsame Datenbank zu, sondern jede Instanz interagiert mit einer eigenständigen Datenbank.

Hardware Modell IBM System X3755M3 Prozessor 4x AMD Opteron 6172

48 Kerne, 16 aktive Kerne 2.1 GHz

Arbeitsspeicher 256 GB

Software Betriebssystem openSuse 12.2, 64 Bit JVM OpenJDK Server VM 1.7.0 Application Server 6x JBoss 7.1.1 Datenbank 6x Apache Derby DB 10.9.1.0

Tabelle 4: Initialer AMD-basierter Hardwareserver Quelle: Eigene Tabelle

65

Hardware Modell IBM System X3550M3 Prozessor 2x Intel Xeon E5645

12 Kerne 2.4 GHz

Arbeitsspeicher 96 GB

Software Betriebssystem openSuse 12.3, 64 Bit JVM OpenJDK Server VM 1.7.0 Application Server 6x JBoss 7.1.1 Datenbank 6x Apache Derby DB 10.9.1.0

Tabelle 5: Intel-basierter Ziel-Hardwareserver Quelle: Eigene Tabelle

Der SPECjEnterprise2010-Benchmark definiert ursprünglich eine bestimmte Datenmenge in der Datenbank in Abhängigkeit von der simulierten Benutzeranzahl eines Benchmark-Laufs. Je mehr Benutzer in einem Lauf simuliert werden, umso größer ist der Datenbestand in der einzelnen Datenbank. Der Benchmark-Driver ändert aber auch das Verhalten eines einzelnen Benutzers in Abhängigkeit zur Größe der Datenbank. So greift z.B. der einzelne Benutzer in einer Transaktion (siehe Kapitel 7.1.3) bei einer größeren Datenbank auf mehr Automobile zu, als bei einer kleineren Datenbank. Diese Verhaltensänderung des einzelnen Benutzers in Ab-hängigkeit der Datenbankgröße ist untypisch für eine Unternehmensanwendung. Der Bench-mark-Driver wurde deshalb im Rahmen dieser Arbeit angepasst. Der geänderte Benchmark-Driver simuliert eine beliebige Anzahl an Benutzern, deren  Anfragen  von  der  „Orders  Domain“  auf Basis einer Datenbank, die ursprünglich für 2400 Benutzer ausgelegt war, verarbeitet wer-den können. Das Verhalten des einzelnen Benutzers ändert sich dadurch nicht mehr in Abhän-gigkeit zur Datenmenge in der Datenbank.

Der Benchmark-Driver (Faban 1.0.1) und ein Load Balancer (mod_cluster 1.2.0.Final) sind auf einem separaten Load-Driver Server installiert. Die Benutzeranfragen des Benchmark-Drivers werden über den Load Balancer gleichmäßig auf die Application Server Instanzen des jeweilig untersuchten Servers verteilt. Die  Antworten  der  „Orders  Domain“ in Form von generierten HTML-Seiten (HyperText Markup Language) werden wieder über den Load Balancer an die Benutzer ausgeliefert. Der Load Balancer ist so konfiguriert, dass alle Anfragen eines einzelnen Benutzers während eines Simulationslaufs immer an die gleiche Application Server Instanz weitergeleitet werden. Somit werden Dateninkonsistenzen in der Datenbank vermieden.

Tabelle 6 fasst die Konfiguration des Load-Driver Servers zusammen. Der Load-Driver Server ist ein auf Basis des Hypervisors VMWare ESXi 5.0.0 (build 469512) virtualisierter Server. Er ist auf einem physikalischen Server baugleich dem initialen Server (IBM System X3755M3, siehe Tabelle 4) virtualisiert. Der Load-Driver Server besitzt 8 virtuelle CPU-Kerne und 80 GB Arbeitsspeicher. Als Betriebssystem ist ein openSuse 12.3 installiert.

66

Hardware Modell Virtueller Server Prozessor 8 virtuelle Kerne Arbeitsspeicher 80 GB Hypervisor VMWare ESXi 5.0.0 (build 469512) Physikalischer Server IBM System X3755M3 (siehe Tabelle 4)

Software Betriebssystem openSuse 12.3, 64 Bit JVM OpenJDK Server VM 1.7.0 Benchmark-Driver Faban 1.0.1 Load Balancer mod_cluster 1.2.0.Final

Tabelle 6: Load-Driver Server Quelle: Eigene Tabelle

Alle drei vorgestellten Server in der Versuchsumgebung sind über eine Gigabit-Ethernet-Ver-bindung miteinander verbunden.

7.3 Erzeugung und Anpassung des Ressourcen-Profils Dieses Kapitel zeigt die Erstellung des PCM-Modells der Benchmark-Anwendung auf dem ini-tialen Hardwareserver und die Anpassung des Modells auf den Ziel-Hardwareserver. Für die Erstellung des initialen PCM-Modells greift diese Arbeit auf das in der Arbeit von Brunnert/ Vögele/Krcmar (2013) entwickelte automatische Modellgenerierungsverfahren zurück. Wie schon in Kapitel 3.6 dargestellt, zeichnet der entwickelte Ansatz das Verhalten einer Anwen-dung inklusive dessen Ressourcenbedarfs während des Betriebs der Anwendung auf und gene-riert daraus ein PCM-Modell. Auf die Einzelheiten der Funktionsweise dieses Modell-generierungsverfahrens geht diese Arbeit im Folgenden nicht weiter ein. Für nähere Details wird auf Kapitel 3.6 und die Arbeit von Brunnert/Vögele/Krcmar (2013) verwiesen.

Für die Generierung des initialen PCM-Modells wird der Modellgenerator so konfiguriert, dass dieser nur den CPU-Bedarf der Anwendung aufzeichnet und im Modell abbildet. Für die Mo-dellgenerierung wird der Benchmark-Driver so eingestellt, dass dieser 2400 Benutzer und damit eine moderate Last auf dem initialen Server mit ca. 50 % CPU-Auslastung erzeugt. Während eines Zeitraums von 20 Minuten unter dieser Benutzerlast sammelt der Modellgenerator die notwendigen Daten, um daraus ein PCM-Modell für den initialen AMD-basierten Server zu generieren. Abbildung 31 zeigt einen Ausschnitt aus dem „Resource  Environment  Model“  des  generierten PCM-Modells.

67

Abbildung 31: Generiertes Resource Environment Model Quelle: Eigene Darstellung

Kapitel 7.1.1 beschreibt die  grobe  Architektur  der  „Orders  Domain“.  Diese  Architektur  spiegelt  sich  in  dem  generierten  „Resource  Environment  Model“  wieder.  Die  Komponente  _app ist das zentrale Java Servlet, welches die Benutzeranfragen entgegennimmt und an die EJBs, z.B. die OrderSession, weiterleitet. Die Generierung der HTML-Seiten ist im Modell in den JSP-Komponenten, z.B. der _purchase_jsp, abgebildet.

Die verschiedenen Operationen der Komponenten spezifizieren alle einen Bedarf an der CPU des initialen Servers. Abbildung 32 zeigt  das  „Resource  Environment  Model“  des  generierten  PCM-Modells.

Abbildung 32: Initiales Resource Environment Model Quelle: Eigene Darstellung

68

Das  „Resource  Environment  Model“  zeigt  den  initialen  Server  mit  seiner CPU. Die Anzahl der CPU-Kerne muss manuell spezifiziert werden, da der Modellgenerator diese nicht automatisch ermitteln kann. Der CPU-Bedarf der einzelnen Operationen ist in Millisekunden in den RDS-EFFs festgelegt. Somit hat die CPU, wie in Kapitel 5 erläutert, eine  „Processing  Rate“  von  1000. Das gezeigte PCM-Modell erfüllt die in Kapitel 5.2 gezeigten Voraussetzungen eines initialen PCM-Modells. Denn das Modell wurde auf Basis eines einzelnen Servers erstellt und modelliert nur eine CPU und keine Netzwerkverbindung. Um dieses initiale PCM-Modell für den Ziel-Server  anzupassen,  wird  die  „Processing  Rate“  im Folgenden mittels Benchmark-Er-gebnissen, wie in Kapitel 5.1 gezeigt, angepasst.

Um die CPUs der beiden Server miteinander zu vergleichen, wird der SPEC CPU20062 (SPEC 2006a) Benchmark gewählt. SPEC CPU2006 ist kein synthetischer Benchmark, sondern baut auf repräsentativen Unternehmensanwendungen auf (Henning 2006). Der Benchmark eignet sich daher, die Leistungsfähigkeit einer CPU im Kontext von Unternehmensanwendungen zu ermitteln. Der SPEC CPU2006 Benchmark besteht aus dem Integer Benchmark CINT2006 und einem Floating Point Benchmark CFP2006. Für den Vergleich der beiden CPUs wird der CINT2006 Benchmark verwendet. Der CINT2006 Benchmark besteht wiederum aus 12 Einzel-Benchmarks, die am Ende eines Benchmark-Laufs zu einem Gesamtergebnis konsolidiert wer-den. Für detailliertere Informationen zu den Einzel-Benchmarks wird auf die Arbeit von Hen-ning (2006) verwiesen. Der SPEC CPU2006 Benchmark misst die Zeit, welche die CPU für die Ausführung eines Einzel-Benchmarks benötigt und setzt diese Zeitspanne in Relation zu einem Referenzsystem. Das Verhältnis zwischen der Referenzzeit und der gemessenen Zeit ist das Benchmark-Ergebnis eines Einzel-Benchmarks. Für das konsolidierte Benchmark-Ergebnis wird das geometrische Mittel aus allen Einzel-Benchmark-Ergebnissen gebildet. Der SPEC CPU2006 Benchmark besitzt zwei Modi um die Leistung einer CPU zu messen. Der SPEC-speed-Modus misst die Leistung eines einzelnen CPU-Kerns, d.h. alle Einzel-Benchmarks wer-den nur auf einem CPU-Kern ausgeführt. Der SPECspeed-Modus misst also die Geschwindig-keit einer CPU für die Bewältigung einer einzelnen Aufgabe. Beim SPECrate-Modus führt der Benchmark jeweils auf jedem Kern der CPU die Einzel-Benchmarks aus und misst somit den Durchsatz der untersuchten CPU. Wie in Kapitel 5.1 erwähnt,  ist  für  die  „Processing  Rate“  im  „Resource  Environment  Model“  die  Leistung  eines  einzelnen  Prozessorkerns relevant und so-mit auch das Benchmark-Ergebnis aus dem SPECspeed-Modus.

Da die CPU auf dem AMD-basierten Server auf 16 Kerne reduziert wurde und die Hyperthrea-ding Funktionalität auf dem Intel-basierten Server ausgeschaltet wurde (siehe Kapitel 7.2), kann nicht auf die bereits auf der Homepage veröffentlichten Benchmark-Ergebnisse für die beiden Server zurückgegriffen werden. Der SPEC CPU2006 Benchmark muss im Rahmen dieser Ar-beit selbst auf den beiden Servern ausgeführt werden. Die detaillierten Ergebnisse des SPEC CPU2006-Benchmarks auf dem initialen AMD-basierten Server und dem Intel-basierten Ziel- 2 Die SPEC CPU2006-Ergebnisse oder -Erkenntnisse in dieser Arbeit wurden nicht von SPEC überprüft oder akzeptiert. Daher können die Ergebnisse dieser Arbeit nicht mit den offiziell veröffentlichten SPEC-Ergebnissen verglichen werden. Die SPEC CPU2006-Ergebnisse in dieser Arbeit sollten daher als Schätzwerte betrachtet wer-den, da die Benchmark-Durchführung möglicherweise von den offiziellen Ausführungsregeln abweicht. Die offi-zielle Webseite für SPEC CPU2006 ist unter folgender Adresse verfügbar: http://www.spec.org/cpu2006/.

69

Server sind in den Anhängen 1 und 2 aufgeführt. Der initiale Server erzielt einen CINT2006 Benchmark-Wert von 12,91. Der Intel-basierte Server erreicht einen Benchmark-Wert von 18,92. Unter Anwendung der Gleichung aus Formel 5 ergibt sich eine „Processing Rate“ von 1464 für die CPU des Intel-basierten Servers.

Damit  kann  das  „Resource  Environment  Model“  aus  Abbildung 32 für den Intel-basierten Ser-ver angepasst werden. Dazu  wird  die  „Processing  Rate“  gemäß  der  obigen  Berechnung  spezi-­fiziert und die Anzahl der Kerne auf 12 angepasst. Das  „Allocation  Model“  des  initialen  PCM-Modells wird nicht geändert, da auch in der Zielumgebung alle Komponenten nur auf einem Server ausgeführt werden. Abbildung 33 zeigt  das  angepasste  „Resource  Environment  Model“  für den Ziel-Server.

Abbildung 33: Angepasstes Resource Environment Model Quelle: Eigene Darstellung

7.4 Erstellung der Leistungsaufnahme-Modelle Kapitel 4 hat das Konzept des Leistungsaufnahme-Modells und dessen Integration in das PCM-Metamodell gezeigt. Zur Evaluation der Prognosefähigkeit des Energieverbrauchs eines An-wendungssystems auf Basis eines solchen Leistungsaufnahme-Modells werden in diesem Ka-pitel sowohl das initiale PCM-Modell als auch das auf den Intel-basierten Server angepasste PCM-Modell um ein Leistungsaufnahme-Modell erweitert.

Da in beiden PCM-Modellen nur die CPU des jeweiligen Hardwareservers abgebildet ist (siehe Kapitel 7.3), stehen am Ende einer Simulation auch nur die Ergebnisse über die Auslastung der CPU zur Verfügung. Daher kann die Leistungsaufnahme des Servers in beiden PCM-Modellen auch nur in Abhängigkeit zur CPU-Auslastung vorhergesagt werden. Deshalb werden im Fol-genden zwei Leistungsaufnahme-Modelle erstellt, welche die Leistungsaufnahme der beiden Server in Abhängigkeit zu deren CPU-Auslastung abbilden. Diese Einschränkung ist akzepta-bel, da laut Capra et al. (2010) die CPU für den Großteil der Gesamtleistungsaufnahme eines Servers verantwortlich ist. Capra et al. (2010) zeigen auch, dass die CPU die einzige Hardwa-reressource ist, deren Leistungsaufnahme signifikant abhängig von dessen Auslastung ist. Alle anderen Hardwareressourcen haben unabhängig von ihrer Auslastung nahezu einen konstanten Bedarf an elektrischer Energie.

Kapitel 4.2 zeigt das Konzept der Kalibrierungsphase, in der die notwendigen Daten für die darauf folgende lineare Regression gesammelt werden. Im Folgenden geht die Arbeit auf die

70

konkrete Kalibrierungsphase für beide in Kapitel 7.2 gezeigten Server ein. In dieser Phase wer-den die Hardwareressourcen, die Bestandteil des Leistungsaufnahme-Modells sein sollen, in unterschiedlicher Intensität ausgelastet. Zeitgleich werden die Auslastungs-Metriken der Hard-wareressourcen und die Leistungsaufnahme des Servers gemessen. Wie oben gezeigt, ist die CPU die einzige Hardwareressource, die in das Leistungsaufnahme-Modell aufgenommen wird. Um die CPU in der Kalibrierungsphase auszulasten, benutzt diese Arbeit das Komman-dozeilenprogramm lookbusy (Carraway 2013). Mit lookbusy kann die CPU auf Linux-Umge-bungen mit einer vorher definierten Intensität belastet werden. Um die CPU in verschiedenen Stufen zu belasten, implementiert diese Arbeit ein Python-Script, welches mit Hilfe von lookbusy die CPU in 10 % Schritten von 0 % bis 100 % auslastet. Jede Auslastungsstufe dauert dabei 120 Sekunden. Um die CPU nach jeder Auslastungsstufe zu beruhigen, wird eine Pause von 60 Sekunden eingelegt. Dieses Script wurde im Rahmen dieser Arbeit nicht komplett neu entwickelt, sondern basiert auf dem Python Script von Beloglazov (2012). Zur Messung der tatsächlichen CPU-Auslastung und der daraus resultierenden Leistungsaufnahme des Servers während dieser Kalibrierungsphase implementiert die vorliegende Arbeit ein weiteres Java Pro-gramm. Das Programm misst pro Sekunde die CPU-Auslastung und die Leistungsaufnahme des Servers und speichert die Daten in einer CSV-Datei (Comma-separated values). Für die Messung der CPU-Auslastung benutzt das Java Programm die frei verfügbare System Informa-tion Gatherer (SIGAR) API (Hyperic 2013). Sowohl der AMD-basierte Server als auch der Intel-basierte Server implementieren die IPMI-Schnittstelle und stellen über sogenannte Sen-soren die Messdaten der aktuellen Leistungsaufnahme der Netzteile des Servers zur Verfügung. Auf die IPMI-Schnittstelle der Server greift das Java Programm mittels der Java Bibliothek Verax IPMI Java Library (Verax Systems 2013) zu. Der AMD-basierte Server verfügt über drei Netzteile und bietet über die IPMI-Schnittstelle die Messdaten der Leistungsaufnahme für diese Netzteile an. Für die Ermittlung der Gesamtleistungsaufnahme des Servers werden die drei Messdaten aufsummiert. Der Intel-basierte Server besitzt nur ein Netzteil und bietet daher nur dessen Leistungsaufnahme durch die IPMI-Schnittstelle nach außen an.

Aus den Messdaten ist ersichtlich, dass die IPMI-Sensoren der in dieser Evaluation verwende-ten Server bei jeder Auslastungsstufe eine gewisse Aufwärmphase benötigen, um stabile Werte für die Leistungsaufnahme zu liefern. Um Seiteneffekte aus der Aufwärm- und Abkühlphase zu verhindern, werden nach dem Kalibrierungslauf für jede Auslastungsstufe die mittleren 30 Messpunkte aus den 120 Messpunkten für das weitere Vorgehen extrahiert. Für die lineare Re-gression stehen somit 330 Messpunkte mit der abhängigen Variablen der Leistungsaufnahme und der unabhängigen Variablen der CPU-Auslastung zur Verfügung. Durch eine einfache li-neare Regression auf diesem Datensatz erhält man die Leistungsaufnahme-Modelle der beiden Server. Abbildung 34 zeigt die Messpunkte für den AMD-basierten Server in einem Koordina-tensystem mit der gemessenen Leistungsaufnahme auf der Y-Achse und der CPU-Auslastung auf der X-Achse. Die durch die lineare Regression ermittelte Regressionsgerade ist ebenfalls in das Koordinatensystem eingezeichnet.

71

Abbildung 34: Lineare Regression auf den Messdaten des AMD-basierten Servers Quelle: Eigene Darstellung

Die Gleichung der Regressionsgerade ist in Formel 6 abgebildet. Durch Einsetzen der CPU-Auslastung (𝑢 ) kann die Leistungsaufnahme des Servers (𝑃 ) prognostiziert werden. Wie in Kapitel 4.2 erläutert, ist die Regressionsgerade gleichzeitig das Leistungsaufnahme-Modell des AMD-basierten Servers.

𝑃 = 243,31 + 139,99 ∗ 𝑢

Formel 6: Leistungsaufnahme-Modell des AMD-basierten Servers

Bei der linearen Regression lässt sich auch die statistische Maßzahl des Bestimmtheitsmaßes 𝑅 berechnen. Das Bestimmtheitsmaß gibt an, welcher Anteil der Streuung einer abhängigen Va-riablen (in diesem Fall die Leistungsaufnahme) durch das Modell erklärt wird. Es gibt also an, wie gut das Modell die Messwerte erklären kann. Das Leistungsaufnahme-Modell in Formel 6 erreicht ein Bestimmtheitsmaß von 73,64 %.

0.0 0.2 0.4 0.6 0.8 1.0

200

250

300

350

CPU-Auslastung

Leis

tung

sauf

nahm

e [W

att]

MesspunktRegressionsgerade

72

Abbildung 35 zeigt die Messpunkte und die Regressionsgerade für den Intel-basierten Server.

Abbildung 35: Lineare Regression auf den Messdaten des Intel-basierten Servers Quelle: Eigene Darstellung

Die Gleichung der Regressionsgerade und somit das Leistungsaufnahme-Modell des Intel-ba-sierten Servers ist in Formel 7 zu sehen. Dieses Leistungsaufnahme-Modell hat auf Basis der für die lineare Regression benutzten Messwerte ein Bestimmtheitsmaß 𝑅 von 90,78 %. Das Leistungsaufnahme-Modell für den Intel-basierten Server kann also auf Grundlage der durch den Kalibrierungslauf generierten Messdaten die Leistungsaufnahme besser abbilden, als das Leistungsaufnahme-Modell des AMD-basierten Servers.

𝑃 = 151,08 + 89,98 ∗ 𝑢

Formel 7: Leistungsaufnahme-Modell des Intel-basierten Servers

Die beiden Leistungsaufnahme-Modelle aus Formel 6 und 7 werden, wie in Kapitel 4.3 gezeigt, im   jeweiligen  „Resource  Environment  Model“ dem modellierten Server hinzugefügt. Somit sind die PCM-Modelle für den initialen und für den Ziel-Server in der Lage, die Leistungsauf-nahme bzw. den Energieverbrauch der Anwendung SPECjEnterprise2010 zu prognostizieren. Mit welcher Genauigkeit die Leistungsaufnahme der Server während eines Benchmark-Laufs prognostiziert werden kann, zeigt das nächste Kapitel 7.5.

0.0 0.2 0.4 0.6 0.8 1.0

140

160

180

200

220

CPU-Auslastung

Leis

tung

sauf

nahm

e [W

att]

MesspunktRegressionsgerade

73

7.5 Vergleich der Mess- und Simulationsergebnisse Kapitel 7.1.2 zeigt die Anwendung der  „Orders  Domain“  von  SPECjEnterprise2010, für die in Kapitel 7.3 ein PCM-Modell auf Basis des AMD-basierten Servers erstellt und anschließend für den Intel-basierten Server angepasst wurde. Beide PCM-Modelle wurden in Kapitel 7.4 um ein Leistungsaufnahme-Modell ergänzt. Wie in Kapitel 2 beschrieben, soll ein Ressourcen-Pro-fil die Performance und den Ressourcen- und Energieverbrauch einer Unternehmensanwen-dung auf einer speziellen Hardwareinfrastruktur und unter einer speziellen Nutzerlast prognos-tizieren. Deshalb wird in diesem Kapitel evaluiert, wie gut die beiden angefertigten PCM-Mo-delle die Performance und den Ressourcen- und Energieverbrauch von SPECjEnterprise2010 auf dem jeweiligen Server unter einer definierten Benutzerlast prognostizieren können. Dazu vergleicht dieses Kapitel die Simulationsergebnisse der beiden PCM-Modelle mit den realen Messergebnissen, die während eines SPECjEnterprise2010-Benchmark-Laufs gesammelt wer-den.

7.5.1 Aufbau der Evaluation

Um die Simulationsergebnisse aus den beiden PCM-Modellen mit realen Messergebnissen ei-nes Benchmark-Laufs vergleichen zu können,  müssen  diese  zunächst  noch  um  das  „Usage  Mo-del“  ergänzt  werden.  Kapitel  7.1.3 zeigt, dass der SPECjEnterprise2010-Benchmark die drei Transaktionen  „Browse“,  „Manage“  und  „Purchase“  definiert.  Der  Benchmark  definiert  wei-terhin die Wahrscheinlichkeit, mit der ein durch den Benchmark-Driver simulierter Benutzer eine bestimmte  Transaktion  ausführt.  Die  „Browse“-Transaktion wird mit 50 % Wahrschein-lichkeit, die  „Manage“- und  „Purchase“-Transaktion mit jeweils 25 % Wahrscheinlichkeit aus-geführt. Zwischen zwei einzelnen Transaktionen simuliert der Benchmark-Driver eine Denk-pause von ca. 9,9 Sekunden. Den beiden PCM-Modellen  wird  deshalb  jeweils  ein  „Usage  Mo-­del“  hinzugefügt,  welches  genau  das Benutzerverhalten des Benchmark-Drivers abbildet. Ab-bildung 36 zeigt  das  hinzugefügte  „Usage  Model“.

Abbildung 36: SPECjEnterprise2010 – Usage Model Quelle: Eigene Darstellung

74

Das  „Usage  Model“  zeigt  die  Wahrscheinlichkeiten, mit denen die drei Transaktionen von den Benutzern ausgeführt werden. Wie in Kapitel 7.1.3 erläutert, besteht jede dieser drei Geschäfts-transaktion aus untergeordneten HTTP-Anfragen. Um  das  „Usage  Model“  übersichtlich  zu  hal-­ten, sind die Aufrufe dieser untergeordneten Anfragen in die Komponente DealerDriver im „Repository  Model“  ausgelagert, obwohl diese Komponente nicht zur Softwarearchitektur von SPECjEnterprise2010 gehört. Die untergeordneten Aufrufe könnten auch  direkt  im  „Usage  Mo-­del“  abgebildet werden. Das  „Usage  Model“  in  Abbildung 36 zeigt auch die vom Benchmark-Driver  simulierte  Bedenkzeit  von  9,9  Sekunden.  Die  Anzahl  der  Nutzer  im  „Usage  Model“  wird  für den Vergleich der Simulationsergebnisse mit den realen Messergebnissen vor jedem PCM-Simulations-Lauf gemäß der im Benchmark-Lauf simulierten Benutzeranzahl angepasst.

Der Vergleich zwischen PCM-Simulationsergebnissen und echten Messergebnissen soll für un-terschiedliche Belastungsszenarien erfolgen. Dazu werden jeweils auf dem AMD- und dem In-tel-basierten Server vier Benchmark-Läufe mit unterschiedlicher Benutzeranzahl durchgeführt. Die Benutzeranzahl wird dabei in Schritten von 1000 Benutzern von 1300 bis 4300 Benutzer erhöht. Benchmark-Läufe auf dem AMD-basierten Server haben gezeigt, dass das System nicht in der Lage ist 4300 Benutzer zu handhaben. Bei einem Benchmark-Lauf mit 3500 Benutzern ist die CPU des AMD-basierten Servers zu 86 % ausgelastet, was der Auslastung des Intel-basierten Servers bei 4300 Benutzern entspricht. Deswegen wird die höchste Belastungsstufe beim AMD-basierten Server von 4300 auf 3500 Benutzer gesenkt. Die beiden PCM-Modelle werden jeweils für die oben gezeigten Belastungsstufen simuliert. Dazu wird nicht die Stan-dard-Simulationsumgebung SimuCom (Becker 2008, 109-200) verwendet, sondern EventSim (Merkle/Henss 2011). EventSim kann mit den hohen Benutzerzahlen, die für die Evaluation benötigt werden, deutlich besser umgehen als SimuCom (Merkle/Henss 2011, 21-22).

Ein Ressourcen-Profil gibt Aufschluss über die Performance, also Antwortzeiten und Durch-satz, sowie den Ressourcen- und Energiebedarf einer Anwendung. Deswegen werden für jede Belastungsstufe die simulierten und gemessenen Antwortzeiten und Durchsatz  der  „Browse“-, „Manage“- und  „Purchase“-Transaktionen miteinander verglichen. Außerdem wird die CPU-Auslastung und die durchschnittliche Leistungsaufnahme der Server aus der Simulation mit den realen Messwerten verglichen. Wie in Kapitel 7.2 gezeigt, ist SPECjEnterprise2010 geclustered mit 6 Instanzen auf dem jeweiligen Server aufgesetzt. Die Antwortzeiten der drei Transaktionen werden nur auf einer der Instanzen gemessen. Für die Messung der Antwortzeiten wird, wie in der Arbeit von Brunnert/Vögele/Krcmar (2013, 85) beschrieben, auf einer JBoss-Instanz ein Servlet  Filter  vor  das  zentrale  Servlet  der  „Orders  Domain“  geschaltet, welcher alle HTTP-Anfragen abfängt und die Antwortzeiten in einer CSV-Datei aufzeichnet. Aus den Antwortzei-ten der verschiedenen HTTP-Anfragen können anschließend die durchschnittlichen Antwort-zeiten der drei Geschäftstransaktionen berechnet werden. Das Schreiben der Antwortzeiten in eine CSV-Datei durch den Servlet Filter hat eine gewisse Beanspruchung der CPU zur Folge. Um diese geringe Verfälschung der CPU-Auslastung zu minimieren, werden die Antwortzeiten nur auf einer Instanz gemessen. Der Benchmark-Driver misst selber auch die Antwortzeiten der drei Geschäftstransaktionen. Diese können aber nicht für den Vergleich mit den Simulationser-gebnissen verwendet werden, da sie auch die Verzögerung durch die Netzwerkverbindung zwi-schen Benchmark-Driver und dem untersuchten Server beinhalten. Das in Kapitel 7.3 angewendete Modellgenerierungsverfahren kann diese Netzwerkverbindung allerdings nicht

75

abbilden. Deswegen berücksichtigen auch die aus den beiden PCM-Modellen simulierten Ant-wortzeiten keine Verzögerung durch eine Netzwerkkomponente. Für den Vergleich der Durch-satzraten werden die Messergebnisse aus dem Benchmark-Driver verwendet. Damit wird sichergestellt, dass nicht durch eine manipulative Konfiguration der Application Server Instan-zen die durchschnittliche Antwortzeit auf Kosten eines geringen Durchsatzes niedrig gehalten wird. Der Vergleich des simulierten und gemessenen Durchsatzes bestätigt daher die Validität der gesamten Evaluations-Ergebnisse. Die CPU-Auslastung und die durchschnittliche Leis-tungsaufnahme des Servers während eines Benchmark-Laufs werden mit dem eigens imple-mentierten Java Programm gemessen, mit dem in Kapitel 7.4 schon die Metriken für die Generierung der Leistungsaufnahme-Modelle gemessen wurden. Das Java Programm misst jede Sekunde die CPU-Auslastung und die Leistungsaufnahme der Netzteile des jeweiligen Servers. Für Details zur technischen Implementierung dieses Java Programms wird auf Kapi-tel 7.4 verwiesen.

Die Messergebnisse werden für jede Belastungsstufe, wie oben beschrieben, in einem 30 Mi-nuten Benchmark-Lauf ermittelt. Ebenso wird in der Palladio-Bench ein 30 Minuten Simulati-onslauf mit der spezifizierten Benutzerlast durchgeführt. Um Seiteneffekte von der Aufwärm- und Abkühlphase des Benchmark- und Simulations-Laufs zu vermeiden, werden nur die Er-gebnisse zwischen der fünfminütigen Aufwärm- und fünfminütigen Abkühlphase für den Ver-gleich extrahiert. Es werden also die Mess- und Simulationsergebnisse für eine Phase von 20 Minuten miteinander verglichen.

7.5.2 Evaluation des initialen PCM-Modells

Dieses Kapitel evaluiert die Genauigkeit des PCM-Modells, das für den AMD-basierten Server generiert und um das Leistungsaufnahme-Modell ergänzte wurde. Dazu zeigen die Tabellen 7 und 8 die gemessenen und simulierten Ergebnisse für  die  „Orders  Domain“  von  SPECjEnter-­prise2010 auf dem AMD-basierten Server. Tabelle 7 zeigt für jede Belastungsstufe und für jede Geschäftstransaktion zum einen die gemessene durchschnittliche Antwortzeit (GAZ), die simu-lierte durchschnittliche Antwortzeit (SAZ) und den sich daraus ergebenden relativen Fehler aus der Simulation des PCM-Modells. Die Antwortzeiten sind in Millisekunden angegeben. Zum anderen sind der gemessene Durchsatz (GD), der simulierte Durchsatz (SD) und der relative Fehler der Simulation in der Tabelle 7 ersichtlich. Die Durchsatzzahlen sind absolute Zahlen und geben die Anzahl der Transaktionen, die in dem betrachteten 20 minütigen Zeitfenster ge-messen bzw. simuliert wurden, wieder. Tabelle 8 zeigt die gemessene CPU-Auslastung (GCPU), die simulierte CPU-Auslastung (SCPU) und die Abweichung, die der simulierte Wert zum tatsächlichen Wert hat. Des Weiteren ist die gemessene Leistungsaufnahme des Servers (GL), die simulierte Leistungsaufnahme (SL) und der prozentuale Fehler der Simulation in der Tabelle aufgeführt. Die Leistungsaufnahme ist in der Einheit Watt angegeben.

Wie oben beschrieben, ist für jedes Simulationsergebnis der relative Fehler zum Messergebnis angegeben. Der relative Fehler (𝑓) berechnet sich aus dem Simulationswert (𝑠) und dem Mess-wert (𝑚) gemäß der Gleichung in Formel 8.

𝑓 = |𝑠 − 𝑚|𝑚

Formel 8: Berechnung des relativen Fehlers

76

Nutzer Transaktion GAZ SAZ Fehler GD SD Fehler 1300 Browse 63,95 ms 61,35 ms 4,06 % 78.623 78.557 0,08 %

Manage 16,62 ms 15,20 ms 8,54 % 39.378 39.245 0,34 % Purchase 13,11 ms 12,27 ms 6,43 % 39.259 39.135 0,32 %

2300 Browse 63,37 ms 61,81 ms 2,46 % 139.328 138.383 0,68 % Manage 15,85 ms 15,38 ms 2,96 % 69.685 70.186 0,72 % Purchase 12,84 ms 12,33 ms 3,94 % 69.932 69.514 0,60 %

3300 Browse 77,60 ms 66,34 ms 14,51 % 200.174 199.166 0,50 % Manage 18,10 ms 16,45 ms 9,12 % 99.643 99.930 0,29 % Purchase 13,66 ms 13,25 ms 3,04 % 99.673 99.315 0,36 %

3500 Browse 95,95 ms 71,88 ms 25,09 % 211.585 211.314 0,13 % Manage 22,21 ms 17,85 ms 19,66 % 105.454 105.506 0,05 % Purchase 18,07 ms 14,37 ms 20,44 % 105.708 105.557 0,14 %

Tabelle 7: Vergleich der gemessenen und simulierten Antwortzeiten und Durchsatz-zahlen auf dem AMD-basierten Server Quelle: Eigene Erhebung

Nutzer GCPU SCPU Fehler GL SL Fehler 1300 33,37 % 30,04 % 9,97 % 367,55 W 285,36 W 22,36 % 2300 57,38 % 52,89 % 7,82 % 403,87 W 317,36 W 21,42 % 3300 82,53 % 76,00 % 7,92 % 433,76 W 349,70 W 19,38 % 3500 86,10 % 80,59 % 6,40 % 436,47 W 356,13 W 18,41 %

Tabelle 8: Vergleich der gemessenen und simulierten CPU-Auslastung und Leistungs-aufnahme des AMD-basierten Servers Quelle: Eigene Erhebung

Die Simulation des für den AMD-basierten Server generierten PCM-Modells kann die Ant-wortzeiten in den meisten Fällen mit einer Abweichung zum Messergebnis von unter 10 % vorhersagen. Vor allem in den unteren drei Belastungsstufen zeigen die prognostizierten Ant-wortzeiten eine hohe Genauigkeit. Auf der höchsten Belastungsstufe zeigen sich größere Ab-weichungen von ca. 20 % bei der Prognose der Antwortzeiten. Es zeigt sich, dass die Simulation insgesamt die Antwortzeiten leicht zu niedrig einschätzt, da die gemessenen Antwortzeiten in allen Fällen über den Simulationswerten liegen.

Der Durchsatz der einzelnen Transaktionen kann durch die Simulation mit einem Fehler unter 1 % prognostiziert werden. Diese sehr hohe Genauigkeit wird dadurch erklärt, dass die Bedenk-zeit eines Nutzers zwischen zwei Transaktionen mit ca. 9,9 Sekunden viel höher ist als die Antwortzeit einer einzelnen Transaktion. Dadurch haben Abweichungen in der simulierten Ant-wortzeit einen sehr geringen Effekt auf den simulierten Durchsatz (Brunnert/Vögele/Krcmar 2013, 86).

77

Die CPU-Auslastung kann in allen drei Belastungsstufen mit einem Fehler von unter 10 % vorhergesagt werden. Die CPU-Auslastung wird dabei in allen Fällen leicht zu niedrig durch die Simulation prognostiziert.

Das um das Leistungsaufnahme-Modell erweiterte PCM-Modell für den AMD-Server kann die Leistungsaufnahme des Servers mit einem Fehler von ca. 20 % vorhersagen. Diese hohe Ab-weichung kann zum einen dadurch erklärt werden, dass die Simulation in allen Fällen die CPU-Auslastung um ca. 10 % zu niedrig prognostiziert und damit das Leistungsaufnahme-Modell aus Formel 6 einen zu niedrigen Wert für den Faktor CPU-Auslastung benutzt. Zum anderen ist die gemessene Leistungsaufnahme konstant 20 % höher als der Simulationswert, was darauf hindeutet, dass das Leistungsaufnahme-Modell nicht alle Hardwareressourcen berücksichtigt, die bei SPECjEnterprise2010 eine Auswirkung auf die Leistungsaufnahme haben. So könnte z.B. der Zugriff auf den Arbeitsspeicher (RAM) einen Einfluss auf die Leistungsaufnahme ha-ben, welche im PCM- und Leistungsaufnahme-Modell nicht berücksichtigt wird.

In der Original-Arbeit zum benutzten Modellgenerierungsansatz (Brunnert/Vögele/Krcmar 2013) wird ebenfalls eine Evaluation  anhand  der  „Orders  Domain“  von  SPECjEnterprise2010  durchgeführt. Die Evaluation wurde allerdings für geringere Benutzerzahlen und mit der Simu-lationsumgebung SimuCom durchgeführt und es wurde kein Leistungsaufnahme-Modell be-rücksichtigt. Für die Antwortzeiten, die Durchsatzzahlen und die CPU-Auslastung kommt die Original-Arbeit zu ähnlichen Ergebnissen wie die Evaluation in diesem Kapitel.

Dieses Kapitel zeigt also, dass der eingesetzte Modellgenerierungsansatz auch bei hohen Be-nutzerzahlen und dem Einsatz von EventSim zu zufriedenstellenden Prognosewerten für die Antwortzeiten, die Durchsatzzahlen und die CPU-Auslastung führt. Das entwickelte Leistungs-aufnahme-Modell liefert mit einer Ungenauigkeit von ca. 20 % zumindest einen sehr guten Anhaltspunkt für die tatsächliche Leistungsaufnahme des Servers.

7.5.3 Evaluation des angepassten PCM-Modells

Das Kapitel 7.5.2 evaluiert die Genauigkeit des für den AMD-Server generierten PCM-Modells. Dieses PCM-Modell wurde in Kapitel 7.3 für den Intel-basierten Server angepasst und in Kapitel 7.4 um ein Leistungsaufnahme-Modell ergänzt. Es wurde also der in Kapitel 6 vor-gestellte Prozess eines Ressourcen-Profils auf Basis des PCM-Metamodells durchlaufen. Die-ses Kapitel vergleicht nun die Simulationsergebnisse dieses PCM-Modells mit den realen Messergebnissen.

Die Tabellen 9 und 10 zeigen  die  gemessenen  und  simulierten  Ergebnisse  für  die  „Orders  Do-­main“  auf  dem  Intel-basierten Server. Die Tabellen sind strukturell genauso aufgebaut wie die beiden Tabellen 7 und 8 in Kapitel 7.5.2. Tabelle 9 vergleicht die gemessenen und simulierten Antwortzeiten   und   den   Durchsatz   der   einzelnen   Transaktionen   der   „Orders   Domain“. Ta-belle 10 vergleicht die gemessene und simulierte CPU-Auslastung und Leistungsaufnahme des Intel-basierten Servers.

78

Nutzer Transaktion GAZ SAZ Fehler GD SD Fehler 1300 Browse 32,35 ms 42,46 ms 31,23 % 78.502 78.333 0,22 %

Manage 10,02 ms 10,55 ms 5,23 % 39.464 39.376 0,22 % Purchase 7,81 ms 8,47 ms 8,46 % 39.367 39.297 0,18 %

2300 Browse 35,85 ms 42,51 ms 18,55 % 139.603 138.961 0,46 % Manage 10,53 ms 10,58 ms 0,48 % 69.314 69.490 0,25 % Purchase 7,98 ms 8,49 ms 6,35 % 69.266 69.576 0,45 %

3300 Browse 41,07 ms 45,01 ms 9,60 % 199.517 199.646 0,06 % Manage 11,45 ms 11,19 ms 2,27 % 99.254 99.936 0,69 % Purchase 8,10 ms 8,99 ms 11,04 % 99.890 99.355 0,54 %

4300 Browse 68,00 ms 83,77 ms 23,19 % 259.548 259.591 0,02 % Manage 18,32 ms 20,82 ms 13,69 % 130.239 129.641 0,46 % Purchase 16,23 ms 16,75 ms 3,22 % 129.909 129.293 0,47 %

Tabelle 9: Vergleich der gemessenen und simulierten Antwortzeiten und Durchsatz-zahlen auf dem Intel-basierten Server Quelle: Eigene Erhebung

Nutzer GCPU SCPU Fehler GL SL Fehler 1300 24,05 % 27,24 % 13,26 % 197,05 W 175,59 W 10,89 % 2300 45,08 % 48,29 % 7,12 % 220,47 W 194,53 W 11,76 % 3300 64,86 % 69,34 % 6,92 % 241,67 W 213,48 W 11,67 % 4300 86,03 % 90,16 % 4,80 % 264,29 W 232,21 W 12,14 %

Tabelle 10: Vergleich der gemessenen und simulierten CPU-Auslastung und Leis-tungsaufnahme des Intel-basierten Servers Quelle: Eigene Erhebung

Das für den Intel-basierten Server angepasste PCM-Modell kann die Antwortzeiten für die „Manage“- und  „Purchase“-Transaktion mit einer Abweichung unter 15 %, in den meisten Fäl-len sogar unter 10 %, zu den Messwerten prognostizieren. Für  die  „Browse“-Transaktion ergibt sich eine leicht höhere Abweichung von bis zu ca. 30 % bei 1300 Benutzern. Im Gegensatz zu den Ergebnissen des initialen PCM-Modells in Kapitel 7.5.2, zeigt sich hier, dass die Simulation des angepassten PCM-Modells die Antwortzeiten tendenziell zu hoch prognostiziert.

Die Durchsatzzahlen können wieder mit einer Abweichung unter 1 % prognostiziert werden. Diese hohe Genauigkeit liegt, wie bereits in Kapitel 7.5.2 dargestellt, an der langen Bedenkzeit eines Nutzers zwischen zwei Transaktionen und der relativ dazu sehr geringen Transaktions-zeit.

Die Auslastung der CPU des Intel-basierten Servers kann auf Basis des angepassten PCM-Modells in den meisten Fällen unter 10 % Abweichung vorhergesagt werden. Nur bei 1300 Benutzern ist eine leicht höhere Abweichung mit ca. 13 % zwischen Simulations- und Messer-gebnis festzustellen.

79

Das PCM-Modell kann die Leistungsaufnahme des Intel-Servers während eines Benchmark-Laufs für alle Belastungsstufen mit einem relativen Fehler zwischen 10 % und 13 % prognos-tizieren. Damit ist die Prognose der Leistungsaufnahme auf dem Intel-basierten Server genauer als auf dem AMD-basierten Server. Die Leistungsaufnahme wird aber, wie beim initialen PCM-Modell, zu niedrig eingeschätzt. Der geringere relative Fehler kann zum einen damit erklärt werden, dass das angepasste PCM-Modell im Gegensatz zum initialen PCM-Modell die CPU-Auslastung leicht zu hoch prognostiziert. Damit geht auch das Leistungsaufnahme-Modell von einer zu hohen CPU-Auslastung bei der Berechnung der Leistungsaufnahme aus. Aber selbst wenn man als Inputparameter der beiden Leistungsaufnahme-Modelle für AMD- und Intel-ba-sierten Server die tatsächlich gemessene CPU-Auslastung einsetzt und die Leistungsaufnahme berechnet, zeigt sich, dass das angepasste PCM-Modelle genauere Ergebnisse liefert als das initiale PCM-Modell. Tabelle 11 zeigt den Vergleich der Leistungsaufnahme-Modelle. Die Ta-belle zeigt für jede Belastungsstufe die gemessene Leistungsaufnahme (GL) des jeweiligen Ser-vers und die Leistungsaufnahme (ML), die sich durch Einsetzen der gemessenen CPU-Auslastung in das Leistungsaufnahme-Modell ergibt.

AMD Intel Nutzer GL ML Fehler GL ML Fehler 1300 367,55 W 290,02 W 21,09 % 197,05 W 172,72 W 12,35 % 2300 403,87 W 323,63 W 19,87 % 220,47 W 191,65 W 13,07 % 3300 433,76 W 358,85 W 17,27 % 241,67 W 209,44 W 13,34 % 3500 bzw. 4300 436,47 W 363,85 W 16,64 % 264,29 W 228,49 W 13,55 %

Tabelle 11: Vergleich der beiden Leistungsaufnahme-Modelle für den AMD- und den Intel-basierten Server Quelle: Eigene Erhebung

Die höhere Genauigkeit des Leistungsaufnahme-Modells des Intel-basierten Servers kann u.a. damit erklärt werden, dass das Bestimmtheitsmaß des Modells mit 90,78 % höher ist als beim AMD-basierten Server mit 73,64 % (siehe Kapitel 7.4).

Dieses Kapitel zeigt, dass das für den AMD-basierten Server angepasste PCM-Modell die Per-formance und den Ressourcen- und Energiebedarf mit ausreichender Präzision prognostizieren kann. Diese Evaluation bestätigt, dass der in dieser Arbeit entwickelte Ansatz eines Ressour-cen-Profils auf Basis von PCM zufriedenstellend funktioniert.

80

8 Zusammenfassung und Ausblick

Die Ergebnisse dieser Arbeit werden in Kapitel 8.1 zusammengefasst. Kapitel 8.2 zeigt die Limitationen des in dieser Arbeit gezeigten Ressourcen-Profils und weist dabei auf weiteren Forschungsbedarf hin.

8.1 Zusammenfassung In dieser Arbeit wurde ein Konzept für ein Ressourcen-Profil einer Unternehmensanwendung entwickelt und umgesetzt. Dazu wurde zunächst in Kapitel 1 motiviert, warum eine Beschrei-bung des Ressourcen- und Energiebedarfs einer Unternehmensanwendung wünschenswert ist. Ähnlich wie die Systemvoraussetzungen von Einzelbenutzer-Anwendungen soll ein Ressour-cen-Profil einem Kunden dabei helfen die richtige Hardware für den Betrieb einer Software zu bestimmen. Der Energieverbrauch ist in Rechenzentren ein immer größerer Kostenfaktor. Da-her ist auch die Kenntnis über den Energiebedarf einer Unternehmensanwendung für den Kun-den von Bedeutung.

In Kapitel 2 wurde aber gezeigt, dass es schwierig ist, die Performance sowie den Ressourcen- und Energiebedarf einer Unternehmensanwendung zu bestimmen. Denn diese Metriken sind abhängig von der konkreten Hardwareinfrastruktur, auf der die Anwendung laufen soll, der Anzahl an Benutzern und deren Benutzerverhalten. Deshalb ist es für einen Softwarehersteller unmöglich, eine allgemeingültige Aussage über den Ressourcen- und Energiebedarf seiner An-wendung zu treffen. Um dieses Problem zu lösen, schlägt Kapitel 2 das Konzept eines Ressour-cen-Profils einer Unternehmensanwendung vor. Das Ressourcen-Profil ist ein Modell, welches die Performance und den Ressourcen- und Energiebedarf einer Unternehmensanwendung in Abhängigkeit der oben genannten Faktoren abbildet. Dieses parametrisierbare Modell soll ein-malig vom Softwarehersteller für eine Unternehmensanwendung erstellt und an die Kunden ausgeliefert werden können. Der Kunde spezifiziert seine Hardwareinfrastruktur, die Anzahl an Benutzern und deren Benutzerverhalten und kann dadurch die Performance und den Ressour-cen- und Energiebedarf der Anwendung in seiner kundenspezifischen Umgebung analysieren. Ein so gestaltetes Ressourcen-Profil hat viele Anwendungsgebiete. So kann es dem Kunden u.a. bei der Investitionsentscheidung für eine neue Unternehmensanwendung helfen. Denn durch das Ressourcen-Profil können die Kosten für die Anschaffung einer neuen Hardware und die voraussichtlichen Energiekosten für den Betrieb der Anwendung abgeschätzt werden.

In Kapitel 3 wurde gezeigt, dass Performance-Modelle grundsätzlich als Basistechnologie für ein Ressourcen-Profil geeignet sind. In einem Performance-Modell werden die Hardwarearchi-tektur, die Softwarearchitektur, der Ressourcenverbrauch der modellierten Anwendungsrouti-nen und das Benutzerverhalten modelliert. Durch analytische oder simulationsbasierte Lösungsverfahren kann die Performance und der Ressourcenbedarf eines Anwendungssystems prognostiziert werden. Ein Ressourcen-Profil ist ein austauschbares Medium zwischen Soft-warehersteller und Kunden. Damit ein Performance-Modell ein Ressourcen-Profil repräsentie-ren kann, muss es gewisse Eigenschaften erfüllen. Die wichtigste Eigenschaft ist, dass ein Performance-Modell, welches nach den Regeln eines Performance-Metamodells erstellt wird,

81

eine modulare Modellierung der Hardwareinfrastruktur, der Softwarearchitektur und des Be-nutzerverhaltens ermöglicht. Außerdem muss es einen geeigneten Mechanismus geben, den Ressourcenbedarf einer Anwendung zwischen zwei Hardwarearchitekturen anzupassen zu kön-nen. Denn dann ist es möglich, dass der Softwarehersteller ein Performance-Modell seiner An-wendung auf seiner eigenen Hardwareinfrastruktur erstellt und dieses dem Kunden zur Verfü-gung stellt. Der Kunde tauscht die modellierte Hardwareinfrastruktur aus und passt den Res-sourcenbedarf entsprechend an. Bei einem Performance-Modell, bei dem diese Aspekte in ei-nem monolithischen Modell ineinander verwoben sind, ist dies nicht möglich. In Kapitel 3 werden deshalb mehrere Performance-Metamodelle hinsichtlich dieser und weiterer Eigen-schaften untersucht. Die Untersuchung der verschiedenen Metamodelle zeigt, dass keines die Abbildung des Energieverbrauchs eines Anwendungssystems unterstützt. Das Kapitel 3 kommt zu dem Ergebnis, dass das Palladio Component Model (Becker/Koziolek/Reussner 2009) unter den untersuchten Metamodellen am besten geeignet ist, um damit das Konzept eines Ressour-cen-Profils weiterzuverfolgen.

Des Weiteren wurden in Kapitel 3 Ansätze aus der Praxis untersucht. Dabei konnten einfache mathematische Modelle in Form von Excel-Tabellen gefunden werden, bei der die Anzahl an Benutzern spezifiziert werden kann und die Modelle daraufhin die Anzahl der notwendigen Referenz-Server berechnet. Nachteil dieser Modelle ist, dass die Ergebnisse auf einer vom Soft-warehersteller spezifizierten Referenzhardwarearchitektur basieren und diese nicht angepasst werden kann. Außerdem besitzen diese einfachen Modelle keine hohe Präzision bei ihrer Vor-hersage. Der SAP Quick Sizer (SAP 2013b) umgeht die Abhängigkeit zu einer Referenzarchi-tektur. Das durch den SAP Quick Sizer implementierte Modell nimmt als Inputparameter die erwartete Anzahl an Benutzern auf und berechnet daraus einen Benchmark-Wert, den ein Hard-wareserver erreichen muss, um diese Benutzerlast zu bewältigen. Nachteil des SAP Quick Sizer ist dessen geringe Präzision. Durch die Untersuchung der verschiedenen Ansätze aus der Lite-ratur und Praxis beantwortet Kapitel 3 die erste Forschungsfrage.

Da PCM keine Funktionalität zur Abbildung des Energiebedarfs eines Anwendungssystems besitzt, dies aber für die Realisierung eines Ressourcen-Profils notwendig ist, wurde in Kapi-tel 4 das PCM-Metamodell um das Modellierungselement eines linearen Leistungsaufnahme-Modells erweitert. Das Leistungsaufnahme-Modell bildet die Leistungsaufnahme eines Servers in Abhängigkeit zur Auslastung der Hardwareressourcen ab. In einer Kalibrierungsphase kann ein solches Leistungsaufnahme-Modell für einen Server generiert werden. Dazu werden die Hardwareressourcen mit variierender Intensität ausgelastet und gleichzeitig die Leistungsauf-nahme des Servers gemessen. Durch eine lineare Regression auf den Messwerten kann ein li-neares Leistungsaufnahme-Modell erstellt werden. Das Kapitel erweitert die beiden PCM-Simulationsumgebungen SimuCom (Becker 2008, 109-200) und EventSim (Merkle/Henss 2011), damit diese auf Basis des Leistungsaufnahme-Modells den Energieverbrauch des mo-dellierten Anwendungssystems berechnen können.

Da ein Ressourcen-Profil die Performance und den Ressourcen- und Energiebedarf unabhängig von einer Hardwareinfrastruktur abbilden soll, wurde in Kapitel 5 gezeigt, wie ein initial vom Softwarehersteller erstelltes PCM-Modell auf die Hardwareinfrastruktur eines Kunden ange-passt werden kann. Diese Arbeit schlägt vor, die Verarbeitungsgeschwindigkeit der modellier-ten Prozessoren analog der Benchmark-Ergebnisse der initialen und der Ziel-Hardware-

82

ressource anzupassen. Dazu wird für die jeweils betrachtete Hardwareressource ein Benchmark auf dem initialen Server und dem Ziel-Server ausgeführt. Die Benchmark-Ergebnisse werden ins Verhältnis gesetzt und dadurch die neue Verarbeitungsgeschwindigkeit berechnet. Damit das geschilderte Verfahren angewendet werden kann, muss das initiale PCM-Modell einige Voraussetzungen erfüllen. Wenn die Hardwareinfrastruktur des initialen PCM-Modells aus mehreren Hardwareservern besteht, ist darauf zu achten, dass die verbauten Hardwareressour-cen identisch sind. Auch muss beachtet werden, dass bei Berücksichtigung der Netzwerkres-source der Bedarf an dieser Ressource bei allen Aufrufen zwischen verschiedenen Komponenten modelliert ist.

Kapitel 6 fasst den Gesamt-Prozess zusammen, der bei der Realisierung eines Ressourcen-Pro-fils auf Basis von PCM notwendig ist. So muss der Softwarehersteller die Softwarearchitektur in den PCM-Teilmodellen  „Repository  Model“  und  „System  Model“  modellieren.  Die  Hard-wareinfrastruktur modelliert  er  im  „Ressource  Environment  Model“.  Die Allokation der Soft-warekomponenten  auf  die  Hardwareserver  spezifiziert  er  im  „Allocation  Model“.  Für die im „Ressource  Environment  Model“  modellierten  Hardwareressourcen  muss  der  Softwareherstel-­ler Benchmarks durchführen und die Ergebnisse zusätzlich zu den oben geschilderten PCM-Teilmodellen dem Kunden zur Verfügung stellen. Der Kunde übernimmt das  „Repository  Mo-del“  und  das  „System  Model“  unverändert.  Über  die  Benchmark-Ergebnisse wird die Verarbei-tungsgeschwindigkeit   der   im   „Resource   Environment   Model“   spezifizierten   Hardware-ressourcen angepasst. Zusätzlich  muss  das  „Resource  Environment  Model“  um das aus der Ka-librierungsphase generierte Leistungsaufnahme-Modell ergänzt werden. Wird die Allokation der Komponenten auf die Hardwareserver verändert, muss  auch  das  „Allocation  Model“  ange-­passt werden. Für ein komplett spezifiziertes PCM-Modell muss der Kunde nun noch sein Be-nutzerverhalten  in  einem  „Usage  Model“  abbilden. Am Ende dieses Prozesses erhält der Kunde ein auf ihn angepasstes Performance-Modell, mit welchem er die Performance und den Res-sourcen- und Energiebedarf der Unternehmensanwendung evaluieren kann. Damit beantworten die Kapitel 4, 5 und 6 die zweite Forschungsfrage, wie der Energiebedarf in einem Ressourcen-Profil abgebildet werden kann, welches auf einem Performance-Modell basiert.

Kapitel 7 evaluiert das Konzept des Ressourcen-Profils auf Basis von PCM anhand der Bench-mark-Anwendung SPECjEnterprise2010 (SPEC 2010a). Dazu wurde ein initiales PCM-Modell auf Grundlage eines initialen Servers erstellt und mittels Benchmark-Egebnissen für einen Ziel-Server angepasst. Die beiden Modelle berücksichtigen dabei jeweils nur den CPU-Bedarf der Anwendung. Beide PCM-Modelle wurden um ein Leistungsaufnahme-Modell erweitert, wel-ches die Leistungsaufnahme in Abhängigkeit zur CPU-Auslastung des Servers prognostiziert. Für unterschiedliche Belastungsstufen, d.h. variierende Anzahl an Benutzern, wurden die Si-mulationsergebnisse der PCM-Modelle mit realen Messergebnissen verglichen. Beide Modelle können die Leistungsaufnahme des jeweiligen Servers mit einer Abweichung zwischen 10 und 20 % zu den realen Messwerten prognostizieren. Die Antwortzeiten, der Durchsatz und die Auslastung der CPU können in den meisten Fällen mit einer Abweichung unter 10 % prognos-tiziert werden. Damit wird die dritte Forschungsfrage hinsichtlich der Genauigkeit des entwi-ckelten Ressourcen-Profils beantwortet.

83

8.2 Ausblick Das in dieser Arbeit vorgestellte und realisierte Konzept eines Ressourcen-Profils auf Basis von PCM hat noch einige Limitationen, die vor einem breiten Einsatz in der Praxis gelöst werden müssen. Dieses Kapitel geht im Folgenden auf einige Bereiche ein, die dazu noch weiter er-forscht werden müssen.

Weiterer Forschungsaufwand müsste u.a. in die Erstellung von initialen PCM-Modellen gelegt werden. In dieser Arbeit wurde ein Generierungsverfahren verwendet, welches für Java EE-Anwendungen entwickelt wurde (Brunnert/Vögele/Krcmar 2013). Das eingesetzte Verfahren ist aber nicht in der Lage, den Bedarf an einer HDD abzubilden. Daher wäre eine Erweiterung um diese Funktionalität wünschenswert. Um ein breiteres Spektrum von Unternehmensanwen-dungen abzudecken, müssten ähnliche Generierungsverfahren auch für andere Frameworks, wie CORBA oder .NET entwickelt werden.

Durch die in dieser Arbeit entwickelte Erweiterung des PCM-Metamodells kann einem Server nur ein lineares Leistungsaufnahme-Modell hinzugefügt werden. So sind auch Modelle mit ei-ner Polynomfunktion denkbar. Ein solches Modell liefert in der Arbeit von Rivoire/Ran-ganathan/Kozyrakis (2008) gute Vorhersageergebnisse für die Leistungsaufnahme eines Servers. Ein Ressourcen-Profil auf Basis von PCM sollte deshalb nicht die Art der möglichen Leistungsaufnahme-Modelle einschränken. Daher ist eine Erweiterung der bisherigen Imple-mentierung des Leistungsaufnahme-Modells notwendig.

Im Zuge dessen wäre es auch erforderlich, dass das PCM-Metamodell um weitere Hardware-ressourcen ergänzt wird. In der aktuellen Version kann nur die CPU und die HDD eines Servers modelliert und simuliert werden. Damit können die Leistungsaufnahme-Modelle auch nur diese beiden Ressourcen berücksichtigen. Aber wie die Ergebnisse aus der in dieser Arbeit durchge-führte Evaluation vermuten lassen, hat auch der Zugriff auf den RAM eine gewisse Auswirkung auf die Leistungsaufnahme des Servers. Daher wäre eine Erweiterung von PCM um die Mög-lichkeit zur Abbildung und Simulation des RAMs wünschenswert.

Die Evaluation in dieser Arbeit hat auf Grund des eingesetzten Modellgenerierungsverfahrens nur die CPU der Server abgebildet. Daher hat auch das Leistungsaufnahme-Modell nur die CPU berücksichtigt. Um die Eignung eines Ressourcen-Profils auf Basis von PCM hinsichtlich der Präzision bei der Vorhersage des Energieverbrauchs umfassender zu evaluieren, sollten in einer zukünftigen Arbeit weitere Hardwareressourcen in das Modell aufgenommen werden.

Durch die Aufnahme weiterer Hardwareressourcen könnte auch die Skalierung der Leistungs-aufnahme über Benchmark-Ergebnisse breiter evaluiert werden. In dieser Arbeit wurde nur die Verarbeitungsgeschwindigkeit einer CPU über den SPEC CPU2006 Benchmark zwischen zwei Servern angepasst. So müsste analysiert werden, ob auch die Verarbeitungsgeschwindigkeit der HDD über geeignete Benchmarks so angepasst werden kann, dass die späteren Simulationser-gebnisse mit ausreichender Präzision die Messergebnisse wiederspiegeln.

Weiterer Forschungsaufwand müsste auch in die Abbildung des Energiebedarfs von Netzwerk-komponenten gelegt werden. So müsste untersucht werden, ob der Energiebedarf der Netz-werkkomponenten auch in Abhängigkeit zu deren Auslastung modelliert werden kann oder ob

84

dort andere Faktoren eine Rolle spielen. In Folge dessen müsste auch ein praktikables Verfah-ren zur Generierung eines Leistungsaufnahme-Modells für eine Netzwerkkomponente konzi-piert werden. Dann könnte auch deren Energieverbrauch auf Basis eines Ressourcen-Profils analysiert werden.

Bisher konzentriert sich das Ressourcen-Profil auf die Prognose des Energiebedarfs der Hard-wareserver. Der Energieverbrauch eines Rechenzentrums besteht nicht nur aus dem direkten Verbrauch der Server. So steuert auch die aktive Kühlung des Rechenzentrums einen großen Anteil am Gesamtenergieverbrauch bei (Greenberg et al. 2008, 68). Ein Rechenzentrum be-treibt in der Regel nicht nur eine Anwendung, sondern mehrere. Daher muss weiter erforscht werden, wie dieser indirekte Energieverbrauch auf eine einzelne Anwendung angerechnet wer-den kann, um diesen in einem Ressourcen-Profil zu berücksichtigen.

Ist die Abbildung des Energiebedarfs in einem Ressourcen-Profil ausreichend erforscht, wäre ein weiterer möglicher Schritt die Konzeption von Energieeffizienzklassen für Unternehmens-anwendung. Solche Kennzeichen existieren z.B. bereits für Kühlschränke oder Automobile. Im Rahmen dieser Arbeit wurde dazu ein Interview mit Dr. Hans-Joachim Popp geführt. Dr. Popp ist Chief Information Officer (CIO) beim Deutschen Zentrum für Luft- und Raumfahrt (DLR) und Jury-Vorsitzender beim GreenIT Best Practice Award (GreenIT BB 2013). Dr. Popp würde Energieeffizienzklassen begrüßen, denn durch effizientere Software ließe sich viel Energie in Rechenzentren einsparen. Solche Energieeffizienzklassen könnten dann auch als Abnahmekri-terium für neue Anwendungen definiert werden. Damit solche Energieeffizienzklassen breite Akzeptanz finden, muss aber noch weitere Forschungsarbeit in dessen Konzeption investiert werden.

85

Literaturverzeichnis

Balsamo, S.; Di Marco, A.; Inverardi, P.; Simeoni, M. (2004): Model-Based Performance Prediction in Software Development: A Survey. In: IEEE Transactions on Software Engineering, Vol. 30 (2004) Nr. 5, S. 295-310.

Bause, F. (1993): Queueing Petri Nets - A Formalism for the Combined Qualitative and Quantitative Analysis of Systems. Proceedings of the 5th International Workshop on Petri Nets and Performance Models, Toulouse, Frankreich, S. 14-23.

Bause, F.; Buchholz, P.; Kemper, P. (1995): QPN-Tool for the Specification and Analysis of Hierarchically Combined Queueing Petri Nets. In: Quantitative Evaluation of Computing and Communication Systems. Hrsg. Springer, 1995, S. 224-238.

Bazan, P.; Bolch, G.; German, R. (2006): WinPEPSY-QNS - Performance Evaluation and Prediction System for Queueing Networks. 13th International GI/ITG Conference on "Measuring, Modelling and Evaluation of Computer and Communication Systems" (MMB), Nürnberg, Deutschland.

BDEW (2013): Bundesverband der Energie- und Wasserwirtschaft e.V.: Erneuerbare Energien und das EEG - Zahlen, Fakten, Grafiken (2013). http://www.bdew.de/internet.nsf/id/17DF3FA36BF264EBC1257B0A003EE8B8/$file/Energieinfo_EE-und-das-EEG-Januar-2013.pdf, zugegriffen am 30.12.2013.

Becker, S. (2008): Coupled Model Transformations for QoS Enabled Component-Based Software Design. Dissertation, Oldenburg 2008.

Becker, S.; Koziolek, H.; Reussner, R. (2009): The Palladio component model for model-driven performance prediction. In: Journal of Systems and Software, Vol. 82 (2009) Nr. 1, S. 3-22.

Begin, C. (2013): iBATIS JPetStore. http://sourceforge.net/projects/ibatisjpetstore/, zugegriffen am 09.12.2013.

Beloglazov, A. (2012): cpu-load-generator – a tool for generating a set of subsequent CPU utilization levels. https://github.com/beloglazov/cpu-load-generator, zugegriffen am 29.12.2013.

Bertoli, M.; Casale, G.; Serazzi, G. (2009a): JMT - Performance Engineering Tools for System Modeling. In: ACM SIGMETRICS Performance Evaluation Review, Vol. 36 (2009a) Nr. 4, S. 10-15.

Bertoli, M.; Casale, G.; Serazzi, G. (2009b): User-friendly Approach to Capacity Planning Studies with Java Modelling Tools. Proceedings of the 2nd International Conference on Simulation Tools and Techniques. Rom, Italien.

BlackBerry (2013): Performance Calculator - BlackBerry Enterprise Service 10. http://docs.blackberry.com/en/admin/subcategories/?userType=2&category=BlackBerry+Enterprise+Service+10&subCategory=BlackBerry+Enterprise+Service+10, zugegriffen am 04.01.2014.

86

Bögelsack, A. (2012): Performance und Skalierung von SAP ERP Systemen in virtualisierten Umgebungen, Gabler Verlag, Wiesbaden 2012.

Brandl, D.-W.-I.R.; Bichler, M.; Ströbel, M. (2007): Cost accounting for shared IT infrastructures. In: Wirtschaftsinformatik, Vol. 49 (2007) Nr. 2, S. 83-94.

Brosig, F.; Huber, N.; Kounev, S. (2011): Automated Extraction of Architecture-Level Performance Models of Distributed Component-Based Systems. 26th IEEE/ACM International Conference on Automated Software Engineering (ASE), Lawrence, Kansas, USA, S. 183-192.

Brunnert, A.; Danciu, A.; Vögele, C.; Tertilt, D.; Krcmar, H. (2013): Integrating the Palladio-Bench into the Software Development Process of a SOA Project. Proceedings of the Symposium on Software Performance: Joint Kieker/Palladio Days 2013, Karlsruhe, Deutschland, S. 30-38.

Brunnert, A.; Vögele, C. (2012): Seminar: Techniken und Methoden des Software Performance Managements, München, Deutschland.

Brunnert, A.; Vögele, C.; Krcmar, H. (2013): Automatic Performance Model Generation for Java Enterprise Edition (EE) Applications. In: Computer Performance Engineering. Hrsg. Springer, 2013, S. 74-88.

Capra, E.; Formenti, G.; Francalanci, C.; Gallazzi, S. (2010): The Impact of MIS Software on IT Energy Consumption. Proceedings of the 18th European Conference on Information Systems Pretoria, Südafrika.

Carraway, D. (2013): lookbusy - a synthetic load generator. http://www.devin.com/lookbusy/, zugegriffen am 24.12.2013.

Cook, D.R.; Dudar, E.; Shallahamer, C.A. (2001): Quickly Performing Low Confidence Capacity Predictions Using Ratio Modeling. Proceedings of the Computer Measurement Group's 2001 International Conference.

Cortellessa, V.; Di Marco, A.; Inverardi, P. (2011): Model-Based Software Performance Analysis, Springer 2011.

D'Ambrogio, A. (2005): A Model Transformation Framework for the Automated Building of Performance Models from UML Models. Proceedings of the 5th International Workshop on Software and Performance, Palma, Spanien, S. 75-86.

DeMichiel, L.; Shannon, B. (2013): Java EE Platform Specification. https://java.net/projects/javaee-spec/pages/Home, zugegriffen am 10.12.2013.

Eclipse (2013): Eclipse Platform Overview. http://www.eclipse.org/platform/overview.php, zugegriffen am 10.12.2013.

Economou, D.; Rivoire, S.; Kozyrakis, C.; Ranganathan, P. (2006): Full-System Power Analysis and Modeling for Server Environments. Workshop on Modeling Benchmarking and Simulation (MOBS), Boston, Massachusetts, USA.

87

Faban (2013): Faban - Open Source Performance and Load Testing Tool. http://faban.org/, zugegriffen am 26.12.2013.

Fan, X.; Weber, W.-D.; Barroso, L.A. (2007): Power Provisioning for a Warehouse-sized Computer. Proceedings of the International Symposium on Computer Architecture (ISCA), San Diego, Kalifornien, USA, S. 13-23.

Franks, G.; Hubbard, A.; Majumdar, S.; Neilson, J.; Petriu, D.; Rolia, J.; Woodside, M. (1995): A toolset for performance engineering and software design of client-server systems. In: Performance Evaluation, Vol. 24 (1995) Nr. 1, S. 117-136.

Franks, G.; Maly, P.; Woodside, M.; Petriu, D.; Hubbard, A.; Mroz, M. (2013): Layered Queueing Network Solver and Simulator User Manual. http://www.sce.carleton.ca/rads/lqns/LQNSUserMan-jan13.pdf, zugegriffen am 27.11.2013.

Futuremark (2013): PCMark 8. http://www.futuremark.com/benchmarks/pcmark8, zugegriffen am 07.01.2014.

Godard, S. (2013): sysstat - System performance tools for the Linux operating system. https://github.com/sysstat/sysstat, zugegriffen am 24.12.2013.

Gradl, S. (2012): Performance-Modellierung und Simulation eines SAP-ERP-Systems. Dissertation, München, Deutschland 2012.

Greenberg, A.; Hamilton, J.; Maltz, D.A.; Patel, P. (2008): The cost of a Cloud: Research Problems in Data Center Networks. In: ACM SIGCOMM Computer Communication Review, Vol. 39 (2008) Nr. 1, S. 68-73.

GreenIT BB (2013): GreenIT Best Practice Award. http://www.greenit-bb.de/, zugegriffen am 07.01.2013.

Gu, G.P.; Petriu, D.C. (2002): XSLT transformation from UML models to LQN performance models. Proceedings of the 3rd International Workshop on Software and Performance, Rom, Italien, S. 227-234.

Gu, G.P.; Petriu, D.C. (2005): From UML to LQN by XML algebra-based model transformations. Proceedings of the 5th International Workshop on Software and Performance, Palma, Spanien, S. 99-110.

Hansen, H.R.; Neumann, G. (2001): Wirtschaftsinformatik 1 - Grundlagen und Anwendungen. (8. Aufl.), Lucius & Lucius, Stuttgart 2001.

Henning, J.L. (2006): SPEC CPU2006 Benchmark Descriptions. In: ACM SIGARCH Computer Architecture News, Vol. 34 (2006) Nr. 4, S. 1-17.

Hirel, C.; Sahner, R.; Zang, X.; Trivedi, K. (2000): Reliability and performability modeling using SHARPE 2000. In: Computer Performance Evaluation. Modelling Techniques and Tools. Hrsg. Springer, 2000, S. 345-349.

Hlynka, M. (2013): List of Queueing Theory Software. http://web2.uwindsor.ca/math/hlynka/qsoft.html, zugegriffen am 27.11.2013.

88

Hyperic (2013): Hyperic SIGAR API. http://www.hyperic.com/products/sigar, zugegriffen am 29.12.2013.

Intel (2013): Intelligent Platform Management Interface. http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html, zugegriffen am 24.12.2013.

Kirschnick, M. (1994): The Performance Evaluation and Prediction SYstem for Queueing NetworkS - PEPSY-QNS. Technical Report TR-I4-94-18, Universität Erlangen-Nürnberg, Deutschland.

Kounev, S. (2006): Performance Modeling and Evaluation of Distributed Component-Based Systems Using Queueing Petri Nets. In: IEEE Transactions on Software Engineering, Vol. 32 (2006) Nr. 7, S. 486-502.

Kounev, S.; Bender, K.; Brosig, F.; Huber, N.; Okamoto, R. (2011): Automated Simulation-Based Capacity Planning for Enterprise Data Fabrics. Proceedings of the 4th International ICST Conference on Simulation Tools and Techniques, Barcelona, Spanien, S. 27-36.

Kounev, S.; Buchmann, A. (2003a): Performance Modeling and Evaluation of Large-scale J2EE Applications. International Conference of the Computer Measurement Group (CMG) on Resource Management and Performance Evaluation of Enterprise Computing Systems, Dallas, Texas, USA, S. 273-283.

Kounev, S.; Buchmann, A. (2003b): Performance Modelling of Distributed E-Business Applications using Queuing Petri Nets. IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) Austin, Texas, USA, S. 143-155.

Kounev, S.; Dutz, C. (2009): QPME: A Performance Modeling Tool Based on Queueing Petri Nets. In: ACM SIGMETRICS Performance Evaluation Review, Vol. 36 (2009) Nr. 4, S. 46-51.

Kounev, S.; Dutz, C.; Buchmann, A. (2006): QPME - Queueing Petri Net Modeling Environment. Third International Conference on Quantitative Evaluation of Systems (QEST), S. 115-116.

Kounev, S.; Spinner, S.; Meier, P. (2010): QPME 2.0 - A Tool for Stochastic Modeling and Analysis Using Queueing Petri Nets. In: From Active Data Management to Event-Based Systems and More. Hrsg. Springer, 2010, S. 293-311.

Koziolek, H. (2010): Performance Evaluation of Component-based Software Systems: A Survey. In: Performance Evaluation, Vol. 67 (2010) Nr. 8, S. 634-658.

Li, H.; Casale, G.; Ellahi, T. (2010): SLA-driven Planning and Optimization of Enterprise applications. Proceedings of the First Joint WOSP/SIPEW International Conference on Performance Engineering, San Jose, Kalifornien, USA, S. 117-128.

89

Liferay (2013): Liferay Portal Performance - Benchmark Study of Liferay PortaL 6.1 Enterprise Edition. http://www.liferay.com/documentation/additional-resources/whitepapers, zugegriffen am 05.12.2013.

Maly, P. (2004): Description of the LQN XML Schema. http://www.sce.carleton.ca/rads/lqns/lqn-documentation/schema/, zugegriffen am 27.11.2013.

Menascé, D.A.; Almeida, V.A.F. (2002): Capacity Planning for Web Services - Metrics, Models, and Methods, Prentice Hall, Upper Saddle River, New Jersey, USA 2002.

Menascé, D.A.; Almeida, V.A.F.; Dowdy, L.W.; Dowdy, L. (2004): Performance by Design: Computer Capacity Planning by Example, Prentice Hall Professional, Upper Saddle River, New Jersey, USA 2004.

Merkle, P.; Henss, J. (2011): EVENTSIM - An Event-driven Palladio Software Architecture Simulator. Palladio Days 2011 Proceedings, Karlsruhe, Deutschland, S. 15-22.

Microsoft (2013): Lync Server 2013 Capacity Calculator. http://www.microsoft.com/en-us/download/details.aspx?id=36828, zugegriffen am 07.12.2013.

Missbach, M.; Hoffmann, U. (2000): SAP Hardware Solutions: Servers, Storage, and Networking for MySAP. com, Prentice Hall 2000.

Oracle (2008): Oracle® WebLogic Portal - Capacity Planning Guide. http://docs.oracle.com/cd/E13155_01/wlp/docs103/capacityplanning/capacityplanning.html, zugegriffen am 05.12.2013.

Peffers, K.; Tuunanen, T.; Gengler, C.E.; Rossi, M.; Hui, W.; Virtanen, V.; Bragge, J. (2006): THE DESIGN SCIENCE RESEARCH PROCESS: A MODEL FOR PRODUCING AND PRESENTING INFORMATION SYSTEMS RESEARCH. Proceedings of the first International Conference on Design Science Research in Information Systems and Technology (DESRIST), Claremont, Kalifornien, USA, S. 83-106.

Petriu, D.; Amer, H.; Majumdar, S.; Abdull-Fatah, I. (2000): Using Analytic Models Predicting Middleware Performance. Proceedings of the 2nd International Workshop on Software and Performance, Ottawa, Kanada, S. 189-194.

Petriu, D.B.; Woodside, M. (2004): A Metamodel for Generating Performance Models from UML Designs. In: << UML>> 2004-The Unified Modeling Language. Modelling Languages and Applications. Hrsg. Springer, 2004, S. 41-53.

Petriu, D.C.; Shen, H. (2002): Applying the UML Performance Profile: Graph Grammar-Based Derivation of LQN Models from UML Specifications. In: Computer Performance Evaluation: Modelling Techniques and Tools. Hrsg. Springer, 2002, S. 159-177.

Qin, M.; Lee, R.; El Rayess, A.; Vetland, V.; Rolia, J. (1996): Automatic Generation of Performance Models for Distributed Application Systems. Proceedings of the 1996 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Kanada.

Reussner, R.; Becker, S.; Happe, J.; Koziolek, H.; Krogmann, K.; Kuperberg, M. (2011): The Palladio Component Model. Technical Report.

90

Rivoire, S.; Ranganathan, P.; Kozyrakis, C. (2008): A Comparison of High-Level Full-System Power Models. HotPower  ’08:  Workshop  on  Power  Aware  Computing  and  Systems, San Diego, Kalifornien, USA.

Rivoire, S.; Shah, M.A.; Ranganatban, P.; Kozyrakis, C.; Meza, J. (2007): Models and Metrics to Enable Energy-Efficiency Optimizations. In: IEEE Computer, Vol. 40 (2007) Nr. 12, S. 39-48.

Rolia, J.; Casale, G.; Krishnamurthy, D.; Dawson, S.; Kraft, S. (2009): Predictive modelling of SAP ERP Applications: Challenges and Solutions. Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools, Pisa, Italien.

Rolia, J.A.; Sevcik, K.C. (1995): The method of layers. In: IEEE Transactions on Software Engineering, Vol. 21 (1995) Nr. 8, S. 689-700.

SAP (2013a): SAP - Published Benchmark Results. http://global.sap.com/solutions/benchmark/sd2tier.epx, zugegriffen am 07.12.2013.

SAP (2013b): SAP Quick Sizer. http://service.sap.com/quicksizing, zugegriffen am 07.12.2013.

Schwarzer, B.; Krcmar, H. (2010): Wirtschaftsinformatik - Grundlagen betrieblicher Informationssysteme (Vol. 4) 2010.

Shannon, B. (2006):  Java™  Platform,  Enterprise  Edition  (Java  EE)  Specification, v5.

Smith, C.U. (1990): Performance Engineering of Software Systems (Vol. 1), Addison-Wesley, Reading, Massachusetts 1990.

Smith, C.U.; Williams, L.G. (1997): Performance Engineering Evaluation of Object-Oriented  Systems  with  SPE•ED™.  In:  Computer Performance Evaluation Modelling Techniques and Tools. Hrsg. Springer, 1997, S. 135-154.

Smith, C.U.; Williams, L.G. (1998): Performance Engineering Evaluation of CORBA-based Distributed  Systems  with  SPE•ED.  In:  Computer Performance Evaluation. Hrsg. Springer, 1998, S. 321-335.

Smith, C.U.; Williams, L.G. (2000): Building Responsive and Scalable Web Applications. Proceedings of the 26th International Computer Measurement Group Conference, Orlando, Florida, USA, S. 127-138.

SPEC (2001): The SPECjAppServer2001 Benchmark. http://www.spec.org/jAppServer2001/, zugegriffen am 04.12.2013.

SPEC (2002): The SPECjAppServer2002 Benchmark. http://www.spec.org/jAppServer2002/, zugegriffen am 27.11.2013.

SPEC (2004): The SPECjAppServer2004 Benchmark. http://www.spec.org/jAppServer2004/, zugegriffen am 05.12.2013.

91

SPEC (2006a): SPEC CPU2006. http://www.spec.org/cpu2006/, zugegriffen am 09.12.2013.

SPEC (2006b): SPEC CPU2006 Results. http://www.spec.org/cpu2006/results/, zugegriffen am 07.01.2014.

SPEC (2010a): The SPECjEnterprise2010 Benchmark. http://www.spec.org/jEnterprise2010/, zugegriffen am 27.11.2013.

SPEC (2010b): SPECjEnterprise2010 Design Document. http://www.spec.org/jEnterprise2010/docs/DesignDocumentation.html, zugegriffen am 26.12.2013.

Spinner, S.; Kounev, S.; Meier, P. (2012): Stochastic Modeling and Analysis Using QPME: Queueing Petri Net Modeling Environment v2. 0. In: Application and Theory of Petri Nets. Hrsg. Springer, 2012, S. 388-397.

Su, L.; Chow, K.; Shiv, K.; Jha, A. (2005): A Comparison of SPECjAppServer2002 and SPECjAppServer2004. Proceedings of the 8th Workshop on Computer Architecture Evaluation Using Commercial Workloads, San Francisco, Kalifornien, USA.

Sun Microsystems (2005): The J2EE 1.4 Tutorial. http://docs.oracle.com/javaee/1.4/tutorial/doc/index.html, zugegriffen am 09.12.2013.

Szyperski, C. (2002): Component Software: Beyond Object-oriented Programming, Pearson Education 2002.

Tiwari, N.; Kashyap, T. (2011): Performance Analysis of a Website in Production Using Modeling and Simulation - Case Study. Proceedings of the 4th International ICST Conference on Simulation Tools and Techniques, Barcelona, Spanien, S. 499-505.

Tiwari, N.; Mynampati, P. (2006): Experiences of using LQN and QPN tools for performance modeling of a J2EE Application. Proceedings of the Computer Measurement Group's 2006 International Conference, Reno, Nevada, USA, S. 537-548.

Tiwari, N.; Nair, K.C. (2010): Performance Extrapolation that Uses Industry Benchmarks with Performance Models. 2010 International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS), Ottawa, Kanada, S. 301-305.

Verax Systems (2013): Verax IPMI Java Library. http://www.veraxsystems.com/en/products/free-ipmi-library-java, zugegriffen am 29.12.2013.

VMware (2013): vFabric GemFire. http://www.vmware.com/products/vfabric-gemfire, zugegriffen am 05.12.2013.

Woodside, M. (2013): Tutorial Introduction to Layered Modeling of Software Performance. http://www.sce.carleton.ca/rads/lqns/lqn-documentation/tutorialh.pdf, zugegriffen am 27.11.2013.

Woodside, M.; Franks, G.; Petriu, D.C. (2007): The future of software performance engineering. Workshop on the Future of Software Engineering (FOSE'07), Minneapolis, Minnesota, USA, S. 171-187.

92

Woodside, M.; Neilson, J.E.; Petriu, D.C.; Majumdar, S. (1995): The stochastic rendezvous network model for performance of synchronous client-server-like distributed software. In: IEEE Transactions on Computers, Vol. 44 (1995) Nr. 1, S. 20-34.

Wu, X.; Woodside, M. (2004): Performance Modeling from Software Components. In: ACM SIGSOFT Software Engineering Notes, Vol. 29 (2004) Nr. 1, S. 290-301.

Xu, J.; Oufimtsev, A.; Woodside, M.; Murphy, L. (2005): Performance Modeling and Prediction of Enterprise JavaBeans with Layered Queuing Network Templates. In: ACM SIGSOFT Software Engineering Notes, Vol. 31 (2005) Nr. 2.

93

Anhang

Anhang 1: SPEC CPU2006 Benchmark-Ergebnis des AMD-basierten Servers Quelle: Screenshot des SPEC CPU2006 Benchmark-Ergebnisses (SPEC 2006a)

94

Anhang 2: SPEC CPU2006 Benchmark-Ergebnis des Intel-basierten Servers Quelle: Screenshot des SPEC CPU2006 Benchmark-Ergebnisses (SPEC 2006a)