Inhaltsverzeichnis

1  Einleitung  15

1.1  Der Lebenszyklus einer Anwendung  16

1.2  Ziel dieser Arbeit  17

2  Übersicht  19

2.1  Proling-Methoden  20

2.2  Aspektorientierte Programmierung  22

2.3  Framework PerfLoad  23

2.4  PerfLoad und AOP  25

3  Proling-Methoden  27

3.1  Übersicht existierender Systeme  27

3.2  JMX  29

3.3  JVM Interfaces  36

3.4  Bytecode Modikation  42

4  Aspektorientierte Programmierung  47

4.1  AspectJ  52

4.2  AspectWerkz  59

4.3  JBossAOP  68

4.4  Weitere Ansätze  69

4.5  Zusammenfassung  70

5  Das Lasttest-Framework PerfLoad  73

5.1  Vorhandene Lasttest-Frameworks  74

5.2  Grundstruktur von PerfLoad  77

5.3  Komponenten von PerfLoad  79

5.4  Testerstellung  82

5.5  Auswertung der Testergebnisse  85

6  AOP für Proling  87

6.1  Zusammenarbeit der Aspekte mit PerfLoad  88

6.2  Kollektor-Prozess  93

6.3  Managementkonsole  94

6.4  EJB-Aspekt  95

3

4  INHALTSVERZEICHNIS  

6.5  Web-Aspekt  99

7  Performancevergleich  101

7.1  Manuelle Codierung vs. AspectJ  101

7.2  AspectJ vs. AspectWerkz  102

7.3  Zusammenfassung  113

8  Konguration  115

8.1  AspectJ  115

8.2  AspectWerkz Oine  118

8.3  AspectWerkz Online  120

8.4  Zusammenfassung  121

9  Fazit  123

A  Übersicht weiterer Proler  125

B  AspectJ Kurzreferenz  128

B.1  Aspekte  128

B.2  Pointcut Denitionen  128

B.3  Advice Deklaration  129

B.4  Spezielle Datentypen innerhalb von Advices  129

B.5  Primitive Pointcuts  130

C  AspectWerkz Kurzreferenz  131

C.1  Join Point Auswahlsprache  131

C.2  Deployment models  132

C.3  Advice Deklaration  132

C.4  Pointcut Denition  133

D  CD Inhalt  134

E  Quellcode  137

F  Verwendete Anwendungen  138

G  Verwendete Bibliotheken  141

Abbildungsverzeichnis   

2.1  Übersicht Proling-Methoden  20

2.2  Architektur von PerfLoad  24

3.1  Übersicht JMX  30

3.2  Übersicht JVMPI  37

3.3  Übersicht JSR 163  40

3.4  Transformation einer Klasse  44

3.5  Möglichkeiten, den Ladevorgang zu beeinussen  46

4.1  Modularisierung durch AOP  49

4.2  Einweben der Aspekte in AspectJ  53

4.3  call und execution bei AspectJ  56

4.4  Native Hotswap  68

5.1  Architektur von The Grinder  75

5.2  Grundstruktur PerfLoad  79

5.3  Informationskonsole auf dem Dämon-Rechner  80

5.4  Managementkonsole während eines Testlaufs  81

5.5  Dämonfenster mit Statusinformationen  82

5.6  Testlauf mit 27 virtuellen Clients  82

5.7  Verteilungsdiagramm mit 3 Messpunkten  86

6.1  Architektur der Messwerterfassung  89

6.2  Modi der Messwerterfassung  93

6.3  Menüpunkte für Messungen ohne Clients  94

6.4  Gesamtarchitektur von PerfLoad  95

7.1  Manuelle Codierung vs. AspectJ  102

7.2  Messpunkte in Szenario 1  106

7.3  Architektur Dukes Bank  111

8.1  Kongurationsablauf AspectJ  116

8.2  Kongurationsablauf AspectWerkz Oine  118

8.3  Kongurationsablauf AspectWerkz Online  120

D.1  CD-Inhalt  134

5

Tabellenverzeichnis   

7.13  Messergebnisse Szenario1 - 1 Client : J2EE Referenzcontainer  107

7.14  Messergebnisse Szenario1 - 16 Clients : J2EE Referenzcontainer  107

7.15  Messergebnisse Szenario1 - 1 Client : OC4J  108

7.16  Messergebnisse Szenario1 - 16 Clients : OC4J  108

7.17  Messergebnisse Szenario1 mit Parameteraufrufen  110

7.20  Messergebnisse Szenario2 - 1 Client : OC4J  113

7.21  Messergebnisse Szenario2 - 9 Clients : OC4J  113

7

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.

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

11

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.

12

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.

13

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.

15

16 KAPITEL 1. EINLEITUNG

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- TM Schichten

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

1.2. ZIEL DIESER ARBEIT 17

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-

1 Spe-

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 über 1 Man bezeichnet im Computerbereich traditionell Dateiformate, Protokolle usw. als proprietär, die nicht allgemein anerkannten, herstellerübergreifenden Standards entsprechen, also sozusagen hausei- gene Entwicklungen sind.

18 KAPITEL 1. EINLEITUNG

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.

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.

19

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

2.1. PROFILING-METHODEN 21

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

1 163 [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 Aggregation 2 genannte 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

1 Java Specication Requests (JSR) sind Spezizierungsprojekte, die Funktionalitäten festlegen, welche evtl. in zukünftigen Java-Versionen integriert werden.

2 Unter Aggregation von Daten versteht man das Zusammenfassen detaillierter Daten zu gröÿeren Einheiten.

22

Im Kapitel 3 werden die vorgestellten Möglichkeiten detailliert untersucht. Es wird beschrieben, wie diese funktionieren und welche Informationen damit gewonnen werden können. Vor allem die Vor- und Nachteile der jeweiligen Proling-Methode und deren Einsatzgebiete werden dort genau erläutert.

Die Analyse der vorhandenen Proling-Methoden zeigt, das JMX zu statisch ist und JVMPI zu viel Overhead erzeugt, um sinnvoll für Lasttests eingesetzt werden zu können. Bytecode Modikation ist der richtige Ansatz, um Messpunkte gezielt und exibel in einer Anwendung setzen zu können. Jedoch verwenden bis jetzt alle Hersteller, die Bytecode verändern, hausinterne Lösungen, um diese Art der Erweiterungen durchzuführen.

Existierende AOP-Ansätze benutzen auch die Bytecode-Modikation. Jedoch verwenden die Implementierungen einen sehr generischen Ansatz, um die Modikationen durchzuführen und sind deswegen sehr exibel einsetzbar.

2.2 Aspektorientierte Programmierung

Einsatzfähige AOP-Implementierungen sind erst seit relativ kurzer Zeit verfügbar und scheinen sehr gut dafür geeignet zu sein, den Anwendungscode zu instrumentieren. Deswegen werden die vielversprechendsten AOP-Ansätze AspectJ, AspectWerkz und JBossAOP vorgestellt (siehe 4.1, 4.2 und 4.3) und vor allem auf Funktionsumfang, Performance und Konguration untersucht.

Zu Beginn des Kapitel 4 wird der Begri der aspektorientierten Programmierung ausführlich erläutert. Für diese Übersicht ist es ausreichend zu wissen, dass Aspekte Programmlogik kapseln, welche an vielen Stellen der Anwendung vorkommen können (z. B. Logging). Diese Aspekte werden über Denitionen, welche je nach verwendeter AOP-Implementierung völlig unterschiedlich aussehen, dem Anwendungscode hinzugefügt.

In den Abschnitten 4.1 - 4.4 wird untersucht, ob der Funktionsumfang der verschiedenen AOP-Ansätze ausreichend ist, um diese im Lasttest-Framework einzusetzen. Dafür werden die verschiedenen Aspekt-Denitionsumfänge genau untersucht. Als Ergebnis kann festgestellt werden, das AspectJ (siehe 4.1) für den Bereich der Messpunktsetzung alle erforderlichen Denitionen unterstützt und damit Messungen an allen Stellen des Systems durchgeführt werden können.

AspectWerkz (siehe 4.2) ist in dieser Hinsicht noch etwas eingeschränkt, da in der aktuellen Version (0.9) bestimmte Messpunkte noch nicht fehlerfrei auf allen Applikationsservern gesetzt werden können. Die zur Verfügung stehenden restlichen Konstrukte sind in den meisten Fällen ausreichend, da die nicht einsetzbaren Denitionen das Setzen der Messpunkte oftmals nur vereinfachen. So können bei AspectJ mit einer einzigen Denition z. B. Messpunkte an allen Methoden gesetzt werden, die einen Datenbankaufruf beinhalten. Bei AspectWerkz müssen die einzelnen Methoden bei der Denition angegeben werden (siehe 7.2.2). Alle anderen AOP-Implementierungen (siehe 4.3 und 4.4) sind zurzeit noch nicht weit genug entwickelt, um sinnvoll für Lasttests eingesetzt

2.3. FRAMEWORK PERFLOAD 23

werden zu können, da deren Funktionsumfang nicht ausreichend für Messpunktsetzung ist.

AspectJ und AspectWerkz sind aufgrund ihres Funktionsumfanges als Proling-Mechanismus für die Entwicklung eines Lasttest-Frameworks prinzipiell geeignet. Da zur Bestimmung des performanteren Ansatzes das Lasttest-Framework benötigt wird, wurde bei dessen Entwicklung darauf geachtet, dass es unabhängig von der jeweiligen AOP-Implementierung ist.

2.3 Framework PerfLoad

Es sollte ein System entstehen, welches gleichzeitig die Last erzeugt und Messungen in der Anwendung durchführt. Dazu wurden zunächst die Architekturen von JMeter und The Grinder analysiert und deren Schwächen und Stärken ermittelt (siehe 5.1.1 und 5.1.2).

Die entstandene Architektur legt Wert darauf, dass der Programmablauf während eines Testlaufes so wenig wie möglich beeinusst wird, und trotzdem eine ausreichende Überwachung des Systemzustandes vorhanden ist.

Beim Entwurf des Frameworks wurde vor allem auf folgende Punkte geachtet:

• Zentrale Verwaltung: Es sollen alle Informationen und Dateien, die für die

Durchführung eines Lasttests benötigt werden, zentral konguriert und verteilt werden können. Kongurationsparameter, Javaklassen, zusätzliche Bibliotheken usw. sollen von einer zentralen Stelle an alle beteiligten Instanzen vor dem Teststart übertragen werden.

• Minimaler Overhead: Um den Overhead während der Tests zu minimieren,

werden Messdaten erst nach Testende zusammengefasst. Während eines Tests sind nur Statusinformationen vorhanden, welche abgeschaltet werden können.

• Flexible Konguration von Clients: Die Clients, die später die Tests durch-führen, sollen unabhängig voneinander konguriert werden können. Dadurch kann man unterschiedliche Szenarien zur gleichen Zeit ablaufen lassen und komplexe Tests möglich machen.

• Thin Clients: Die Clients sollen keine Abhängigkeiten zum eigentlichen Test

haben. Dies bedeutet, dass z. B. selbst die Laufzeitumgebung, in der sie gestartet werden, dynamisch erzeugt wird.

• Überwachung: Die einzelnen Clients müssen periodisch überprüft werden kön-nen um sicherzustellen, ob diese noch korrekt funktionieren. Dadurch kann man fehlerhafte Testläufe erkennen und abbrechen.

Bei der Umsetzung wurden neben den genannten auch noch weitere Kriterien berück- sichtigt, die im Abschnitt 5.2 beschrieben sind.

24

Die Architektur von PerfLoad (siehe Abbildung 2.2) kann in 4 Bereiche aufgeteilt werden:

1. Managementkonsole: Die Managementkonsole ist die zentrale Verwaltungsein-

heit im System. Sie liest alle für einen Test benötigten Komponenten ein und verteilt diese auf die jeweiligen Client-Rechner. Man kann die Tests auf der graschen Oberäche starten, stoppen und auswerten. Auch ist es möglich, die Testabläufe zu editieren und den Test während der Ausführung zu überwachen. Am Testende sammelt die Konsole die Testergebnisse von den Clients (siehe Punkt 2) und dem externen Kollektorprozess ein (siehe Punkt 3) und stellt verschiedene grasche Auswertungsmetriken zur Verfügung.

2. Dämon: Auf jedem Rechner, der für die Lasterzeugung genutzt werden soll, wird

ein Dämon gestartet, welcher für die Erzeugung der Testclients zuständig ist. Er bekommt die Informationen von der Managementkonsole und startet eine entsprechende Anzahl von Testprozessen, welche wiederum eine bestimmte Anzahl von Testthreads erzeugen. Die Testprozesse fordern die Testinformationen vom Dämon an und initialisieren die Testthreads entsprechend. Nach der Initialisierungsphase warten alle Clients auf ein Startsignal vom Dämon, das er von der Managementkonsole erhält. Am Ende des Testsdurchlaufs schicken die Testclients ihre Messergebnisse an den Dämon und dieser wartet, bis die Managementkonsole die Daten abruft. Dadurch wird während des Tests keine Last auf dem Netzwerk erzeugt.

3. Externer Kollektorprozess: Der externe Kollektorprozess sammelt alle Mess-

daten, die er von der Messpunktverwaltung (siehe Punkt 4) geschickt bekommt

2.4. PERFLOAD UND AOP 25

und speichert sie, bis die Daten am Testende von der Managementkonsole an-gefordert werden. Durch den Einsatz des externen Prozesses ist es möglich, die Verwaltung der Messdaten während des Tests von dem Testsystem auf einen anderen Rechner zu verlagern.

4. Messpunktverwaltung und Aspekte: In dem zu testenden System ist ein 3 enthalten, welches dafür zuständig ist, die

Sendeobjekt in Form eines Singletons

Messdaten der Aspekte zu verwalten. Ein Aspekt führt eine Messung durch und übergibt die Ergebnisse an das Singleton. Dieses speichert die Daten zunächst lokal und sendet sie bei geringer Serverbelastung an den externen Kollektorprozess (siehe Punkt 3). Dadurch beeinusst die Messpunktverwaltung die aktuell laufende Anwendung nur minimal.

In den Kapiteln 5 und 6 ist das Framework PerfLoad und die einzelnen Design- und Implementierungsentscheidungen, die getroen wurden, genau beschrieben. Während der Entwicklung wurde für die Messwerteerfassung noch eine Implementierung mit einem stateless SessionBean getestet, welches genau so performant wie die Singleton-Lösung war. Der Kongurationsaufwand war jedoch deutlich höher als beim Singleton, und deswegen wurde die Singleton-Lösung verwendet und weiter optimiert. Nach der Entwicklung von PerfLoad wurde das Framework zunächst in einem Projekt für die Obernanzdirektion Bayern eingesetzt. Dabei wurden noch weitere Detailverbesserungen eingebaut, um Testkongurationen und Auswertungen exibler zu machen.

Bis zu dieser Entwicklungsstufe wurde AspectJ bei der Integration in das Frame-work verwendet, weil eine grasche Unterstützung für Entwicklungsumgebungen vor-handen ist, und damit die Entwicklung der Aspekte vereinfacht wurde. Zu dem Zeitpunkt, als mit der Untersuchung von AspectWerkz begonnen wurde ist die Version 0.9 RC1 veröentlicht worden. Bei diesem Release wurden selbstdenierende Aspekte (siehe 4.2.2) eingeführt, wodurch für die Messpunktsetzung fast die gleichen Möglichkeiten wie bei AspectJ entstanden sind.

2.4 PerfLoad und AOP

Um die Performance der verschiedenen AOP-Ansätze zu testen, wird zunächst ein Vergleich zwischen AspectJ und einer manuell codierten Lösung vorgestellt (siehe 7.1). Die Aspekt-Implementierung ist hier nur ca. 3 Prozent langsamer und somit in einer realen Anwendung vernachlässigbar. Wenn man dann berücksichtigt, dass der Aufwand den Code manuell einzufügen und zu verändern sehr hoch ist, kann als Ergebnis festgehalten werden, dass sich die AOP-Lösung sehr gut zur Messpunktsetzung eignet. Um festzustellen, ob AspectJ oder AspectWerkz performanter ist, wurden zwei Szenarien entworfen, welche jeweils einen anderen Kontext untersuchen. So ist Szenario 1 3 Von einer nach dem Singleton Pattern implementierten Klasse wird nur eine Instanz erzeugt, welche bis zum Herunterfahren der JVM erhalten bleibt.

26

(siehe 7.2.1) ein Test, bei dem nur ein einziges Bean ohne externe Zugrie (z. B. Datenbank) verwendet wird. Das Bean besitzt drei Methoden, welche einander aufrufen und sehr wenig Logik enthalten. Dabei werden Messpunkte an allen Methodenaufrufen gesetzt, um den maximalen Overhead, der durch die Instrumentierung ensteht, zu erzeugen. Bei den Testdurchläufen, die mit immer gröÿer werdender Last durchgeführt wurden, hat sich gezeigt, dass die Initialisierung von Aspekten bei AspectWerkz sehr teuer ist, und dieser AOP-Ansatz bei schlechtem Cachingverhalten des Applikationsserver langsamer ist als AspectJ. Bei vielen Beanaufrufen und gutem Caching des Containers ist AspectWerkz jedoch ca. 20 % schneller als AspectJ, da der eingewebte Code nach der Setup-Phase sehr ezient ist. Szenario 1 ist allerdings keine Anwendung, die in der Realität bei einem Lasttest instrumentiert wird. Deswegen wurde als zweites Szenario (siehe 7.2.2) die Beispielanwendung Dukes Bank aus dem J2EE Tutorial verwendet, um Messungen durchzuführen. Dort wurden die Hälfte der Datenbankzugrie und alle Aufrufe eines Session-Beans instrumentiert. Der Client testet in den Testläufen alle Teile der Anwendung, wobei in die Hälfte aller aufgerufenen Methoden Messpunkte eingewebt waren. Der Overhead, der von beiden AOP-Implementierungen erzeugt wurde, war praktisch identisch, und deswegen können für Lasttests beide Ansätze gleichermaÿen verwendet werden.

Zum Ende der Untersuchungen wurde verglichen, wie aufwändig es ist, eine fertige Anwendung mit den unterschiedlichen AOP-Implementierungen zu instrumentieren (siehe Kapitel 8). Dabei ist bei AspectWerkz in der Variante, wo die Aspekte während der Laufzeit eingewebt werden, die Konguration am einfachsten. Jedoch muss AspectWerkz bei den Applikations- oder Servlet-Containern mit in die Konguration eingebunden werden (siehe 4.2.3). Dies ist nicht bei allen Applikationsservern möglich (z. B. BeanTA [63]) und bedeutet einen zusätzlichen Aufwand beim Erstellen der Tests. AspectJ kann ohne Einschränkungen auf allen Plattformen und Containern verwendet werden, da alle benötigten Klassen mit der Anwendung deployed werden können. Wenn man alle Kriterien wie Funktionsumfang, Performance und Konguration betrachtet, ist AspectJ zurzeit für die Instrumentierung einer J2EE-Anwendung bei Lasttests die bessere Lösung und wird deswegen für das PerfLoad-Framework verwendet.

In den nachfolgenden Kapiteln werden die hier kurz vorgestellten Ansätze und Lö- sungen ausführlich beschrieben.

Kapitel 3

Proling-Methoden

In Kapitel 2 wurden bereits die existierenden Proling-Methoden in einer kurzen Übersicht dargestellt. Diese werden ab Abschnitt 3.2 genau untersucht und deren Stärken und Schwächen zusammengefasst. Im nächsten Abschnitt werden ein paar bekannte Proler kurz vorgestellt, um einen Eindruck über deren Funktionsumfang zu erhalten.

3.1 Übersicht existierender Systeme

Existierende Proler benutzen meist eine Kombination von verschiedenen Untersuchungsmethoden, um dem Benutzer möglichst viele verschiedene Messergebnisse anbieten zu können. Auch sind viele dieser Tools für unterschiedliche Einsatzzwecke konzipiert und können nicht in den verschiedenen Lebenszyklen der Software eingesetzt werden (siehe 1.1). Da die Anforderungen an die Proler - wie schon in Kapitel 1 beschrieben - sehr unterschiedlich sind, sind Komplettlösungen meist eine Ansammlung von Einzelprogrammen, die eine gemeinsame Auswertungs- und Kongurationsoberäche besitzen.

Die nachfolgende Übersicht zeigt einige Proler, die zurzeit auf dem Markt verfügbar sind. Dabei sind keine Bewertungen der einzelnen Anwendungen enthalten, da dies über den Fokus dieser Arbeit hinausgeht.

• LoadRunner TM der Firma Mecury Interactive [7] ermöglicht, das Systemver-

halten und die Systemleistung von Anwendungen vorherzubestimmen. Herausragend ist hier die Toolunterstützung für die J2EE-Applikationsserver aller bekannten Anbieter (z. B. IBM, Bea, Oracle) in den einzelnen Enterprise Bereichen. Die LoadRunnerSuite besteht aus verschiedenen Echtzeit-Monitoren für Applikationsserver, Datenbankserver, Webserver und Netzwerk, die präzise Performance Messungen während der Lasttests durchführen.

Über den LoadRunnerController werden die Tests gesteuert und es ist z. B. auch möglich, Testläufe aufzuzeichnen und zu verändern. Alle Performancedaten des Systems werden gesammelt in einem Repository zur späteren Analyse und Auswertung abgelegt.

27

28 KAPITEL 3. PROFILING-METHODEN

• JProbe TM und PerformaSure TM : Aus der Softwareschmiede Sitraka [8] kom- TM undmit PerformaSure TM zwei Werkzeuge, die im Bereiche

men mit JProbe

Proling und Performance sehr viele Bereiche abdecken. JProbe Sammlung von Werkzeugen zur Fehlerbehebung und Aufdeckung von Performancelöchern zur Verfügung. Mit Threadanalyzer, Memory Debugger, Coverage und Proler wird eine Diagnose der Anwendung und des Umfelds erstellt. Dabei lässt

TM

sich jedes auftretende Probleme genau nachverfolgen. Während sich JProbe

TM Umfeld positioniert, setzt PerformaSure TM

als Werkzeug im allgemeinen Java

die entsprechenden Ansprüche in Bezug auf das J2EE Umfeld um. Einsetzbar als Monitor, kann das gesamte Umfeld einer J2EE Applikation unter Performance-Gesichtspunkten betrachtet werden. Werden beispielsweise bestimmte Transak- TM durchVi-tionen als Flaschenhals ausndig gemacht, erlaubt PerformaSure sualisierung der einzelnen Transaktionsschritte das genaue Beobachten der beteiligten Komponenten und deren Verhalten.

• Introscope: Wily Solutions [9] hat mit Introscope ein System entwickelt, wel-

ches mit geringem Overhead Anwendungen auf Performance untersucht. Die so

TM Technologie erlaubt es, Bottlenecks in Servlets, EJBs, Klassen

genannte Blame

und Methoden zu nden. Dabei werden Agenten eingesetzt, welche die Anwendung permanent überwachen und deren Ergebnisse and den Enterprise-Manager weitergeben. So existieren z. B. SQL-Agenten, mit deren Hilfe alle Datenbankaufrufe protokolliert werden können. Mit der Konsole kann man dann die Ergebnisse der Agenten über eine Reportingschnittstelle auswerten, über ein Webinterface anzeigen oder so aufbereiten, dass z. B. Alarme an ein anderes System gesendet werden.

Man kann Introscope auch so kongurieren, dass ein sehr geringer Overhead entsteht und es zum Überwachen von laufenden Anwendungen eingesetzt werden kann. Dazu wird hier vor allem JMX (siehe 3.2) verwendet, da dieses von vielen Applikationsservern bereits unterstützt wird.

• JDBInsight von JInspired Ltd [10] ist ein innovatives Managementprodukt,

welches darauf ausgerichtet ist, Performancetuning durchzuführen und J2EE Anwendungen zu testen, welche ihre Datenbankanbindung über JDBC herstellen. Es analysiert den Datenzugri von J2EE Komponenten und stellt deren Ablaufzeiten, Ressourcenbenutzung und Transaktionspfade in einer übersichtlichen Auswertung dar. Der Unterschied zu anderen Proling- und Performance Tools ist, dass JDBInsight versucht, die Anwendung aus einer sequentiellen Sicht zu analysieren. Die meisten anderen Produkte zeigen nur einen einfachen Aufrufbaum und stellen nicht dar, was für ein so genannter Execution Plan (Ausführungsplan) von der Anwendung durchgeführt wird. Dort ist zwar meist bekannt, von wem die Methode aufgerufen wurde, aber nicht, in welchem Kontext. Da langsame Methoden oftmals von vielen Bereichen einer Anwendung aufgerufen werden und evtl. dieses Verhalten nur bei bestimmten Parametern auftritt, kann man bei JDBInsight diesen Pfad sehr gut zurückverfolgen und die Ursache lokalisieren.

3.2. JMX 29

• JProler und Optimizeit TM sind zwei Vertreter von Prolern, die ausschlieÿ-

lich das Java Virtual Machine Proling Interface (JVMPI) nutzen (siehe 3.3.1). Sie besitzen beide einen Proler-Agenten, der die Daten sammelt, und ein Frontend, auf dem die Daten aufbereitet werden.

JProler [11] hilft vor allem dabei CPU, Thread und Speicherdaten zu erhalten um Speicherprobleme zu beheben. Auch ist eine Unterstützung für viele Entwicklungsumgebungen und Applikationsserver vorhanden.

TM [12] bietet neben den normalen Proling-Informationen auch ein

Optimizeit

Tools namens Code Coverage, mit dem ausgewertet werden kann, wie oft Statements im Javacode durchlaufen werden. So ist es möglich, unbenutzte Methoden aus dem Code zu entfernen oder den Programmablauf zu optimieren. Der ebenfalls enthaltene Thread Debugger bietet die Möglichkeit, die Abhängigkeiten von Threads zu analysieren. Durch Testläufe kann man bestimmen, wie oft und von wem ein Thread blockiert wird, und Deadlock-Situationen können leicht erkannt werden.

Die Liste der Anbieter von Test Tool Suiten könnte noch um einige Seiten erweitert werden, da auch im Open-Source Bereich sehr viele kleinere Projekte in diesem Bereich vorhanden sind. Im Anhang A ist noch eine Liste von weiteren Proling-Anwendungen zu nden, die zeigt, wie viel Interesse und auch Bedarf in diesem Bereich besteht. Eine Analyse der vorhandenen Tools hat jedoch gezeigt, dass selbst die umfangreichsten Systeme gewisse Einschränkungen und Abhängigkeiten haben, da diese oftmals vom zu untersuchenden Ziel abhängig sind. Es sind z. B. bei vielen der Produkten spezielle Module für einen bestimmen Applikationsserver nötig, um die Messdaten zu ermitteln oder es wird eine bestimme JVM benötigt. Die in dieser Arbeit entwickelte Lösung hat keine dieser Abhängigkeiten und ist somit auf allen Plattformen uneingeschränkt einsetzbar.

3.2 JMX

Die Java Management Extension (JMX) Spezikation 1.2 deniert ein Paket für J2EE

1 ), welches eine Managementarchitektur und eine API bereit-

1.4 (bis J2EE 1.3 optional

stellt. Zusätzlich erlaubt sie, jede auf Javatechnologie basierte Ressource zu überwachen und/oder zu kontrollieren. Eine Ressource ist in dem hier betrachteten Kontext meist eine Javaanwendung, kann aber z. B. auch alles sein, was von Java gewrapped oder erreicht werden kann. Zu diesem Zweck führt JMX ein JavaBean Model ein, wobei die Basis ein einfacher und doch hoch entwickelter und erweiterbarer Verwaltungsagent für die Java Virtual Machine (JVM) ist.

JMX deniert einen Satz von Diensten, welche helfen, Anwendungen zu verwalten und ist dabei sehr einfach zu benutzen. Es ist so möglich, den Quellcode eine Anwendung mit ein paar wenigen Zeilen Code zu instrumentieren.

1 Um JMX nutzen zu können, muss bis JDK1.3 die JMX Bibliothek [13] extra mit eingebunden werden.

30 KAPITEL 3. PROFILING-METHODEN

Abbildung 3.1 zeigt eine Übersicht von JMX.

Im Grunde ist JMX das gleiche für Verwaltungssysteme, wie JDBC (Java Database Connectivity) [15] für Datenbanken: Es ist eine Abstraktionsschicht zwischen der Anwendung und beliebigen Managementsystemen.

3.2.1 JMX Architektur

Die JMX Architektur lässt sich in 3 Ebenen aufteilen:

• Instrumentation level

Diese Ebene ist der Anwendung selbst am nächsten. Sie besteht aus vier verschiedenen Konstrukten, die verwendet werden, um Anwendungen und Systemressourcen verwaltbar zu machen und einem Model, um Benachrichtigungen zu senden und zu empfangen. Die instrumentierten Ressourcen werden Management Beans (MBeans) genannt und liefern ein Interface, an dem die gewünschten Informationen abgerufen werden können.

• Agent level

Die mittlere Ebene der JMX Architektur wird agent level genannt. Sie enthält