Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten Performance-Modells

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Informatik Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten Performance-Modells Stefan Neubig

2 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Informatik Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten Performance-Modells Evaluating the resource estimation of an exemplary enterprise application based on an automatically generated performance model Bearbeiter: Stefan Neubig Aufgabensteller: Prof. Dr. Helmut Krcmar Betreuer: Andreas Brunnert Abgabedatum: 17. Februar 2014

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

4 Zusammenfassung Neben funktionalen Anforderungen spielen nichtfunktionale Anforderungen von Software eine tragende Rolle. Unter dem Begriff der Performance-Anforderungen werden Anforderungen gesammelt, die beispielsweise Vorgaben bezüglich zu erreichender Antwortzeiten machen. Um solche Vorgaben zu erfüllen, sind ausreichend Ressourcen notwendig. Im Zuge der Kapazitätsplanung wird daher versucht abzuschätzen, wie viele Ressourcen für die Erreichung spezifizierter Ziele notwendig sind. Eine solche Abschätzung kann durch Performance- Modelle unterstützt werden. Performance-Modelle repräsentieren das Performance-Verhalten eines Anwendungssystems und ermöglichen es, Aussagen über dasselbe in Abhängigkeit ihrer Parametrisierung, beispielsweise die Nutzeranzahl oder verfügbare Ressourcen, zu treffen. Neben klassischen Performance Modellen wie Queueing Networks oder Layered Queueing Networks existieren spezielle Performance-Modelle für komponentenbasierte Software. Da die manuelle Modellierung eines Systems mit Hilfe eines Performance-Modells aufwändig ist, geht der Trend zu einer automatischen Generierung solcher Performance-Modelle. Der von Brunnert/Vögele/Krcmar (2013) vorgestellte Ansatz ermöglicht die automatische Generierung eines Performance-Modells für Java Enterprise Edition Anwendungen, basierend auf dem Palladio Component Model. Dieser Ansatz wird bezüglich der Qualität seiner getroffenen Performance-Vorhersagen unter Variation der Anzahl vorhandener CPU-Kerne evaluiert. Stichworte: Kapazitätsplanung, Performance-Modelle, Komponentenbasierte Software, Modellgenerierung, Java Enterprise Edition, Palladio Component Model. Abstract In addition to functional requirements, nonfunctional requirements play an important role in the software development process. Performance requirements specify, for example, which response times of a software are acceptable. To meet such requirements, an adequate amount of resources is necessary. Within the scope of capacity planning, one tries to estimate how many resources are required to reach the specified goals. Such estimations can be supported by performance models. Performance models represent the software s behavior regarding performance aspects. They allow to make predictions about the future performance behavior of software systems depending on parameterization like the number of users using the system or the amount of available resources. Besides classical performance modeling techniques such as queueing networks or layered queueing networks, special performance models for component based software evolved. Modeling performance manually is complex, therefore the trend is towards automatic generation of performance models. Brunnert/Vögele/Krcmar (2013) introduced an approach to automatically model the performance of Java Enterprise Edition applications using the Palladio Component Model. This work evaluates the approach investigating the quality of predicted performance behavior regarding the variation of CPU cores. Keywords: Capacity Planning, Performance Models, Component Based Software, Model Generation, Java Enterprise Edition, Palladio Component Model. III

5 Inhaltsverzeichnis Zusammenfassung... III Abbildungsverzeichnis... VI Tabellenverzeichnis... VII Formelverzeichnis... VIII Abkürzungsverzeichnis... IX 1 Einleitung Motivation Aufbau der Arbeit Grundlagen Grundbegriffe Component Based Software Performance Engineering Kapazitätsplanung Ansätze der Performance-Modellierung Queueing Networks (QN) Queueing Networks und Execution Graphs Layered Queueing Networks (LQN) UML Profile for Schedulability, Performance and Time (SPT) Palladio Component Model (PCM) Performance-Modellierung komponentenbasierter Systeme Automatisierung der Performance-Modellgenerierung Komponentenbasierte Software mit der Java Enterprise Edition (EE) Komponenten einer Java EE Anwendung Transaktionsbearbeitung in Java EE Anwendungen Instrumentierung Modellgenerierung Bestehende Einschränkungen und zukünftige Erweiterungen Performance-Analyse mit Hilfe geeigneter Metriken Erhebung von Performance-Metriken Definition der zu erhebenden Performance-Metriken Minimierung des Monitoring-Overheads Bedingungen für die Erhebung valider Daten Besonderheit bei der Erhebung von Performance-Metriken für Java IV

6 5.2 Statistische Auswertung von Performance-Metriken Lage- und Streuungsmaße Approximation einer Verteilung Konfidenzintervalle Evaluierung der automatisierten Modellgenerierung SPECjEnterprise2010 als beispielhafte Unternehmensanwendung Aufbau von SPECjEnterprise Modellgenerierung Vergleich-Runs Testumgebung Evaluierung Erhöhung der CPU-Kerne mit konstantem Workload Erhöhung der CPU-Kerne mit variablem Workload Reduktion der CPU-Kerne Schlussfolgerungen Fazit Literaturverzeichnis Anhang V

7 Abbildungsverzeichnis Abbildung 1: SPE-Prozess nach Smith... 5 Abbildung 2: Ressourcen-Server mit vorgeschalteter Queue Abbildung 3: Notation von Queueing Networks Abbildung 4: Notation von Execution Graphs Abbildung 5: Notation von Layered Queueing Networks Abbildung 6: Notation von UML-SPT (Sequenzdiagramm) Abbildung 7: Notation von UML-SPT (Deployment-Diagramm) Abbildung 8: Notation des Palladio Component Models (Repository) Abbildung 9: Notation des Palladio Component Models (RDSEFF) Abbildung 10: Notation des Palladio Component Models (System) Abbildung 11: Notation des Palladio Component Models (Usage) Abbildung 12: Architektur einer typischen Java Enterprise Anwendung Abbildung 13: Lagemaße gerader und schiefer Verteilungen Abbildung 14: Box-Plot zum Vergleich der Antwortzeiten zweier Systeme Abbildung 15: Beispielhafter Verlauf der CPU-Auslastung Abbildung 16: Approximative Darstellung eines Histogramms Abbildung 17: Architektur der Order Domain von SPECjEnterprise Abbildung 18: Aufbau der Testumgebung VI

8 Tabellenverzeichnis Tabelle 1: Parametrisierung der Elemente eines Queueing Network Tabelle 2: Overhead-Matrix zur Umlage von Software- auf Hardware-Ressourcen Tabelle 3: Umlage des Bedarfs der Software-Ressourcen eines Execution Graphs Tabelle 4: Experiment 1, Vergleich der Antwortzeit (ms). Validierung Tabelle 5: Experiment 1, Vergleich der CPU-Auslastung. Validierung Tabelle 6: Experiment 1, Vergleich des Durchsatzes/Min. Validierung Tabelle 7: Experiment 1, Vergleich der Antwortzeit (ms). Erhöhung um zwei Kerne Tabelle 8: Experiment 1, Vergleich der CPU-Auslastung. Erhöhung um zwei Kerne Tabelle 9: Experiment 1, Vergleich des Durchsatzes/Min. Erhöhung um zwei Kerne Tabelle 10: Experiment 1, Vergleich der Antwortzeit (ms). Erhöhung um vier Kerne Tabelle 11: Experiment 1, Vergleich der CPU-Auslastung. Erhöhung um vier Kerne Tabelle 12: Experiment 1, Vergleich des Durchsatzes/Min. Erhöhung um vier Kerne Tabelle 13: Experiment 2, Vergleich der Antwortzeit (ms). Validierung Tabelle 14: Experiment 2, Vergleich der CPU-Auslastung. Validierung Tabelle 15: Experiment 2, Vergleich des Durchsatzes/Min. Validierung Tabelle 16: Experiment 2, Vergleich der Antwortzeit (ms). Erhöhung um zwei Kerne Tabelle 17: Experiment 2, Vergleich der CPU-Auslastung. Erhöhung um zwei Kerne Tabelle 18: Experiment 2, Vergleich des Durchsatzes/Min. Erhöhung um zwei Kerne Tabelle 19: Experiment 2, Vergleich der Antwortzeit (ms). Erhöhung um vier Kerne Tabelle 20: Experiment 2, Vergleich der CPU-Auslastung. Erhöhung um vier Kerne Tabelle 21: Experiment 2, Vergleich des Durchsatzes/Min. Erhöhung um vier Kerne Tabelle 22: Experiment 3, Vergleich der Antwortzeit (ms). Validierung Tabelle 23: Experiment 3, Vergleich der CPU-Auslastung. Validierung Tabelle 24: Experiment 3, Vergleich des Durchsatzes/Min. Validierung Tabelle 25: Experiment 3, Vergleich der Antwortzeit (ms). Reduktion um zwei Kerne Tabelle 26: Experiment 3, Vergleich der CPU-Auslastung. Reduktion um zwei Kerne Tabelle 27: Experiment 3, Vergleich des Durchsatzes/Min. Reduktion um zwei Kerne Tabelle 28: Experiment 3, Vergleich der Antwortzeit (ms). Reduktion um vier Kerne Tabelle 29: Experiment 3, Vergleich der CPU-Auslastung. Reduktion um vier Kerne Tabelle 30: Experiment 3, Vergleich des Durchsatzes/Min. Reduktion um vier Kerne VII

9 Formelverzeichnis Formel 1: Utilization Law... 9 Formel 2: Analytische Lösung eines Execution Graphs Formel 3: Berechnung der durchschnittlichen CPU-Auslastung Formel 4: Stichprobenmittel Formel 5: Spannweite Formel 6: Standardabweichung Formel 7: Stichprobenvarianz Formel 8: Alternative Formel der Stichprobenvarianz Formel 9: Variationskoeffizient (COV) Formel 10: Schiefe einer Verteilung Formel 11: Stichprobenmedian Formel 12: p-quantil Formel 13: Interquartilsabstand (IQR) Formel 14: Ende des oberen Ausläufers im Box-Plot Formel 15: Ende des unteren Ausläufers im Box-Plot Formel 16: Bowley-Koeffizient Formel 17: Integral der Dichtefunktion Formel 18: Konfidenzintervall VIII

10 Abkürzungsverzeichnis CBSE COV CPU DBMS EJB EQN FCFS HTML HTTP I/O ID Java EE JIT JMS JMT JSP JVM LQN MARTE MVA PCM PQNF QN RAM RDSEFF RMI SEFF SMART SPE SPTF SQL SUT UML UML-SPT VM Component Based Software Engineering Coefficient of Variation Central Processing Unit Database Management System Enterprise Java Bean Extended Queueing Network First Come First Served Hypertext Markup Language Hypertext Transfer Protocol Input/Output Identification Java Enterprise Edition Just-In-Time Java Message Service Java Modeling Tools Java Server Pages Java Virtual Machine Layered Queueing Network Modeling and Analysis of Real Time and Embedded Systems Mean Value Analysis Palladio Component Model Product-Form Queueing Network Queueing Network Random Access Memory Resource Demanding Service Effect Specification Remote Method Invocation Service Effect Specification Specific, Measurable, Attainable, Realizable, Traceable Software Performance Management Shortest Processing Time First Structured Modeling Language System Under Test Unified Modeling Language UML Profile for Schedulability, Performance and Time Virtual Machine IX

11 1 Einleitung Für eine positive User Experience spielen die nichtfunktionalen Anforderungen an eine Software eine tragende Rolle. Nichtfunktionale Anforderungen sind solche, die im Gegensatz zu funktionalen Anforderungen auf Qualitätseigenschaften des fertigen Systems abzielen. Eine wichtige Qualitätseigenschaft ist beispielsweise die Zeit, mit der ein Softwaresystem auf Benutzereingaben reagiert. Der Begriff der Performance einer Software beschreibt das Verhalten einer Software oder eines Systems hinsichtlich seiner Ressourcenauslastung, seiner Reaktionsgeschwindigkeit (Antwortzeit) und seines Durchsatzes (Smith 2007). 1.1 Motivation Um Performance-Anforderungen genügen zu können, müssen eingesetzte Software und eingesetzte Hardware im Einklang stehen, es ist erforderlich, dass die verfügbaren Hardware- Ressourcen den Bedarf der Software unter der angedachten Systemnutzung ausreichend decken können. Die notwendigen Hardware-Ressourcen müssen daher frühzeitig abgeschätzt werden können. Um dies zu erreichen, können bereits während des Entwicklungsprozesses einer Software regelmäßige Last- und Performancetests durchgeführt werden (Kounev 2005). Da repräsentative Last- und Performancetests jedoch aufwändig sind (Kounev 2005), sollten diese auf ein Minimum reduziert werden. Eine Alternative bieten daher Performance-Modelle an, mit solchen lassen sich veränderte Annahmen bezüglich des Workloads oder vorhandener Hardware-Ressourcen unter zumeist geringerem Gesamtaufwand simulieren. Ein Nachteil der Performance-Analyse mit Hilfe von Modellen ist der vorhergehende Aufwand der Erstellung eines solchen. Dies ist häufig aufwändig (Woodside/Franks/Petriu 2007) und benötigt technisches Fachwissen. Die fortiss Performance Group (fortiss 2012) beschäftigt sich daher mit der Entwicklung automatisierter Verfahren, die die automatische Generierung eines Performance-Modells aus gesammelten Performance-Daten über die Ausführung einer Java Enterprise Edition (EE) Anwendung ermöglichen. Die vorliegende Arbeit möchte diesen Ansatz unterstützen und gibt einen Überblick über vorhandene Techniken zur Performance-Modellierung. Ein am fortiss entwickelter Ansatz, basierend auf dem Palladio Component Model (Reussner et al. 2011) wird bezüglich seiner Nutzung zur Ressourcenabschätzung der Anzahl notwendiger CPU-Kerne evaluiert. Konkret beschäftigt sich die vorliegende Arbeit mit folgenden Forschungsfragen. Zunächst wird geklärt, welche Ansätze es gibt, um die Kapazitätsplanung komponentenbasierter Systeme durch Performance-Modelle zu unterstützen. Anschließend wird geklärt, wie der am fortiss entwickelte Ansatz für eine beispielhafte Unternehmensanwendung genutzt werden kann, um ein Performance-Modell zu erzeugen. Abschließend wird evaluiert, wie gut das entwickelte Modell für die Abschätzung von Hardware-Ressourcen verwendet werden kann. 1

12 1.2 Aufbau der Arbeit Die Arbeit ist in sieben Kapitel gegliedert, jedes Kapitel besteht aus einem oder mehreren Abschnitten. Kapitel 1 gibt eine kurze thematische Einleitung und stellt die behandelten Forschungsfragen vor. Kapitel 2 geht auf allgemeine Grundlagen der Performance-Modellierung ein. Es werden zunächst wichtige Grundbegriffe erläutert, das sogenannte Software Performance Engineering wird vorgestellt und in den Kontext komponentenbasierter Systeme gesetzt. Der Begriff der Kapazitätsplanung wird geklärt. Außerdem werden unterschiedliche Ansätze vorgestellt, die in der Praxis zur Modellierung der Performance eines Systems eingesetzt werden. Kapitel 3 stellt die in Kapitel 2 ermittelten Ansätze kurz gegenüber und setzt sie in den Kontext komponentenbasierter Systeme. Kapitel 4 stellt den am fortiss entwickelten Ansatz zur automatisierten Performance- Modellgenerierung vor. Da dieser Ansatz zunächst auf Java EE Anwendungen beschränkt ist, stellt Kapitel 4 zunächst einen kurzen Überblick über die Java EE Welt zur Verfügung. Anschließend wird sowohl die notwendige Datensammlung als auch die eigentliche Modellgenerierung besprochen. Bestehende Einschränkungen des Ansatzes werden kurz zusammengefasst. Kapitel 5 beschäftigt sich detailliert mit der Performance-Analyse eines mit Hilfe geeigneter Metriken. Dazu wird darauf eingegangen, wie Performance-Metriken über vorhandene Systeme erhoben, also gemessen werden können. Dazu werden wichtige Richtlinien vorgestellt, die für die Sammlung nutzbarer Daten beachtet werden müssen. Des Weiteren werden unterschiedliche statistische Maßzahlen vorgestellt, mit deren Hilfe Performance-Metriken ausgedrückt werden können. Die Diskussion soll den Leser auch anhand von Beispielen in die Lage versetzen, Entscheidungen bezüglich der zu verwendenden Performance-Metriken zu treffen. In Kapitel 6 wird schließlich der in Kapitel 4 vorgestellte Ansatz unter Beachtung der in Kapitel 5 diskutierten Performance-Metriken evaluiert. Die Evaluierung wird anhand der beispielhaften Unternehmensanwendung SPECjEnterprise2010 (SPEC 2012) durchgeführt. Neben der Anwendung wird das verwendete Testsystem erläutert, die durchgeführte Evaluierung beschäftigt sich Skalierungsbetrachtungen bezüglich Erhöhung und Reduktion der Anzahl genutzter CPU-Kerne. Kapitel 7 schließt die Arbeit in einem kurzen Fazit ab. 2

13 2 Grundlagen Dieses Kapitel fasst die für das Verständnis der nachfolgenden Kapitel notwendigen Grundlagen zusammen und soll dem Leser den Kontext vermitteln, in dem sich diese Arbeit bewegt. Abschnitt 2.1 definiert dabei einige Grundbegriffe, Abschnitt 2.2 geht kurz auf die Prozesse und Methoden des Software Performance Engineering ein. Abschnitt 2.3 setzt sich mit Möglichkeiten der Kapazitätsplanung auseinander und Abschnitt 2.4 stellt schließlich einige geläufige Ansätze der Performance-Modellierung vor. 2.1 Grundbegriffe Die Performance einer Software lässt sich durch ihre Antwortzeit (engl. Response Time), Ressourcenauslastung (engl. Utilization) und Durchsatz (engl. Throughput) definieren (Smith 2007). Die Antwortzeit kann beispielsweise die von Nutzern wahrgenommene Zeit sein, die die Abarbeitung einer Anfrage benötigt. Ressourcenauslastung definiert die zeitliche Auslastung von Hardware-Ressourcen im Verhältnis zur Gesamtzeit, Hardware-Ressourcen können beispielsweise Central Processing Unit (CPU), Random Access Memory (RAM), allgemein Input/Output (I/O), oder spezifischer Netzwerke und Festplatten sein. Durchsatz entspricht der Anzahl an Nutzeranfragen, die pro Zeiteinheit beantwortet werden können. Die Performance eines Systems wird maßgeblich durch - den Workload (Frequenz von Nutzeranfragen), - das Operational Profile (Nutzungsprofil) sowie - dem Ressourcenbedarf der ausgeführten Software beeinflusst (Cortellessa/Di Marco/Inverardi 2011, S. 5; Woodside/Franks/Petriu 2007). Der Workload eines Systems kann offen oder geschlossen sein. Offener Workload bedeutet, dass Benutzer das System betreten, eine Aktion ausführen und es anschließend wieder verlassen. Die Intensität eines offenen Workloads wird deshalb durch die Anzahl der eingehenden Anfragen pro Zeitintervall spezifiziert. Mit geschlossenem Workload werden vor allem interaktive Systeme mit konstanter Nutzerzahl beschrieben (Smith/Williams 2001, S. 147). Bei einem geschlossenen Workload führen die sich im System befindenden Nutzer kontinuierlich neue Aktionen mit einer spezifizierten Wartezeit zwischen einzelnen Aufrufen aus. Die Intensität eines geschlossenen Workloads wird durch die konstante Anzahl an Systemnutzern sowie durch die Think Time (Wartezeit zwischen zwei Nutzeraktionen) definiert (Cortellessa/Di Marco/Inverardi 2011, S. 5). Das Operational Profile ist eine Sammlung von Wahrscheinlichkeiten, mit denen Nutzern bestimmte Aktionen ausführen. Im Kontext der Performance- Modellierung wird das Operational Profile häufig durch Usage Models (Modellierung des Nutzerverhaltens) spezifiziert. Der Ressourcenbedarf einer Software gibt an, welche Hardware-Ressourcen in welcher Menge benötigt werden. Der Ressourcenbedarf des Systems berechnet sich daher durch Summierung des Ressourcenbedarfs der gesamten auf dem System aktiven Software (Cortellessa/Di Marco/Inverardi 2011, S. 5ff.). 3

14 Zu Beginn eines Softwareprojekts werden im Rahmen der Anforderungsanalyse Anforderungen an die zu entwickelnde Software gestellt, Anforderungen können funktional oder nichtfunktional sein. Funktionale Anforderungen spezifizieren die eigentlichen Funktionen, die das fertige Produkt bieten muss, nichtfunktionale Anforderungen spezifizieren Qualitätsmerkmale (Schatten et al. 2010). Anforderungen, welche die angestrebte Performance betreffen, zählen daher zu den nichtfunktionalen Anforderungen. Nichtfunktionale Anforderungen werden in Metriken ausgedrückt, eine Performance-Metrik trifft daher quantitative Aussagen über Antwortzeiten, Ressourcenauslastung und Durchsatz (Jain 1991, S. 33). In Anforderungen werden Rahmenbedingungen festgelegt, die von den Werten der in den Anforderungen benutzten Metriken erfüllt sein müssen. Eine beispielhafte Performance-Anforderung an eine zu entwickelnde Anwendung könnte beispielsweise sein: Die Anwendung soll hinreichend schnell auf Nutzereingaben reagieren. Diese Formulierung ist jedoch ungünstig, da - das gewählte Detaillevel (gesamte Anwendung) zu abstrakt ist, - die gewünschte Geschwindigkeit nicht messbar ist ( hinreichend schnell ) und - letztlich nicht überprüft werden kann, ob die Anforderung erfüllt ist. Als Formulierungshilfe für Anforderungen adaptierten Mannion/Keepence (1995) das aus der Organisationspsychologie bekannte SMART-Akronym an die Anforderungsanalyse des Software Engineerings und setzten die Bedeutung der einzelnen Buchstaben auf Specific, Measurable, Attainable, Realisable und Traceable. Anforderungen müssen demnach - spezifisch sein, d.h. ein angemessenes Detaillevel aufweisen, - messbar sein, d.h. in Zahlen ausgedrückt und auf instrumentierbare Softwarekomponenten beschränkt, - angemessen sein, d.h. Aufwand und Nutzen müssen im Verhältnis stehen, - realisierbar sowie - nachweisbar, d.h. verifizierbar auf ihre Erfüllung sein (Mannion/Keepence 1995). Eine Anforderung, die den SMART-Kriterien nach valide ist, könnte beispielsweise folgendermaßen formuliert werden: Die Antwortzeit der Suchfunktion der Anwendung soll in 90% aller Fälle unter 2 Sekunden liegen. Diese Anforderung ist spezifisch, da mit der Suchfunktion ein hinreichendes Detaillevel spezifiziert wurde, sie ist messbar, angemessen, für die meisten Systeme realisierbar und nachweisbar, d.h. es kann überprüft werden, ob die Anforderung erfüllt wurde oder nicht. Bei der Formulierung einer Anforderung ist es wichtig, die zu beschreibende Metrik auf angemessene Weise auszudrücken. In obigem Beispiel wurde die Rahmenbedingung mit Hilfe eines 90-Perzentils gewählt. Alternative Möglichkeiten wären z.b. Mittelwerte wie arithmetisches Mittel oder Median. Die Verwendung des Maximums ist hingegen eher nicht empfehlenswert, da so ein einzelner Ausreißer bereits zur Nichterfüllung einer Anforderung führt. Hilfestellung zur Auswahl geeigneter Metriken gibt Abschnitt

15 2.2 Component Based Software Performance Engineering Während des Entwicklungszyklus einer Software fokussieren sich viele Entwickler vor allem auf die Erfüllung funktionaler Anforderungen. Nichtfunktionale Anforderungen, insbesondere Performance-Anforderungen, werden häufig erst dann betrachtet, wenn die zu entwickelnde Software kurz vor ihrer Vollendung steht, beispielsweise wenn Performance-Messungen möglich sind. Smith (2007) ist deshalb der Ansicht, dass gute Performance in einem Endprodukt eine stetige Kontrolle der Performance-Anforderungen während des gesamten Entwicklungsprozess erforderlich macht. Unter dem Namen Software Performance Engineering (SPE) führt sie ein Vorgehensmodell ein, das den gesamten Entwicklungsprozess einer Software begleitet und es bereits in frühen Stadien ermöglichen soll, Performancevorhersagen zu treffen und zu validieren (vgl. Abbildung 1). Performance-Ziele des Zyklus definieren Verifikation und Validierung Mögliche Lösung erstellen Bis Lösung im Einklang mit Performance-Zielen Datensammlung Modellierung und Evaluierung Bericht Lösung überarbeiten Lösung akzeptabel Performance-Ziele definieren Performance-Ziele überarbeiten Abbildung 1: SPE-Prozess nach Smith Quelle: Angelehnt an Smith (2007) Der Entwicklungsprozess einer Software ist in mehrere Zyklen aufgeteilt, im SPE werden zu Beginn eines Zyklus Performance-Ziele festgelegt. Daraufhin wird eine mögliche Lösung erstellt, je nach Zyklus beispielsweise eine Softwarearchitektur oder Algorithmen (Smith 2007). Um diese Lösung auf die Erfüllung ihrer Performance-Ziele hin zu prüfen werden Daten erhoben und daraus ein Performance-Modell (vgl. Abschnitt 2.4) generiert. Für die Datenerhebung schlägt Smith (2007) die Erstellung von Szenarien für die typische Softwarenutzung vor, aus denen sich letztendlich Execution Graphs ableiten lassen, welche sich zur Parametri- 5

16 sierung eines Performance-Modells auf Basis von Queueing Networks (QN) eignen (vgl. Abschnitt 2.4.2). Anhand der durch die Analyse des Modells erhaltenen Ergebnisse wird entschieden, ob die definierten Performance-Ziele erreicht wurden. Parallel wird überprüft, ob das erzeugte Modell korrekte Ergebnisse liefert (Verifikation und Validierung). Wurden die Ziele verfehlt, werden entweder Lösung oder Ziele angepasst und der Vorgang wenn nötig wiederholt. Wurden die Ziele erreicht, so beginnt der nächste Zyklus des Entwicklungsprozess (Smith 2007). Woodside/Franks/Petriu (2007) erweitern den Begriff des Software Performance Engineering und definieren ihn als eine Sammlung aller Aktivitäten und Analysen während eines Entwicklungsprozess, die auf die Erfüllung von Performance-Anforderung zielen. Sie diskutieren dabei sowohl messbasierte Ansätze, die erst spät in den Entwicklungszyklus eingreifen und die Messbarkeit fertiger Systemkomponenten voraussetzen, als auch modellbasierte Ansätze, die den Entwicklungsprozess von Anfang an begleiten und mit Hilfe von früh erzeugten Performance-Modellen Schwachstellen in Architektur und Design suchen. Sie plädieren für eine Annäherung der beiden Ansätze, Daten aus Messungen sollen Performance-Modelle validieren und ihre Parametrisierung unterstützen. Die von Smith vorgeschlagene Vorgehensweise zur Implementierung des Prozesses aus Abbildung 1 unter der Nutzung von Execution Graphs mit Queueing Models ist insbesondere für den Entwicklungsprozess komponentenbasierter Software nicht ideal. Unter komponentenbasierter Software versteht man Software, die aus mehreren Softwarekomponenten zu einer Gesamtarchitektur zusammengesetzt wird. Eine Softwarekomponente ist eine in sich geschlossene Einheit, die Schnittstellen nach außen anbietet und in Abhängigkeit zu anderen Komponenten stehen kann, indem sie auf deren Schnittstellen zugreift (Koziolek 2009). Der Entwicklungsprozess komponentenbasierter Software, das Component Based Software Engineering (CBSE), gibt eine klare Rollenverteilung vor: Wie in jedem Software-Projekt kennen Business-Domain-Experten die Anwendungsfälle der zu entwickelnden Software und stellen Anwendungsszenarien zur Verfügung, die für die Anforderungsanalyse notwendig sind, Komponenten-Entwickler entwickeln Komponenten und spezifizieren deren Schnittstellen, verschiedene Komponenten werden in einem Repository verwaltet. Software-Architekten bedienen sich aus dem Repository und setzen verschiedene Komponenten zu einer Gesamtarchitektur zusammen. System-Deployer verteilen die in der Softwarearchitektur verwendeten Komponenten auf vorhandene Hardware-Ressourcen (Becker/Koziolek/Reussner 2009; Koziolek 2009; Schatten et al. 2010). Es entsteht eine modulare Softwarearchitektur, deren Komponenten beliebig durch gleichwertige Komponenten ausgetauscht werden können. Die von Smith (2007) vorgeschlagenen Execution Graphs ignorieren den komponentenorientierten Aufbau der Softwarearchitektur und modellieren stattdessen Szenarien, welche die Nutzung mehrerer Komponenten einschließen können. Tauscht man eine einzelne Softwarekomponente aus, müssen sämtliche Performance-Modelle neu erstellt werden, Wiederverwendung ist somit nicht möglich (Koziolek 2008). Die grundsätzliche in Abbildung 1 illustrierte zyklische Vorgehensweise (Performance- Modelle erzeugen, auswerten, die Ergebnisse den Performance-Anforderungen gegenüberstellen und wenn nötig nachbessern) ist auch für CBSE anwendbar, die Umsetzung muss allerdings modularisiert erfolgen. Analog zum Entwicklungsprozess stellen Komponenten- 6

17 Entwickler zu den von ihnen entwickelten Komponenten geeignet spezifizierte Performance- Modelle zur Verfügung (eine Übersicht sinnvoller Performance-Spezifikationen für Komponenten findet sich z.b. in Koziolek (2009)), Software-Architekten setzen die Performance- Modelle der genutzten Komponenten zu einem systemweiten Gesamt-Performance-Modell zusammen. Dieses wird dann mit den von Business-Domain-Experten zur Verfügung gestellten Informationen bzgl. Workload und Operational Profile sowie den vorhandenen Hardware- Ressourcen (Koziolek 2009) parametrisiert. Welche Modellierungsansätze für eine derartige Vorgehensweise geeignet sind, wird in Kapitel 3 diskutiert. 2.3 Kapazitätsplanung Bereits aus Kostengründen ist eine angemessene Kapazitätsplanung wichtig. In der Kapazitätsplanung ermittelt man die benötigte Menge aller Ressourcen, welche für die Erfüllung der spezifizierten Anforderungen notwendig sind in einer möglichst kosteneffizienten Weise (Jain 1991, S. 123). Im Kontext von Performance-Anforderungen sind dies meist Hardware- Ressourcen wie CPU, RAM oder I/O. Die Verfügbarkeit von Hardware-Ressourcen wirkt sich nicht nur auf die Ressourcenauslastung, sondern auch auf die Antwortzeit und den Durchsatz aus. Die Antwortzeit einer Nutzeranfrage entspricht der Gesamtzeit aller Operationen, die mit einer Anfrage verbunden sind. Die von einer Operation benötigte Zeit entspricht der Zeit, in der die Operation Ressourcen belegt oder auf Ressourcen wartet. Je nach Art der Ressource hängt Wartezeit von unterschiedlichen Faktoren ab. Die Wartezeit auf Scheduling-Ressourcen (d.h. Ressourcen, die abwechselnd immer nur von einem Nutzer genutzt werden können) hängt von der Auslastung und der gewählten Scheduling-Strategie ab, die Wartezeit auf begrenzt verfügbare Ressourcen (z.b. RAM) rein von der Verfügbarkeit. Auch durch den Kontrollfluss können sich Wartezeiten ergeben, beispielsweise wenn die Synchronisation zweier Threads (nebenläufige Programmausführung) notwendig ist. Wartezeiten sind umso länger, je mehr Operationen gleichzeitig auf dieselbe Ressource zugreifen möchten, da die entsprechende Ressource dann häufiger/stärker belegt ist. Je mehr Nebenläufigkeit in einem System stattfindet, desto länger sind die Wartezeiten auf Ressourcen und desto höher ist die Antwortzeit des Systems. Die Antwortzeit ist also im hohen Maße abhängig von der Intensität des zugrunde liegenden Workloads sowie der Anzahl, Größe und Geschwindigkeit (z.b. Geschwindigkeit/Durchsatz einer Netzwerkverbindung, Taktung einer CPU, etc.) verfügbarer Ressourcen. Auch der Durchsatz richtet sich offensichtlich nach der Verfügbarkeit notwendiger Ressourcen, je schneller eine Anfrage abgearbeitet ist, desto schneller kann die nächste Anfrage bearbeitet werden und desto mehr Anfragen werden pro Zeiteinheit entgegengenommen. Es gibt daher zwei Ansätze, Performance zu beeinflussen. Eine Möglichkeit ist es, den Ressourcenbedarf einer Software zu reduzieren, eine andere Möglichkeit ist es, die Qualität oder Quantität der verfügbaren Ressourcen zu erhöhen. Intelligente Programmierung reduziert den Ressourcenverbrauch beispielsweise durch die Reduktion der Anzahl elementarer Operationen (z.b. durch Nutzung baumartiger Datenstrukturen statt Listen) oder durch die Reduktion des Speicherverbrauchs (z.b. durch Datenaggregation). Anstatt die Performance direkt durch Senkung des Ressourcenbedarfs positiv zu beeinflussen, kann auch eine Priorisierung verschiedener Anfrageklassen vorgenommen werden, um wichtigen Anfragen eine höhere Per- 7

18 formance zukommen zu lassen (Smith/Williams 2001, S. 267ff.). Performance Programmierung ist somit ein wichtiger Bestandteil des Software Performance Engineerings und sollte der im Anschluss beschriebenen Ressourcenanpassung durch Hardwarevariation vorausgehen (Smith 2007). Nichtsdestotrotz beschränkt sich diese Arbeit auf die Beschreibung des Einflusses der Variation von Hardware-Ressourcen, für weitere Informationen bzgl. performanter Programmierung sei deshalb beispielsweise auf die von Smith/Williams (2001, S ) eingeführten Performance-Patterns/und -Antipatterns sowie auf den Einsatz effizienter Algorithmen und Datenstrukturen, wie sie beispielsweise in Weicker/Weicker (2013) beschrieben sind, verwiesen. Neben der softwareseitigen Reduktion benötigter Ressourcen können bei Performance- Problemen auch die vorhandenen Hardware-Ressourcen entsprechend dem zu erwartenden Workload erhöht werden, beispielsweise die Kapazität des RAMs oder die Anzahl vorhandener CPUs. Load Balancing ist eine weitere Möglichkeit, hier werden eingehende Anfragen auf redundante Server verteilt (Stark 2006, S. 298). Wichtig ist, dass nur jene Ressourcen erhöht werden, an denen auch tatsächlich Bedarf besteht. Eine Erhöhung der CPU-Anzahl bringt beispielsweise keinen Performance-Gewinn, wenn die durchschnittliche CPU-Auslastung zuvor bereits weniger als 20% betrug. Eine wichtige Aufgabe der Kapazitätsplanung ist es also, kritische Ressourcen zu identifizieren und so zu erhöhen (Bottleneck Identifikation (Woodside/Franks/Petriu 2007)), dass die spezifizierten nichtfunktionalen Anforderungen erfüllt sind. Grundsätzlich gilt jedoch, dass mehr Ressourcen auch mit höheren Kosten verbunden sind. Für eine größere Anzahl CPUs fallen beispielsweise neben den eigentlichen Anschaffungskosten auch höhere Energiekosten für deren Betrieb, sowie eventuelle Lizenzkosten für genutzte Softwarekomponenten an diese müssen bei Serverprodukten häufig pro Prozessor bezahlt werden, als Beispiel sei der Oracle WebLogic Application Server genannt, entsprechende Preislisten finden sich in Oracle (2014b). Eine Reduktion vorhandener Ressourcen ist daher erstrebenswert. Wie eingangs erwähnt ist es daher eine Hauptaufgabe der Kapazitätsplanung, die tatsächlich notwendigen Ressourcen möglichst genau abzuschätzen, sodass einerseits die zu erwartenden Kosten minimal, andererseits die spezifizierten Anforderungen erfüllt werden. Eine Abschätzung mit einer Genauigkeit im Größenbereich von 10-30% gilt dabei im Kontext der Kapazitätsplanung als hinreichend ( enasc Almeida Dowd, S. ). Um die für ein System notwendigen Ressourcen abzuschätzen, kann man beispielsweise Lasttests durchführen. Das zu untersuchende System wird dazu auf der angedachten Zielkonfiguration (bzgl. Hardware) mit einem künstlich erzeugten Workload belastet, der Workload muss dabei so realistisch wie möglich sein. Ein System, welches einen solchen Workload erzeugt, heißt Lasttreiber. Die Ergebnisse der Messungen können beispielsweise zur Identifikation von Bottlenecks genutzt werden (Kounev 2005). Nachteilig an diesem Ansatz sind die damit verbundenen, hohen Kosten sowie der Umstand, dass die Durchführung von Lasttests ein fertiges System erfordert. Eine andere Möglichkeit, notwendige Ressourcen abzuschätzen, stellen Performance-Modelle dar. Diese werden im folgenden Abschnitt näher erläutert. 8

19 2.4 Ansätze der Performance-Modellierung Performance-Modelle modellieren den Ressourcenbedarf einer Software. In Abschnitt 2.3 wurde bereits der Zusammenhang zwischen Ressourcenauslastung, Antwortzeiten und Durchsatz erklärt, die Ressourcenauslastung kann als der Ursprung der anderen beiden Metriken interpretiert werden. Der beschriebene Zusammenhang lässt sich mit der Utilization Law auch als Formel zusammenfassen: Formel 1: Utilization Law Quelle: Cortellessa/Di Marco/Inverardi (2011, S. 143) Dabei bezeichnen die durchschnittliche Ressourcenauslastung über einen festen Zeitraum, die absolute Anzahl der beantworteten Anfragen innerhalb desselben Zeitraums und die Zeit, die die Ressource im Durchschnitt mit der Abarbeitung einer einzelnen Anfrage beschäftigt ist (Service-Zeit). Grundsätzlich können Performance-Modelle analytisch oder mittels Simulation gelöst werden. Analytische Lösungen bestehen in der mathematischen Auswertung verschiedener Formeln oder Algorithmen ( enasc Almeida Dowd, S. ), die im Modell spezifizierte Parameter auswerten. Eine Simulation beschreibt ein Computerprogramm, welches den tatsächlichen Kontrollfluss durch die modellierte Software emuliert. Einer Simulation zugrunde liegende Modelle können beliebig detailliert erstellt werden, während analytische Modelle keinen hohen Detailgrad aufweisen dürfen, um mathematisch handhabbar zu bleiben ( enasc Almeida Dowd, S. ). Außerdem gibt es Situationen, die analytisch nicht gelöst werden können. Der Vorteil von analytischen Modellen ist dafür, dass sie schneller lösbar sind und ihre Lösung weniger Ressourcen benötigt ( enasc Almeida Dowd, S. 17). Im Laufe der Zeit wurden unterschiedliche Ansätze zur Performance-Modellierung (Meta- Modelle) entwickelt. Klassische Ansätze wie Queueing Networks eignen sich zwar für die Performance-Analyse komponentenbasierter Systeme, sie eignen sich aber nur bedingt für die Integration in deren Entwicklungsprozess und profitieren nicht von den vielen Vorteilen des CBSE, beispielsweise der Rollenverteilung (Koziolek 2009). Die klassischen Ansätze wurden im Laufe der Zeit daher verfeinert, es entstanden neue Meta-Modelle zur Performance- Modellierung speziell zur Integration in den CBSE-Prozess. Nichtsdestotrotz wird für deren Lösung häufig auf die klassischen Varianten zurückgegriffen. Die folgenden Abschnitte bis stellen eine Auswahl verschiedener Ansätze der Performance-Modellierung vor, dabei werden sowohl klassische als auch speziell für CBSE optimierte Ansätze besprochen. Eine Diskussion der unterschiedlichen Ansätze im Kontext komponentenbasierter Software und deren Entwicklungsprozess (CBSE) findet sich in Kapitel 3. 9

20 2.4.1 Queueing Networks (QN) Um die ihnen zugedachten Aufgaben verrichten zu können, benötigen auszuführende Operationen eine bestimmte Anzahl verschiedener Ressourcen. Um eine Anfrage beantworten zu können benötigt ein Datenbankserver beispielsweise Zugriffe auf Festplatten sowie Rechenleistung (CPU), um die gespeicherten Daten zu durchsuchen und zu aggregieren. Da ein Datenbankserver darüber hinaus zumeist mehrere Anfragen gleichzeitig beantworten muss, ist es wahrscheinlich, dass die von einer eingehenden Anfrage benötigte Ressource bereits belegt ist und die Anfrage warten muss, bis die entsprechende Ressource frei wird ( enasc Almeida Dowd 04, S. 18). Ressourcen können deshalb Warteschlangen (Queues) vorgeschaltet werden. Eine solche Ressource wird auch als Server bezeichnet, ein Server repräsentiert eine Ressource und verwaltet die darauf erfolgenden Zugriffe (Smith/Williams 2001, S. 135). Abbildung 2 zeigt eine mögliche Notation. Abbildung 2: Ressourcen-Server mit vorgeschalteter Queue Quelle: Angelehnt an Smith/Williams (2001, S. 136) Möchte man das Abstraktionsniveau hoch halten, lässt sich ein kompletter Datenbankserver als einzelner Ressourcen-Server modellieren ( enasc Almeida Dowd, S. ): Anfragen warten in einer Queue bis sie vom Datenbankserver entgegengenommen werden können, werden anschließend bearbeitet und verlassen das System. Typischerweise unterscheidet man jedoch mehrere Ressourcen, beispielsweise CPU und Festplatte. Werden mehrere Ressourcen-Server miteinander verbunden, entsteht ein sogenanntes Queueing Network (Balsamo/Marin 2007). p Queued Center Queued Center 1-p Source Node Sink Node Delay Node Abbildung 3: Notation von Queueing Networks Quelle: Eigene Darstellung Ein Queueing Network ist ein gerichteter Graph, dessen Knoten (Service Centers) Ressourcen repräsentieren und dessen Kanten potentielle Pfade darstellen, die von Jobs (Aufträgen) durchlaufen werden können (Cortellessa/Di Marco/Inverardi 2011, S. 39). Jobs lassen sich mit beliebiger Granularität in Klassen einteilen, bei einem Datenbankserver ließen sich so beispielsweise lesende von schreibenden Anfragen unterscheiden, oder auch unterschiedliche Klassen für lesende Zugriffe bilden. Ist der Fluss eines Jobs durch das Queueing Network nicht eindeutig bestimmt (d.h. mindestens ein Knoten hat mehrere Nachfolger), so wird die 10

21 Wahrscheinlichkeit für die Wahl einer jeden Kante abhängig von der Job-Klasse angegeben (Cortellessa/Di Marco/Inverardi 2011, S. 41). Wie in Abbildung 3 illustriert, gibt es verschiedene Typen von Service Centern. Je nach Typ ist unterschiedliche Parametrisierung notwendig, manche Parametrisierungen werden unabhängig, andere abhängig von der Job-Klasse vorgenommen. Abzuarbeitende Jobs betreten das QN durch Source Nodes. Mit Hilfe einer parametrisierten Wahrscheinlichkeitsverteilung wird die Zeit spezifiziert, die zwischen der Ankunft zweier Jobs derselben Klasse verstreicht (Cortellessa/Di Marco/Inverardi 2011, S. 40f.). Häufig wird hierfür auf die Poisson- Verteilung zurückgegriffen (Balsamo/Marin 2007). Queued Center wurden bereits in Abbildung 2 illustriert und bestehen aus einem oder mehreren Servers, denen eine gemeinsame Warteschlange vorgeschaltet ist. Eingehende Jobs warten demnach bis sie von einem freigewordenen Server bearbeitet werden können. Die Zeit, die in einem Queued Center aktiv für die Abarbeitung eines Jobs aufgewandt werden muss (Service- Zeit) wird in Abhängigkeit von der Job-Klasse und als parametrisierte Wahrscheinlichkeitsverteilung spezifiziert (Cortellessa/Di Marco/Inverardi 2011, S. 39). Scheduling-Strategien definieren die Reihenfolge, in der wartende Jobs abgefertigt werden. Mögliche Scheduling- Strategien sind beispielsweise First Come First Served (FCFS), Round Robin oder Shortest Processing Time First (SPTF). FCFS arbeitet dabei Jobs in der Reihenfolge ihrer Aknunft ab, SPTF bearbeitet den Job mit dem kleinsten Bedarf an Service-Time zuerst. Round Robin teilt wartenden Jobs nacheinander einen kurzen Zeit-Slot auf der Ressource zu (Balsamo/Marin 2007). Queues können je Job-Klasse mit unterschiedlichen Scheduling-Strategien parametrisiert werden. Zudem wird die maximale Kapazität der Queue spezifiziert, eine Queue kann auch eine unendliche Kapazität aufweisen (Cortellessa/Di Marco/Inverardi 2011, S. 39). Mit einem Delay Center definiert man für verschiedene Job-Klassen eine bestimmte Wartezeit. Diese kann durch Angabe einer parametrisierten Wahrscheinlichkeitsverteilung angegeben werden. Delay Centers benötigen keine Queue, ankommende Jobs werden unmittelbar bedient, d.h. sie verbleiben tatsächlich exakt für die Dauer der spezifizierten Wartezeit ( enasc Almeida Dowd, S. f.). Sink Nodes markieren den Punkt, an dem ein Job das Queueing Network verlässt. Hier sind keine weiteren Parametrisierungen notwendig (Cortellessa/Di Marco/Inverardi 2011, S. 40f.). Der Workload des in Abbildung 3 dargestellten Modells wird vollständig durch den spezifizierten Ankunftsprozess beschrieben, Jobs betreten das System (Source Node), werden abgearbeitet, verlassen das System (Sink Node). Es handelt sich daher um einen offenen Workload, man spricht in diesem Zusammenhang auch von einem offenen Queueing Network (Cortellessa/Di Marco/Inverardi 2011, S. 40). Wie bereits in Abschnitt 2.1 beschrieben, beschreibt man einen geschlossenen Workload durch die Angabe der Nutzeranzahl und der Think Time. Ein geschlossenes Queueing Network besitzt deshalb weder Source noch Sink Node, sondern einen alternativen Warteknoten, sogenannte Terminals Nodes. Diese definieren einen Wartebereich, in dem ankommende Jobs gemäß ihrer Think Time verweilen. Nach Ablauf der Think Time wird eine neue Nutzeranfrage derselben Job-Klasse generiert. Zur Spezifikation eines Terminals Node gibt man die Anzahl der Jobs sowie deren Think Time (als 11

22 parametrisierte Wahrscheinlichkeitsverteilung) jeder Job-Klasse an (Cortellessa/Di Marco/Inverardi 2011, S. 41). Queueing Networks mit den vorgestellten Elementen sind in ihrer Mächtigkeit insofern beschränkt, als dass sie einige in modernen Computersystemen geläufige Vorgänge nicht modellieren können. Nebenläufige Bearbeitung von Jobs sowie deren Synchronisation, das Blockieren von Ressourcen oder der gleichzeitige Besitz mehrerer Ressourcen wären Beispiele, weitere Beispiele finden sich in Balsamo/Marin (2007) oder enasc Almeida Dowd (2004, S. 272ff.). Um diese Umstände dennoch modellieren zu können existieren im Rahmen sogenannter Extended Queueing Networks (EQNs) weitere Notationen, die den Funktionsumfang von Queueing Networks entsprechend erweitern. Diese werden im Rahmen dieser Arbeit allerdings nicht vorgestellt. Eine Zusammenfassung der vorgestellten QN-Elemente und deren Parametrisierung gibt Tabelle 1. QN Element Parameter Spezifikation Source Node Zwischenankunftszeit Wahrscheinlichkeitsverteilung Queued Center Queue-Länge Ganzzahl Service-Zeit Scheduling-Strategie Wahrscheinlichkeitsverteilung FCFS, Round Robin, SPTF, etc. Delay Center Wartezeit Wahrscheinlichkeitsverteilung Sink Node - - Terminals Node Nutzeranzahl Ganzzahl Think Time Tabelle 1: Parametrisierung der Elemente eines Queueing Network Quelle: Eigene Darstellung Wahrscheinlichkeitsverteilung Eine besondere Form von Queueing Networks stellen Product-Form Queueing Networks (PQNF) dar. Um ein PFQN zu sein muss ein Queueing Network bestimmte Eigenschaften erfüllen, beispielsweise hinsichtlich seiner Topologie, seines Schedulings oder der bei der Parametrisierung genutzten Wahrscheinlichkeitsverteilungen (Cortellessa/Di Marco/Inverardi 2011, S. 150). PQNFs lassen sich z.b. mit Hilfe der Mean Value Analysis (MVA) analytisch lösen (Balsamo/Marin 2007): Basierend auf dem Gesetz von Little werden Gleichungen aufgestellt. Löst man die Gleichungen, so erhält man den Durchsatz, die Aufenthaltszeit (residence time) sowie die Queue-Länge für das jeweils -te Service Center. Andere Performance-Metriken lassen sich durch Anwendung der Gesetze der Warteschlangentheorie errechnen. Die Lösung mittels MVA besitzt polynomielle Komplexität bezüglich der Anzahl der QN-Elemente und ist somit besonders effizient (Cortellessa/Di Marco/Inverardi 2011, S. 42, 150f.). Die oben angesprochenen EQNs weisen keine Product-Form auf. Solche Modelle sind deshalb normalerweise nicht analytisch lösbar. Die Lösungsmöglichkeiten beschränken sich daher auf approximative analytische Methoden sowie Simulation. Approximative analytische Methoden wandeln das zu analysierende Queueing Network zunächst approximativ in ein PQNF um und lösen dieses dann mit Hilfe analytischer Methoden wie der MVA ( enasc Almeida Dowd, S. ). 12

23 Für die praktische Umsetzung von Queueing Models existieren mehrere Tools, beispielsweise die von Bertoli/Casale/Serazzi (2009) eingeführten Java Modeling Tools (JMT). JMT stellt Oberflächen zur Verfügung, mit denen Queueing Models textuell oder grafisch beschrieben werden. Erstellte Modelle lassen sich sowohl analytisch, approximativ analytisch als auch durch Simulation lösen Queueing Networks und Execution Graphs Der Umgang mit Queueing Networks ist eine komplexe Aufgabe. Architektur und Kontrollfluss einer Software werden in Queueing Networks nur indirekt durch den Ressourcenbedarf ihrer Ausführung repräsentiert (Koziolek 2008). Unterschiedliche Job-Klassen müssen identifiziert und hinsichtlich ihres Ressourcenverbrauchs, ihrer Ankunftshäufigkeit und ihres Operational Profiles (d.h. Pfadwahrscheinlichkeiten) parametrisiert, das richtige Abstraktionsniveau der Topologie muss gefunden werden ( enasc Almeida Dowd, S. 19). Um die Arbeit mit Queueing Networks zu vereinfachen, kann die Verwendung von Execution Graphs nützlich sein, durch welche die Parametrisierung von Queueing Networks unterstützt werden kann. Während der Anforderungsanalyse eines Softwareprojekts werden typischerweise Anwendungsfälle identifiziert (Schatten et al. 2010). Ein Anwendungsfall beschreibt eine typische Nutzung der zu entwickelnden Software und stellt dafür alternative Abläufe dar, ein Szenario illustriert einen konkreten Ablauf und repräsentiert somit Logik der zu entwickelnden Software. Szenarien werden normalerweise in einem UML Sequenzdiagramm modelliert (Smith/Williams 2001, S. 50ff.). Execution Graphs können aus Sequenzdiagrammen abgeleitet werden (Smith/Williams 2001, S. 88f.) und repräsentieren somit das Software Execution Model, welches den logischen Programmfluss einer Software abbildet (Smith/Williams 2001, S. 73ff.). Basic Node 1 SW 1 SW Expanded Node SW 1 SW n=5 Repetition Node Case Node 0,7 0,3 Basic Node 2 Basic Node 3 SW 1 SW 2 SW 1 SW Basic Node 4 SW 1 SW Basic Node 5 SW 1 SW 2 Abbildung 4: Notation von Execution Graphs Quelle: Eigene Darstellung

24 Abbildung 4 zeigt einen beispielhaft parametrisierten Execution Graph mit seinen wichtigsten Notationen, wie sie in Smith/Williams (2001, S. 77) dargestellt werden. Basic Nodes stellen für das betrachtete Abstraktionsniveau die elementaren Operationen dar. Expanded Nodes enthalten Subgraphen. Sie ermöglichen daher die Modularisierung eines Execution Graphs. Repetition Nodes realisieren eine Schleife, wiederholen also die von ihnen eingeschlossenen Befehle -mal. Ein Case Node ermöglicht die bedingte Ausführung der an ihn angeschlossenen Nodes. Die Ausführung eines angeschlossenen Nodes unterliegt dabei einer gewissen Wahrscheinlichkeit. Für eine Verzweigung innerhalb des Programms existieren neben dem hier aufgeführten Case Node auch Pardo Nodes und Split Nodes, welche die parallele Ausführung mit bzw. ohne anschließende Synchronisation ermöglichen. Ausführlichere Beschreibungen zu diesen und den vorgestellten Execution Graph-Elementen finden sich in Smith/Williams (2001, S. 72ff.). Basic und Expanded Nodes werden entsprechend ihres Ressourcenbedarfs annotiert, wobei der Ressourcenbedarf von Expanded Nodes dem Gesamtressourcenbedarf des darunterliegenden Subgraphen entspricht. Abbildung 4 stellt die Annotation in tabellarischer Form neben den entsprechenden Nodes dar, die Notation stammt aus Smith/Williams (2001, S. 85). In obigem Graphen gibt es also zwei Arten von Ressourcen, SW1 und SW2. Dabei handelt es sich nicht um Hardware-Ressourcen (CPU, etc.), sondern um (virtuelle) Software- Ressourcen. Je nach System können Software-Ressourcen beispielsweise durch die Anzahl auszuführender SQL-Queries oder die Anzahl zu übermittelnder Netzwerknachrichten definiert werden (Smith/Williams 1997). Execution Graphs werden analytisch gelöst, indem die von verschiedenen Nodes benötigten Software-Ressourcen unter Einbezug ihrer Ausführungswahrscheinlichkeit aufaddiert werden (Smith/Williams 2001, S. 80ff.). Die Lösung eines Execution Graphs besteht also in der Aggregation der für seine Ausführung notwendigen Software-Ressourcen. Aus einem (gelösten) Software Execution Model lässt sich jedoch nicht die hardwareabhängige System- Performance bestimmen. In einem System Execution Model modelliert man daher die verfügbaren Hardware-Ressourcen in einem Queueing Network (vgl. Abschnitt 2.4.1). Die Lösungen vorhandener Execution Graphs können dann dazu genutzt werden, das vorhandene System Execution Model zu parametrisieren. Dazu müssen die spezifizierten Software- Ressourcen auf die tatsächlichen Hardware-Ressourcen umgelegt werden, die Anzahl der für eine Software-Ressource notwendigen Hardware-Ressourcen kann durch Abschätzung oder Messung gewonnen und in einer Overhead-Matrix (vgl. Tabelle 2) festgehalten werden (Smith/Williams 1997). Hardware-Ressource CPU Festplatte Netzwerk Anzahl Einheit Tsd. Operationen I/O-Zugriffe Nachrichten SW SW Service-Zeit [Sek.] 0, ,05 0,01 Tabelle 2: Overhead-Matrix zur Umlage von Software- auf Hardware-Ressourcen Quelle: Angelehnt an Smith/Williams (2001, S. 85) 14