Entwurf und Implementierung eines Frameworks für Profiling- und Performancemessungen mit Hilfe von aspektorientierter Programmierung (AOP) E-Book
Michael Dempfle
36,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Deutsch
Masterarbeit aus dem Jahr 2004 im Fachbereich Informatik - Technische Informatik, Note: 1.0, Georg-Simon-Ohm-Hochschule Nürnberg, Veranstaltung: Masterstudiengang, Sprache: Deutsch, Abstract: Aspektorientierte Programmierung (AOP) ist ein Ansatz, Funktionalitäten zu kapseln, die an vielen Stellen einer Anwendung auftreten. Für die Programmierung dieser sogenannten Crosscutting Concerns sind mehrere Implementierungen auf den Markt gekommen, welche sehr unterschiedliche Ansätze verfolgen. Bis jetzt wird AOP jedoch in realen Projekten noch nicht sehr häug eingesetzt. Diese Masterarbeit verfolgt das Ziel, ein Framework zu entwickeln, um AOP für die Messpunktsetzung in bereits laufenden Anwendungen zu verwenden. Um eine Aussage treffen zu können, ob AOP dafür eingesetzt werden kann, sind folgende Punkte zu klären: 1. Ist AOP ein guter Ansatz, mit dem existierende Anwendungen mit geringem Aufwand instrumentiert werden können? 2. Welche der existierenden AOP-Ansätze ist am besten für diesen Zweck geeignet? Unter dem Namen PerfLoad ist ein Lasttest-Framework entworfen und implementiert worden, welches man einfach, flexibel und zentral konfigurieren kann. Es bietet eine Managementkonsole, mit der die Lasttests gestartet, verwaltet und die Ergebnisse ausgewertet werden können. Für die Messpunktsetzung verwendet PerfLoad AOP. Es wurde damit untersucht, welcher der AOP-Ansätze am Besten geeignet ist, um Anwendungen gezielt instrumentieren zu können.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2004
Ähnliche
Page 1
Page 2
Page 6
Page 8
Page 9
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich diese Masterarbeit selbstständig verfasst und noch nicht anderweitig zu Prüfungszwecken vorgelegt habe.
Ich habe weiterhin keine anderen Quellen oder Hilfsmittel benutzt, als die angegebenen. Alle wörtlichen und sinngemäÿen Zitate habe ich im Text entsprechend als solche gekennzeichnet.
Page 10
Page 11
Zusammenfassung
Aspektorientierte Programmierung (AOP) ist ein Ansatz, Funktionalitäten zu kapseln, die an vielen Stellen einer Anwendung auftreten. Für die Programmierung dieser sogenannten Crosscutting Concerns sind mehrere Implementierungen auf den Markt gekommen, welche sehr unterschiedliche Ansätze verfolgen. Bis jetzt wird AOP jedoch in realen Projekten noch nicht sehr häug eingesetzt. Diese Masterarbeit verfolgt das Ziel, ein Framework zu entwickeln, um AOP für die Messpunktsetzung in bereits laufenden Anwendungen zu verwenden. Um eine Aussage treen zu können, ob AOP dafür eingesetzt werden kann, sind folgende Punkte zu klären:
1. Ist AOP ein guter Ansatz, mit dem existierende Anwendungen mit geringem Aufwand instrumentiert werden können?
2. Welche der existierenden AOP-Ansätze ist am besten für diesen Zweck geeignet?
Unter dem Namen PerfLoad ist ein Lasttest-Framework entworfen und implementiert worden, welches man einfach, exibel und zentral kongurieren kann. Es bietet eine Managementkonsole, mit der die Lasttests gestartet, verwaltet und die Ergebnisse ausgewertet werden können. Für die Messpunktsetzung verwendet PerfLoad AOP. Es wurde damit untersucht, welcher der AOP-Ansätze am Besten geeignet ist, um Anwendungen gezielt instrumentieren zu können.
Um eine Aussage treen zu können, ob AOP überhaupt sinnvoll für die Messpunktsetzung verwendet werden kann, wurden die existierenden Methoden (JMX, JVMPI und Bytecode-Manipulation) untersucht, mit deren Hilfe Informationen aus einem laufenden System gewonnen werden können. Dabei wurde festgestellt, dass diese Methoden für bestimmte Aufgaben gut geeignet sind, jedoch immer auch Nachteile besitzen, die eine uneingeschränkte Benutzung in allen Phasen der Entwicklung nicht ermöglichen. Die Untersuchung der beiden Java-basierenden AOP-Ansätzen AspectJ und Aspect-Werkz hat gezeigt, dass diese ausreichende Möglichkeiten bieten, die für Messpunktsetzung benötigte Bytecode-Modikation auch ohne teure Speziallösungen und ohne groÿen Aufwand durchzuführen. Beide Lösungen erzeugen im Verhältnis zu einer handcodierten Variante nur einen geringen Overhead und sind deswegen sehr gut geeignet, Instrumentierung von Anwendungen einfach, schnell und ezient durchzuführen. Zum Schluss war noch die Frage zu klären, welcher der AOP-Ansätze am besten für die Verwendung bei Lasttests geeignet ist. Zunächst wurde die Performance als wichtigstes Kriterium untersucht. Hierbei hat sich gezeigt, dass die Geschwindigkeitsunterschiede in einem realen Szenario sehr klein waren. So wurde zusätzlich noch der
Page 12
Kongurationsaufwand und der Funktionsumfang für die endgültige Beurteilung berücksichtigt.
AspectJ bietet die meisten Möglichkeiten, Messpunkte zu setzen, ist auf allen getesteten Servern problemlos einsetzbar und hat auch eine gute Toolunterstützung, welche die Denition der Messpunkte deutlich einfacher macht. AspectWerkz ist dagegen bei Lasttests etwas performanter und die Konguration ist im Online Modus mit dem wenigsten Aufwand verbunden.
Obwohl AspectWerkz für die Messpunktsetzung bei Lasttests leichte Performance und Kongurationsvorteile zeigte, ist die Entscheidung letztlich für AspectJ gefallen, da hier der Stand der Entwicklung, die Serverunabhängigkeit, die Möglichkeiten der umfangreichen Messpunktsetzung und die bereits vorhandene Unterstützung von Entwicklungsumgebungen ein schnelleres und problemloseres Arbeiten ermöglicht. Jedoch kann man von AspectWerkz noch einiges erwarten. So sind zurzeit zwar noch einige Einschränkungen und Fehler in der Implementierung enthalten, jedoch darf man nicht vergessen, das dieses Projekt erst in der Version 0.9 verfügbar ist und meiner Meinung nach noch sehr viel mehr Potential darin steckt.
Page 13
Vorwort
Ich möchte mich bei der Firma MGM EDV-Beratung dafür bedanken, dass Sie mich dabei unterstützt hat, meinen Master machen zu können. Vor allem die exible Arbeitszeit hat es mir ermöglicht, dieses Vollzeitstudium parallel zu meiner normalen Arbeit durchzuführen.
Auch möchte ich allen Verantwortlichen der FH-Nürnberg meinen Dank aussprechen, da ein Stundenplan gefunden werden konnte, um Arbeit und Studium unter einen Hut zu bringen. Vor allem Herr Prof. Dr. Riekeheer und mein Betreuer Herr Prof. Dr. Knebl haben sich immer wieder Zeit genommen, um mich zu unterstützen. Vielen Dank auch an Martin Backschat, da mit ihm die Idee entstand, dieses Thema genauer zu untersuchen. Er hat vor allem am Anfang der Arbeit dazu beigetragen, diese in die richtige Richtung zu lenken. Ebenfalls bedanken möchte ich mich bei Silke Schmidt, Karl-Wilhelm Schick, Christian Ey und Jutta Sohili für die gewissenhafte Korrektur dieser Arbeit.
Page 14
Page 15
Kapitel 1
Einleitung
Die Anforderungen, die heutzutage an Software gestellt werden, haben sich in den letzten Jahren in vielerlei Hinsicht geändert. Mit der Web-Technologie wird seit Ende der 90-er Jahre ein immer gröÿer werdender Anteil an Server-zentrierten Internet- und Intranet-Anwendungen entwickelt, die oft eine hohe Anzahl von Benutzern haben und auf groÿe Datenmengen zugreifen.
In der Entwicklung werden in vielen Firmen zwar Funktionstests durchgeführt, jedoch wird in den seltensten Fällen bereits in frühen Phasen das System daraufhin untersucht, wie sich die einzelne Module bzw. die gesamte Anwendung unter Last verhalten. Anwendungen, die schon im produktiven Einsatz sind, bekommen oft Per-formanceprobleme, wenn plötzlich die Anzahl der Benutzer stark zunimmt oder sich die Datenmengen, die übertragen werden bzw. sich in den Datenbanken benden, vergröÿern.
Eine Anwendung kann in der Entwicklungs- und Testphase sehr stabil und schnell laufen, aber dennoch in der Produktionsumgebung nicht entsprechend skalieren. Per-formanceprobleme können im produktiven Betrieb durch eine Vielzahl nicht vorhersehbarer Faktoren hervorgerufen werden. Darum ist es wichtig, den Einuss der Infrastruktur, in der die Anwendung läuft, und das Verhalten, wie sich die vielen verschiedenen Anwendungskomponenten unter Last gegenseitig beeinussen, zu verstehen. Zur Diagnose ist es wichtig, ein Performanceproblem Schritt für Schritt eingrenzen und so bis an die Wurzel zurückverfolgen zu können. Hierbei benötigt man Mechanismen, um zunächst die Schicht in der Anwendungsarchitektur, dann die Anwendungskomponente und zum Schluss das verantwortliche Codestück zu isolieren. Performancekritische Faktoren in Bezug auf den produktiven Einsatz liegen auch in den Bereichen Auslieferungen und Management der Anwendungen. So ist oftmals keine ausreichende Kommunikation zwischen der Entwicklung, der Qualitätssicherung und dem Support-Team vorhanden, welches die Anwendung verwaltet. Es gibt groÿe Rechenzentren, die viele hunderte Anwendungen ohne tieferes Wissen betreiben und somit Problemstellen sehr schwer identizieren können.
Oft ist auch bei der Architektur der Software zu wenig auf Performance und Skalierbarkeit geachtet worden. In späteren Entwicklungsstadien ist es dann meist nur mit sehr groÿem nanziellen Aufwand möglich, eine performante Lösung zu nden.
Page 16
Aufgrund des enormen Zeitdrucks bei vielen Projekten werden Anwendungen oftmals ohne ausreichende Lasttests ausgeliefert, welche Skalierungs- und Leistungsschwächen rechtzeitig aufdecken würden.
Die Ursache für ein Performanceproblem in einer komplexen, verteilten und dyna-
TM(Java2 Enterprise Edition) Umgebung [1] zu nden, ist somit eine
mischen J2EE echte Herausforderung.
1.1 Der Lebenszyklus einer Anwendung
Im Lebenszyklus einer Anwendung gibt es viele Personen, die für die Leistung des Systems verantwortlich sind: Software-Architekten, Entwickler, die Qualitätssicherung und ein Admin-Team, welches die Anwendung in der Produktion betreut. Sie alle haben Anforderungen an eine Leistungsanalyse, aber durch die verschiedenen Umgebungen, in denen sie arbeiten, sehr unterschiedliche Möglichkeiten, das System zu beeinussen:
•In der Designphase sind Skalierbarkeit und Performance wichtige Kriterien, die oftmals über den Erfolg eines Projekts entscheiden. Dieser Bereich wird in dieser Arbeit nicht weiter beleuchtet, da in dieser Phase keine Testtools verwendet werden. Interessierte können in [2], [3] oder [4] Informationen zu diesem Thema erhalten.
•In der Entwicklungsphase können Testprogramme sehr sinnvoll eingesetzt werden, um Performance und Funktionalität zu testen. Entwickler sollten in diesem Zeitraum die einzelnen Komponenten nach Kriterien wie Latenz und Ressourcennutzung untersuchen.
•In der Qualitätssicherungsphase werden typischerweise Funktionstests des gesamten Systems und anschlieÿend Lasttests durchgeführt. Die vollständige Anwendung sollte mit allen Schnittstellen zu externen Systemen vor dem Release der Software einem Lasttest unterzogen werden. Besonderes Augenmerk muss vor allem darauf gelegt werden, dass die zu erwartende Last auch in der zu erwar-TMSchichten
tenden Umgebung erzeugt wird. Dabei sollten die einzelnen J2EE bis hinunter zu den einzelnen Methoden untersucht werden. Dies kann mit so genannten Prolern geschehen, welche Daten mit unterschiedlichsten Methoden (siehe Kapitel 3) direkt aus der laufenden Anwendung gewinnen können. Prolingtools aus der Entwicklungsphase können während eines Lasttests wegen ihres groÿen Overheads in der Qualitätssicherung nicht verwendet werden. Deswegen müssen solche Diagnoseanwendungen in dieser Phase speziell für diesen Zweck ausgelegt und optimalerweise in ein Lasttestsystem eingebettet sein. In diesem Bereich liegt auch der Fokus des Frameworks, das in dieser Arbeit entwickelt wurde.
•In Produktivsystemen ist es wichtig, die Anwendung permanent zu überwachen, um im Fehlerfall das Problem schnell einzugrenzen und beheben zu können. Hier
Page 17
1.2. ZIEL DIESER ARBEIT17
ist der Einsatz von Monitoring-Systemen sinnvoll, welche festgelegte Parameter überwachen und protokollieren. Es ist manchmal schwierig, Probleme aus der Produktivumgebung in Testumgebungen nachzustellen. Deswegen ist eine gewisse Analysefähigkeit im Produktivsystem sehr wichtig.
Ein komplettes Analysepaket sollte alle Bereiche im Lebenszyklus einer Anwendung abdecken, um Performanceprobleme erkennen zu können. Doch es wird sich hier nie um eine einziges Tool handeln, denn je nach Phase müssen verschiedene Möglichkeiten bereitgestellt werden, um die gewünschten Messwerte zu bekommen. Diese werden in dieser Arbeit im Kapitel 3 Proling-Methoden detailliert dargestellt und analysiert.
1.2 Ziel dieser Arbeit
Es gibt bereits viele verschiedene Ansätze, Messungen in einer J2EE Umgebung durch-
1Spe-
zuführen. Diese haben jedoch meist einen groÿen Overhead oder sind proprietäre ziallösungen, die Firmen für ihre eigenen Produkte entwickelt haben. Ziel dieser Masterarbeit ist es, ein Verfahren zu entwickeln, das J2EE Systeme mit möglichst wenig Overhead und maximaler Flexibilität für Messungen instrumentieren und unter Last testen kann. Dabei sollte dieses Verfahren die Hauptschwächen vorhandener Proler eliminieren: Erzeugung unnötiger CPU-Last und die Ermittlung von nicht benötigten Informationen, welche herausgeltert werden müssen und somit weitere Performanceverluste erzeugen.
Grundidee ist der Einsatz aspektorientierter Programmierung (AOP) im Bereich der Lasttestmessungen. Aspekte sind in diesem Zusammenhang Codestücke, die an beliebigen Stellen im Programm eingebunden werden können. Dieser Ansatz soll verwendet werden, um Messpunkte in die vorhandene Anwendung einzuweben. So wird die Anwendung mit dem gewünschten Code angereichert und Messdaten damit gewonnen. Dieser Ansatz ist bisher noch nicht speziell für den Einsatz zur Messpunktsetzung bei Lasttests verwendet worden. Die Arbeit soll den Aufwand, den Nutzen und die Möglichkeiten dieser Lösung für solche Messungen klären. Für die Performance-Messungen müssen Messpunkte in eine bestehende J2EE-Anwendung eingefügt werden, ohne den Quellcode dieser Anwendung zu verändern. Die Messpunkte sollen exibel denierbar, einfach veränderbar und erweiterbar sein. Dazu werden verschiedene Ansätze aspektorientierter Programmierung (AOP) untersucht, um das optimale Verfahren auszuwählen. Ziel ist es, alle benötigten Informationen aus einem laufenden System mit minimalem Overhead zu gewinnen. Dabei werden die verschiedenen Aspekte Schritt für Schritt in verschiedenen Testszenarien entwickelt, um das Verhalten des J2EE Systems zu testen.
Um dies zu realisieren, wird ein Framework entwickelt und implementiert, welches eine Clientverteilung auf verschiedene Rechner ermöglicht. Diese Clients werden über1Man bezeichnet im Computerbereich traditionell Dateiformate, Protokolle usw. als proprietär, die nicht allgemein anerkannten, herstellerübergreifenden Standards entsprechen, also sozusagen hausei- gene Entwicklungen sind.
Page 18
einen Masterprozess von einem Rechner aus gesteuert. Die Messungen innerhalb der Anwendung sollen mit Hilfe von AOP durchgeführt und die Messdaten vom Framework verarbeitet werden. Das zu entwickelnde Framework soll möglichst frei kongurierbar und die komplette Administration zentral verwaltbar sein.
Page 19
Kapitel 2
Übersicht
In dieser Masterarbeit wurde das Framework PerfLoad (Performance and Loadtest) entwickelt, welches als exibles und unabhängig einsetzbares Lasttestsystem für Serverbasierte J2EE-Anwendungen verwendet werden kann. Dabei wurden zuerst existierende Tools untersucht, um die Anforderungen zu kennen, die solche Systeme erfüllen müssen. Vor allem ist es wichtig, deren Einschränkungen und Ansätze zu ermitteln, damit in der Konzeptionsphase ein optimales Design gewählt werden kann. Es werden zwei Arten von Programmen, benötigt, um Performancemessungen durchzuführen:
1. Tools zur Lasterzeugung und
2. Tools um Messungen im System durchzuführen.
Es existieren Kombinationen der beiden, jedoch kann man diese unabhängig vonein-ander betrachten, da die Erzeugung der Last nichts mit den Messungen selbst zu tun hat.
Pure Lasterzeugungssysteme, wie z. B. JMeter [5] und The Grinder [6], welche später im Abschnitt 5.1 noch genauer vorgestellt werden, liefern nur Messergebnisse von der Clientseite. Diese spiegeln die Antwortzeiten des Servers wider, wie sie am Client gemessen werden. Das sind sehr wichtige Daten, da der Benutzer des Systems diese Zeiten direkt zu spüren bekommt. Ein erster Lasttest mit solchen Tools ist meist der erste wichtige Ansatzpunkt um das Verhalten einer Anwendung unter Last herauszunden. Wenn in dieser Testphase die gewünschten Reaktionszeiten vorhanden sind, werden meist weitergehende Untersuchungen nicht mehr durchgeführt. Sind tiefergreifende Untersuchungen notwendig, ist meist der Einsatz von Prolern nötig. In Abschnitt 3.1 werden einige der wichtigsten existierenden Proler-Systeme kurz vorgestellt. Das in dieser Arbeit entwickelte Lasttestsystem ist eine Kombination aus Lasterzeugungsanwendung und Proler. Es ermöglicht komplette Untersuchungen einer J2EEbasierten Anwendungslandschaft durchzuführen. Bevor mit der eigentlichen Entwicklung begonnen werden konnte, mussten zunächst die vorhandenen Proling-Methoden untersucht werden, um später eine Aussage machen zu können, ob die Messpunktsetzung mit AOP wirklich ein sinnvolles Einsatzgebiet dieser neuen Technologie ist.
Page 20
2.1 Proling-Methoden
Zurzeit gibt es drei verschiedene Möglichkeiten (siehe Abbildung 2.1), um Messdaten aus J2EE Anwendungen zu gewinnen:
1. Java Management Extension (JMX)
2. Java Virtual Machine Proling Interface (JVMPI)
3. Bytecode Modikation
Die JMX Schnittstelle (siehe 3.2) [13] ist eine einfache Möglichkeit, Anwendungen zu überwachen, da diese bereits von vielen Applikationsserverherstellern bereitgestellt wird. An der JMX-Schnittstelle können Messwerte abgegrien werden, die von den Entwicklern des Servers und der Anwendung festgelegt werden. Eine Veränderung der Messpunkte ist durch Konguration des Testsystems somit nicht möglich. Diese Werte sind meist Statusinformationen und können sehr gut dafür verwendet werden, um ein System ohne groÿen Overhead zu überwachen. Zum Beispiel kann bei dem Servlet-Container Tomcat die aktuelle Anzahl der Sessions abgefragt werden. Der Nachteil dieses Ansatzes ist, dass tiefere Diagnosen aufgrund der fest vorgegebenen Messpunkte nicht möglich sind.
Die zweite Möglichkeit ist die Verwendung der Schnittstelle JVMPI (siehe 3.3.1)
TM(JVM) bereitstellt. Viele Proler verwen-[14], die die Laufzeitumgebung von Java
den dieses Interface, da hier sehr detailliert und dynamisch Daten ausgelesen werden können. Vor allem für Entwickler sind diese Informationen sehr interessant, da diese Zugrismöglichkeit bis auf Methodenebene verfügbar sind und sogar Transaktionsver- folgung möglich ist. Dadurch sind aber auch sehr viele Daten vorhanden, welche nicht
Page 21
2.1. PROFILING-METHODEN21
benötigt und somit weggeworfen werden. Aus diesem Grund wird diese Methode selten für Lasttests und in der Produktion eingesetzt, sondern für das Feststellen von Blockierungen, Optimierungsmöglichkeiten der Programmierung usw. verwendet. Ab JDK 1.5 soll es noch zwei weitere Möglichkeiten geben, J2EE Anwendungen zu
1163 [22] (siehe 3.3.2) und JSR 174 [23] (siehe 3.3.3) sind zwei Spe-
überwachen. JSR
zikationen, die festlegen, wie über eine Schnittstelle der JVM gezielt Informationen aus dem laufenden System gewonnen werden können.
Als dritter Mechanismus steht die Instrumentierung des Bytecodes (siehe 3.4) zur Verfügung. Diese Methode wird meist von Herstellern für Diagnoseanwendungen in späteren Phasen des Lebenszyklus einer Software verwendet. Hier gibt es verschiedene Techniken um ein ausgeglichenes Verhältnis zwischen Detailinformationen und Overhead herzustellen:
•Man kann man stichprobenartig einen Teil der auftretenden Ereignisse herausltern, um die Anwendung so wenig wie möglich zu beeinträchtigen. Das so genannte Sampling hat den Nachteil, dass man Events, die nur unregelmäÿig oder nur bei einer bestimmten Reihenfolge auftreten, nicht erkennen kann.
•Eine Aggregation2genannte Technik protokolliert und kombiniert eine Sequenz
von Ereignissen und hält diese als einen einzelnen Wert - wie zum Beispiel einem Durchschnitt - fest. Man kann so sehr schnell eine Übersicht und eine Eingrenzung des Problems gewinnen, jedoch ist eine genaue Diagnose nicht möglich, da der einzelne Wert, wie der eines Übergabeparameters, mit dieser Methode nicht mehr ermittelt werden kann.
•Es können alle Ereignisse aufgezeichnet werden, um möglichst viele Informationen zu gewinnen. Diese Vorgehensweise bietet die meisten Details, um Probleme mit langsamen Methoden, Abhängigkeiten von Übergabeparametern, Speicher oder Synchronisierung zu erkennen und zu beheben. Sie bringt aber wieder sehr viel Overhead mit sich und sollte deswegen intelligent eingesetzt werden. Der Fehler kann zunächst grob eingegrenzt und dann weiter lokalisiert werden, indem das Überwachungsnetz immer enger gezogen wird.
Bei der Bytecode-Modikation gibt es drei verschiedene Zeitpunkte, wann diese durchgeführt werden können:
•Statisch
•Beim Laden der Klasse
•Dynamisch
1Java Specication Requests (JSR) sind Spezizierungsprojekte, die Funktionalitäten festlegen, welche evtl. in zukünftigen Java-Versionen integriert werden.
2Unter Aggregation von Daten versteht man das Zusammenfassen detaillierter Daten zu gröÿeren Einheiten.
