Performanzevaluierung von Anwendungsservern

Größe: px
Ab Seite anzeigen:

Download "Performanzevaluierung von Anwendungsservern"

Transkript

1 Performanzevaluierung von Anwendungsservern Masterarbeit zur Erlangung des akademischen Grades Master of Science an der Universität Potsdam Frank Feinbube (B. Sc.) Betreut durch Prof. Dr. Andreas Polze Lehrstuhl für Betriebssysteme und Middleware Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Potsdam, Deutschland 05. Mai 2009

2

3 Danksagung Mein Dank gilt Andreas Polze für die Betreuung und Unterstützung dieser Arbeit. Ihm habe ich den Kontakt zu Krystian Brachmaoski und seinem Team zu verdanken. Unser kurzes Aufeinandertreffen und der anregende Austausch von Ideen und Beobachtungen zeigten mir, dass ich auf dem richtigen Weg bin und erfüllten mich mit neuem Tatendrang. Die Konfiguration des JBoss-Anwendungsservers war eine mühevolle, langwierige Arbeit. Daher möchte ich mich an dieser Stelle für die Unterstützung durch Tomasz Wozniak, Martin von Löwis, Peter Johnson und Benjamin Eckart bedanken, die sich die Zeit nahmen, sich meine Probleme anzuhören und gemeinsam mit mir über eine Lösung nachzudenken. Außerdem möchte ich Robert Wierschke für die vielen Anregungen bezüglich des GlassFish- Anwendungsservers danken. Vielleicht habe ich eines Tages die Zeit, sie alle auszuprobieren. Überdies möchte Bernhard Rabe danken, der immer ein offenes Ohr für mich hatte und mir mehrfach mit Rat und Tat zur Seite stand. Weiterhin möchte ich Christine Lehmann dafür danken, dass sie mich zielsicher durch die Irrungen und Wirrungen der statistischen Datenanalyse führte. Mein Dank gilt darüber hinaus Daniel Richter, von dem ich zusätzlichen Beistand auf diesem Gebiet erhielt.

4

5 Zusammenfassung Unternehmensanwendungen werden immer komplexer. Um die hohen Anforderungen, die an sie gestellt werden, dennoch verlässlich erfüllen zu können, benötigt man ausgereifte Technologien, welche die Entwicklung von Unternehmenssoftware unterstützen und eine Plattform liefern, um die erstellten Programme in einer skalierbaren, flexiblen und sicheren Umgebung zur Verfügung zu stellen. Eine solche Umgebung liefern Anwendungsserver für die Java Platform, Enterprise Edition. Als eine Entscheidungshilfe, welcher Server für ein spezifisches Einsatzszenario eingesetzt werden sollte, dienen Standardbenchmarks wie das SPECjAppServer2004-Benchmark. Solche Benchmarks bilden ein verbreitetes repräsentatives Geschäftsszenario ab und bewerten die Anwendungsserver hinsichtlich ihrer diesbezüglichen Leistungsfähigkeit. Obwohl die Bedeutung von Open-Source- Software ungebrochen ist, existieren zurzeit keine Vergleiche der beiden populären Anwendungsserver JBoss und GlassFish anhand des SPECjAppServer2004-Standardbenchmarks. Diese Arbeit schließt diese Lücke indem sie den JBoss- und den GlassFish-Anwendungsserver hinsichtlich ihrer Leistungsfähigkeit und ihrer Ressourcennutzung mit Hilfe des SPECjAppServer2004-Benchmarks untersucht. Damit liefert sie einen wichtigen Beitrag für die Vergleichbarkeit der beiden Anwendungsserver. Sie enthält neben eine Übersicht über Evaluierungswerkzeuge eine Beschreibung des SPECjAppServer2004-Benchmarks und verwandte Arbeiten. Der Hauptteil der Arbeit ist der Evaluierung des GlassFish- und des JBoss-Anwendungsservers sowie dem Vergleich ihrer erzielten Resultate gewidmet. Abschließend enthält sie einen Ausblick auf weitere Themen und offene Fragen. Abstract Enterprise applications are becoming increasingly complex. To meet the high demands that are put on them you need sophisticated technologies that support the development of enterprise software and provide a platform to deploy programs in a scalable, flexible and secure environment. Such an environment is provided by the application server for the Java Platform, Enterprise Edition. Standard benchmarks like the SPECjAppServer2004 benchmark are used as a decision aid which server fits best for a specific scenario. These benchmarks are representative for a widespread business scenario and evaluate the application server in terms of their performance in this. Although the importance of open source software is unbroken, there are currently no comparisons of the two popular application server JBoss and Glassfish using the SPECjAppServer2004 standard benchmark. This work fills this gap by investigating the JBoss and Glassfish application server in terms of their performance and their use of resources with the help of the SPECjAppServer2004 benchmark. Doing this, it provides an important contribution to the comparability of the two application server. It contains an overview of evaluation tools, a description of the SPECjAppServer2004 benchmark and related work. The main part of the paper is devoted to the evaluation of the Glassfish and JBoss application server and the comparison of their results. Finally, it contains an outlook on further topics and open questions.

6

7 Inhaltsverzeichnis 1 Einführung und Überblick Motivation Überblick über diese Arbeit Grundlagen Überblick über aktuelle Technologien Java Platform, Enterprise Edition Enterprise JavaBeans Anwendungsserver Verwendungsmuster Vierschichtarchitektur Java Blue Prints Clustering Werkzeuge Werkzeuge für die Performanzoptimierung Java Management Extensions Skripte Statistische Datenanalyse Selbsterstellte Werkzeuge Das SPECjAppServer2004-Benchmark Einführung Benchmarks Minibenchmarks Individuallösungen Standardbenchmarks SPECjAppServer Geschäftsszenario Technische Umsetzung Metriken Konfiguration Benchmarkresultate Infrastruktur und Messumgebung Verwandte Arbeiten Performance Tuning and Optimization of J2EE Applications on the JBoss Platform GlassFish vs. JBoss Evaluierungsbericht Scaling Up the JBoss Application Server... 28

8 4.4 SPECjAppServer-2004-Ergebnisse des GlassFish vom September GlassFish Full Disclosure Archive Einsatz für die Durchführung des Benchmarks Probleme und Lösungen Ergebnisse Ergebnisse des Benchmarks Ressourcenauslastung in Abhängigkeit von der Injektionsrate Betrachtungen bei begrenzten Ressourcen Fehlerbetrachtungen Fazit JBoss Specj-Kit für JBoss Einsatz für die Durchführung des Benchmarks Probleme und Lösungen Ergebnisse Ergebnisse des Benchmarks Ressourcenauslastung in Abhängigkeit von der Injektionsrate Betrachtungen bei begrenzten Ressourcen Fehlerbetrachtungen Fazit Vergleich Konfiguration Einrichtung Probleme und Lösungen Clustering Ergebnisse Ergebnisse des Benchmarks Ressourcenauslastung in Abhängigkeit von der Injektionsrate Betrachtungen bei begrenzten Ressourcen Fehlerbetrachtungen Fazit Zusammenfassung und Ausblick Glossar Literaturverzeichnis... 74

9 Abbildungsverzeichnis Abbildung 1: Die Architektur der Java Platform, Enterprise Edition v5 (6)... 4 Abbildung 2: Überblick über die 4-Schicht-Architektur und die J2EE-spezifischen Komponentenmodelle (13)... 8 Abbildung 3: Der Zusammenhang zwischen Antwortszeit, Durchsatz und Auslastung (15) Abbildung 4: Das Schichtenmodell bei der Ausführung von Java-EE-Anwendungen Abbildung 5: Das Geschäftsszenario des SPECjAppServer2004-Benchmarks (30) Abbildung 6: Die Architektur des SPECjAppServer2004-Benchmarks Abbildung 7: Auswertung des repräsentativen Zeitraums mit dem Performance Monitor Abbildung 8: Benchmarkergebnisse für den GlassFish-Anwendungsserver in Abhängigkeit von der Injektionsrate Abbildung 9: Benchmarkergebnisse des GlassFish-Anwendungsservers für Fertigungs- und Händlerdomäne Abbildung 10: Benchmarkergebnisse des GlassFish-Anwendungsservers nach Teilaufgaben Abbildung 11: Die durchschnittliche Prozessorauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 12: Die durchschnittliche Netzwerkauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 13: Die durchschnittliche Threadanzahl der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 14: Die durchschnittliche Anzahl der TCP-Verbindungen der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 15: Die durchschnittliche Anzahl der TCP-Fehler der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 16: Benchmarkergebnisse des GlassFish-Anwendungsservers bei unterschiedlichen Speichergrößen und einer Injektionsrate von Abbildung 17: Benchmarkergebnisse und Ressourcenverbrauch des GlassFish-Anwendungsservers bei unterschiedlichen Speichergrößen in Abhängigkeit von der Injektionsrate Abbildung 18: Stabilitätsanalyse der Benchmarkergebnisse des GlassFish-Anwendungsservers für ausgewählte Injektionsration Abbildung 19: Benchmarkergebnisse für den JBoss-Anwendungsserver in Abhängigkeit von der Injektionsrate Abbildung 20: Benchmarkergebnisse des JBoss-Anwendungsservers für Fertigungs- und Händlerdomäne Abbildung 21: Benchmarkergebnisse des JBoss-Anwendungsservers nach Teilaufgaben Abbildung 22: Die durchschnittliche Prozessorauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate... 50

10 Abbildung 23: Die durchschnittliche Anzahl von Seitenfehlern der Arbeitsspeicher der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss- Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 24: Die durchschnittliche Netzwerkauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 25: Die durchschnittliche Threadanzahl der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 26: Die durchschnittliche Anzahl der TCP-Verbindungen der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 27: Die durchschnittliche Anzahl der TCP-Fehler der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 28: Benchmarkergebnisse des JBoss-Anwendungsservers bei unterschiedlichen Speichergrößen und einer Injektionsrate von Abbildung 29: Benchmarkergebnisse und Ressourcenverbrauch des JBoss-Anwendungsservers bei unterschiedlichen Speichergrößen in Abhängigkeit von der Injektionsrate Abbildung 30: Stabilitätsanalyse der Benchmarkergebnisse des JBoss-Anwendungsservers für ausgewählte Injektionsration Abbildung 31: Einbruch der Prozessorauslastung beim JBoss-Anwendungsserver Abbildung 32: Benchmarkergebnisse der Anwendungsserver in Abhängigkeit von der Injektionsrate62 Abbildung 33: Benchmarkergebnisse der Anwendungsserver nach Teilaufgaben für die Injektionsraten 20 und Abbildung 34: Die durchschnittliche Prozessorauslastung der Anwendungsserver bei der Durchführung des SPECjAppServer2004-Bechmarks in Abhängigkeit von der Injektionsrate Abbildung 35: Die durchschnittliche Netzwerkauslastung der Anwendungsserver bei der Durchführung des SPECjAppServer2004-Bechmarks in Abhängigkeit von der Injektionsrate Abbildung 36: Die durchschnittliche Threadanzahl der Anwendungs- und Datenbankserver bei der Durchführung des SPECjAppServer2004-Bechmarks für ausgewählte Injektionsraten Abbildung 37: Die durchschnittliche Anzahl von TCP-Verbindungen der Anwendungs- und Datenbankserver bei der Durchführung des SPECjAppServer2004-Bechmarks in Abhängigkeit von der Injektionsrate Abbildung 38: Die Anzahl der aufgetretenen TCP-Fehler auf Treiberseite bei der Durchführung des SPECjAppServer2004-Bechmarks in Abhängigkeit von der Injektionsrate Abbildung 39: Verteilung der statistischen Varianz der Benchmarkergebnisse der Anwendungsserver für ausgewählte Injektionsration Abbildung 40: Variationspunkte und weiter führende Themenfelder... 70

11 Tabellenverzeichnis Tabelle 1: Vergleich von Mehrschichtarchitekturen... 8 Tabelle 2: Die Datenbankfüllrate in Abhängigkeit von der Injektionsrate (SPEC, 2006) Tabelle 3: Hardwarekonfiguration der Infrastruktur Tabelle 4: Softwarekonfiguration der Infrastruktur Tabelle 5: Relevante Performanzzähler Tabelle 6: Einfaktorielle Varianzanalyse der Benchmarkergebnisse aus Abbildung Tabelle 7: Werte für die Anpassung der TCP-Konfiguration unter Windows Tabelle 8: Einfaktorielle Varianzanalyse der Benchmarkergebnisse aus Abbildung Tabelle 9: Einfaktorielle Varianzanalyse bei einer Injektionsrate von 40 (konstante Konfiguration)... 58

12

13 1 Performanzevaluierung von Anwendungsservern 1 Einführung und Überblick 1.1 Motivation Anwendungen, die für den Einsatz in Unternehmen konzipiert sind, übersteigen täglich ihre bisherige Komplexität. Sie müssen in der Lage sein, enorme Mengen an Daten zu verwalten und dabei trotzdem andauernd, verlässlich und schnell auf Nutzeranfragen zu reagieren. Sie müssen Sicherheit garantieren, sich in eine heterogene Softwarelandschaft integrieren und dabei flexibel, wartbar und skalierbar sein. Mit der fortschreitenden Globalisierung und zunehmenden Nutzung des Internets in allen Unternehmensbereichen potenziert sich diese Komplexität. Dies wirft die Frage auf, wie man die schwierigen Anforderungen an die Unternehmensanwendungen der Zukunft erfüllen kann. Zum Glück ähneln sich viele der Probleme, die es in der Unternehmensdomäne zu lösen gilt, so stark, dass es Sinn macht, von den Lösungen anderer Unternehmen zu lernen. Es kristallisieren sich bewährte Praktiken heraus und die besten werden in Entwurfsmustern allgemeingültig beschrieben. Einen guten Einstieg in die Verwendung von Entwurfsmustern für Unternehmensanwendungen liefert Martin Fowler in (1). Hat man erst einmal diese Stufe erreicht, ist es ein kleiner Schritt zur Erstellung eines einheitlichen Programmrahmens als Basisumgebung für Unternehmenssoftware, das bereits Lösungen für eine Vielzahl der auftretenden Probleme mit sich bringt. Ein solcher Rahmen sollte in Zusammenarbeit vieler Unternehmen erstellt und erweitert werden, damit es universell einsetzbar bleibt. Ein Beispiel für die erfolgreiche Umsetzung eines allgemein einsetzbaren Programmrahmens ist die Java Platform, Enterprise Edition (Java EE). Diese beschreibt eine Mehrschichtarchitektur, die Komponenten in Anwendungscontainern bereit stellt, Integrationen mit anderen Unternehmensanwendungen standardisiert und dafür die Softwareentwicklung mit der plattformunabhängigen, objektorientierten Programmiersprache Java vorsieht. Java EE bietet damit eine solide und flexible Grundlage für die Entwicklung komplexer Unternehmenslösungen. Sie lässt sich zudem mit Hilfe umfangreicher Konfigurationsmöglichkeiten an das individuelle Problemfeld anpassen, um das reale Einsatzszenario abzubilden. Um die erstellten Lösungen für die Benutzung zur Verfügung zu stellen, werden Anwendungsserver eingesetzt. Es gibt viele verschiedene Anwendungsserver, welche die Java-EE-Spezifikation erfüllen. Diese zeigen jedoch ein unterschiedliches Leistungsverhalten und besondere Konfigurationseigenheiten. Daher stehen viele Unternehmen vor der Frage, welcher der Java-EE-konformen Anwendungsserver für den Einsatz in ihrem Unternehmen am besten geeignet ist. Da es aufgrund des enormen Aufwands vielen Unternehmen nicht möglich ist, alle verfügbaren Anwendungsserver anhand des tatsächlichen Anwendungsszenarios zu evaluieren, wurden Standardbenchmarks geschaffen. Diese bilden ein übliches Unternehmensproblemfeld und die entsprechenden Anwendungsszenarien ab. Mit Hilfe dieser Standardbenchmarks erhält man einen guten Überblick über die Einsatzfähigkeit aktueller Anwendungsserver und ist insbesondere in der Lage diese zu vergleichen. Eine Reihe solcher Standardbenchmarks für Java-Anwendungsserver wurde von einem Unterkomitee der Standard Performance Evaluation Corporation (SPEC) entwickelt, das sich unter anderen aus Vertretern von BEA, Hewlett-Packard, IBM, Intel, Oracle und Sun Microsystems zusammensetzt. Das SPECjAppServer2004-Benchmark (2) ist das aktuellste Standardbenchmark der SPEC und dient dieser Arbeit als Grundlage für die Evaluierung.

14 Einführung und Überblick 2 Viele Unternehmen besinnen sich heutzutage wieder auf ihre Kernkompetenzen und betreiben Outsourcing. Dies spiegelt sich auch in der Entwicklung und im Einsatz von Unternehmensanwendungen wieder. Während früher jeweils eigene Lösungen entwickelt wurden, besinnt man sich heute auf gemeinsame Standards und Projekte. Die daraus resultierende Unterstützung von Open- Source-Software durch die Industrie hat die Qualität und Wettbewerbsfähigkeit dieser freien Projekte erheblich gesteigert. Zu den populärsten freien Java-EE-konformen Anwendungsservern gehören JBoss (3) und GlassFish (4). Aufgrund ihrer weiten Verbreitung und ihrer umfassenden Fähigkeiten gewinnen sie für den Einsatz in Unternehmen zunehmend an Bedeutung. Bisher existieren keine Arbeiten, welche die Leistungsfähigkeit der beiden Server anhand des SPECjAppServer2004-Benchmarks miteinander vergleichen. Außerdem existieren nur vier SPECjAppServer2004-Benchmarks, bei denen Windows als Betriebssystem verwendet wurde. Diese Arbeit schließt diese Lücke, indem sie eine ausführliche Untersuchung des Leistungsverhaltens und der Ressourcenbeanspruchung des GlassFish- und des JBoss-Anwendungsservers für den Einsatz des SPECjAppServer2004-Benchmarks durchführt und die erzielten Ergebnisse gegenüberstellt. Damit liefert sie einen wichtigen Beitrag für die Vergleichbarkeit der beiden Anwendungsserver. 1.2 Überblick über diese Arbeit Java EE und andere für diese Arbeit relevanten Technologien werden zusammen mit den Verwendungsmustern für Anwendungsserver im Grundlagenkapitel 2 beschrieben. In diesem Kapitel gibt es zudem einen Überblick über Werkzeuge, die bei der Analyse von Anwendungsservern im Java- EE-Bereich dienlich sind. Der Hauptgrundlage dieser Arbeit, dem SPECjAppServer2004-Benchmark, ist mit Kapitel 3 ein eigenes Kapitel gewidmet. Darin ist neben einem Überblick über Benchmarks im Allgemeinen die Funktionsweise des Benchmarks erläutert und die für die Messung der Ergebnisse geschaffene Infrastruktur beschrieben. Vor der Untersuchung der beiden Anwendungsserver werden in Kapitel 4 verwandte Arbeiten vorgestellt. Dazu zählen andere Untersuchungen der beiden Anwendungsserver mit dem SPECjAppserver2004-Benchmarks sowie eine Untersuchung anhand von Minibenchmarks. Einige der hier beschriebenen Beobachtungen und Erkenntnisse dienten der Konfiguration der beiden Anwendungsserver oder liefern Erklärungen für deren Benchmarkresultate. Die beiden folgenden Kapitel beschreiben die Evaluierung der Anwendungsserver. Dabei werden zunächst die notwendigen Konfigurationsschritte zur Durchführung des Benchmarks beschrieben und dann die Benchmarkergebnisse der Server ausgewertet. Kapitel 5 ist dem GlassFish und Kapitel 6 dem JBoss gewidmet. In Kapitel 7 werden die Resultate für die beiden Anwendungsserver gegenübergestellt und miteinander verglichen. Zuletzt gibt Kapitel 8 eine Zusammenfassung der Arbeit und einen Ausblick über weitere Themen und offene Fragen.

15 3 Performanzevaluierung von Anwendungsservern 2 Grundlagen Dieses Kapitel beschreibt zunächst in Abschnitt 2.1 einige aktuelle Technologien, die für das Verständnis dieser Arbeit relevant sind. Im Anschluss werden in Unterkapitel 2.2 gängige Verwendungsmuster beim Einsatz von Anwendungsservern im Bereich von Unternehmenssoftware beschrieben. Das Unterkapitel 2.3 liefert einen Überblick über Werkzeuge, die bei der Analyse von Anwendungsservern nützlich sind. 2.1 Überblick über aktuelle Technologien Dieser Abschnitt liefert eine Einführung in die für diese Arbeit relevanten Technologien. Dazu wird in Abschnitt die Java Platform, Enterprise Edition (Java EE) vorgestellt und das Konzept der Enterprise JavaBeans (EJB) in Abschnitt vertieft. Der Abschnitt enthält schließlich einen Überblick über Anwendungsserver Java Platform, Enterprise Edition Seit der Veröffentlichung der Programmiersprache Java im Jahr 1995 gewann diese zunehmend an Bedeutung. Heute zählt sie zu den verbreitesten 1 Programmiersprachen für den Einsatz in Unternehmen. Ihre Popularität hat sie unter anderem der am 17. Dezember 1999 von Sun Microsystems veröffentlichten Java 2 Platform Enterprise Edition (J2EE) Spezifikation, v1.2 (5) zu verdanken. Diese vereinfachte die Entwicklung von Java-Programmen für Unternehmen, indem sie die Kosten und die Komplexität bei der Erstellung, Bereitstellung und Erweiterung von Diensten für Mehrschichtarchitekturen stark reduzierte. Dazu stellt J2EE eine Architektur zur Verfügung, um Komponenten in Anwendungscontainern plattformunabhängig, sicher und verlässlich bereit zu stellen. Diese Komponenten werden Enterprise JavaBeans (EJBs) genannt und sind im folgenden Abschnitt näher beschrieben. Die Container ermöglichen zudem die Veröffentlichung von Webressourcen und den Zugriff auf Enterprise Information Systems (EIS), wie zum Beispiel Datenbanken. Über die Jahre wurde J2EE erweitert und verbessert. J2EE 1.3 war die erste J2EE-Spezifikation, die als Java-Community-Prozess entwickelt wurde. Sie erschien im Jahr 2001 und enthielt vor allem bessere Integrationsmöglichkeiten für EIS sowie eine stark überarbeitete Fassung der EJBs. Im folgenden Jahr wurde J2EE 1.4 eingeführt, welche neben Verbesserungen der bestehenden APIs die Unterstützung für Webdienste als größte Neuerung mit sich brachte. Am 28. April 2006 wurde die aktuellste Version der J2EE-Familie veröffentlicht: Die Java Platform, Enterprise Edition (Java EE) Spezifikation, v5 (6). Außer der Einführung eines neuen Namensschemas wurde für diese Version der Fokus auf einfachere Entwicklung gelegt. Dazu wurde starker Gebrauch von den in Java Platform, Standard Edition 5.0 eingeführten Annotationen gemacht. Auf diese Weise konnte der Zusatzaufwand durch Deployment-Deskriptoren vor allem für kleine bis mittelgroße Anwendungen erheblich verringert werden. Zudem wurde die Unterstützung für Webdienste verbessert sowie die Enterprise JavaBeans 3.0 (EJB 3.0) als notwendiges Paket gefordert. Eine Übersicht über die Architektur von Java EE 5 ist in Abbildung 1 dargestellt. Es sind die verschiedenen Containertypen zu sehen. Der Webcontainer stellt Webinhalte, wie JavaServer Pages (JSP) oder Servlets bereit. Darauf kann insbesondere aus dem Applet-Container heraus, aber auch aus dem Container des Anwendungsklienten zugegriffen werden. Der EJB-Container stellt die EJBs zur Verfügung. Außerdem zeigt die Abbildung, dass diese Container auf eine normale Java- Implementierung aufsetzen. 1 Nach (62) die populärste Programmiersprache. (Stand März 2009.)

16 Grundlagen 4 Abbildung 1: Die Architektur der Java Platform, Enterprise Edition v5 (6) Java EE Connector Architecture Geschäftsanwendungen sollen in der Regel mit verschieden EIS zusammenarbeiten können. Die Java EE Connector Architecture (JCA) (7) ist ein offener Standard der es ermöglicht diese Verbindungen herstellerübergreifend aufzubauen. JCA spezifiziert drei Arten von Ressourcenadaptern, die dem Aufbau der Verbindung dienen: DataSource, ConnectionFactory und MessageListener. DataSource beschreibt eine Java-Database-Connectivity-konforme (JDBC) Datenquelle. Die ConnectionFactory repräsentiert eine zentrale Verbindungsverwaltung, die Sessions und Transaktionen steuert. Bei MessageListenern handelt es sich um nachrichtenbasierte Systeme. Über diese Adapter können die Softwaresysteme entsprechender Hersteller an den Anwendungscontainer angeschlossen werden Java Database Connectivity Die Java Database Connectivity (JDBC) ist ein Komponentenmodell der JCA, das einen einheitlichen Zugriff auf die relationalen Datenbanksysteme verschiedener Hersteller ermöglicht. Durch die Verwendung von JDBC können Anwendungen Unabhängigkeit von speziellen Datenbanklösungen erreichen. Dies erhöht deren Flexibilität, Wartbarkeit und Wiederverwendbarkeit. Erreicht wird diese Unabhängigkeit durch eine standardisierte Schnittstelle für die Herstellung einer Datenbankverbindung sowie für das Erzeugen und Ausführen von Datenbankanweisungen in der Structured Query Language (SQL). Die Datenbankanbindungen, die im Rahmen dieser Arbeit erstellt wurden, verwenden alle die JDBC-Programmierschnittstelle Enterprise JavaBeans Enterprise JavaBeans (EJB) ist eine serverseitige komponentenbasierte Architektur für J2EE (8). Sie vereinfacht die Entwicklung und Bereitstellung von portablen, verteilten, transaktionalen und sicheren Geschäftsanwendungen. EJB konzentriert sich dabei auf die Anwendungsserverschicht und

17 5 Performanzevaluierung von Anwendungsservern liefert Lösungen für Standardprobleme bei der Implementierung der Geschäftslogik, wie Bereitstellung, Persistierung, Sicherheit, Kontrolle von Nebenläufigkeit, Transaktionsverarbeitung und entfernte Aufrufbarkeit. Die erste EJB-Spezifikation (EJB 1.0) wurde am 24. März 1998 von Sun Microsystems veröffentlicht. Seit der Version 2.0 vom 22. August 2001 wird EJB als Java Community Process (JCP) weiter entwickelt. Die aktuellste Version ist EJB 3.0, die am 11. Mai 2006 verabschiedet wurde. Bis einschließlich J2EE 1.4 gab es drei Haupttypen von EJB-Komponenten (EJBs): Session Beans, Message-Driven Beans (MDB) und Entity Beans. Diese kapseln jeweils eine Teilfunktionalität, die zur Erstellung von komplexen Geschäftsanwendungen benötigt wird. Session Beans bilden die Geschäftslogik ab. Sie verarbeiten Nutzeranfragen und kommunizieren für deren Beantwortung mit den anderen Bean-Typen. Message-Driven Beans dienen der Verarbeitung von asynchronen Nachrichten. Entity Beans repräsentieren Datenobjekte. Die drei Bean-Arten werden in den folgenden Abschnitten näher beschrieben. Die EJB-Komponenten werden herstellerunabhängig entwickelt. Ihre Konfiguration für einen bestimmten Anwendungsserver wird über herstellerspezifische Deployment-Deskriptoren realisiert. EJBs können verteilt platziert werden und über eine Middleware per Remote Method Invocation (RMI) angesprochen werden. Dazu wird wahlweise das Java Remote Method Protokoll (JRMP) oder das Internet Inter-Orb Protokoll (IIOP) verwendet Session Beans Eine Session Bean entspricht einem Objekt, das eine Sitzung mit einer Klientenanwendung repräsentiert. Es beantwortet die Anfragen des Klienten an die verteilte Geschäftsanwendung und bietet ihm Zugriff auf die Geschäftsfunktionalitäten. Eine Session Bean kapselt die Geschäftslogik der Anwendung. Der Zugriff erfolgt über RMI-Aufrufe. Um Modularität zu wahren, ist in einer Session Bean in der Regel nur jeweils ein Teil der Geschäftslogik gekapselt. Deshalb ist es häufig notwendig, dass verschiedene Session Beans zur Beantwortung der Klientenanfragen miteinander kommunizieren. Diese können sich entweder im selben Anwendungsserver befinden oder auf einem entfernten. Befindet sich die aufgerufene Session Bean auf demselben Anwendungsserver kann statt RMI ein lokaler Methodenruf verwendet werden. Dies bringt einen enormen Performanzvorteil mit sich. Session Beans können zustandslos sein (Stateless Session Beans). Sie verlieren ihre Zustandsinformationen nach einer Anfrage. Dadurch sind sie in der Lage mehrere Klienten gleichzeitig zu bedienen. Da die Persistierung der Zustände entfällt, sind diese performanter als zustandsbehaftete Session Beans (Stateful Session Beans). Eine solche Session Bean übernimmt die gesamte Kommunikation mit einem Klient. Sie ist nur diesem zugeordnet und behält ihren Zustand zwischen den Anfragen. Sie wird erst nach dem Abschluss der Kommunikation entfernt Message-Driven Beans In Java EE werden Objekte zur Verarbeitung von Ereignissen und asynchronen Nachrichten durch einen eigenen EJB-Typ abgebildet: so genannte Message-Driven Beans (MDB). Sie basieren auf dem Java-Message-Service-Standard (JMS) und werden nicht über RMI angesprochen. MDBs werden in zwei Kategorien unterteilt: Queues und Topics. Eine Queue realisiert dabei Punkt-zu-Punkt- Kommunikation, während ein Topic nach dem Publish/Subcribe-Prinzip funktioniert. Sie warten auf ankommende Nachrichten und verarbeiten diese automatisch.

18 Grundlagen Entity Beans In J2EE werden Datenobjekte durch einen eigenen EJB-Typen abgebildet: so genannte Entity Beans. Hierbei handelt es sich um zustandsbehaftete verteilte Objekte. Sie enthalten einen Primärschlüssel und können Relationen mit anderen Entity Beans eingehen. Wenn eine Entity Bean die eigene Persistierung steuert, spricht man von Bean Managed Persistence (BMP). Eine solche Entity Bean enthält entsprechenden Programmcode zum Auslesen und Abspeichern von Zustandsdaten, zum Beispiel in einer Datenbank. Wird die Persistierung einer Entity Bean ausschließlich vom Anwendungscontainer gesteuert, spricht man von Container Managed Persistence (CMP). In diesem Fall generiert der Container automatisch den erforderlichen Quelltext: zum Beispiel SQL-Befehle für die notwendigen Datenbankaufrufe. Bei der Verwendung von Container Managed Persistence ist es erforderlich im Deployment-Deskriptor den Namen eines abstrakten Schemas einzutragen. Durch diesen wird im Regelfall die Datenbanktabelle identifiziert, auf welche die Entity Bean abgebildet wird. In EJB 3.0 wurden Entity Beans durch das Java Persistence API abgelöst und sind nur noch zu Kompatibilätszwecken enthalten EJB 3.0 Viele Entwickler waren mit der Komplexität und der schwachen Performanz der EJB-2.*- Realisierungen sehr unzufrieden. Die führte dazu, dass alternative Konzepte wie das Spring- Framework (9) entwickelt wurden, die sich vor allem durch ihre geringe Komplexität auszeichneten. Die EJB-3.0-Spezifikation sollte die EJB-Architektur wieder interessanter machen. Dazu wurde ihr Fokus klar auf die Vereinfachung der Entwicklung von EJBs gelegt. Um diese Vereinfachung zu erreichen wurden die folgenden Konzepte eingesetzt: Annotationen, Plain Old Java Objects (POJOs) und Entwurfsmuster für die lose Kopplung von Anwendungsteilen. Statt die Konfiguration der EJBs weiterhin über komplexe externe Deployment Deskriptoren durchzuführen, ist es mit EJB 3.0 möglich, die Konfigurationen mit Hilfe von Annotationen direkt im Quellcode durchzuführen. Bei der Entwicklung von EJBs mussten bis einschließlich Version 2.1 viele Namenskonventionen eingehalten werden und diverse Interfaces implementiert werden. Der Begriff Plain Old Java Object (POJO) steht für ein Objekt, dem diese Konventionen nicht auferlegt wurden. Solche Objekte weisen eine höhere Wartbarkeit und Wiederverwendbarkeit auf, weil weniger Abhängigkeiten bestehen. Eine der Hauptneuerungen in EJB 3.0 ist die Verwendung der Java Persistence API (JPA) für die Persistierung der Komponentenzustände. Die JPA verwendet POJOs und macht Entity Beans und den damit verbundenen Konfigurationsaufwand obsolet. Das im Rahmen dieser Arbeit eingesetzte Benchmark basiert auf J2EE 1.3 und damit auf dem komplexeren EJB-2.0-Standard, der keine der hier beschriebenen Vereinfachungen enthält. Da die Entwicklung des Nachfolgers dieses Benchmarks SPECappPlatform eingestellt wurde, ist unklar, ob es in absehbarer Zeit ein SPEC-Benchmark für EJB 3.0 geben wird Anwendungsserver Wie bereits in Abschnitt beschrieben, werden bei Java EE Anwendungscontainer zur Ausführung der Geschäftslogik verwendet. Diese Container werden von Java-EE-konformen Anwendungsservern bereitgestellt.

19 7 Performanzevaluierung von Anwendungsservern Java-EE-konforme Anwendungsserver Inzwischen gibt es eine Vielzahl von Anwendungsservern, die kompatibel zum Java-EE-5-Standard (6) sind: Apache Geronimo Apusic Application Server (v5.0) GlassFish Application Server v2 IBM WASCE 2.0 IBM WebSphere Application Server v7 JBoss JBossAS NEC WebOTX 8.1 Oracle Application Server 11 SAP NetWeaver 7.1 Sun GlassFish Enterprise Server 9.1 TmaxSoft JEUS 6 WebLogic Server v10.0 Im Rahmen dieser Arbeit werden der GlassFish Application Server v2 (GlassFish) und der JBoss JBossAS evaluiert. Beide erfüllen neben der aktuellen Java-EE-5-Spezifikation auch die J2EE-1.3- Spezifikation, auf der das SPECjAppServer2004-Benchmark basiert. Außerdem handelt es sich sowohl beim GlassFish als auch beim JBoss um aktive Open-Source-Projekte. Der Sun GlassFish Enterprise Server 9.1 ist eine leicht erweiterte Version des GlassFish Anwendungsservers und wird kommerziell von Sun Microsystems abgeboten Anwendungsserver für andere Plattformen Anwendungsserver gibt es nicht nur für die Java-Plattform. Auch für andere Programmiersprachen wurden vergleichbare Architekturframeworks geschaffen. Als Beispiel dafür seien die Internet Information Services (IIS) sowie der BizzTalk-Server jeweils von Microsoft genannt. Durch den Einsatz dieser Technologien ist es möglich Webdienste bereitzustellen, die auf dem.net-framework basieren. Dieses Framework ist das wichtigste Konkurrenzprodukt der Java-EE-Plattform. Mehr Informationen zu den Anwendungsservertechnologien von Microsoft sind unter (11) verfügbar, mehr Informationen zum.net-framework werden bei (12) bereitgestellt. 2.2 Verwendungsmuster Um einen besseren Überblick über den Einsatz von Java EE und Anwendungsservern zu schaffen, wird in diesem Kapitel zunächst deren bekannteste Einsatzart, die Vierschichtarchitektur, in Abschnitt beschrieben. Beispiele für Anwendungen, die eine solche Architektur aufweisen finden sich in den in Abschnitt beschriebenen Java BluePrints. Abschnitt schließlich beschreibt ein typisches Verfahren um mit hohen Lastzahlen umzugehen: das Clustering von Anwendungsservern Vierschichtarchitektur Die meisten der heutigen Geschäftsanwendungen folgen in ihrem Aufbau der in Abbildung 2 dargestellten Vierschichtarchitektur. Diese ist der Nachfolger der Zweischichtarchitektur, bei der eine Trennung von Frontend und Backend erfolgte und der Dreischichtarchitektur, die eine eigene Schicht (10)

20 Grundlagen 8 für die Geschäftslogik einführte. Vierschichtarchitekturen erhalten zudem eine eigene Schicht zur Aufbereitung der Präsentation. Abbildung 2: Überblick über die 4-Schicht-Architektur und die J2EE-spezifischen Komponentenmodelle (13) Die Visualisierung wird in einem Vierschichtszenario häufig von Webbrowsern realisiert. Der dargestellte Inhalt wird in der Präsentationsschicht aufbereitet. Die Informationen, die von der Geschäftslogik geliefert werden, werden dort zum Beispiel in ein grafisch ansprechendes, übersichtliches und verständliches Format überführt. Die Geschäftslogik bildet Geschäftsprozesse ab und verarbeitet die Daten, die von der Datenbankebene zur Verfügung gestellt werden. (Vergleiche Tabelle 1) Tabelle 1: Vergleich von Mehrschichtarchitekturen Ebene I Ebene II Ebene III Ebene IV 2-Schicht-Architektur Präsentation Datenbank Geschäftslogik 3-Schicht-Architektur Präsentation Geschäftslogik Datenbank 4-Schicht-Architektur Visualisierung Präsentationsaufbereitung Geschäftslogik Datenbank Für die Realisierung der Aufgaben der verschiedenen Ebenen kommen unterschiedliche Technologien zum Einsatz. Die Web-Browser sind in der Lage Standardformate wie die Hypertext Markup Language (HTML), Extensible Markup Language (XML) oder JavaScript darzustellen. In einigen Fällen werden sogar Java Applets für die Darstellung verwendet. Die aufbereiteten Inhalte erhalten diese per HTML oder XML. Generiert werden diese Inhalte mit Hilfe von Java Servlets, JSP oder ähnlichen Technologien. Um Geschäftslogik auszuführen und Geschäftsinformationen zu

21 9 Performanzevaluierung von Anwendungsservern ermitteln greift die Präsentationsaufbereitungsschicht per IIOP, SOAP oder JRMP auf die Geschäftsschicht zu, in der sich die EJBs befinden. Diese verwenden JDBC oder JCA für den Zugriff auf Datenbanken und andere EISe. J2EE ist für den Einsatz in vierschichtigen Architekturen vorgesehen. Die Anwendungsserver sind dabei in Ebene III angesiedelt und kapseln die Geschäftslogik Java Blue Prints Häufig steht man bei der Implementierung von Softwaresystemen für den Unternehmensbereich vor ähnlichen Problemen. Die besten Praktiken von Sun Microsystems, um solche Probleme mit Java EE zu lösen, sind auf der Webseite der Java BluePrints (14) zusammengetragen. Auf dieser Seite befinden sich neben Leitfäden und freien elektronischen Büchern über die Entwicklung auch viele komplexe Beispielanwendungen. Das größte und bekannteste Beispielprojekt ist die Java Pet Store Demo. Diese Anwendung realisiert eine Online-Tierhandlung und demonstriert aktuelle Java-EE-Technologien. Die Quellen stehen unter einer BSD-ähnlichen Lizenz zur freien Verwendung bereit Clustering Beim Einsatz von Anwendungsservern in Szenarien mit vielen unabhängigen Nutzeranfragen sind die Kapazitäten eines einzelnen Servers schnell ausgeschöpft. Auch mit dem Aufstocken der Hardware eines einzelnen Computersystems stößt man früher oder später an dessen Grenzen. Viel effizienter ist es, die Last möglichst gleichmäßig auf viele einzelne Computersysteme zu verteilen. Ein weiterer Vorteil, der sich dabei ergibt, ist die Toleranz gegenüber Ausfällen einzelner Systeme. Die Verwendung von mehreren einzelnen Servern für die Realisierung der Geschäftslogik wird als Clustering bezeichnet Sättigung Ein jedes System erreicht bei steigender Last irgendwann den Punkt der Sättigung. Bis zu diesem Punkt hat das System freie Kapazitäten. Eine Erhöhung der Anfragenanzahl führt zu einer Erhöhung des Durchsatzes, also der Anzahl der Antworten in einem gegebenen Zeitraum. Nach diesem Punkt führt die Erhöhung der Anfragenanzahl zu einer Minderung des Durchsatzes, weil das System bereits überlastet ist. Neue Anfragen führen dann dazu, dass sie die Threads, die Zugriff auf die Ressourcen benötigen, gegenseitig blockieren. Die Zeit, die der Nutzer auf seine Antwort warten muss, steigt dabei an. Abbildung 3 zeigt den Zusammenhang von Antwortszeit, Durchsatz und Auslastung der Systemressourcen. Um die Last trotzdem weiter erhöhen zu können ohne die Software zu verändern, müssen entweder die Kapazitäten des Systems durch Aufstocken der Hardware erhöht werden oder es müssen weitere Computersysteme hinzugenommen werden, damit die Last auf diese verteilt werden kann.

22 Grundlagen 10 Abbildung 3: Der Zusammenhang zwischen Antwortszeit, Durchsatz und Auslastung (15) Lastverteilung Eine gesonderte Rolle im Verbund nimmt das Computersystem ein, das die Anfragen auf die einzelnen Computerknoten verteilt: der Lastbalancierer. Hierbei kann es sich um einen der Teilnehmer im Cluster oder um ein eigenes, nur für den Zweck der Lastverteilung vorgesehenes, Computersystem handeln. Dieses kann im schlechtesten Fall den Flaschenhals des Systems darstellen. Es sollte vermieden werden, dass ein Ausfall des Lastverteilers einem Ausfall des Gesamtsystems gleichkommt, weil in diesem Fall keine Anfragen mehr weitergeleitet werden können. Es gibt verschiedene Algorithmen mit denen eine Anfrage einem Computersystem zugeordnet wird. Am einfachsten ist es, zufällig einen bekannten Anwendungsserver auszuwählen. Eine weitere einfache Möglichkeit ist die Verwendung des Round-Robin-System. Dabei wird nacheinander jedem Computersystem eine neue Anfrage zugeordnet und dann von vorn begonnen. Weitere Verbesserungen sehen zum Beispiel die Zuordnung von Folgeanfragen an dasselbe Computersystem vor, das schon die vorhergehenden Anfragen beantwortete. Dabei hofft man, dass die notwendigen Informationen noch im Speicher des entsprechenden Systems verfügbar sind und nicht erneut durch einen Datenbankzugriff oder eine Berechnung ermittelt werden müssen. Auch die Anpassung der Verteilung an die Kapazitäten und die Auslastung der einzelnen Computersysteme ist denkbar. Dafür ist es allerdings notwendig, dass der Lastverteiler in der Lage ist, diese Informationen zu ermitteln Horizontales und vertikales Clustering Werden Anwendungsserver, wie bereits beschrieben, auf mehreren einzelnen Computersystemen platziert und zu einem Verbund (Cluster) zusammengefügt, so spricht man von horizontalem Clustering. Die Bildung eines Verbundes mehrerer Anwendungsserver auf einem Computersystem wird als vertikales Clustering bezeichnet. Zudem ist es natürlich möglich, vertikales und horizontales Clustering zu verbinden und mehrere Computersysteme mit jeweils mehreren Anwendungsservern auszustatten.

23 11 Performanzevaluierung von Anwendungsservern Performanz- und Failover-Cluster Bei der Bildung von Clustern wird in der Regel entweder das Ziel verfolgt, die Performanz zu verbessern oder die Verlässlichkeit des Systems zu erhöhen. Im ersten Fall spricht man von Performanz-Clustern, im zweiten Fall von Failover-Clustern. Zur Performanzverbesserung wird horizontale Clustering eingesetzt, bei dem mehrere gleichartige Computersysteme zu einem Verbund zusammengeschaltet werden. Ein Lastbalancierer verteilt die Anfragen möglichst so, dass alle Systeme, in Relation zu ihren Kapazitäten, gleich ausgelastet sind. Im Idealfall kann die Leistungsfähigkeit des Gesamtsystems durch das hinzunehmen neuer Systeme beliebig verbessert werden, um somit beliebig große Lasten zu bewältigen. Um die Systemverlässlichkeit zu erhöhen genügt in einigen Fällen die Verwendung vertikaler Cluster. Dabei sind mehrere Anwendungsserver auf einem Computersystem installiert. Wenn nun einer der Server ausfällt, übernimmt ein anderer seine Aufgaben. Dies sichert das Gesamtsystem gegen den Ausfall einzelner Anwendungen und Anwendungsserver ab, kann aber den Verlust eines Computersystems nicht kompensieren. Um auch Systemausfälle bewältigen zu können, wird horizontales Clustering eingesetzt. Die Anwendungsserver werden auf verschiedene Computersysteme platziert; fällt ein System aus, so übernehmen die anderen dessen Aufgaben. Für die Realisierung eines Failover-Clusters ist es notwendig, dass alle Kopien eines Servers über denselben Zustand verfügen. Um dies zu erreichen müssen sich die einzelnen Server synchronisieren Skalierbarkeit Die Verdopplung der Anzahl gleichartiger Computersysteme führt im Idealfall zu einer Verdopplung der Gesamtsystemleistung des Systems. Die Systemleistung wird dabei als proportional zur maximalen Last betrachtet, die das System in der Lage ist zu bewältigen. Zeigt ein System ein solches Verhalten, skaliert es gut. Bei der Hinzunahme neuer Computersysteme spricht man von horizontaler Skalierung, während die Aufstockung der Hardware eines vorhandenen Systems als vertikale Skalierung bezeichnet wird. (16) 2.3 Werkzeuge Es gibt eine Reihe von Werkzeugen, welche die Analyse des Verhaltens von Anwendungsservern insbesondere im Hinblick auf Performanz und Lastverteilung unterstützen. Dieser Abschnitt beschreibt die wichtigsten Werkzeuge, die im Rahmen dieser Arbeit eingesetzt wurden Werkzeuge für die Performanzoptimierung Jede Anwendung erreicht bei genügend hoher Last einen Sättigungszustand, ab dem ihr Verhalten nicht mehr zufriedenstellend ist. Ziel der Performanzoptimierung ist es, diesen Punkt weiter nach hinten zu verschieben, indem man den aktuellen Flaschenhals der Anwendung identifiziert und beseitigt. Allgemein gesprochen möchte man die Ressourcenauslastung einer Anwendung verringern, während sie weiterhin das spezifizierte Verhalten erbringt. Ziel ist dabei die Verringerung der Antwortszeiten für den Endnutzer und die Erhöhung des Durchsatzes der Anwendung. Im ersten Schritt muss dazu das Performanzverhalten der Anwendung erfasst werden. Dann werden die Daten analysiert und mögliche Flaschenhälse identifiziert. Als nächstes wird eine Lösung zur Weitung oder Umgehung des Flaschenhalses gesucht. Dieser Prozess wird iterativ wiederholt, bis man letztlich ein akzeptables Systemverhalten erzielt.

24 Grundlagen 12 Dieser als Performanztuning bezeichnete Vorgang kann im Bereich von Java-EE-Anwendungen auf verschiedenen Ebenen erfolgen. Abbildung 4 zeigt einen Überblick über das Schichtenmodell für Java EE. Die Anwendungen werden vom entsprechenden Container verwaltet, der innerhalb eines Anwendungsservers platziert ist, welcher durch eine Java virtuellen Maschine (JVM) ausgeführt wird. Diese setzt auf ein Betriebssystem auf, welchem eine Hardwarekonfiguration als Ausführungskontext dient. Jede dieser Schichten kann einen Flaschenhals darstellen und daher einzeln analysiert und optimiert werden. Java-EE-Anwendungen Web-/EJB-Container Anwendungsserver Java Virtuelle Maschine Betriebssystem Hardware Abbildung 4: Das Schichtenmodell bei der Ausführung von Java-EE-Anwendungen Erschwerend kommt noch hinzu, dass es sich bei Java EE um ein verteiltes System handelt. Dies bedeutet, dass potentiell jeder einzelne Computerknoten optimiert werden muss, weil er einen Flaschenhals darstellen könnte Performanzindikatoren Zunächst stellt sich für die Performanzoptimierung die Frage, wie man Performanz misst. Im Allgemeinen werden Ressourcenauslastung, Durchsatz und Antwortszeit als Anzeiger für die Performanz verwendet. Zudem stellt sich die Frage, welche Ressourcen erfasst werden sollten. In der Regel gilt die Prozessorauslastung als Hauptindikator. Aber auch die Arbeitsspeicher-, Netzwerk- und Festplattenauslastung können für eine Analyse von Nutzen sein, da sie Flaschenhälse des Systems bilden können. Außerdem können nach Bedarf Betriebssystemressourcen, wie die Anzahl der Verbindungen und Threads und die Ressourcen der JVM, wie die Anzahl der erzeugten Objekte, der Füllstand der Pools oder das Verhalten des Garbage Collectors, erfasst werden. Des Weiteren kann es von Vorteil sein, Monitore in den eigenen Anwendungen zu platzieren. Ausführliche Betrachtungen relevanter Performanzindikatoren für J2EE finden sich in (15). Ergänzende Erkenntnisse finden sich in (17), welches vor allem auf den Bereich der Webdienste fokussiert. In der Industrie gibt es teilweise eigene Indikatoren für Performanz. Ein Beispiel für einen solchen Industrieindikator ist der SAP Application Performance Standard (SAPS) (18), der als Vergleichswert für den Durchsatz beim SAP Standard Application Benchmark dient.

25 13 Performanzevaluierung von Anwendungsservern Werkzeuge zur Erfassung von Performanzindikatoren Für die Erfassung der Performanzwerte gibt es je nach betrachteter Schicht eine Vielzahl von APIs und Werkzeugen. Auf Anwendungsebene kann man zum Beispiel die Instrumentierung von Quelltexten verwenden, um Performanzzähler zu platzieren. Dies kann entweder manuell oder automatisiert mit Hilfe eines Werkzeuges erfolgen. Um einen tiefen Einblick in das Verhalten von Applikationen zu erlangen können so genannte Profiler eingesetzt werden, die in der Regel auf Quellcode- oder Bytecodeinstrumentierung basieren. Eine ausführliche Betrachtung der Profiler, die für den Einsatz in J2EE-Anwendungen geeignet sind, ist in (19) enthalten. Ein Beispiel für einen solchen Profiler ist der NetBeans Profiler, der aus dem JFuild-Projekt hervorgegangen ist und in die Entwicklungsumgebung NetBeans integriert wurde. Auf der Ebene der Anwendungsserver können entweder herstellerspezifische Werkzeuge, wie der JBoss Profiler oder die in Abschnitt vorgestellten Java Management Extensions (JMX) eingesetzt werden. Die JVM kann unter Zuhilfenahme der verfügbaren Schnittstellen, durch die Auswertung von Log-Dateien oder durch Werkzeuge wie HProf analysiert werden. Für die Untersuchung der Performanzwerte der Betriebssystemschicht liefert jedes Betriebssystem eigene Werkzeuge und Möglichkeiten. Unter OpenSolaris beispielsweise steht mit DTrace ein mächtiges Werkzeug für die Einsichtnahme in die verwendeten Ressourcen einer Anwendung bereit. Unter Windows können viele Informationen über die Systemressourcen mit Hilfe des Performance Monitors (Perfmon) ermittelt werden. Zudem steht bei Windows mit der Windows Management Instrumentation (WMI) eine Technologie zur Verfügung, die Zugriff auf eine Vielzahl von Systeminformationen gewährt. Mit dem.net Framework liefert Microsoft eine komfortable Möglichkeit aus eigenen Anwendungen heraus auf die Informationen, die Windows über Performanzzähler und WMI bereitstellt, zuzugreifen. Im Rahmen diese Arbeit wurde unter anderem eine verteilte.net-anwendung erstellt, die Performanzdaten auf den einzelnen Computerknoten erfasste und in einer zentralen Instanz akkumulierte. Dieses eigene Werkzeug wurde allerdings durch die Verwendung von Perfmon und Logman, welches die entfernte Steuerung von Perfmon erlaubt, ersetzt. Auf welche Weise Perfmon für die Überwachung der Ressourcenauslastung bei der Durchführung der Benchmarks eingesetzt wurde, ist in Abschnitt beschrieben Kosten von Performanzmessungen Die Instrumentierung der einzelnen Schichten, die Erfassung und die Akkumulation der Performanzdaten rufen eine zusätzliche Belastung der überwachten Ressourcen hervor. Je genauer das Verhalten nachvollzogen werden soll, desto mehr Messwerte müssen erfasst werden. Das bedeutet sowohl, dass sehr viele Performanzzähler eingesetzt werden sollten, als auch, dass diese möglichst oft ausgelesen werden müssen. Daher muss ein Kompromiss zwischen Anzahl und Genauigkeit der erfassten Werte und möglicher Beeinflussung dieser Werte gefunden werden, der es ermöglicht, die erforderlichen Schlussfolgerungen zu ziehen und dabei das Verhalten nur marginal zu beeinflussen. Außerdem sollte das Verhalten mit unterschiedlichen Messkonfigurationen erfasst werden, um den Einfluss der Messungen ableiten zu können. Dazu kann zum Beispiel der Lastgenerator die Antwortszeiten und den Durchsatz mit und ohne installierte Messinstrumentierung des Anwendungsservers ermitteln und vergleichen Java Management Extensions Früher hatten viele Anwendungsserver jeweils eigene Schnittstellen und Mechanismen für die Konfiguration und Ermittlung von Performanzinformationen. Dies machte die Administration und

26 Grundlagen 14 Erfassung von Performanzdaten sehr aufwändig. Die Java Mangement Extensions (JMX) API ist eine einheitliche Schnittstelle zum Verwalten und Überwachen von Java-EE-Anwendungen und der JVM. Sie wurde im Rahmen eines Java Community Prozesses (JCP) als Java Specification Request (JSP) 3 entwickelt (20). Mit JMX ist es möglich: Anwendungskonfigurationen zu konsultieren und zu verändern Statistiken über das Anwendungsverhalten zu erstellen und zur Verfügung zu stellen Informationen über Zustandsänderungen und fehlerhafte Bedingungen zu erhalten Entwicklungs- und Managementlösungen für J2EE mit geringem Zeitaufwand zu erstellen J2EE-Anwendungen in bestehende Managementsysteme zu integrieren ein einheitliches Managementwerkzeug für die Plattformen mehrerer Hersteller zu verwenden eine Plattformimplementierung (von einem entfernten Rechner) mit verschiedenen Managementtools zu verwenden (20), (15) Die Performanzinformationen werden von Managed Beans (MBeans) zur Verfügung gestellt. MBeans ähneln den anderen EJB-Arten, verfügen zusätzlich aber über Methoden zum Lesen und Schreiben von Konfigurationen und Zuständen des Anwendungsservers. Den Zugriff auf diese gewährt der MBean-Server im JMX-Agenten. Ausführliche Informationen über JMX liefert (20). In (15) ist beschrieben, wie sie im Kontext von Performanzverwaltung und optimierung eingesetzt werden können Skripte Bei der Durchführung von komplexen verteilten Anwendungen, wie dem SPECjAppServer2004- Benchmark, müssen häufig redundante Aktionen auf unterschiedlichen Computerknoten in einer festgelegten Reihenfolge durchgeführt werden. Bei der Konfiguration des JBoss für einen neuen Benchmarklauf beispielsweise mussten zunächst die alten Domänen entfernt, dann die Benchmarkeinstellungen gesetzt, darauf hin das Specj-Kit ausgeführt und schließlich einzelnen Anwendungsteile in der richtigen Reihenfolge gestartet werden. Um diesen Prozess nicht jedes Mal von Hand durchführen zu müssen, können Skriptsprachen verwendet werden. Unter Windows bietet sich hierfür der Einsatz von Batch-Dateien an. Diese lassen sich sehr schnell und zielgerichtet erstellen und einsetzen. Obwohl Batchskripte schnell erstellt werden können, unterliegen sie zumindest und Windows XP starken Einschränkungen, weil viele Befehle nicht zur Verfügung stehen und ein Debugging nicht möglich ist. Damit sie für den Einsatz im beschriebenen Szenario tauglich wurden, war es notwendig, zusätzlich die Werkzeuge der Sysinternals Suite (21) und des Microsoft Windows Server 2003 Resource Kit (22) einzusetzen. Für die Entwicklung von Batch-Skripten stehen neben Texteditoren inzwischen spezielle Entwicklungsumgebungen bereit, die es dem Entwickler sogar ermöglichen die Skripte schrittweise auszuführen und den Zustand der verwendeten Variablen zu überwachen. Im Rahmen dieser Arbeit wurden GO!Script 3.0 (23) und Stepping Software 1.1 (24) verwendet.

27 15 Performanzevaluierung von Anwendungsservern Statistische Datenanalyse Bei der Analyse der Ergebnisse einer Performanzdatenerfassung steht man häufig vor der Frage ob einzelne Messreihen miteinander korrelieren, also ob gemessene Werte von einander abhängen. Mit der Beantwortung von solchen und ähnlichen Fragen beschäftigt sich die statistische Datenanalyse. Zu den Werkzeugen, die der Beantwortung von Fragen der statischen Analyse von Daten dienen, zählen R (25), SPSS und Microsoft Excel. Für diese Arbeit wurde der Einsatz von R und Microsoft Excel evaluiert. R wurde durch den Einsatz von Microsoft.NET mit Hilfe eines selbsterstellten eingebetteten Programms in Microsoft Excel integriert. Auf diese Weise konnten die erfassten Benchmarkergebnisse automatisch aus den Tabellen extrahiert und in R eingespeist werden. Die von R erzeugten Ergebnisse wurden dann von dem eingebetteten Programm ausgelesen und verwendet, um wiederum einen Teilbereich der Excel-Mappe zu füllen. R wurde vor allem für die Bestimmung der Abhängigkeiten zwischen mehreren Wertpaaren mit Hilfe des Chi-Quadrat-Tests verwendet. Beim Chi-Quadrat-Test wird die Hypothese überprüft, ob mehrere Reihen mit Wertpaaren unabhängig von einander sind. Als Ergebnis liefert dieser Test einen p-wert. Ist dieser Wert kleiner als ein vorher festgelegtes Signifikanzniveau, so kann davon ausgegangen werden, dass die Datenreihen abhängig sind. Das Signifikanzniveau ist in der Regel bei 0,05. Dies bedeutet, dass die Irrtumswahrscheinlichkeit fünf Prozent beträgt. Ist der p-wert kleiner als das Signifikanzniveau, so gilt es als statistisch gesichert, dass es einen Zusammenhang zwischen den beiden Datenreihen gibt. Der Umkehrschluss gilt allerdings nicht. Ist der p-wert größer als das Signifikanzniveau, kann man lediglich feststellen, dass die Daten nicht dagegen sprechen, dass es keinen Zusammenhang gibt. Microsoft Excel verfügt ebenfalls über umfangreiche Fähigkeiten für die Datenanalyse. Vor allem die Korrelationsanalyse wurde für die Auswertung der Benchmarkergebnisse eingesetzt. Excel stellt dazu die Funktion KORREL bereit, welche den Korrelationskoeffizienten zwischen mehreren Messreihen berechnet. Als Ergebnis erzeugt diese Funktion ein Korrelationsfeld, das den Korrelationskoeffizienten für jedes mögliche Messreihenpaar darstellt. Der Korrelationskoeffizient gibt an, in wie weit zwei Messreihen gemeinsam variieren. Er liegt immer im Bereich von -1 und +1. Ein Korrelationskoeffizient von nahezu +1 bedeutet, dass hohen Werten der einen Messreihe hohe Werte der anderen zugeordnet sind. Im Gegensatz dazu bedeutet ein Korrelationskoeffizient von nahezu -1, dass hohen Werten der einen Messreihe niedrige Werte der anderen zugeordnet sind. Ist der Koeffizient sehr klein, so ist die Wahrscheinlichkeit sehr hoch, dass die beiden Messreihen unabhängig sind. Zusätzlich zur Korrelationsanalyse wurde die einfaktiorielle Varianzanalyse ( analysis of variance, Anova) mit Hilfe von Excel durchgeführt. Diese Analyse überprüft die Hypothese, dass eine Wahrscheinlichkeitsverteilung für alle Stichproben gilt und stellt sie der Alternative gegenüber, dass den Stichproben unterschiedliche Wahrscheinlichkeitsverteilungen zugrundeliegen. Weitere Informationen zum Ausführen statistischer und technischer Analysen mit den Analysefunktionen von Microsoft Excel finden sich unter (26). Da der Chi-Quadrat-Test die Normalverteilung der Daten voraussetzt und diese Forderung im Rahmen der vom Benchmark erfassten Daten in der Regel nicht gesichert werden kann, wurden zusätzlich Korrelationstests zur Analyse der Ergebnisse verwendet. Korrelationstests prüfen auf lineare Abhängigkeit ohne Annahmen über die Verteilung der Daten zu treffen.

28 Grundlagen Selbsterstellte Werkzeuge Im Laufe der Durchführung dieser Arbeit wurden häufig kleine Werkzeuge benötigt, die einem speziellen Zweck dienen. Aus diesem Bedürfnis heraus sind viele Werkzeuge entstanden, die zur Unterstützung der Arbeit dienten. Einiges ließ sich mit Batchskripten realisieren, häufig wurde das.net-framework zur Erstellung dieser Werkzeuge eingesetzt. Zu den erstellten Werkzeugen zählen: Ein komplexes System aus Batch-Skripten, für die automatische Durchführung der Benchmarks, das in Abschnitt beschrieben ist. Das Excel-Addin für die Auswertung der in Excel erfassten Daten mit R, das in Absatz beschrieben ist. Ein lokaler Monitor für die Erfassung von Systemressourcen und ein verteiltes Programm, das auf diese Monitore zugreift und die erfassten Daten akkumuliert. Es wurde später durch Perfmon ersetzt. Ein.NET-Programm für die Erfassung von Threadzuständen und den Gründen, warum sich diese im Wartezustand befinden. Ein.NET-Programm für die Auswertung der Benchmarkergebnisse. Es erstellt eine Übersicht über alle erfassten Benchmarkresultate. Ein.NET-Programm zur Unterstützung bei der Erzeugung von Performanzzählern. Obwohl Batchskripte schnell erstellt werden können, unterliegen sie zumindest und Windows XP starken Einschränkungen, weil viele Befehle nicht zur Verfügung stehen und ein Debugging nur eingeschränkt möglich ist. In den Problemsituationen in denen Batchskripte an ihre Grenzen stoßen, bietet sich zum Beispiel das.net-framework als Ergänzung an. Die Entwicklung eines Programms dauert damit etwas länger, dafür ist es wesentlich mächtiger und vor allem bei der Entwicklung von komplexeren Werkzeugen zu empfehlen.

29 17 Performanzevaluierung von Anwendungsservern 3 Das SPECjAppServer2004-Benchmark Die in dieser Arbeit betrachteten Anwendungsserver wurden mit Hilfe des SPECjAppServer2004- Benchmarks verglichen. Vor der ausführlichen Beschreibung des Benchmarks im Abschnitt 3.2 bietet dieses Kapitel zunächst in Unterkapitel 3.1 einen Überblick über die unterschiedlichen Benchmarkarten. 3.1 Einführung Benchmarks Häufig gibt es viele gleichartige Systeme unterschiedlicher Hersteller, welche die gleiche Problemdomäne adressieren und Lösungen für deren Probleme bereitstellen. Um diese Systeme zu vergleichen werden Benchmarks eingesetzt. Benchmarks liefern in der Regel eine definierte Last als Eingabe und Analysieren das Ausgabeverhalten des getesteten Systems anhand gegebener Kriterien. Für viele Industriezweige gibt es Benchmarks, die branchenweit anerkannt sind und verwendet werden. Für den Vergleich von Grafikkarten ist das zum Beispiel die 3DMark-Reihe der Firma Futuremark. Werden solche Benchmarks in Zusammenarbeit der wichtigsten Vertreter einer Branche erstellt, um die Bedürfnisse der Branche so genau wie möglich abzubilden, so spricht man von Standardbenchmarks. Daneben gibt es auch Benchmarks, die von einer einzelnen Firma, teilweise nur für den internen Gebrauch, erstellt wurden. In der Regel ist das Herzstück eines Benchmarks für den Anwendungsserverbereich der aktive Systemteil, der die Last generiert: der so genannten Loadrunner. Er erzeugt eine definierte, gegebenenfalls konfigurierbare Last und überprüft das Verhalten des getesteten Systems anhand von festgelegten Kriterien. Die Ergebnisse werden dann ausgewertet und können mit denen analoger Systeme verglichen werden Minibenchmarks Manchmal ist es notwendig, nur einen gewissen Systemteil oder nur ein gewisses Kriterium genauer zu untersuchen. Außerdem kann man Benchmarks erstellen, die das Verhalten des Systems in einem genau spezifizierten Anwendungskontext evaluieren. Dazu können kleine, speziell zugeschnittene Benchmarks verwendet werden. Mit diesen kann man zum Beispiel das Verhalten unterschiedlicher Webcontainer für einen Anwendungsserver bei einer hohen Zahl von leichtgewichtigen Webanfragen untersuchen. Im Anwendungsserverbereich ist es interessant, das Verhalten des Web- und EJB- Containers sowie der Persistierungsschicht zu untersuchen. Außerdem ist es sinnvoll, die Abhängigkeit der Performanzeigenschaften von den Systemressourcen zu untersuchen. Besondere Beachtung sollten dabei Prozessor, Arbeitsspeicher und Netzwerk finden, da sie häufig die Flaschenhälse bilden. Der Vorteil solcher Minibenchmarks liegt klar auf ihrem Fokus und ihrem geringen Implementierungsaufwand. Sie sind besonders gut geeignet, um ungewöhnliches Verhalten und Flaschenhälse näher zu untersuchen, sagen aber wenig über das Verhalten des Anwendungsservers im tatsächlichen Einsatzszenario aus. Eine zusätzliche Erstellung, Durchführung und Auswertung solcher Minibenchmarks hätte den Rahmen dieser Arbeit gesprengt. Außerdem existiert bereits eine Evaluation des JBoss- und des GlassFish-Anwendungsservers anhand gezielter Minibenchmarks. Diese wird in Unterkapitel 4.1 vorgestellt.

30 Das SPECjAppServer2004-Benchmark Individuallösungen Neben den in Abschnitt beschriebenen Minibenchmarks kommen bei vielen Unternehmen auch komplexe eigene Benchmarklösungen zum Einsatz. Diese Bilden die Problemdomäne des Unternehmens und das entsprechende Anwendungsszenario sehr viel genauer ab als die in Abschnitt beschriebenen Standardbenchmarks. Allerdings sind sie mit einem hohen zusätzlichen Aufwand für das entsprechende Unternehmen verbunden. Dies gilt insbesondere dann, wenn dieses Benchmark so allgemeingültig sein soll, dass es mit einem Großteil der vielen verfügbaren Anwendungsserver funktioniert Standardbenchmarks Um den enormen Aufwand der Evaluierung verschiedener Anwendungsserver für die jeweiligen Unternehmen zu verringern, wurden Standardbenchmarks geschaffen. Diese dienen als Maß für die Leistungsfähigkeit der Anwendungsserver in einer Unternehmensdomäne. Dazu bilden sie ein Anwendungsszenario ab, dass die alle Anwendungen der Unternehmen dieser Domäne möglichst genau repräsentiert. Die Hersteller von Anwendungsservern können diese anhand des Standardbenchmarks evaluieren, die erzielten Ergebnisse veröffentlichen und sich auf diese Weise bezüglich der Leistungsfähigkeit ihrer Server mit den anderen Herstellern vergleichen. Eine Reihe solcher Standardbenchmarks für Java-Anwendungsserver wurde von einem Unterkomitee der Standard Performance Evaluation Corporation (SPEC) entwickelt, das sich unter anderen aus Vertretern von BEA, Hewlett-Packard, IBM, Intel, Oracle und Sun Microsystems zusammensetzt. Die SPEC ist eine gemeinnützige Organisation, die sich dem Ziel widmet eine Reihe von standardisierten Benchmarks zu erstellen, zu pflegen und zu unterstützen, die für die neuste Generation von hochperformanten Computern eingesetzt werden können. (27) Neben der Entwicklung von Benchmarkanwendungen validiert und veröffentlicht die SPEC die jeweils erzielten Benchmarkergebnisse. Das SPECjAppServer2004-Benchmark (2) ist das aktuellste Standardbenchmark der SPEC für den Bereich von Anwendungsservern und dient dieser Arbeit als Grundlage für die Evaluierung. Eine weitere bekannte Organisation, die sich mit der Erstellung von Standardbenchmarks für den Anwendungsserverbereich befassen ist das Transaction Processing Performance Council (28), dessen Fokus auf Transaktions- und Datenbanksystemen liegt. 3.2 SPECjAppServer2004 Das SPECjAppServer2004-Benchmark ist ein industrielles Standardbenchmark, um die Performanz und die Skalierbarkeit von J2EE-Technologie-basierten Anwendungsservern zu messen. (29) Es wurde von der von einem Unterkomitee der SPEC (siehe dazu Abschnitt 3.1.3) entwickelt Geschäftsszenario Die Nutzlast für das getestete System basiert auf einer verteilten Anwendung, die den Anspruch hat, groß und komplex genug zu sein, um ein reales E-Geschäftssystem zu repräsentieren. Um diesem Anspruch gerecht zu werden, orientiert sich diese Anwendung an den softwaretechnischen Charakteristika der Automobilindustrie. Es gibt verschiedene Domänen, deren Zusammenspiel den Umfang der gesamten Anwendung ergibt: Die Kundendomäne, die Händlerdomäne, die Produktionsdomäne, die Zuliefererdomäne und das Herzstück: die Unternehmensdomäne. Diese Domänen und ihre Kommunikationswege sind in

31 19 Performanzevaluierung von Anwendungsservern Abbildung 5 dargestellt. Händler können über die Webseiten des virtuellen Unternehmens den aktuellen Autokatalog einsehen. Sie können Automobile erwerben, verkaufen sowie den aktuellen Inventarzustand überwachen. Das Unternehmen bekommt die Bauteile für die Autos von externen Zulieferern. Diese werden verwaltet und Bauteilbestellungen nach Bedarf durchgeführt. Händler Händlerdomäne Kundendomäne Unternehmensdomäne Lieferanten Zuliefererdomäne Produktionsdomäne Abbildung 5: Das Geschäftsszenario des SPECjAppServer2004-Benchmarks (30) Die Kundendomäne verwaltet die Bestellungen der Kunden des Unternehmens: den Autohändlern. Sie wird von einer Anwendung zur Bestellungseingabe realisiert. Diese verfügt über Funktionen zum Erstellen und Stornieren von Bestellungen, sowie zum Ermitteln des aktuellen Zustandes von Bestellungen und Kunden. Eine Bestellung von mehr als 100 Automobilen wird als Großbestellung gesondert vom System behandelt. Um die Händlerdomäne abzubilden, wird eine Webanwendung eingesetzt. Sie ist an die Kundendomäne angeschlossen und erlaubt es, den Händlern ihre Nutzerkonten einzusehen, einen virtuellen Einkaufswagen zu verwalten und Automobile zu verkaufen sowie zu erwerben. Die Aufgaben der Unternehmensdomäne sind die Verwaltung der Kunden und Zulieferer sowie der Bauteile für die Automobile. Diese Domäne bietet Funktionen zum Registrieren von Kunden, zum Ermitteln von Preisnachlässen und zum Überprüfen von Krediten. Die Produktionsdomäne repräsentiert die Steuerung für die Fertigungsstrecken der Automobilfabrik. Davon gibt es zwei Stück: eine für die normale Produktion und eine, um Großbestellungen abzufertigen. Der Normalbetrieb läuft nach einem festen Plan und produziert eine vorherbestimmte Anzahl von Automobilen. Die Fertigungsstrecke für Großbestellungen hingegen läuft nur bei Bedarf, also wenn eine Großbestellung von der Kundendomäne erzeugt wird. Die Arbeitseinheiten entsprechen dabei den Produktionsaufträgen für eine bestimmte Anzahl an Fahrzeugen eines gewählten Modells. Sobald ein Produktionsauftrag erstellt wurde, wird der entsprechende Materialbedarf ermittelt und aus dem Lager entfernt. Während die Fahrzeuge sich auf der Fertigungsstrecke befinden wird ihr Zustand aktualisiert. Sobald der Produktionsauftrag abgeschlossen ist, wird er als erledigt markiert und die hergestellten Fahrzeuge werden dem Bestand hinzugefügt. Realisiert wird das ganze durch eine Anwendung, die Funktionen zum Eintakten,

32 Das SPECjAppServer2004-Benchmark 20 Aktualisieren und Abschließen von normalen Produktionsaufträgen sowie Großbestellungen bereitstellt. Damit das Lager immer ausreichend gefüllt bleibt, gibt es die Zuliefererdomäne, die mit den Zulieferern interagiert. Sie stellt die Funktionalitäten zum Auswählen eines Lieferanten und zum Senden eines Lieferauftrages bereit. Außerdem wird hier der Erhalt der Lieferungen abgebildet. In (31) finden sich ausführlichere Informationen zum Geschäftsszenario des SPECjAppServer2004- Benchmarks Technische Umsetzung Das SPECjAppServer2004-Benchmark hat den Anspruch möglichst viele Technologien zu verwenden, die von einem J2EE-konformen Anwendungsserver unterstützt werden müssen. Dazu gehören: Der Webcontainer mit Servlets und JavaServer Pages Der Container für Enterprise JavaBeans EJB 2.0 Container Managed Persistence (CMP) Java Messaging Service und Message Driven Beans Transaktionsmanagement Datenbankverbindungen Um diesem Anspruch gerecht zu werden, ist das Benchmark durch eine verteilte Anwendung mit einer Mehrschichtarchitektur realisiert. Abbildung 6 gibt einen Überblick über die Verteilung dieser Anwendung. (2) Treiber Anwendungs- Server Emulator Anwendungs- Server Anwendungs- Server Cluster Datenbank Server Getestetes System Abbildung 6: Die Architektur des SPECjAppServer2004-Benchmarks Durchgeführt wird das Benchmark von einer Java-Anwendung: dem Treiber. Dieser greift auf die Betriebslogik des Kerns der verteilten Anwendung im Anwendungsserver zu. Das Benchmark ist vor allem darauf ausgelegt, diesen Kern zu testen. Da diese Schicht allerdings von der Persistenzschicht abhängt, spiegelt sich auch die Leistung des DBMS im Ergebnis des Benchmarks wieder. Daher sollte

33 21 Performanzevaluierung von Anwendungsservern sichergestellt werden, dass das DBMS nicht den Flaschenhals des Systems darstellt. Die Interaktion mit den Zulieferern, wird von einer unabhängigen Teilanwendung simuliert: dem Emulator. Der Treiber generiert die Last für das System, überprüft ob die Anforderungen an das Benchmark erfüllt wurden und erzeugt die Ergebnisberichte. Er ist als nebenläufige Java-Anwendung implementiert, die so konzipiert wurde, dass sie auf mehrere Klientenmaschinen verteilt werden kann. Auf diese Weise ist garantiert, dass der Treiber keine inhärenten Skalierbarkeitsbeschränkungen besitzt. Der Treiber besteht aus drei Teilkomponenten: zwei Produktionstreibern und dem Händlertreiber. Die Produktionstreiber verwenden den Anwendungsteil, der die Produktion steuert, um die Leistung der Produktionslinien für normale Produktionen und Großbestellungen zu testen. Diese Treiber werden durch eine konfigurierbare Anzahl von eigenständigen Prozessen realisiert, die sich entweder um die normale Produktion (M) oder um Großbestellungen (L) kümmern. Der Händlertreiber simuliert die Benutzung der Webanwendungen in der Händlerdomäne und deren Zugriff auf die Anwendungen zur Bestellungseingabe in der Kundendomäne. Dabei kommen drei Arten von Geschäftstransaktionen zum Einsatz: das Blättern im Fahrzeugkatalog, das Erwerben von Fahrzeugen und das Verwalten des Kundeninventars. Jede dieser Geschäftstransaktionen führt zu einer Reihe von Teilschritten. Bei Blättern im Fahrzeugkatalog werden zum Beispiel jeweils 13 Seitenaufrufe erzeugt. Die Verteilung der Häufigkeit der drei Transaktionen kann in den Einstellungen für einen Benchmarklauf festgelegt werden. Realisiert wird der Treiber, der diese ausführt, durch eine konfigurierbare Anzahl von eigenständigen Prozessen (O). Die Kernanwendung besteht aus Enterprise JavaBeans (EJB), Servlets und JavaServer Pages (JSP). Sie bildet das in Abschnitt beschriebene Geschäftsszenario ab und kommuniziert mit allen anderen Anwendungsteilen. Für die Bereitstellung der Kernkomponenten wird der J2EE-konforme Anwendungsserver benötigt, dessen Leistung mit Hilfe des Benchmarks ermittelt werden soll. Der Emulator ist in einer separaten Servlet-Webanwendung implementiert, die auf einem eigenen unabhängigen Computersystem installiert ist. Bereitgestellt wird er durch einen Webserver wie den von der SPEC empfohlenen Apache Tomcat. (32) Der Emulator repräsentiert die Zuliefererdomäne, indem er das Senden von Lieferaufträgen und deren Erfüllung simuliert. Da die Anwendungen der Zulieferer auch in realen Systemen extern sind und zudem das Kommunikationsvolumen mit diesem Anwendungen gering ist, zählt der Emulator nicht zum getesteten System. Es ist allerdings vorgeschrieben, ihn nicht auf dem gleichen Server einzusetzen, wie einen anderen Anwendungsteil, sondern ihm einen eigenen Server zur Verfügung zu stellen. Die Datenhaltung erfolgt mit Hilfe eines eigenen Datenbankservers. Es kommen J2EE-Entity-Beans zu Einsatz, die mittels CMP auf Datenbanktabellen abgebildet werden. Als Zugriffstechnologie wird JDBC verwendet. Dies ermöglicht es, verschiedene DBMSe einzusetzen. Da das Benchmark stark datengetrieben ist, wird das Testergebnis auch von der die Leistung des Datenbankservers beeinflusst. Da wie bereits beschrieben viele J2EE-Technologien zum Einsatz kommen sollen, werden für die Kommunikation zwischen den einzelnen Systemteilen verschiedene Protokolle verwendet. Die domänenübergreifende Kommunikation innerhalb des Anwendungskerns erfolgt durch den Einsatz von JMS und MDBs. Der Produktionstreiber verwendet RMI zur Kommunikation mit der Kernanwendung. Die Kommunikation zwischen Händlertreiber und Kernanwendung hingegen erfolgt mit Hilfe des Hypertext Transfer Protokolls (HTTP). Datenbankzugriffe finden über das JDBC-Protokoll statt.

34 Das SPECjAppServer2004-Benchmark 22 Die Benchmarkdurchführung setzt sich aus fünf Phasen zusammen. Zunächst überprüft der Treiber in der Initialisierungsphase die Benchmarkeinstellungen, sowie die Gesamtkonfiguration der Benchmarkanwendung. Dabei wird der Zustand der Datenbank validiert und sichergestellt, dass alle Teilanwendungen erreichbar sind. Als nächstes werden alle notwendigen Threads erzeugt und Verbindungen erstellt. Die nächste Phase ist die Aufwärmphase, in der das Benchmark bereits die vorgesehene Systemlast produziert, in der das Performanzverhalten des Anwendungsservers aber noch nicht in das Benchmarkergebnis einfließt. Im Anschluss erfolgt die tatsächliche Durchführung des Benchmarks. Dabei wird der Anwendungsserver standardmäßig eine Stunde lang mit Anfragen belastet und dabei seine Leistungsfähigkeit bei deren Beantwortung beurteilt. Weitere Details zu der generierten Last und der Bewertungskriterien des Benchmarks werden im folgenden Abschnitt vorgestellt. Vor dem Abschluss des Benchmarks gibt es eine Abkühlphase, in der das Benchmark noch die normale Last produziert, das Leistungsverhalten des Servers aber nicht mehr in die Bewertung einfließt. Die Finalisierungsphase schließt das Benchmark ab, in dem sie die erzeugten Verbindungen beendet, die erstellten Threads terminieren lässt und einen Abschlussbericht mit einer ausführlichen Darstellung der Benchmarkresultate anfertigt Metriken Das Benchmark wird über die so genannte Injektionsrate skaliert. Diese beeinflusst die Anzahl der generierten Geschäftstransaktionen sowie die Anzahl der Produktionsaufträge, die vom System simuliert werden. Neben dem daraus resultierenden Durchsatz für die Anwendung, wird auch der Umfang der in der Datenbank abgelegten Informationen erhöht. Die Füllrate der Datenbank folgt dabei einer logarithmischen Skalierung, die von der Injektionsrate abhängt: Tabelle 2: Die Datenbankfüllrate in Abhängigkeit von der Injektionsrate (SPEC, 2006) Injektionsrate Schrittweite Datenbankfüllrate Datenbankgröße , 2, 3, 10 4,3 MB 43 MB , 30, 40, MB 430 MB , 300, 400, MB 4,3 GB Durch eine erhöhte Injektionsrate wird also auch das Datenbankmanagementsystem in einem größeren Maße beansprucht. Die Anzahl der Klienten für die Webanwendung der Händlerdomäne entspricht dem zehnfachen der Injektionsrate. Dadurch werden die Fähigkeiten des Anwendungsserver in Bezug auf das Verarbeiten vieler konkurrierender Sitzungen getestet. Um die erhöhte Anzahl an Bestellungen verarbeiten zu können, entspricht die Anzahl der regulären Produktionslinien dem dreifachen der Injektionsrate. Damit entspricht die Gesamtanzahl der erzeugten Threads dem 13-fachen der Injektionsrate, verteilt auf mindestens drei Prozesse. Die Metrik, in der das Benchmark misst, wird SPECjAppServer2004 JOPS genannt. JOPS steht für jappserver-operationen pro Sekunde. Die SPECjAppServer2004 JOPS ergeben sich aus der Summe der fertig gestellten Geschäftstransaktionen und der durchgeführten Produktionsaufträge, normiert anhand der Gesamtlaufzeit des Benchmarks: SPECjAppServer2004 JOPS = Gescäftstransaktionen Gesamtlaufzeit + erfüllte Produktionsaufträge Gesamtlaufzeit Die Geschäftstransaktionen setzen sich aus den drei Transaktionsarten Einkauf, Verwaltung und Durchsuchen zusammen. Um den Einfluss von sporadisch auftretenden Störfaktoren auf die

35 23 Performanzevaluierung von Anwendungsservern Resultate möglichst weit zu reduzieren, beträgt die Gesamtlaufzeit des Benchmarks standardmäßig 60 Minuten Konfiguration Die Durchführung der Konfiguration erfolgt im Wesentlichen in zwei Schritten. Zum einen muss die Benchmarkanwendung angepasst und erzeugt werden. Dabei entsteht ein Enterprise Application Archive (EAR), das auf dem Anwendungsserver ausgeführt werden soll. Dazu muss dieser im zweiten Konfigurationsschritt entsprechend eingerichtet werden. Dies ist der tatsächliche Hauptaufwand bei der Installation des Benchmarks, denn dabei müssen anwendungsserverspezifische Konfigurationsdateien erstellt werden, um die folgenden Anforderungen der Anwendung zu erfüllen: Die Abbildung der CMP für die Entity Beans der Anwendung auf das Datenbankschema Die Einrichtung des Java Naming and Directory Interfaces (JNDI), um der Anwendung mitzuteilen, über welche Namen sie auf Objektreferenzen zugreifen kann Die Erstellung von Warteschlangen und Themen für den Java Message Service, um der Anwendung zu erlauben, deren Namen auf Ressourcen abzubilden Die Art der Konfiguration dieser Eigenschaften unterscheidet sich für die einzelnen Anwendungsserver teilweise grundlegend und erfordert daher in der Regel viel Erfahrung in der Verwendung der Anwendungsserver für den Einsatz mit J2EE 1.3. Seit der Version 1.08, die im Februar 2007 erschien, enthält das Benchmark eine zusätzliche Konfiguration, die insbesondere für den Einsatz in Universitäten vorgesehen ist: Den so genannten research mode. Er erzeugt eine veränderte Last (EAStress), die den Ausführungsregeln nicht unbedingt entsprechen muss und daher nicht mit den normalen SPECjAppServer2004-Ergebnissen verglichen werden darf. Diese neue Konfiguration kann verwendet werden, um Teile von Anwendungsservern zu testen, die sich noch im experimentellen Stadium befinden Benchmarkresultate Wie bereits beschrieben, erstellt das Benchmark im letzten Schritt der Finalisierungsphase einen ausführlichen Abschlussbericht, der das Leistungsverhalten des Anwendungsservers während des Benchmarks beschreibt. Außerdem wird eine Reihe von Konsistenzüberprüfungen durchgeführt, um sicherzustellen, dass das Benchmark korrekt ausgeführt wurde. Der Abschlussbericht weist auf Inkonsistenzen und Fehler hin und enthält zudem die Fehlerlogeinträge des Treibers. Nach einer zweimaligen erfolgreichen Durchführung des Benchmarks kann ein Paket erstellt werden, das von der SPEC begutachtet und veröffentlich wird. Dieses Paket wird als Java-Archive-Datei (JAR) ausgeliefert und enthält die folgenden Bestandteile: Ein Konfigurationsdiagramm des getesteten Systems Ein Full Disclosure Archive (FDA), das die Testkonfiguration enthält (mehr dazu in 5.1) Das ausgefüllte Einreichungsformular mit dem Abschlussbericht Seit dem Erscheinen des Benchmarks im April 2004, sind 80 dieser Ergebnisse von der SPEC anerkannt und veröffentlicht worden. Die Ergebnisse finden sich auf (33). Darunter gibt es vor allem Ergebnisse für die folgenden Anwendungsserver: BEA WebLogic Server Oracle Application Server / Oracle WebLogic Server

36 Das SPECjAppServer2004-Benchmark 24 WebSphere Application Server Sun Java System Application Server Für den GlassFish-Anwendungsserver wurde bisher nur ein einziges Ergebnis veröffentlicht. Dieses wurde am 08. September 2008 auf einem SunFire-X4150-Cluster aus zwei Servern mit je vier CPUs mit jeweils zwei Kernen durchgeführt. Ausführliche Informationen zu dem Benchmark finden sich in (34). Als Injektionsrate wurde 761 verwendet und es konnten 1197 SPECjAppServer2004 JOPS erreicht werden. Der JBoss ist unter den veröffentlichten Ergebnissen überhaupt nicht vertreten Infrastruktur und Messumgebung Die im Rahmen dieser Arbeit eingerichtete Infrastruktur entsprach der in Abbildung 6 dargestellten Architektur. Es kamen handelsübliche Computersysteme zum Einsatz. Deren Hardware ist in Tabelle 3 dargestellt. Tabelle 3: Hardwarekonfiguration der Infrastruktur Rolle Prozessor Arbeitsspeicher Netzwerk Treiber Intel 3.0 Ghz 3.25 GB Intel 82566DM-2 Gbit Emulator Intel 2.4 Ghz 3.00 GB Broadcom NetXtreme 57xx Gbit Anwendungsserver Intel 3.0 Ghz 3.25 GB Intel 82566DM-2 Gbit Datenbankserver Intel 2.4 Ghz 3.00 GB Broadcom NetXtreme 57xx Gbit Eine Übersicht über die verwendete Software ist in Tabelle 4 zu sehen. Es wurde ausschließlich Microsoft Windows XP als Betriebssystem eingesetzt. Als Datenbankmanagementsystem wurde MySQL 5.1 (35) eingesetzt. Für die Realisierung der Lieferantenemulation wurde bei den GlassFish- Benchmarks wurde Apache Tomcat verwendet. Bei den JBoss-Benchmarks kam JBoss Web (36) zum Einsatz, das auf dem Apache Tomcat 6.0 Webcontainer basiert und im JBoss enthalten ist. (37) Tabelle 4: Softwarekonfiguration der Infrastruktur Rolle Betriebssystem Java Virtual Machine Sonstige Anwendungen Treiber Windows XP SP3 HotSpot RE 1.6.0_11 Emulator Windows XP SP3 HotSpot RE 1.6.0_11 Apache Tomcat / JBoss Web Anwendungsserver Windows XP SP3 HotSpot RE 1.6.0_11 GlassFish v2.1 / JBoss Datenbankserver Windows XP SP3 - MySQL Verwendung von Perfmon Für die Überwachung der einzelnen Computerknoten des Systems wurde der Performanzmonitor von Microsoft Windows XP (Perfmon) verwendet. Perfmon erlaubt es Performanzzähler auf lokalen oder entfernten System zu installieren. Diese Zähler kann man sich wie Messfühler vorstellen, die in frei wählbaren Intervallen vom Perfmon abgefragt werden. Es gibt vorgefertigte Messfühler zur Überwachung der Hardware, des Betriebssystems und diversen Middleware-Systemen. Hinzu kommen noch herstellerspezifische Messfühler. Solche gibt es zum Beispiel für die.net-plattform und das MySQL-Datenbankmanagementsystem.

37 25 Performanzevaluierung von Anwendungsservern Neben einer Visualisierung der aktuellen Messwerte, bietet Perfmon auch die Möglichkeit, die Ergebnisse in Logdateien zu speichern, um später Auswertungen durchzuführen. Mit diesem Werkzeug kann man sich einen schnellen Überblick über mögliche Zusammenhänge zwischen den gemessenen Werten zu verschaffen. Tabelle 5 zeigt eine Übersicht der überwachten Performanzzähler. In (30) verwenden die Autoren die Prozessorauslastung als einzigen relevanten Indikator bei der Ressourcenüberwachung eines Anwendungsservers. Allerdings ist der Prozessor nicht der einzig denkbare Flaschenhals in dem beschriebenen Szenario. Ein zu kleiner Arbeitsspeicher kann in diesem Beispiel das System genauso beeinträchtigen wie eine langsame Festplatte. Im SPECjAppServer2004-Benchmark werden sehr viele Threads erzeugt, die viele Netzwerkverbindungen erstellen. Daher war es naheliegend, die Anzahl der Threads und Verbindungen sowie die Auslastung des Netzwerks zu überwachen. Tabelle 5: Relevante Performanzzähler Ressource Prozessor Arbeitsspeicher Festplatte Netzwerk Threads Verbindungen Relevante Performanzzähler Processor(_Total)\% Processor Time Memory\Pages/sec PhysicalDisk\Avg. Disk Queue Length <Network Interface>\Bytes Total/sec System\Threads TCP\Connection Failures TCP\Connections Established Für die Bestimmung der Prozessorauslastung wurde der Mittelwert der absoluten Prozessorzeit beider Prozessorkerne ermittelt. Diese gibt den prozentualen Anteil wieder, den der Prozessorkern nicht im Leerlaufprozess verbringt. Eine sehr hohe Prozessorauslastung weist auf eine Überlastung des Systems hin und ist nahezu immer ein Zeichen für Performanzprobleme. Beim Arbeitsspeicher wurden die Seitenzugriffe pro Sekunde ermittelt. Diese entsprechen der Rate mit denen Speicherseiten von der Festplatte gelesen beziehungsweise auf die Festplatte geschrieben werden. Eine hohe Rate ist damit ein Indikator für Speicherprobleme, die zur Ursache für Performanzprobleme werden können. Um auf festplattenbedingte Schwierigkeiten aufmerksam zu werden, wurde die durchschnittliche Länge der Festplattenwarteschlange für Schreib- und Lesezugriffe ermittelt. Leider war es nicht möglich, die erfassten Werte für die Festplatte aus den Logdateien von Perfmon zu extrahieren. Daher wurden nur die anderen hier genannten Messfühler für die Evaluierung verwendet. Eine Überwachung der Auslastung der Netzwerkadapter erfolgte, indem die Anzahl an gesendeten und empfangenen Informationen in Bytes ermittelt wurde. Um herauszufinden, wie viele TCP- Verbindungen bestehen, wurden alle Verbindungen ermittelt, die sich im ESTABLISHED- oder CLOSE- WAIT-Zustand befanden. Außerdem wurde die Anzahl der Verbindungsfehler überwacht. Ein Verbindungsfehler bedeutet, dass ein direkter Übergang vom SYN-SENT- oder SYN-RCVD-Zustand in den CLOSED-Zustand oder ein Übergang vom SYN-RCVD-Zustand zum LISTEN-Zustand erfolgte. Ein Zustandsdiagramm des Transmission-Control-Protokolls (TCP) ist bei (38) dargestellt. Die Messungen erfolgten auf allen beteiligten Computerknoten. Sie wurden dabei zentral verwaltet und gesteuert. Die Erfassung der Messwerte wurde nur alle 120 Sekunden durchgeführt, um das

38 Das SPECjAppServer2004-Benchmark 26 Benchmark möglichst wenig zu beeinflussen und dennoch repräsentative Informationen zu erhalten. Bei einigen Benchmarkläufen wurde auf die Erfassung einiger Messwerte verzichtet. Einen Einstieg in die Untersuchung von Flaschenhälsen mit Perfmon bietet (39) Vorgehen bei der Auswertung Damit die erfassten Performanzwerte der einzelnen Messungen miteinander verglichen werden können, müssen sie den gleichen Zeitraum repräsentieren. Daher wurde stets der Zeitraum gewählt, in dem alle Verbindungen zum Anwendungsserver aufgebaut wurden und noch nicht damit begonnen wurde, sie wieder zu schließen. Der Beginn dieses Zeitraums entspricht in etwa dem Ende der Initialisierungsphase des Benchmarks, das Ende entspricht in etwa dem Anfang der Finalisierungsphase. Da für alle Messreihen die Standardeinstellungen des Benchmarks für die Durchführungsdauer verwendet wurden, sollte der ausgewählte Zeitraum etwa 75 Minuten betragen. Abbildung 7 zeigt die Auswahl dieses repräsentativen Bereiches. Abbildung 7: Auswertung des repräsentativen Zeitraums mit dem Performance Monitor Für nahezu alle in Tabelle 5 aufgeführten Performanzzähler wurde der Durchschnitt der erfassten Werte für diesen Zeitraum verwendet. Die einzige Ausnahme ist der Zähler, der die Anzahl der Verbindungsfehler erfasst. Bei diesen wurde die Differenz von maximaler und minimaler Anzahl verwendet, um die Anzahl der während des ausgewählten Zeitraums aufgetretenen Fehler zu ermitteln. Durch die Verwendung des Durchschnitts der Werte sind die Ergebnisse selbst dann noch repräsentativ, wenn der Bereich nicht immer exakt identisch ausgewählt wurde.

39 27 Performanzevaluierung von Anwendungsservern 4 Verwandte Arbeiten Dieses Kapitel verschafft einen Überblick über verwandte Arbeiten, die sich mit der Untersuchung von Anwendungsservern mit Hilfe von Benchmarks beschäftigen. Die hier aufgeführten Arbeiten haben dabei aufgrund der untersuchten Anwendungsserver, beziehungsweise wegen der Verwendung eines SPECjAppServer-Benchmarks starken Bezug zu diesem Projekt. 4.1 Performance Tuning and Optimization of J2EE Applications on the JBoss Platform In der Veröffentlichung Performance Tuning and Optimization of J2EE Applications on the JBoss Platform (30) haben Samuel Kounev, Björn Weis und Alejandro Buchmann von der Technischen Universität Darmstadt ebenfalls das Verhalten des JBoss-Servers mit Hilfe des SPECjAppServer2004- Benchmarks analysiert. Sie haben dabei allerdings nicht die JOPS erfasst, sondern sich auf die Ermittlung der Prozessorauslastung, des Durchsatzes und der Antwortszeiten der Geschäftstransaktionen beschränkt. Analysiert wurde das Verhalten eines JBoss-Servers der Version als Einzelsystem sowie im Verbund mit anderen JBoss-Servern bei unterschiedlichen Systemkonfigurationen. Als Betriebssystem kam SuSE Linux 8 zum Einsatz. Es wurden verschiedene Webcontainer und JVMs getestet. Diese Informationen sind heute allerdings aufgrund ihres Alters nicht mehr repräsentativ. Des Weiteren ergab der Vergleich der Performanz von lokalen Aufrufen mit der von entfernten Aufrufen, dass letztere zu einer 9% höheren Prozessorauslastung und zu einer um 35% größeren Antwortszeit führten. Außerdem wurden verschiedene Datenbankeinstellungen evaluiert, die zum Teil sehr starke Performanzvorteile erbrachten. Eine weitere Testreihe zeigte, dass der JBoss-Anwendungsserver starke Performanzeinbrüche bei hoher Last zeigt. Dabei ergaben sich insbesondere Einbußen bei der Verlässlichkeit und der Skalierbarkeit. Es entstanden viele Transaktionsabbrüche und JBossspezifische Systemfehler, die sich bei einem alternativen Anwendungsserver in gleichen Kontext nicht zeigten. Die beschriebenen Probleme ähneln sehr stark denen, die auch im Rahmen dieser Evaluierung auftraten. Eine weitere Beobachtung war die Tatsache, dass der Web Container ein großer Flaschenhals des Systems war. Die meisten Ergebnisse dieser Arbeit, die sich mit der Veränderung der JBoss-Konfiguration zur Performanzverbesserung beschäftigen, waren allerdings schon im Jahr 2006 veraltet. (40) 4.2 GlassFish vs. JBoss Evaluierungsbericht Eine weitere Arbeit, die den GlassFish- mit dem JBoss-Anwendungsserver vergleicht, ist der Evaluierungsbericht GlassFish vs. JBoss (41) von Krystian Brachmanski, Pawel Lipinski, Thomas Wenckebach, Tomasz Wozniak und Boguslaw Fraszko, der im Oktober 2008 erschien. Im Rahmen dieses Projektes wurden die beiden Anwendungsserver anhand ihrer Merkmale mit einander verglichen und durch gezielte Minibenchmarks evaluiert. Es wurde eine ganze Reihe von Testläufen mit einem GlassFish-v2-UR2-Anwendungsserver und einem JBoss Anwendungsserver auf einem T2000-System durchgeführt. Diese evaluierten das Performanzverhalten der Web- und EJB-Container sowie der Remoting- und Persistenz- Implementierung der Anwendungsserver. Zusätzlich wurden Webcontainertests für einen GlassFishv2-UR2- und einen JBoss Anwendungsserver auf einem PrimePower650-System durchgeführt. Als Betriebssystem kam jeweils Solaris 10 update 4 zum Einsatz. Erfasst wurden die Auslastung der Prozessoren, des Arbeitsspeichers, der Festplatten und des Netzwerkes. Außerdem wurde unter

40 Verwandte Arbeiten 28 anderem die Anzahl aktiver Sitzungen und Threads der Testanwendungen erfasst. Für die Auswertung wurden allerdings nur die Prozessorauslastung und die Antwortszeiten berücksichtigt. Die Untersuchen ergaben, dass beim JBoss die Verwendung von JSP zu stärken Problemen mit Seitenblockierungen führt als beim GlassFish. Dies führte beim JBoss zu einem enormen Performanzeinbruch bei hohen Lasten. Bei Servlets mit kurzen, wenig komplexen Sitzungen ergab sich ein ähnliches Performanzverhalten. Als mögliche Ursache wird in diesem Bericht die bessere Skalierbarkeit des GlassFish-Servers auf Mehrkern- und Multithreading-Systemen genannt. Diese Ergebnisse bestätigen jene, die in Abschnitt 4.1 beschrieben wurden. Eine große Last führt bei JBoss- Anwendungsservern noch immer zu einem starken Anstieg der Antwortszeiten. Die gilt insbesondere für den Webcontainer. Ein zweites Ergebnis, war die Feststellung, dass die Implementierung der lokalen Aufrufe von EJBs beim JBoss bis zu 20 Mal schlechte Performanzwerte erzielt als die des GlassFish-Anwendungsservers, was vor allem durch den unverhältnismäßigen Einsatz von Reflektionsmechanismen beim JBoss begründet ist. Bei einem persönlichen Gespräch berichteten die Autoren davon, dass beim JBoss die allgegenwärtige Verwendung von Synchronisierungskonzepten ein großes Problem ist. Teilweise werden ganze Methoden synchronisiert und nicht nur jene Abschnitte, die eine Synchronisierung erzwingen. Ein weiteres Problem ist die Verwendung einer großen Anzahl von Abstraktionsschichten. Dies macht den JBoss zwar flexibel, sorgt aber für gewaltige Performanzeinbußen. Zudem gibt es offenbar einen Fehler, der dafür sorgt, dass für Methodenaufrufe an entfernten EJBs derselbe Quelltext ausgeführt wird wie bei lokalen EJBs. Dies bedeutet, dass beim JBoss für einen EJB-Aufruf eine sehr viel höhere Stacktiefe benötigt wird als beim GlassFish. Es traten zudem massive Probleme mit Verbindungen auf, die sich im ESTABLISHEDund TIME_WAIT-Zustand befanden. Auch hier wirkten sich diese Probleme stärker auf die Performanz des JBoss-Anwendungsservers aus. Auch die Persistierungslösung Hibernate, die beim JBoss eingesetzt wird, unterliegt dem im GlassFish verwendeten Toplink bei der Verwendung der üblichen lazy-fetch-strategie. Zudem zeigt der Bericht, dass selbst die Kombination GlassFish und Hibernate bessere Ergebnisse erzielt als die Kombination JBoss und Hibernate. In vielen Fällen sorgten die Blockierungen in den Containern dazu, dass die Prozessoren nicht vollständig ausgelastet werden konnten. Dieses Problem könnte sich zukünftig beim Einsatz von Multikern- und Multiprozessorsystemen noch verstärken. Als Ursache wird auch hier der unverhältnismäßig hohe Gebrauch von Synchronisierungskonzepten genannt. Vor dem Hintergrund dieser Evaluation wurden ausschließlich Minibenchmarks erstellt. Diese ergänzen in einem guten Maße die Untersuchungen dieser Arbeit. Da in beiden Untersuchungen ähnliche Probleme auftraten, bestätigen die Ergebnisse dieses Berichtes die in dieser Arbeit vorgestellten Beobachtungen und liefern weitere Begründungen für deren Ursachen. 4.3 Scaling Up the JBoss Application Server In der Präsentation Scaling Up the JBoss Application Server (42) von Peter Johnson und David Strong, die am 14. Februar 2007 auf dem LinuxWorld Open Solutions Summit veröffentlicht wurde, wird eine Untersuchung des JBoss und JBoss Anwendungsservers mit dem SPECjAppServer2002-Benchmarks zusammengefasst. Als Betriebssysteme kamen Red Hat Enterprise Linux 4 und SUSE Linux Enterprise Server 9 zum Einsatz. In der Präsentation wird darauf hingewiesen, dass das optimale Verhältnis von Total Operations Per Second (TOPS) zur Injektionsrate für den JBoss circa 1,7 sein sollte. Dies entspricht grob den in dieser Arbeit für den GlassFish erzielten Ergebnissen mit dem Nachfolger des verwendeten Benchmarks.

41 29 Performanzevaluierung von Anwendungsservern Es werden verschiedene Möglichkeiten für die Performanzjustierung vorgestellt. Dazu zählen, die Aufrüstung der Hardware, die Veränderung der JVM-Optionen, die Anpassung der Einstellungen der Datenbank, des Anwendungsservers und der Anwendung selbst. Einzig die Überarbeitung der Anwendung zur Verbesserung der Performanz ist von der SPEC untersagt. Einige der vorgeschlagenen Optimierungen wurden im Rahmen dieser Arbeit eingesetzt. So zum Beispiel die Anpassung der Heap-Speichergröße und des Garbage Collectors der JVM sowie die Erhöhung des Caches für vorbereitete Datenbankbefehle und Zeiten, nach denen eine blockierende Datenbankverbindung abgebrochen wird. Des Weiteren sind Vorschläge über die Größe des Datenbankverbindungspools in Abhängigkeit von der Injektionsrate enthalten. Es wird vorgeschlagen, die maximale und minimale Größe auf den gleichen Wert zu setzen und folgende Formeln zur Ermittlung der Poolgrößen zu verwenden: Poolgröße = 8.8 Injektionsrate, Injektionsrate Injektionsrate, Injektionsrate > 50 Es wird auch hier darauf verwiesen, dass der MySQL-Verbindungspool der Thread-Poolgröße entsprechen soll. Diese Werte wurden im Rahmen dieser Arbeit evaluiert, führten aber zu einer Verschlechterung der JBoss-Ergebnisse. 4.4 SPECjAppServer-2004-Ergebnisse des GlassFish vom September 2008 Im September 2008 wurde das erste und bisher einzige Ergebnis eines GlassFish-Anwendungsservers für das SPECjAppServer-2004-Benchmark von Sun Microsystems Inc. bei der SPEC veröffentlicht. Es wurde ein Sun GlassFish Enterprise Server v2 Update 2 auf einem SunFire-X4150-Cluster mit MySQL 5.0 auf einem OpenSolaris getestet. Eine genaue Beschreibung des Benchmarks und der verwendeten Software liefert (34). Diese enthält neben einer genauen Beschreibung des Versuchsaufbaus auch Details über die verwendeten Konfigurationen der einzelnen Softwarekomponenten. Nahezu alle für diese Veröffentlichung verwendeten Optimierungen wurden auch im Rahmen dieser Arbeit verwendet. Ausgenommen waren nur jene Optimierungen, die von Windows XP SP3 oder von der verwendeten Hardware nicht unterstützt wurden. Bei einer Injektionsrate von 716 konnten 1.197,10 SPECjAppServer 2004 JOPS erzielt werden. Dies entspricht einem Verhältnis von SPECjAppServer 2004 JOPS zu Injektionsrate von circa 1,7. Dazu wurden zwei Computersysteme mit jeweils vier Kernen à 3166 Mhz und 8 GB Arbeitsspeicher in einem Verbund für den Anwendungsserver eingesetzt. Die Gesamtprozessorleistung entspricht damit in etwa dem Vierfachen der im Rahmen dieser Arbeit verwendeten Hardware. Das von Sun Microsystems Inc. erzielte Ergebnis ist etwa sechs Mal größer als in Abschnitt 5.2 beschriebene. Außerdem enthält diese Veröffentlichung die folgende Aussage: The only errors in the driver log files were those that are normally generated by this benchmark. Dies führte zu einiger Verwirrung, sowohl bei der Arbeit mit dem JBoss- als auch bei der Analyse des GlassFish-Anwendungsservers. Bei jeder auftretender Meldung war unklar, ob es sich nun um einen normalen Fehler oder um ein echtes Problem handelte. Das Ziel bei der Erstellung dieser SPEC-Veröffentlichung war die Maximierung der SPECjAppServer JOPS. Dieses Benchmark wurde folglich nur mit einer einzigen Konfiguration durchgeführt und es wurden keine Informationen bezüglich Korrelationen der erzielten Ergebnisse und mit den Systemressourcen veröffentlicht.

42 GlassFish 30 5 GlassFish Der GlassFish-Anwendungsserver der Firma Sun Microsystems ist für diese Arbeit interessant, weil er vom gleichen Hersteller entwickelt wurde, welche die J2EE-Spezifikation herausbrachte und bis heute stark beeinflusst. Der GlassFish kann als Referenzimplementierung der aktuellen Java-EE- und EJB- Spezifikationen betrachtet werden. Zudem wird er im Rahmen eines Open-Source-Projektes entwickelt und steht unter der GNU General Public License (GPL) und der Common Development and Distribution License (CDDL) unter (4) zur freien Verfügung. Der Quelltext des GlassFish basiert auf dem des Sun Java System Application Servers PE9 von Sun Microsystems und dem des Persistenzsystems TopLink von Oracle. Als Webcontainer kommt Grizzly (43) zum Einsatz. Für die Evaluierung wurde die Version GlassFish Application Server v2 betrachtet. Die Version GlassFish Application Server v3 befindet sich derzeit noch in der Entwicklung und ist zurzeit nicht in der Lage das SPECjAppServer2004-Benchmark auszuführen. Diese Kapitel beschreibt zunächst in Abschnitt 5.1, wie das FDA des veröffentlichten GlassFish- Ergebnisses für die Konfiguration des Benchmarks verwendet wurde und präsentiert dann in Unterkapitel 5.2 die Resultate der Testläufe. Abschnitt 5.3 enthält das Fazit des Autors zum GlassFish. 5.1 Full Disclosure Archive Die Ergebnispakete des SPECjAppServer2004-Benchmarks enthalten das so genannte Full Disclosure Archive (FDA). Dieses beinhaltet die Testkonfiguration des entsprechenden Benchmarks. Die Dateien, die in dieser Archivdatei enthalten sind, können eingesetzt werden, um selbst eine äquivalentes Testsystem zu konfigurieren und damit die Testläufe zu rekonstruieren. Ein FDA kann von der Ergebniswebseite eines Benchmarks herunter geladen werden. Diese Ergebnisseiten sind auf (33) verfügbar. Das FDA kann die in Abschnitt beschriebene Hauptleistung bei der Konfiguration des Anwendungsservers erheblich erleichtern, weil es die anwendungsserverspezifischen Deployment- Deskriptoren enthält, die für die Platzierung des Benchmarks im Anwendungsserver unerlässlich sind Einsatz für die Durchführung des Benchmarks Im Rahmen dieser Arbeit wurde das FDA aus dem veröffentlichen Benchmark für den GlassFish- Anwendungsserver als Grundlage für die Konfiguration des entsprechenden Testszenarios verwendet. Dieser Abschnitt beschreibt die Schritte, die nach dem Herunterladen des FDA durchgeführt wurden, um das Benchmark lauffähig zu machen. Die hier beschriebenen Konfigurationsschritte dienen der Reproduzierbarkeit der Evaluierung Konfiguration des Datenbankmanagementsystems Bevor das Benchmark durchgeführt werden kann, muss die Datenbank mit den Benchmarkdaten gefüllt werden. Dazu sollte zunächst das Datenbankmanagementsystem unter Zuhilfenahme der Datei FDA\Config\Database\my.cnf konfiguriert werden. Als nächstes muss der Nutzer spec angelegt und mit allen Rechten ausgestattet werden. Anschließend muss die Datenbank specdb erzeugt werden. Diese erhält ihr Datenbankschema mit Hilfe der im Verzeichnis FDA\Schema befindlichen SQL-Dateien. Als nächstes muss das Benchmark selbst konfiguriert werden, um die eben erzeugte Datenbank zu verwenden. Dazu müssen alle Dateien, die auf db.properties enden und im Ordner SPECjAppServer2004\config liegen, entsprechend angepasst werden. Zuletzt muss unter Windows

43 31 Performanzevaluierung von Anwendungsservern der Pfad der JAR-Datei des verwendeten JDBC-Treibers in die CLASSPATH-Variable in der Datei SPECjAppServer2004\bin\loadbd.bat des Benchmarks eingetragen werden. Nach der Konfiguration des Benchmarks, die in den Abschnitten und beschrieben ist, kann die Datenbank mit dieser Datei gefüllt werden. Die Injektionsrate muss ihr dabei als erster Parameter übergeben werden. Vor jeder Durchführung des Benchmarks sollte die Datenbank neu erzeugt und geladen werden Erstellung der Benchmarkanwendung Um das Benchmark für den GlassFish-Anwendungsserver durchzuführen, muss die Benchmarkanwendung entsprechend angepasst und erzeugt werden. Dazu muss als erstes der Ordner FDA\Deploy\glassfish in den Ordner SPECjAppServer2004\src\deploy des Benchmarks kopiert werden. Der Wert für categories in der mfg.xml sollte danach auf 1 geändert werden. Zudem muss die Datei FDA\Deploy\build_GlassFish.xml in den Hauptordner des Benchmarks kopiert werden. Damit die Anwendung mit einer korrekten Konfiguration erstellt wird, muss nun die Datei FDA\Config\Driver\glassfish.env in den Ordner SPECjAppServer2004\config kopiert und entsprechend angepasst werden. Dabei sollte darauf geachtet werden, keine Gegenschrägstriche zu verwenden. Nun kann die Benchmarkanwendung mit Hilfe von Apache Ant unter Verwendung der build_glassfish.xml erzeugt werden Konfiguration des Anwendungsservers Die Schritte für die Konfiguration des Anwendungsservers und sind in der Datei FDA\Deploy\deployCmds.txt beschrieben. Vor der Aktualisierung der Domänenbeschreibung für den GlassFish sollten allerdings der Pfad für den JDBC-Treiber im classpath-prefix der javaconfig und der Name des Datenbankservers für den JDBC-Pool SpecJPool angepasst werden. Außerdem sollte bei den JVM-Optionen die Größe des zu verwendenden Arbeitsspeichers konfiguriert werden Konfiguration des Emulators Für die Konfiguration des Emulators kann die FDA\Config\Emulator\server.xml zusammen mit einer eigenständigen Apache-Tomcat Instanz verwendet werden. Mit dieser muss die Datei emulator.ear bereitgestellt werden, die bei der Erstellung der Benchmarkanwendung ebenfalls erzeugt wird Durchführung des Benchmarks Die Durchführung des Benchmarks besteht aus drei Schritten. Zunächst wird durch das Ausführen der Datei setenv.bat der Benchmarkkontext gesetzt, dann muss mit der Datei loaddb.bat die Datenbank mit den Benchmarkdaten gefüllt werden und schließlich wird das eigentliche Benchmark mit der Datei driver.bat vom Treibersystem aus durchgeführt. Die drei Dateien befinden sich im Ordner SPECjAppServer2004\bin. Es kann passieren, dass der Treiber Probleme damit hat, wenn Sonderzeichen wie $ in den Werten der Umgebungsvariablen enthalten sind. Diese Umgebungsvariablen sollten vor der Durchführung des Benchmarks überschrieben werden. Vor der Ausführung des Benchmarks müssen die für den Benchmarklauf zu verwendenden Einstellungen in der Datei run.properties angepasst werden. Diese muss zuvor vom Ordner FDA\Config\Driver in den Ordner SPECjAppServer2004\config kopiert werden. Einmalig muss der Wert für Url angepasst werden und die msbetweenthreadstart auf 100 erhöht werden. Danach

44 JOPS GlassFish 32 kann die Injektionsrate für jeden Benchmarklauf über txrate festgelegt werden und sollte stets dem gleichen Wert entsprechen mit dem die Datenbank gefüllt wurde Probleme und Lösungen Nach der Durchführung des Benchmarks mit dem GlassFish-Anwendungsserver ist die Domäne weiterhin aktiv. Die Prozessorauslastung bleibt relativ hoch und die Log-Dateien wachsen an. Eine weitere Ausführung des Benchmarks würde also von der vorhergehenden beeinflusst werden. Eine Untersuchung der resultierenden Ergebnisse zeigt zwar keine offensichtlichen Performanzunterschiede, dennoch wurde für die Erfassung der hier vorgestellten Benchmarkergebnisse die ausführende Domäne jeweils neu erzeugt. Dazu genügte es, die Domäne einmalig zu konfigurieren und vor der Durchführung ein Backup anzulegen, welches vor jedem Benchmarklauf wiederhergestellt wird. 5.2 Ergebnisse Das Benchmark wurde mit der in Abschnitt vorgestellten Konfiguration durchgeführt. Dieser Abschnitt beschreibt die dabei erzielten Testergebnisse des GlassFish-Anwendungsservers. Ein Ergebnis ist durch ein Diagramm und eine Tabelle mit den zugehörigen erfassten Daten dargestellt. Linien zwischen den erfassten Messpunkten dienen lediglich der Orientierung. Sie lassen keine Schlüsse über die erwarteten Messergebnisse zwischen den erfassten Messpunkten zu Ergebnisse des Benchmarks Dieser Abschnitt führt die mit dem Benchmark erzielten Resultate auf. Dabei werden auch die Teilergebnisse aus der Händler- und Fertigungsdomäne sowie aus deren Teilaufgaben präsentiert GlassFish 16,80 25,10 33,59 66,94 83,77 100,34 164,77 156,23 135,50 91,04 28,90 18,56 Injektionsrate Abbildung 8: Benchmarkergebnisse für den GlassFish-Anwendungsserver in Abhängigkeit von der Injektionsrate Abbildung 8 zeigt die erzielten Resultate des GlassFish-Anwendungsservers beim SPECjAppServer2004-Benchmark. Der GlassFish skaliert für eine Injektionsrate zwischen 10 und 100 ideal. Das Verhältnis von erzieltem JOPS-Wert zur Injektionsrate ist in diesem Bereich stets zwischen 1,65 und 1,68. Die Injektionsrate korreliert in diesem Bereich mit einem Korrelationskoeffizienten von knapp +1 mit den erzielten JOPS-Werten. Danach werden die erzielten Ergebnisse zunehmend schlechter, fallen jedoch selbst für eine Injektionsrate von 400 nicht auf Null. Für eine Injektionsrate von 100 bis 400 liegt der Korrelationskoeffizient bei etwa -0,97.

45 JOPS 33 Performanzevaluierung von Anwendungsservern Fertigung 13,36 33,47 64,01 31,03 14,40 9,52 3,50 Händler 20,22 50,30 100,76 125,20 121,11 81,52 25,40 Injektionsrate Abbildung 9: Benchmarkergebnisse des GlassFish-Anwendungsservers für Fertigungs- und Händlerdomäne In Abbildung 9 ist die Verteilung der Ergebnisse nach Händler- und Fertigungsdomäne aufgeteilt. Diese Aufteilung ist sinnvoll, weil die Händlerdomäne vor allem den Webcontainer testet, während der Fokus der Fertigungsdomäne beim EJB-Container liegt. Die optimale Injektionsrate unterscheidet sich für die beiden Container. Während die Fertigungsdomäne bei einer Injektionsrate von etwa 100 ihr Maximum erreicht, erzielt die Händlerdomäne bei einer Injektionsrate von circa 125 ihre besten Ergebnisse. Die besten Gesamtergebnisse repräsentieren also nicht gleichzeitig die besten Teilergebnisse. Außerdem zeigt die Abbildung, dass das Gesamtergebnis am stärksten von den Ergebnissen des Webcontainers abhängt. Bis zu einer Injektionsrate von 100 bestimmt der Webcontainer das Gesamtergebnis zu circa 60%, danach sogar zu 80% bis 90%. Die beiden Domänen haben eigene Teilaufgaben. Die Fertigungsdomäne kümmert sich um die Produktion der bestellten Automobile und unterscheidet dabei zwischen normalen und Großbestellungen. Die Händlerdomäne erlaubt es ihren Benutzern Artikel zu suchen, ihr Konto zu verwalten oder Automobile zu erwerben. Die Ergebnisse für diese Teilaufgaben sind in Abbildung 10 aufgeführt. Die Verteilung der erzielten Ergebnisse für die drei Teilaufgaben in der Händlerdomäne entspricht der konfigurierten Verteilung für die Benchmarkläufe (50:25:25). Im Bereich der idealen Skalierung, bis zu einer Injektionsrate von 100, korrelieren alle gemessenen Werte mit einem Korrelationskoeffizienten von nahezu +1 miteinander und mit der Injektionsrate. Danach korrelieren fast alle gemessenen Werte mit einem Korrelationskoeffizienten von weniger als -0,93 mit der Injektionsrate. Die einzige Ausnahme sind hier die Ergebnisse für die normalen Bestellungen, deren Koeffizient nur bei etwa +0,5 zu den anderen Messergebnissen und bei circa +0,65 zur Injektionsrate liegt. Obwohl normale Bestellungen, Großbestellungen in der Händlerdomäne jeweils durch eine konfigurierbare Anzahl eigenständiger Prozesse realisiert sind, korrelieren (Korrelationskoeffizient: +0,99) bei diesen Messungen die Händlerdomäne und die Großbestellungen besonders stark miteinander. Die erzielten Ergebnisse für die normalen Bestellungen brechen schon früher und heftiger zusammen. Die Ergebniszahl der Großbestellungen wächst gemeinsam mit denen der Händlerdomäne weiter an, während die Ergebnisse der Fertigungsdomäne bereits schlechter

46 JOPS GlassFish 34 werden. Dies kann dadurch erklärt werden, dass normale und Großbestellungen vom EJB-Container ausgeführt werden und eine Großbestellung mindestens 100 normalen Bestellungen entspricht. Dieser Umstand führt dazu, dass sich das Anwachsen der Anzahl der Großbestellungen negativ auf die Produktionsperformanz der normalen Bestellungen auswirkt normale Bestellungen 12,00 29,99 57,00 22,55 6,21 4,83 2,40 Großbestellungen 1,36 3,47 7,00 8,47 8,19 4,70 1,10 suchen 10,09 25,05 50,29 62,52 60,43 40,70 12,55 verwalten 5,06 12,65 25,25 31,39 30,39 20,39 6,49 kaufen 5,07 12,59 25,22 31,29 30,29 20,43 6,36 Injektionsrate Abbildung 10: Benchmarkergebnisse des GlassFish-Anwendungsservers nach Teilaufgaben Ressourcenauslastung in Abhängigkeit von der Injektionsrate Dieser Abschnitt betrachtet die Auslastung der erfassten Systemressourcen in Abhängigkeit von der Injektionsrate und ihren Zusammenhang mit den Benchmarkergebnissen. Jedes Diagramm enthält zusätzlich die skalierten Benchmarkergebniswerte als Vergleichswert. Diese Skalierung wirkt sich nicht auf die Korrelationskoeffizienten aus. Abbildung 11 zeigt die Abhängigkeit der Prozessorauslastung der bei der Durchführung des Benchmarks verwendeten Computerknoten von der Injektionsrate. Die Auslastungen aller Prozessoren korrelieren miteinander und mit den erzielten Benchmarkergebnissen. Die Abhängigkeit von der Injektionsrate verhält sich wie in Abschnitt Im Bereich bis zu einer Injektionsrate von 100, korrelieren alle Messreihen mit einem Korrelationskoeffizienten von etwa +1, danach ist der Koeffizient zur Injektionsrate jeweils etwa -0,95. Die Prozessoren des Anwendungsservers sind am stärksten ausgelastet und erreichen bei einer Injektionsrate von 100 ihre Maximalauslastung von 68%. Dies ist das erwartete Verhalten, da das Benchmark diesen Server fokussiert. Dass keine vollständige Prozessorauslastung erreicht werden kann und die Auslastungen zusammen mit den Benchmarkergebnissen für höhere Injektionsraten absinken, deutet darauf hin, dass die Prozessoren nicht den Flaschenhals des Systems sind. Wäre dies der Fall, so müsste die Auslastung konstant einen Maximalwert halten, wie in Abschnitt beschrieben ist.

47 Prozessorauslastung (%) 35 Performanzevaluierung von Anwendungsservern ,5*JOPS (zum Vgl.) 16,79 41,88 82,38 78,11 67,75 45,52 14,45 Anwendungsserver 14 % 33 % 68 % 66 % 50 % 36 % 18 % Treiber 3 % 8 % 14 % 16 % 15 % 12 % 6 % Datenbankserver 7 % 19 % 34 % 32 % 28 % 19 % 9 % Emulator 0 % 1 % 1 % 1 % 1 % 1 % 0 % Injektionsrate Abbildung 11: Die durchschnittliche Prozessorauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Die Prozessoren des Datenbankserver werden etwa halb so stark ausgelastet wie die des Anwendungsservers und erreichen eine maximale Auslastung von 34%. Diese Prozessoren sind also ebenfalls nicht überlastet. Die Kurve der Prozessorauslastung des Treibers ist gegenüber der des Anwendungsservers leicht verschoben. Daher entspricht sie zunächst einem Viertel und später einem Drittel der Auslastung des Anwendungsservers. Diese Verschiebung ist damit zu erklären, dass der Treiber noch freie Kapazitäten hat, während der Anwendungsserver bereits überlastet ist. Daher reagiert er verspätet auf den Zusammenbruch der Leistung des Anwendungsservers. Der Emulator hat eine maximale Prozessorauslastung von 1%. Die Analyse des Arbeitsspeichers ergab keine aufschlussreichen Resultate. Die durchschnittliche Anzahl der Seitenfehler war für den GlassFish nahezu immer gleich Null. Die einzigen Ausnahmen waren Störungen, die offensichtlich durch andere Prozesse hervorgerufen wurden. Dies war insbesondere daran zu erkennen, dass sie leicht zeitversetzt auf allen beteiligten Computerknoten und auch denen, die nicht im Benchmark involviert waren, auftraten. Dies deutet darauf hin, dass es sich hierbei um zeitgesteuerte Prozesse oder Dienste handelte. Die erreichte Netzwerkauslastung beim GlassFish in Abhängigkeit von der Injektionsrate ist in Abbildung 12 dargestellt. Auch hier gibt es eine starke Korrelation der Messreihen. Insbesondere hängen die Messreihen des Anwendungsservers und der Anwendung (Korrelationskoeffizient: +0,999) und die Messreihen des Datenbankservers mit den erreichten Benchmarkergebnissen (Korrelationskoeffizient: +0,994) zusammen. Diese Messungen verdeutlichen den Verlauf des Benchmarks: Die meiste Kommunikation erfolgt zwischen dem Treiber und dem Anwendungsserver. Die Kommunikation zwischen dem Datenbankserver und dem Anwendungsserver macht nur etwa ein Zehntel davon aus, die zwischen Emulator und Anwendungsserver nur ein Hundertstel. Obwohl der Datenbankserver nur verhältnismäßig wenig kommuniziert, zeigt die Korrelation seiner

48 Netzwerkauslastung (MB/s) GlassFish 36 Netzwerkauslastung mit den erzielten Benchmarkergebnissen, dass er wahrscheinlich einen wichtigen Einfluss auf diese hat. Eine weitere Untersuchung und anschließende Optimierung in diesem Bereich scheint sinnvoll. Außerdem muss zwischen der Art der Kommunikation unterschieden werden. Die zusätzliche Kommunikationsmenge zwischen Treiber und Anwendungsserver liegt vor allem darin begründet, dass sie mittels HTTP kommunizieren. Im Gegensatz dazu verwenden Datenbankserver und Anwendungsserver das JDBC-Protokoll. Dass keine vollständige Netzauslastung erreicht werden kann und die Auslastungen zusammen mit den Benchmarkergebnissen für höhere Injektionsraten absinken, deutet darauf hin, dass das Netzwerk nicht den Flaschenhals des Systems darstellt. Wäre es der Flaschenhals, müsste die Auslastung konstant einen Maximalwert halten wie in Abschnitt beschrieben ist ,2*JOPS (zum Vgl.) 6,72 16,75 32,95 31,25 27,10 18,21 5,78 Anwendungsserver (MB/s) 4,21 10,54 21,08 24,74 23,90 15,65 5,25 Treiber (MB/s) 3,68 9,22 18,42 22,77 21,29 14,25 4,76 Datenbankserver (MB/s) 0,52 1,30 2,53 2,23 1,87 1,21 0,45 Emulator (MB/s) 0,01 0,02 0,03 0,02 0,02 0,01 0,00 Injektionsrate Abbildung 12: Die durchschnittliche Netzwerkauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate In Abbildung 13 ist die ermittelte Threadanzahl auf den einzelnen Computerknoten bei unterschiedlichen Injektionsraten dargestellt. Selbst im Bereich einer Injektionsrate von 20 bis 100, aber insbesondere im Bereich von 100 bis 400 korreliert nur der Treiber mit der Injektionsrate. Die Threadanzahl der anderen Knoten bleibt relativ konstant. Das bedeutet, dass der GlassFish- Anwendungsserver keine zusätzlichen Threads erzeugt, um die zusätzlichen Anfragen vom Treiber zu beantworten. Außerdem verwendet der GlassFish nur einen kleinen Teil der verfügbaren Datenbankverbindungen, denn der MySQL-Server würde für neue Verbindungen einen eigenen Threads erzeugen. Auch der Threadpool von maximal 2000 Threads auf dem Emulator wird nicht ausgelastet. Auf dem Emulator befinden sich nur unwesentlich mehr Threads als in einem vergleichbaren System im Leerlauf. Die steigende Threadzahl auf Treiberseite und der daraus resultierende zusätzliche Aufwand für die Synchronisierung dieser Threads könnten auf einen Flaschenhals des Systems hindeuten. Die Vielzahl konkurrierender Anfragen führt zu einer gegenseitigen Blockierung und damit zu einer höheren Antwortszeit, die sich wiederum in schlechteren Benchmarkergebnissen zeigt.

49 Anzahl TCP-Verbindungen Threadanzahl 37 Performanzevaluierung von Anwendungsservern *JOPS (zum Vgl.) 671, , , , , ,83 577,97 Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 13: Die durchschnittliche Threadanzahl der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate *JOPS (zum Vgl.) 335,88 837, , , ,01 910,41 288,98 Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 14: Die durchschnittliche Anzahl der TCP-Verbindungen der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Die Anzahl der TCP-Verbindungen der einzelnen Computerknoten in Abhängigkeit der Injektionsrate ist in Abbildung 14 dargestellt. Es gibt wenige herausstechende Korrelationen, insbesondere gibt es keine für den Zusammenhang mit den Benchmarkergebnissen. Die TCP-Verbindungsanzahl des

50 Anzahl TCP-Fehler (logarithmische Skalierung) GlassFish 38 Anwendungsservers korreliert mit einem Korrelationskoeffizienten von +1 mit der des Treibers. Das bedeutet, dass der Anwendungsserver immer mehr Anfragen mit einer konstanten Anzahl an Ressourcen und einer gleichbleibenden Threadanzahl bewältigen muss. Die Anzahl der Verbindungen des Datenbankservers ist relativ klein und steigt so lange an, bis ein Maximum von etwa 85 Verbindungen erreicht ist. Diese maximale Schranke entspricht nicht der im MySQL-Server festgelegten Größe, sondern der maximalen Anzahl, die beim GlassFish-Server zur Bewältigung der Anfragen konfiguriert ist. Dass der Datenbankserver dieses Maximum erst erreicht, nachdem die Benchmarkergebnisse schlechter werden, deutet darauf hin, dass diese Verbindungsanzahl nicht den Flaschenhals des Systems darstellt. Die Anzahl der TCP-Verbindungen des Emulator ist relativ klein und anfangs weitestgehend konstant. Diese Anzahl steigt erst für sehr hohe Injektionsraten leicht an *JOPS (zum Vgl.) Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 15: Die durchschnittliche Anzahl der TCP-Fehler der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem GlassFish-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 15 zeigt anhand einer logarithmischen Skala die Anzahl der aufgetretenen TCP-Fehler in Abhängigkeit von der Injektionsrate. Beim Anwendungs- und Datenbankserver treten keine solchen Fehler auf. Es besteht eine starke Korrelation (Korrelationskoeffizient: +0,978) zwischen den Fehlern, die beim Emulator auftreten und den erzielten Benchmarkergebnissen. Dies deutet auf ein echtes Problem hin, weil die Anzahl der Fehler beim Emulator offensichtlich vom Benchmark abhängen und nicht durch andere Prozesse hervorgerufen werden. Eine Auswertung und die Schritte zur Beseitigung dieses Problems sind in Abschnitt beschrieben. Da diese Kurve jedoch mit den Benchmarkergebnissen korreliert, handelt es sich hier auch nicht um eine Sättigungssituation die einen Flaschenhals repräsentiert. Entscheidender ist das Verhalten des Treibers. Zunächst treten keine Fehler auf. Für eine steigende Injektionsrate, wächst die Anzahl der Fehler allerdings drastisch an. Dies ist tatsächlich ein Indikator dafür, wovon die schlechter werdenden Benchmarkergebnisse abhängen. Die Ursache dieser Fehler liegt in den vielen Verbindungen begründet, die deshalb nicht aufgebaut werden können, weil der Anwendungsserver so stark überlastet ist, dass er den TCP-Handshake nicht mehr korrekt ausführen kann. Sie sind also Folge der Überlastung und nicht deren Ursache.

51 JOPS 39 Performanzevaluierung von Anwendungsservern Betrachtungen bei begrenzten Ressourcen Zusätzlich zu den bisherigen Untersuchungen wurden die Auswirkungen begrenzter Ressourcen auf das Verhalten der Anwendungsserver untersucht. Dabei fokussiert dieser Abschnitt auf die Begrenzung des verfügbaren Arbeitsspeichers für den Anwendungsserver. Dieser wurde direkt in der domain.xml des GlassFish justiert. Auf diese Weise konnte der Einsatz von externen Werkzeugen, die zum Beispiel für die Begrenzung der verfügbaren Prozessorleistung notwendig sind, vermieden werden Fertigung 0,00 0,00 1,58 7,76 13,77 14,92 14,40 Händler 0,00 0,00 16,98 70,89 118,88 124,83 121,11 MB Arbeitsspeicher Abbildung 16: Benchmarkergebnisse des GlassFish-Anwendungsservers bei unterschiedlichen Speichergrößen und einer Injektionsrate von 150 Eine Übersicht über Messreihen zur Untersuchung der Arbeitsspeicheraffinität des GlassFish- Anwendungsservers im Kontext des Benchmarks ist in Abbildung 16 dargestellt. Für diese Messungen wurde eine feste Injektionsrate von 150 verwendet. Diese Messreihen zeigen, dass die Zuordnung eines zu kleinen Arbeitsspeicherbereiches dazu führen kann, dass die Benchmarkergebnisse auf Null fallen. Für Größen von 256 MB bis 512 MB ist eine Verbesserung der erzielten Ergebnisse in Abhängigkeit von der Injektionsrate zu erkennen. In diesem Bereich korrelieren der verfügbare Arbeitsspeicher und die erzielten Benchmarkergebnisse mit einem Korrelationskoeffizienten von über +0,93. Bei 512 MB verfügbarem Arbeitsspeicher erreichen die Benchmarkergebnisse ihren Maximalwert. Eine weitere Erhöhung führt zu keinem weiteren Performanzgewinn. In Abbildung 17 ist das Verhalten des Anwendungsservers für unterschiedliche Speichergrößen in Abhängigkeit von der Injektionsrate dargestellt. Dabei wurde eine Messreihe, für deren Ausführung 256 MB Arbeitsspeicher zur Verfügung standen, mit einer Messreihe verglichen, für die der Anwendungsserver über 1024 MB Arbeitsspeicher verfügte. Das obere linke Diagramm zeigt die erzielten Benchmarkergebnisse. Für eine Injektionsrate von 50 und 100 unterscheiden sich die Ergebnisse nur marginal. Danach brechen die Ergebnisse bei der geringeren Arbeitsspeichergröße sehr viel schneller zusammen.

52 Netzwerkauslastung (MB/s) Threadanzahl JOPS Prozessorauslastung (%) GlassFish MB RAM 83,55 162,06 26,41 18, MB RAM 83,77 164,77 156,23 135,50 30,0 25,0 20,0 15,0 10,0 5,0 0,0 Injektionsrate MB RAM 10,5 21,9 4,9 0, MB RAM 10,5 21,1 24,7 23,9 Injektionsrate MB RAM 33 % 70 % 83 % 83 % 1024 MB RAM 90 % 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % 0 % 33 % 68 % 66 % 50 % Injektionsrate MB RAM MB RAM Injektsionsrate Abbildung 17: Benchmarkergebnisse und Ressourcenverbrauch des GlassFish-Anwendungsservers bei unterschiedlichen Speichergrößen in Abhängigkeit von der Injektionsrate Das obere rechte Diagramm von Abbildung 17 zeigt die Abhängigkeit der Prozessorauslastung von der Injektionsrate. Bei einem kleineren Arbeitsspeicherbereich ist die Prozessorauslastung ab einer Injektionsrate von 100 deutlich höher als bei der Messung mit 1024 MB Arbeitsspeicher. Insbesondere nähert sich dieser Wert einem konstanten Maximum eine Prozessorauslastung von 83% an. Dies deutet nach Abschnitt auf eine gesättigte Ressource und damit darauf hin, dass der Prozessor in dieser Konfiguration zu einem Flaschenhals wird. Auch bei der Netzwerkauslastung, die im unteren linken Diagramm dargestellt ist, zeigt sich, dass eine Begrenzung des verfügbaren Arbeitsspeichers zu einem früheren und stärkeren Zusammenbruch der Kommunikation führt. Ein Vergleich mit der linken oberen Ecke zeigt die bereits in Abschnitt festgestellte Korrelation zwischen Netzwerkauslastung und erzielten Benchmarkergebnissen. Die untere rechte Ecke zeigt die Anzahl der erzeugten Threads. Offenbar erzeugt der GlassFish weniger Threads, wenn ihm weniger Ressourcen zur Verfügung stehen. Die geringere Threadanzahl könnte aufgrund der damit einhergehenden geringeren Anzahl an Blockierungen zu der im oberen rechten Diagramm dargestellten höheren Prozessorauslastung geführt haben. Die Anzahl der TCP-Verbindungsfehler ist sowohl für 256 MB RAM also auch für 1024 MB RAM gleich Null. Auch die Anzahl der durchschnittlichen Arbeitsspeicherseitenfehler ist in beiden Fällen vernachlässigbar klein.

53 41 Performanzevaluierung von Anwendungsservern Fehlerbetrachtungen Dieser Abschnitt beschäftigt sich mit der Frage, inwieweit die Ergebnisse repräsentativ und reproduzierbar sind. Zunächst wird ein Konfigurationsfehler beschrieben, der aus den erfassten Werten ermittelt wurde. Im zweiten Schritt wird die Stabilität der Benchmarkergebnisse untersucht Das Emulator-Problem Wie bereits in Abschnitt im Zusammenhang mit Abbildung 15 beschrieben, trat eine Häufung von TCP-Verbindungsfehlern beim Emulator auf. Es gab zwei Ursachen dafür, dass diesen Fehlern lange Zeit keine Bedeutung geschenkt wurde: Zum einem lief die zentrale Perfmon-Instanz lange Zeit auf dem Emulatorcomputerknoten. Dies ließ, zusammen mit der Tatsache, dass die Performanzzähler für die Festplattenaktivitäten nicht ausgelesen werden konnten, vermuten, dass diese Probleme durch Perfmon begründet sind. Die Korrelation zwischen Benchmarkergebnisse und Emulatorverbindungsfehlern allerdings wiederlegte diese These. Die zweite Ursache war eine Formulierung aus der SPEC-Veröffentlichung von Sun, die besagte, dass dieses Benchmark im Normalfall eine Reihe von Fehlermeldungen in den Logs erzeugt. (34) Aus einer genaueren Betrachtung aller Benchmarkergebnisdateien konnte unter Berücksichtigung der Häufung von TCP-Verbindungsfehlern das Konfigurationsproblem erschlossen werden. Der Emulator war so konfiguriert, dass er zwar erreicht werden konnte, jedoch die Verbindung zum Anwendungsserver über einen falschen Port herzustellen versuchte. Dies führte jeweils zu einem Verbindungsfehler. Das SPECjAppServer2004-Benchmark kontrolliert zwar selbstständig vor der Durchführung der Messungen, ob alle Komponenten aktiv, erreichbar und richtig konfiguriert sind, scheint aber über keine Überprüfung für den beschriebenen Fall zu verfügen. Um diesen Fehler zu beheben genügte es, den korrekten Port beim Emulator einzutragen. Die Durchführung erneuter Messungen zeigte, dass die erzielten Messergebnisse für die neue Konfiguration durchschnittlich kaum von den bisherigen abwichen. Daher wurde aus Zeitgründen keine vollständige Neuerfassung der Werte durchgeführt Allgemeine Fehlerbetrachtungen und Stabilität Jede Messung ist von Störfaktoren begleitet. Im vorliegenden Fall wurden die Ergebnisse von den anderen Prozessen und Diensten beeinflusst, die auf den verwendeten Windows-Systemen ausgeführt wurde. Außerdem kommt der zusätzliche Aufwand für die Messinstrumentation selbst hinzu. Dies war zum einen deshalb der Fall, weil die Performanzzähler auf jedem System während des Benchmarks ausgelesen wurden, und zum anderen, weil anfangs die zentrale Perfmon-Instanz auf dem Emulator lief. Die Intervalle für das Auslesen der Performanzzähler wurden mit 120 Sekunden sehr groß eingestellt. Außerdem war der Emulator während des Benchmarks nur minimal ausgelastet. Um die tatsächliche Belastung der Benchmarkergebnisse durch Störfaktoren und den Perfmon zu ermitteln, wurden verschiedene Messreihen mehrmals durchgeführt. Darunter solche mit einem aktivierten Perfmon, mit deaktiviertem Perfmon und mit einem aktiven Perfmon, dessen zentrale Instanz sich auf einem eigenständigen Computerknoten befand. Dabei ergaben sich nur marginale Unterschiede und insbesondere keine Muster. Der Computer-knoten, auf dem die zentrale Instanz von Perfmon ausgeführt wurde, verfügte während der gesamten Laufzeit durchschnittlich sechs Verbindungen und erzeugte konstant circa ein Kilobyte Netzauslastung. Diese Werte müssten also von den für den Emulator erfassten Werten abgezogen werden.

54 JOPS GlassFish IR 50 IR 100 IR 150 IR 300 Abbildung 18: Stabilitätsanalyse der Benchmarkergebnisse des GlassFish-Anwendungsservers für ausgewählte Injektionsration Wie bereits beschrieben wurde eine Vielzahl von Messreihen durchgeführt, für die zum Teil unterschiedliche Umgebungsbedingungen galten. Zum einen zählt dazu die veränderte Konfiguration bezüglich der Perfmon-Nutzung, zum anderen ist das Betriebssystem in einigen Fällen gerade neu gestartet worden und lief in anderen schon über eine längere Zeit. Abbildung 18 stellt diese Messreihen dar. Es zeigt sich, dass die Ergebnisse trotz ungleicher Umgebungsbedingungen nahezu identisch sind. Dies bedeutet, dass weder die beschriebenen Änderungen bezüglich der Perfmon- Nutzung, noch die veränderten Laufzeiten des Betriebssystems starken Einfluss auf die Ergebnisse des Benchmarks hatten. Außerdem haben die anderen Prozesse und Dienste, die zeitparallel auf demselben Betriebssystem ausgeführt wurden, sowie weitere Störfaktoren die Resultate offenbar wenig beeinflusst. Tabelle 6: Einfaktorielle Varianzanalyse der Benchmarkergebnisse aus Abbildung 18 Gruppen Anzahl Summe Mittelwert Varianz IR ,12 83,78 0,04 IR ,50 163,72 1,98 IR ,70 136,62 5,61 IR ,85 29,28 0,17 Tabelle 6 zeigt zudem, dass die Varianz der erfassten Messreihen sehr gering ist. Damit sind die zu erwartenden Ergebnisse für vergleichbare Messungen relativ gut vorherzusagen. Der störende Einfluss, der durch fremde Prozesse entstand, wurde vor allem in den Perfmon- Ausgaben der einzelnen Messungen sichtbar. Sie zeigten sich vor allem als plötzliche Spitzen in der Prozessorauslastung und der Anzahl der Arbeitsspeicherseitenfehler. Da bis auf die Messung der aufgetretenen TCP-Fehler immer Mittelwerte für die Ressourcenauslastung verwendet wurden, wurde das Gewicht dieser Störfaktoren wieder reduziert Gültigkeit der Ergebnisse Nach der Behebung des in Abschnitt beschriebenen Problems konnten mit dem GlassFish- Anwendungsserver Benchmarkläufe durchgeführt werden, bei denen die Fehlerberichtsdateien des Benchmarks bis zu einer Injektionsrate von 100 keine Fehler enthielten. Allerdings wurden in dieser

55 43 Performanzevaluierung von Anwendungsservern Konfiguration zwei Konsistenzprüfungen nicht bestanden: Die Rate für die Erzeugung von Fahrzeugen auf der normalen Fertigungsstrecke war zu gering und die Antwortszeiten der Fertigungsdomäne lagen außerhalb des zulässigen Bereiches. Mit einer Injektionsrate von 90 konnte ein gültiges Ergebnis erzielt werden, dessen Fehlerlogdateien leer waren und das zudem allen Konsistenzüberprüfungen standhielt. Bei diesem Ergebnis wurden JOPS erzielt. 5.3 Fazit Der Einsatz des GlassFish auf einer Windows-Plattform und zusammen mit einem MySQL-Datenbankmanagementsystem gestaltete sich als nahezu problemlos. Die Konfiguration konnte, mit ausreichendem Vorwissen über die Arbeitsweise des SPECjAppServer2004-Benchmarks, an einem einzigen Tag durchgeführt werden. Überraschend ist, dass für die Konfiguration des GlassFish auf dem Windows-System eine beinahe identische Konfiguration verwendet werden kann wie auf einem OpenSolaris-Betriebssystem. Es müssen insbesondere keine Änderungen an der Konfiguration des Betriebssystems vorgenommen werden. Auch die Interaktion zwischen MySQL-Server und GlassFish- Anwendungsserver funktioniert einwandfrei. Die mit dem Benchmark erzielten Resultate liegen leicht oberhalb des erwarteten Bereiches. Die Ressourcenauslastung ist selbst bei hohen Werten für die Injektionsrate gering. Die Stabilität des Servers, insbesondere bei sehr hohen Injektionsraten und sogar bei Störfaktoren wie vorhandener Restbelastung mehrerer bereits abgeschlossener Benchmarkläufe, übertrifft die Erwartungen des Autors. Das einzige Defizit, welches sich bei der Arbeit mit dem GlassFish ergab, trat bei dem Versuch auf, das Benchmark in einem GlassFish-Cluster auszuführen. Denn obwohl das verwendete FDA eine Clusterkonfiguration enthielt, war der Autor weder in der Lage durch die Anpassung der domain.xml- Dateien noch durch die Verwendung der Webkonfigurationsschnittstelle des GlassFish eine lauffähige Clusterkonfiguration zu erzeugen, die in der Lage war, dass Benchmark auszuführen. Detaillierte Informationen zur Clusterbildung mit dem GlassFish sind unter (44) verfügbar.

56 JBoss 44 6 JBoss Der JBoss-Anwendungsserver der Firma JBoss, die seit April 2006 zur Red Hat, Inc. gehört, ist für diese Arbeit interessant, weil er aufgrund seiner weiten Verbreitung eine starke Konkurrenz für proprietäre Anwendungsserver ist. Der JBoss gehört zur JBoss Enterprise Middleware Suite (JEMS), einer J2EE-Middleware-Plattform, die sich aus vielen eigenständigen Open-Source-Projekten zusammensetzt. Der JBoss-Anwendungsserver steht unter der GNU Lesser General Public License (LGPL) unter (3) zur freien Verfügung. Als Webcontainer für den JBoss wird seit der Version das auf Apache Tomcat basierende JBoss Web eingesetzt. Für die Evaluierung wurde die Version JBoss AS GA verwendet. Die Version JBoss AS GA erschien zwar noch innerhalb des Bearbeitungszeitraumes, ist aber nicht kompatibel zu dem in Unterkapitel 6.1 vorgestellten Specj-Kit. Daher war konnte das SPECjAppServer2004-Benchmark nicht mit dem JBoss durchgeführt werden. Da der in der Version verwendete Web- und EJB- Container denen der Vorgängerversionen ähnelt, sollten sich nach (41) keine Performanzunterschiede zwischen Version und ergeben. Diese Kapitel beschreibt zunächst in Abschnitt 6.1, wie das Specj-Kit für JBoss für die Konfiguration des Benchmarks verwendet wurde und präsentiert dann in Unterkapitel 6.2 die Resultate der Testläufe. Abschnitt 6.3 enthält das Fazit des Autors zum JBoss-Anwendungsserver. 6.1 Specj-Kit für JBoss Wie bereits beschrieben, wurde für den JBoss-Anwendungsserver bisher kein einziges Ergebnis für das SPECjAppServer2004-Benchmark veröffentlicht. Daher konnte für diesen das in Abschnitt 5.1 beschriebene Verfahren nicht verwendet werden. Stattdessen kam hier das Specj-Kit für JBoss zum Einsatz. Bei diesem handelt es sich um ein Projekt der JBoss-Community unter der Leitung von Clebert Suconic. Die Projektseite ist unter (45) verfügbar. Ziel des Projektes war die Erstellung eines Baukastens, der es erleichtert, das SPECjAppServer2004- Benchmark für den Einsatz mit dem JBoss zu konfigurieren und auszuführen. Entwickelt wurde dieser Baukasten vor allem in den Jahren 2004 und Die aktuelle Version ist vom 01. Oktober Der Baukasten ist öffentlich verfügbar, wurde aber vor allem für interne Zwecke wie dem Überprüfen der täglichen Erstellungsprozessergebnisse verwendet Einsatz für die Durchführung des Benchmarks Für den Einsatz mit der aktuellen Version des Benchmarks müssen einige Veränderungen vorgenommen werden. Dieser Abschnitt beschreibt die Schritte, die nach dem Herunterladen des Specj-Kits specj-kit-oct01.tar.bz2 von (46) durchgeführt wurden, um das Benchmark lauffähig zu machen. Eine Anleitung bietet (45), diese ist mittlerweile aber in vielen Punkten veraltet. Die hier beschriebenen Konfigurationsschritte ermöglichen die Reproduzierbarkeit der Evaluierung Konfiguration des Datenbankmanagementsystems Vor der Durchführung des Benchmarks muss eine Datenbank angelegt und mit den Benchmarkdaten gefüllt werden. Zunächst muss dazu das Datenbankmanagementsystem angepasst werden. Dazu genügt es, in der my.ini den sql-mode auf IGNORE_SPACE und die lower_cas_table_names auf 1 zu setzen. Im nächsten Schritt müssen die Nutzer mit Hilfe des Skripts specj-kit- 2004\schema\mysql\createUser.sql angelegt werden. Das Datenbankschema befindet sich in specj-kit-2004\database\mysql\specj.sql. Es werden zwei Datenbanken angelegt: specj,

57 45 Performanzevaluierung von Anwendungsservern welche die Benchmarkdaten enthält, und jms, welche die JMS-Informationen des JBoss beinhaltet. Vor jeder Durchführung des Benchmarks sollten diese Datenbanken neu erzeugt und geladen werden. Nach der Konfiguration des Specj-Kits, die in Abschnitt beschrieben ist, genügt es die Datei setenv.bat aus dem Ordner SPECjAppServer2004\bin auszuführen und danach den Befehl ant loaddb im Heimatverzeichnis des Specj-Kits zu verwenden, um die Datenbank mit der aktuellen Konfiguration zu laden Erstellung der Benchmarkanwendung Die Erzeugung der Benchmarkanwendung erfolgt mit Hilfe des Kits. Zur Vorbereitung genügt es, die Datei specj-kit-2004\jboss-mysql-run.properties entsprechend anzupassen. Wird nun Apache Ant im Heimatverzeichnis des Specj-Kits ausgeführt, erstellt es die Benchmarkanwendung und erzeugt zwei Domänen in der angegebenen JBoss-Instanz. Eine Domäne repräsentiert die Benchmarkanwendung, die andere den Emulator. Außerdem werden die Konfigurationsdateien für das Benchmark erzeugt. Vor der Ausführung von Apache Ant sollte allerdings das Debugging in der build.xml des Specj-Kits deaktiviert werden. Dazu ist es notwendig, den auskommentierten Bereich des Ziels install-createserver zu aktivieren. Beim Starten der beiden Domäne auf je einem Computerknoten ist zu beachten, dass sie nur dann von anderen Systemen aus erreichbar sind, wenn sie mit der Option -b gestartet werden. Sollen die Einstellungen für die JBoss-Server verändert werden, so kann dies in der run.bat geschehen. Damit das Benchmark ausgeführt werden kann, muss der Datei SPECjAppServer2004\config\ run.properties die Zeile researchmode=false angefügt werden. Diese Option ist erst seit der Version 1.08 des Benchmarks enthalten und wird daher vom Specj-Kit nicht erzeugt. Zusätzlich muss in den beiden erzeugten Anwendungsdomänen des JBoss in der Datei conf/login-config.xml der Wert dsjndiname auf java:/specjjmsds gesetzt werden Durchführung des Benchmarks Die Durchführung des Benchmarks besteht aus drei Schritten. Zunächst wird durch das Ausführen der Datei setenv.bat der Benchmarkkontext gesetzt, dann muss mit dem Befehl ant loaddb die Datenbank mit den Benchmarkdaten gefüllt werden und schließlich wird das eigentliche Benchmark mit der Datei driver.bat vom Treibersystem aus durchgeführt. Die beiden Batchskripte befinden sich im Ordner SPECjAppServer2004\bin. Es kann passieren, dass der Treiber Probleme damit hat, wenn Sonderzeichen wie $ in den Werten der Umgebungsvariablen enthalten sind. Daher sollten diese Umgebungsvariablen vor der Durchführung des Benchmarks überschrieben werden. Vor der Ausführung können die aktuellen Benchmarkeinstellungen konfiguriert werden. Dies erfolgt über die Datei specj-kit-2004\jboss-mysql-run.properties und muss vor der in Abschnitt beschriebenen Erzeugung der Benchmarkanwendung durchgeführt werden. Damit ist sicher gestellt, dass für Datenbank und Benchmarkanwendung immer die gleiche Injektionsrate TXRATE verwendet wird Probleme und Lösungen Dieses Kapitel beschreibt die Probleme, die beim Einsatz des JBoss-Anwendungsservers mit dem Benchmark aufgetreten sind und die Schritte, die zur Behebung des jeweiligen Problems führten. Die

58 JBoss 46 Konfigurationsschwierigkeiten, deren Lösungen bereits in Abschnitt beschrieben sind, werden dabei nicht erneut betrachtet Verwendung neuer Domänen Wie auch beim GlassFish hinterlässt das Benchmark seine Spuren in der ausführenden Domäne. Darum sollte diese zwischen zwei Durchführungen jeweils neu erzeugt werden. Dies kann nach dem in Abschnitt beschriebenen Verfahren erfolgen MySQL-Konfiguration In (42) und (47) wird darauf verwiesen, dass die Anzahl der maximalen Verbindungen des MySQL- Servers gleich der Anzahl der für den JBoss eingestellten Verbindungen sein sollte. Es stellte sich heraus, dass diese Anzahl erheblich größer eingestellt werden muss. Für einen JDBC-Pool von 400 und einer maximalen Verbindungsanzahl von 600 auf Datenbankseite kam es zu dem MySQL-Fehler too many connections. Der Versuch die Anzahl der Datenbankverbindungen stark zu erhöhen führte zu Problemen bei der Erzeugung neuer Datenbankthreads. Dies liegt in der Tatsache begründet, dass MySQL bei der Erstellung neuer Threads jeweils einen Megabyte an Speicher für deren Threadstapelspeicher reserviert. (48) Unter Windows XP stehen jedem Prozess in der normalen Konfiguration aber maximal zwei Gigabyte an Speicher für Heap, Programmcode und die Stapelspeicher der Threads zur Verfügung. Daher wurde die Verbindungsanzahl auf 600 festgelegt und die JDBC-Pools, wie in Abschnitt beschrieben, entsprechend angepasst Windowskonfiguration Wie in den Abschnitten 4.1 und 4.2 berichtet, erzeugt der Benchmarktreiber sehr viele Verbindungen. Während dieses beim GlassFish erst bei sehr hohen Injektionsraten zu Problemen führt, treten beim JBoss schon ab einer Injektionsrate von 30 Probleme bei der Verbindungserzeugung auf. Der Grund dafür ist die Tatsache, dass der JBoss-Anwendungsserver offenbar für jeden Aufruf von bind einen neuen Port benötigt. In der Standardkonfiguration ermöglicht Windows XP aber nur die Vergabe von 5000 Nutzerports, solange keine explizite Portnummer angefragt wird. Um diese Probleme zu beheben wurden die Ratschläge aus (49) befolgt. Es war notwendig, einige TCP-Einstellungen mit Hilfe der Windowsregistrierung zu verändern. Dazu wurden die in Tabelle 7 aufgelisteten DWORD-Werte unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters erzeugt. Tabelle 7: Werte für die Anpassung der TCP-Konfiguration unter Windows Name Wert TcpTimedWaitDelay 30 MaxUserPort MaxHashTableSize MaxFreeTcbs Die Verwendung dieser Konfiguration auf Treiber und auf Anwendungsserverseite führte zur Beseitigung der Probleme mit sich bereits in Verwendung befindlichen Adressen.

59 47 Performanzevaluierung von Anwendungsservern Verwendung eines aktuellen JDBC-Treibers Aufgrund der Häufung von Fehlern, die sich auf die XA-Ressourcen bezogen, wurde die Konfiguration der specj-mysql-ds.xml von local-tx-datasource auf xa-datasource umgestellt. Im gleichen Zuge wurde der aktuelle MySQL-JDBC-Treiber Connector/J (50) eingesetzt. Dieser kam auch beim GlassFish zum Einsatz. Ursprünglich enthält das Specj-Kit die Version dieses Treibers, der aber nach (51) keinen Zweiphasen-Commit unterstützt Feintuning der Threadpools Die richtige Konfiguration für den JDBC-Pool zu finden, ist leider nicht so einfach wie in Abschnitt 4.3 beschrieben. Denn bei der vorgeschlagenen Konfiguration einer Poolgröße von 88 treten Fehler auf, die darauf hinweisen, dass keine verwalteten Verbindungen im vorgegebenen Zeitrahmen von knapp einer Minute gefunden werden konnten. Die tatsächlich zu konfigurierende Anzahl muss erheblich höher sein. Überschreitet sie allerdings 300, so versucht der JBoss mehr als die erlaubten 600 Verbindungen zur Datenbank zu erzeugen. In der gegebenen Konfiguration erwiesen sich Threadpoolgrößen von 240 bis 280 für den JDBC-Pool als geeignet. Für den JMS-Pool wurde eine Poolgröße von 10 verwendet. Der Threadpool des Webcontainers, der in der Datei server.xml konfiguriert werden kann, wurde auf 160 festgelegt, da es bei der Standardgröße von 250 Probleme beim Zusammenspiel mit dem JDBC-Pool gab Bestehende Probleme Bei der Durchführung des Benchmarks treten auf Anwendungsserverseite viele Warnungen auf, weil beim Zweiphasen-Commit versucht wird eine Transaktion, die bereits abgebrochen wurde, zu bestätigen. Es ist unklar, ob dies das normale Verhalten des Benchmarks repräsentiert oder auf ein tatsächliches Problem hindeutet. Bei der Durchführung des Benchmarks zeigt die Treiberkonsole nach der Initialisierungsphase keine Fehler, solange die Injektionsrate 40 nicht überschreitet. Die Fehler, die bei einer höheren Injektionsrate auftreten, sind die Folge der Überlastung des Anwendungsservers. Sie treten auf, weil dieser nicht in der Lage ist den TCP-Verbindungsaufbau korrekt durchzuführen. Doch selbst bei geringen Injektionsraten enthalten die Fehlerlogs des Benchmarks viele Fehler, deren Ursache für den Autor nicht zu ermitteln war, da die Fehlerlogs keine Hinweise auf deren Ursache enthalten. In einigen Fällen erreicht das Benchmark einen Zustand, in dem es immer wieder die gleiche Transaktionszahl zurückliefert. Es findet also keine weiterer Benchmarkfortschritt statt und das Benchmark terminiert nicht. Dieses Problem tritt besonders häufig auf, wenn dem Anwendungsserver nur wenig Arbeitsspeicher zur Verfügung steht. Nach der Durchführung des Benchmarks stehen viele Informationen über seine Durchführung bereit. So zum Beispiel die erzielten JOPS-Werte und die aufgetretenen Fehler. Zum Schluss wird ein Prüfungsbericht erstellt, der alle für das Benchmark erforderlichen Konsistenzprüfungen durchführt. Dieser finale Schritt der Erzeugung des Prüfungsberichtes schlägt beim JBoss-Anwendungsserver allerdings mit einem Nullzeiger-Fehler fehl. Der Grund für den Abbruch ist unbekannt. Damit ist es unmöglich nachzuweisen, ob der JBoss alle für das Benchmark erforderlichen Konsistenzüberprüfungen besteht. Wie bereits in Abschnitt beschrieben, baut der JBoss mehr Verbindungen zum Datenbankserver auf als für die JDBC-Pools konfiguriert sind. Bei einer Poolgröße von insgesamt 340

60 JOPS JBoss 48 Thread für die drei Pools verwendet er beispielsweise bereits alle 600 Verbindungen, die von der Datenbank bereitgestellt werden. 6.2 Ergebnisse Das Benchmark wurde mit der in Abschnitt vorgestellten Konfiguration durchgeführt. Dieser Abschnitt beschreibt die dabei erzielten Testergebnisse für den JBoss-Anwendungsserver. Ein Ergebnis ist durch ein Diagramm und eine Tabelle mit den zugehörigen erfassten Daten dargestellt. Linien zwischen den erfassten Messpunkten dienen lediglich der Orientierung. Sie lassen keine Schlüsse über die erwarteten Messergebnisse zwischen den erfassten Messpunkten zu Ergebnisse des Benchmarks Dieser Abschnitt führt die mit dem Benchmark erzielten Ergebnisse auf. Dabei werden auch die Teilergebnisse aus der Händler- und Fertigungsdomäne sowie aus deren Teilaufgaben präsentiert JBoss 15,5 22,2 29,3 37,6 48,2 49,5 49,0 50,5 46,6 35,3 17,9 15,5 3,4 JBoss repariert 15,7 29,1 40,9 51,3 39,4 16,8 14,9 Injektionsrate Abbildung 19: Benchmarkergebnisse für den JBoss-Anwendungsserver in Abhängigkeit von der Injektionsrate In Abbildung 19 sind die Benchmarkergebnisse des JBoss-Anwendungsservers beim SPECjAppServer2004-Benchmark dargestellt. Eine Linie repräsentiert die ursprüngliche Konfiguration. Bei der zweiten, als repariert gekennzeichneten Messreihe, wurden die in Abschnitt beschriebenen Anpassungen durchgeführt. Beide Messreihen skalieren für eine Injektionsrate zwischen 10 und 40 relativ gut. Das Verhältnis von erzieltem JOPS-Wert zur Injektionsrate ist in diesem Bereich stets zwischen 1,3 und 1,6. Die Injektionsrate und der JOPS-Wert korrelieren in diesem Bereich für beide Messreihen mit einem Korrelationskoeffizienten von knapp +1. Danach werden die erzielten Ergebnisse zunehmend schlechter, fallen jedoch selbst für eine Injektionsrate von 100 nicht auf Null. Eine negative Korrelation gibt es für diesen Bereich trotzdem nur mit einem Korrelationskoeffizienten von etwa -0,92 für die ursprüngliche Messreihe und etwa -0,84 bei der als repariert gekennzeichneten Messreihe. Abbildung 20 stellt die Verteilung der Ergebnisse nach Händler- und Fertigungsdomäne dar. Die Händlerdomäne wird vor allem vom Webcontainer realisiert, während die Fertigungsdomäne durch den EJB-Container ausgeführt wird. Wie auch beim GlassFish zeigen die Kurven beim JBoss keinen parallelen Verlauf. Allerdings ist es beim JBoss der Webcontainer, der zuerst überlastet ist. Er erreicht

61 JOPS JOPS 49 Performanzevaluierung von Anwendungsservern seine maximale Leistungsfähigkeit bei einer Injektionsrate von 40, während der EJB-Container bei einer Injektionsrate von 50 seine besten Ergebnisse erzielt. Auch beim JBoss hängt das Gesamtergebnis zunächst am stärksten von den Ergebnissen des Webcontainers ab. Zu Beginn hat er einen Anteil von etwa 60%, sein Einfluss wächst bis zu einer Injektionsrate von 40 auf fast 75% an. Danach fällt er jedoch rapide ab. Am Ende ist der Einfluss des EJB-Containers mit circa 60% am stärksten Fertigung 5,83 8,90 11,34 12,91 14,38 5,51 8,81 Händler 9,90 20,20 29,57 38,39 25,02 11,30 6,11 Injektionsrate Abbildung 20: Benchmarkergebnisse des JBoss-Anwendungsservers für Fertigungs- und Händlerdomäne normale Bestellungen 5,17 7,59 9,33 10,64 12,60 4,39 8,36 Großbestellungen 0,66 1,31 2,01 2,27 1,79 1,12 0,44 suchen 4,96 10,13 14,82 19,18 12,17 4,89 2,79 verwalten 2,47 5,03 7,37 9,59 6,39 3,15 1,68 kaufen 2,47 5,03 7,39 9,62 6,46 3,26 1,64 Injektionsrate Abbildung 21: Benchmarkergebnisse des JBoss-Anwendungsservers nach Teilaufgaben

62 Prozessorauslastung (%) JBoss 50 Wie bereits beschrieben, haben beide Domänen eigene Teilaufgaben. Bestellungen werden von der Fertigungsdomäne verarbeitet, Nutzeraktionen von der Händlerdomäne. Abbildung 21 zeigt die Ergebnisse dieser Teilaufgaben. Die Verteilung der Ergebnisse für Händlerdomäne entspricht der konfigurierten Verteilung für die Benchmarkläufe (50:25:25). Leichte Abweichung gibt es nur für die letzten beiden Messergebnisse. Im Bereich bis zu einer Injektionsrate von 40 korrelieren die Messreihen mit einem Korrelationskoeffizienten von fast +1 miteinander und mit der Injektionsrate. Danach zeigt sich, wie auch beim GlassFish, eine Abweichung für die normalen Bestellungen. Während alle anderen Messreihen weiterhin in gleichem Maße korrelierende Werte erzielen und mit einem Korrelationskoeffizienten von weniger als -0,91 mit der Injektionsrate korrelieren, beträgt der Koeffizient für normale Bestellungen nur etwa 0,6 für die anderen Messreihen und -0,5 für die Injektionsrate. Auch beim JBoss korrelieren die Ergebnisse der Großbestellungen mit denen der Händlerdomäne (Korrelationskoeffizient: +0,97). Daher brechen die für die Großbestellungen erzielten Werte gemeinsam mit denen der Händlerdomäne schon zusammen, während die Werte für die normalen Bestellungen weiter ansteigen Ressourcenauslastung in Abhängigkeit von der Injektionsrate Dieser Abschnitt betrachtet die Auslastung der erfassten Systemressourcen in Abhängigkeit von der Injektionsrate und ihren Zusammenhang mit den Benchmarkergebnissen. Jedes Diagramm enthält zusätzlich die skalierten Benchmarkergebniswerte als Vergleichswert. Diese Skalierung wirkt sich nicht auf die Korrelationskoeffizienten aus JOPS (zum Vgl.) 15,72 29,09 40,91 51,30 39,41 16,81 14,92 Anwendungsserver 12 % 27 % 34 % 55 % 60 % 76 % 82 % Treiber 3 % 9 % 9 % 13 % 11 % 11 % 13 % Datenbankserver 9 % 8 % 16 % 16 % 16 % 11 % 10 % Emulator 5 % 0 % 8 % 1 % 5 % 4 % 0 % Injektionsrate Abbildung 22: Die durchschnittliche Prozessorauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate

63 Anzahl Speicherseitenfehler 51 Performanzevaluierung von Anwendungsservern In Abbildung 22 ist die Auslastung der Prozessoren der für das Benchmark eingesetzten Computerknoten zu sehen. Während beim GlassFish alle Messreihen mit der Injektionsrate korrelierten, zeigt der Prozessor des JBoss-Anwendungsservers die in Abschnitt vorgestellte Sättigungskurve. Im Gegensatz zu den Benchmarkergebnissen, die ab einer Injektionsrate von 40 fallen, strebt die Prozessorauslastung stetig dem Maximum von 100% entgegen. Dieser Verlauf deutet darauf hin, dass der Prozessor des Anwendungsservers in diesem Fall einen Flaschenhals des Systems darstellt. Im Bereich bis zu einer Injektionsrate von 40 korrelieren Treiber und Anwendungsserver (Korrelationskoeffizient: +0,93) sowie Datenbankserver und Anwendungsserver (Korrelationskoeffizient: +0,8). Der Treiber produziert immer mehr Anfragen, die vom Anwendungsserver verarbeitet werden, der dazu die Datenbank verwendet. Ab einer Injektionsrate von 40 erzeugt der Treiber zwar mehr Threads, wartet jedoch ständig auf den Anwendungsserver, weshalb seine Prozessorauslastung relativ konstant bleibt. Da der Datenbankserver immer weniger Anfragen vom immer stärker überlasteten Anwendungsserver bekommt, sinkt seine Auslastung. Sie korreliert negativ mit einem Korrelationskoeffizienten von -0,995 mit der Auslastung des Anwendungsservers. Die Prozessorauslastung des Emulators erscheint zufällig. Die Ursache sind vermutlich Störfaktoren und die geringe Beeinflussung der Auslastung des Emulators durch das Benchmark. Auch beim JBoss ist der Prozessor des Anwendungsservers am stärksten ausgelastet. Der Datenbankserver hat eine maximale Auslastung von 16%, der Treiber erreicht gerade einmal eine 13%ige Auslastung ,5*JOPS (zum Vgl.) 7,86 14,55 20,46 25,65 19,70 8,40 7,46 Anwendungsserver 5,10 24,00 0,40 42,40 1,50 3,20 30,00 Treiber 5,10 5,80 0,30 12,70 0,10 0,70 5,60 Datenbankserver 9,30 8,10 16,20 16,40 15,80 11,20 9,60 Emulator 4,70 0,30 7,90 0,50 4,90 4,20 0,10 Injektionsrate Abbildung 23: Die durchschnittliche Anzahl von Seitenfehlern der Arbeitsspeicher der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Im Gegensatz zum GlassFish-Anwendungsserver, bei dem die Anzahl der Seitenfehler des Arbeitsspeichers nahezu immer Null war, zeigten sich beim JBoss in allen beteiligten Computerknoten Seitenfehler. Diese sind in Abbildung 23 dargestellt. Obwohl auch hier viele Fehler durch Störfaktoren wie andere Prozesse bedingt sein können, lässt der gewaltige Unterschied in der

64 Netzwerkauslastung (MB/s) JBoss 52 Auftrittshäufigkeit von Seitenfehlern für GlassFish und JBoss darauf schließen, dass es sich nicht nur um Zufälle handelt. Bestärkt wird diese Vermutung durch die vorhandenen Korrelationen. Zum einen Korrelieren die Seitenfehlerhäufungen des Treibers mit denen des Anwendungsservers mit einem Korrelationskoeffizienten von +0,91. Zum anderen korrelieren die Seitenfehler des Emulator negativ mit denen des Anwendungsservers (Korrelationskoeffizient: -0,88). Beides lässt sich möglicherweise mit auf den beiden Computerknoten installierten Prozessen oder Diensten erklären, die zu gewissen Zeitpunkten aktiv werden. Die wichtigste Erkenntnis dieser Messung ist jedoch die Korrelation der Seitenfehler des Datenbankservers mit den Benchmarkergebnissen (Korrelationskoeffizient: 0,83). Während es beim GlassFish keine nennenswerten Fehlerhäufungen gibt, hängt das JBoss-Ergebnis offenbar direkt von den Seitenfehlern der Datenbank ab. Offenbar existiert hier ein Konfigurationsproblem, dessen Lösung die JBoss-Ergebnisse noch verbessern könnte ,2*JOPS (zum Vgl.) 3,14 5,82 8,18 10,26 7,88 3,36 2,98 Anwendungsserver (MB/s) 2,22 4,43 6,48 8,33 6,38 4,63 2,96 Treiber (MB/s) 1,86 3,74 5,60 7,24 5,11 3,55 2,19 Datenbankserver (MB/s) 0,36 0,62 0,89 1,08 1,18 0,97 0,80 Emulator (MB/s) 0,01 0,01 0,01 0,02 0,01 0,01 0,00 Injektionsrate Abbildung 24: Die durchschnittliche Netzwerkauslastung der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate Abbildung 24 zeigt die Netzwerkauslastung für den JBoss-Anwendungsserver in Abhängigkeit von der Injektionsrate. Die Knoten korrelieren untereinander und mit den Benchmarkergebnissen (Korrelationskoeffizient: +0,9). Dabei steigt die jeweilige Netzwerkauslastung zunächst mit der Injektionsrate und fällt ab einer Injektionsrate von 40 wieder. Die einzige Ausnahme bildet der Datenbankserver, der seinen Maximalwert bei einer Injektionsrate von 50 erreicht. Auch hier verdeutlicht der Graf im Wesentlichen den Ablauf des Benchmarks. Da auch die Netzwerkauslastung keine Sättigung erreicht, bildet sie keinen Flaschenhals des Systems. Die Threadanzahl der einzelnen Computerknoten für unterschiedliche Injektionsraten ist in Abbildung 25 dargestellt. Wie beim GlassFish steigt auch beim JBoss die Anzahl der Threads des Treibers mit der Injektionsrate (Korrelationskoeffizient: +0,99). Auch hier könnte die Vielzahl konkurrierender Anfragen zu einer gegenseitigen Blockierung, damit zu höheren Antwortszeiten und somit zu schlechten Benchmarkergebnissen führen und damit einen Flaschenhals des Systems darstellen. Im Gegensatz zum GlassFish bleibt die Anzahl der Threads der anderen Computerknoten nicht konstant. Die Threadanzahl des Anwendungsserver und des Emulators wächst bis zu einer

65 Anzahl TCP-Verbindungen Threadanzahl 53 Performanzevaluierung von Anwendungsservern Injektionsrate von 50 und fällt danach wieder ab. Die Threadanzahl des Datenbankservers korreliert negativ mit einem Koeffizienten von -0,88 mit der Injektionsrate. Der JBoss nutzt das konfigurierte Maximum an verfügbaren Datenbankverbindungen aus. Deshalb werden 600 Threads vom MySQL- Server erzeugt. Der Threadpool des Emulators, der maximal 800 Threads enthalten kann, wird nicht ausgenutzt *JOPS (zum Vgl.) 628, , , , ,28 672,21 596,70 Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 25: Die durchschnittliche Threadanzahl der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate *JOPS (zum Vgl.) 314,47 581,84 818, ,04 788,14 336,11 298,35 Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 26: Die durchschnittliche Anzahl der TCP-Verbindungen der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate

66 Anzahl TCP-Fehler (logarithmische Skalierung) JBoss 54 Abbildung 26 zeigt die durchschnittliche Anzahl von TCP-Verbindungen der einzelnen Computerknoten in Abhängigkeit der Injektionsrate. Die Anzahl der TCP-Verbindungen des Datenbankservers entspricht dem konfigurierten Maximum von 600 Datenbankverbindungen. Hinzu kamen noch die Verbindungen für Perfmon. Ab einer Injektionsrate von 50 wurde die JDBC-Poolgröße beim Anwendungsserver wie in Abschnitt von 300 auf 280 verkleinert, um gelegentliche Fehler beim Verbindungsaufbau zu beseitigen. Daher verringert sich die Verbindungsanzahl hier auf 592. Die Verbindungsanzahl des Anwendungsservers und des Treibers korreliert mit einem Korrelationskoeffizienten von +0,998. Beide korrelieren mit der Injektionsrate (Korrelationskoeffizient: +0,93). Die Anzahl der Verbindungen des Anwendungsservers ist dabei, außer bei einer Injektionsrate von 100, stets geringer als die Anzahl der zur Verfügung stehenden Threads. Die Verbindungsanzahl des Emulators steigt bis zu einer Injektionsrate von 70 kontinuierlich an und fällt danach wieder *JOPS (zum Vgl.) 157,23 290,92 409,10 513,02 394,07 168,05 149,18 Anwendungsserver Treiber Datenbankserver Emulator Injektionsrate Abbildung 27: Die durchschnittliche Anzahl der TCP-Fehler der beteiligten Computerknoten bei der Durchführung des SPECjAppServer2004-Bechmarks mit dem JBoss-Anwendungsservers in Abhängigkeit von der Injektionsrate In Abbildung 27 ist die Anzahl der aufgetretenen TCP-Fehler in Abhängigkeit von der Injektionsrate anhand einer logarithmischen Skala dargestellt. Beim Anwendungs- und Datenbankserver treten keinerlei Verbindungsfehler auf. Die Anzahl der Fehler beim Treiber korrelieren mit einem Korrelationskoeffizienten von +0,94 mit der Injektionsrate. Diese Fehler treten erst ab einer Injektionsrate von 40 auf. Auch die Anzahl der Fehler, die für den Emulator auftreten, wächst ab einer Injektionsrate von 40. Einzige Ausnahme ist hier die Fehlerzahl für eine Injektionsrate von 100, die unter dem Wert für die Fehleranzahl bei einer Injektionsrate von 70 liegt. Die auftretenden TCP- Verbindungsfehler entstehen, weil der Anwendungsserver so stark überlastet ist, dass er den TCP- Handshake nicht mehr korrekt ausführen kann. Als Folge kann es bei Verbindungsversuchen vom Treiber oder vom Emulator zu Fehlern kommen. Diese sind dann die Ursache für schlechte Resultate beim Benchmark.

67 JOPS 55 Performanzevaluierung von Anwendungsservern Betrachtungen bei begrenzten Ressourcen Zusätzlich zu den bisherigen Untersuchungen wurden die Auswirkungen begrenzter Ressourcen auf das Verhalten der Anwendungsserver untersucht. Dabei fokussiert dieser Abschnitt auf die Begrenzung des verfügbaren Arbeitsspeichers für den Anwendungsserver. Für die Konfiguration wurde die run.bat des JBoss angepasst. Auf diese Weise konnte der Einsatz von externen Werkzeugen, die zum Beispiel für die Begrenzung der verfügbaren Prozessorleistung notwendig sind, vermieden werden Fertigung 0,00 0,09 6,05 14,72 10,22 12,91 Händler 0,00 0,04 17,54 39,22 32,66 38,39 MB Arbeitsspeicher Abbildung 28: Benchmarkergebnisse des JBoss-Anwendungsservers bei unterschiedlichen Speichergrößen und einer Injektionsrate von 40 Abbildung 28 zeigt die Messreihen, zur Untersuchung des Verhaltens des JBoss-Anwendungsservers bei unterschiedlichen Arbeitsspeichergrößen und einer festen Injektionsrate von 40. Es wurde nach Fertigungs- und Händlerdomäne unterschieden, um die Auswirkungen der Arbeitsspeicherbegrenzung auf Web- und EJB-Container zu evaluieren. Stehen dem JBoss zu wenige Ressourcen zur Verfügung, so werden schlechtere Ergebnisse erzielt. Dabei korreliert die Größe des verfügbaren Arbeitsspeichers mit den Benchmarkergebnissen (Korrelationskoeffizient für den Bereich von 256 bis 384: +0,99). Bei 384 MB Arbeitsspeicher erreichen die Benchmarkergebnisse ihren Maximalwert. Eine weitere Erhöhung des Speichers führt zu keinem weiteren Performanzgewinn. Der Einbruch für einen Wert von 512 MB kann mit den in Abschnitt beschriebenen Beobachtungen erklärt werden. Zwischen Händler- und Fertigungsdomäne besteht eine Korrelation mit einem Koeffizienten von +0,99. Die Verminderung des verfügbaren Arbeitsspeichers wirkt sich also auf beide Container gleich stark aus. In Abbildung 17 ist das Verhalten des JBoss-Anwendungsservers für unterschiedliche Speichergrößen in Abhängigkeit von der Injektionsrate dargestellt. Es wurden dazu zwei Messreihen durchgeführt. Bei der ersten standen dem Anwendungsserver 256 MB Arbeitsspeicher zur Verfügung, bei der zweiten verfügte er über 1024 MB Arbeitsspeicher. Das obere linke Diagramm zeigt die erzielten Benchmarkergebnisse. Nur für eine Injektionsrate von 10 sind sie nahezu identisch. Danach brechen die Ergebnisse bei geringerer Arbeitsspeichergröße rapide zusammen.

68 Anzahl TCP-Verbindungen Anzahl TCP-Fehler (Treiber) (logarithmische Skalierung) Netzwerkauslastung (MB/s) Threadanzahl JOPS Prozessorauslastung (%) JBoss MB RAM 15,70 2,76 0,11 0, MB RAM 15,72 29,09 40,91 51,30 Injektionsrate 100 % 90 % 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % 0 % MB RAM 31 % 87 % 91 % 88 % 1024 MB RAM 12 % 27 % 34 % 55 % Injektionsrate 8,00 7,00 6,00 5,00 4,00 3,00 2,00 1,00 0, MB RAM 1,88 0,24 0,03 0, MB RAM 1,86 3,74 5,60 7,24 Injektionsrate MB RAM MB RAM Injektionsrate MB RAM MB RAM Injektionsrate MB RAM MB RAM Injektionsrate Abbildung 29: Benchmarkergebnisse und Ressourcenverbrauch des JBoss-Anwendungsservers bei unterschiedlichen Speichergrößen in Abhängigkeit von der Injektionsrate Im oberen rechte Diagramm von Abbildung 17 ist die Prozessorauslastung in Abhängigkeit von der Injektionsrate abgebildet. Die Prozessorauslastung ist bei der Messung mit 256 MB Arbeitsspeicher stets um ein wesentlich höher als bei der Messung mit 1024 MB Arbeitsspeicher. Ab einer Injektionsrate von 20 kann man von einer Sättigung der Ressource ausgehen. Damit ist der Prozessor nach Abschnitt der Flaschenhals und somit die Ursache für das schlechte Benchmarkergebnis.

69 JOPS 57 Performanzevaluierung von Anwendungsservern Wie auch die JOPS fällt die Netzwerkauslastung, die im linken mittleren Diagramm dargestellt ist, stark mit steigenden Injektionsraten. Trotz des geringeren verfügbaren Speichers verwendet der JBoss für eine Injektionsrate von 10 und 20 mehr Threads als bei der zweiten Messreihe. Die Threadanzahl, die das rechte mittlere Diagramm zeigt, steigt mit der Injektionsrate an, wird aber bei einer Injektionsrate von 30 von der zweiten Messreihe überholt. Das untere linke Diagramm zeigt, dass die Anzahl der TCP-Verbindungen bei der Messreihe mit 256 MB Arbeitsspeicher trotz der begrenzten Ressourcen stets höher ist als die der zweiten Messung. Das untere rechte Diagramm schließlich zeigt, dass bei begrenzter zur Verfügung stehender Arbeitsspeichergröße die Anzahl der TCP-Verbindungsfehler schon bei geringen Injektionsraten sehr groß ist und stark wächst. Dies liegt an der stärken Auslastung des Prozessors des Anwendungsservers Fehlerbetrachtungen Dieser Abschnitt beschäftigt sich mit der Frage, inwieweit die Ergebnisse repräsentativ und reproduzierbar sind Allgemeine Fehlerbetrachtungen und Stabilität Wie bei jeder Messung wurden auch hier die Messergebnisse durch Störfaktoren verfälscht. Im Kontext der Erfassung der vorliegenden Messreihen zählen neben der Messinstrumentierung selbst zum Beispiel andere Prozesse und Dienste auf den verwendeten Windows-Systemen zu diesen Störgrößen. Im Gegensatz zur Messung des GlassFish-Anwendungsservers wurde für die Erfassung der Messwerte in diesem Kapitel die zentrale Perfmon-Instanz auf einem eigenständigen Computerknoten ausgeführt. Das Ausleseintervall für die Performanzzähler lag ebenfalls bei 120 Sekunden IR 10 IR 15 IR 20 IR 30 IR 40 IR 50 IR 70 IR 80 IR 100 Abbildung 30: Stabilitätsanalyse der Benchmarkergebnisse des JBoss-Anwendungsservers für ausgewählte Injektionsration Zur Ermittlung des Einflusses der Störfaktoren sowie der Vorhersagbarkeit der Performanz des Anwendungsservers für eine gegebene Konfiguration wurden mehrere Messreihen mit gleichen und unterschiedlichen Konfigurationen durchgeführt. Das Betriebssystem war in einigen Fällen gerade neu gestartet worden und lief in anderen schon über eine längere Zeit. In einigen Fällen wurde auch die Größe der JDBC-Pools geringfügig verändert. Die Ergebnisse dieser Stabilitätsanalyse sind in Abbildung 30 dargestellt. Da für die Injektionsrate von 40 insgesamt 33 Messreihen vorlagen, wurden

70 JBoss 58 für die visuelle Darstellung sieben repräsentative herausgegriffen. Tabelle 8 enthält die zugehörige einfaktorielle Varianzanalyse dieser Messreihen. Tabelle 8: Einfaktorielle Varianzanalyse der Benchmarkergebnisse aus Abbildung 30 Gruppen Anzahl Summe Mittelwert Varianz IR ,21 15,61 0,03 IR ,79 22,40 0,43 IR ,96 29,32 0,10 IR ,51 39,84 7,78 IR ,24 46,28 52,73 IR ,92 33,98 56,25 IR ,32 16,16 0,84 IR ,25 21,13 598,93 IR ,89 8,30 35,40 Für Injektionsraten bis einschließlich 30 ist die Varianz relativ gering. Danach schwankt sie teilweise erheblich. Um auszuschließen, dass die verschiedenen Konfigurationen bezüglich des JDBC-Pools für die starke Varianz verantwortlich waren, wurden weitere Messungen durchgeführt, bei denen die Konfiguration vollständig unangetastet blieb. Die Ergebnisse sind in Tabelle 9 dargestellt. Auch in diesem Fall war die Varianz erheblich. Dies lässt darauf schließen, dass die Performanz des JBoss- Anwendungsserver, insbesondere für höhere Injektionsraten, stark von Störfaktoren beeinflusst wird. Es ist also unmöglich die zu erwartenden Ergebnisse für vergleichbare Messungen vorherzusagen. Tabelle 9: Einfaktorielle Varianzanalyse bei einer Injektionsrate von 40 (konstante Konfiguration) Gruppen Anzahl Summe Mittelwert Varianz IR ,14 48,03 83,49 Der störende Einfluss, der durch fremde Prozesse entstand wurde vor allem in den Perfmon- Ausgaben der einzelnen Messungen sichtbar. Sie zeigten sich vor allem als plötzliche Spitzen in der Prozessorauslastung und der Anzahl der Arbeitsspeicherseitenfehler. Da bis auf die Messung der aufgetretenen TCP-Fehler immer Mittelwerte für die Ressourcenauslastung verwendet wurden, wurde das Gewicht dieser Störfaktoren wieder reduziert. Dennoch zeigte der JBoss- Anwendungsserver zum Teil erhebliche Einbrüche bei der Ressourcennutzung, für die keine Beeinflussung von außen festgestellt werden konnte. Abbildung 31 zeigt einen solchen Fall. Die Prozessorauslastung ist für einen Zeitraum von 20 Minuten stark verringert. Das Benchmark wurde viermal mit der gleichen Konfiguration durchgeführt. In drei Fällen kam es zu dem dargestellten Verhalten, jeweils mit einer unterschiedlichen Auslastungsreduzierung. Jedes mal war dies mit einem schlechten Benchmarkergebnis verbunden. Bei einem Durchlauf jedoch fand dieser Einbruch nicht statt und die Benchmarkergebnisse waren respektabel.

71 59 Performanzevaluierung von Anwendungsservern Abbildung 31: Einbruch der Prozessorauslastung beim JBoss-Anwendungsserver Gültigkeit der Ergebnisse Selbst nach der Behebung der in Abschnitt beschriebenen Probleme konnte mit dem JBoss- Anwendungsserver kein Benchmark durchgeführt werden, bei dem die Fehlerberichtsdateien leer blieben. Zumindest die in Abschnitt beschriebenen Transaktionsabbrüche waren jeweils vertreten. Außerdem führte der im gleichen Abschnitt beschriebene Fehler bei der Erstellung des Abschlussberichtes dazu, dass unklar bleibt, ob der JBoss die Konsistenzprüfungen bestehen würde. Die in Abschnitt beschriebenen Probleme bei der Stabilität der Ergebnisse erschweren es zudem, zwei aufeinander folgende Testläufe zu erzeugen, deren Resultate innerhalb des von der SPEC geforderten Toleranzbereiches liegen. Es konnte kein gültiges Ergebnis erzielt werden, dessen Fehlerlogdateien leer waren und das zudem alle Konsistenzprüfungen bestand. 6.3 Fazit Der Einsatz des JBoss auf einer Windows-Plattform und zusammen mit einem MySQL-Datenbankmanagementsystem gestaltete sich als sehr umständlich. Eine Konfiguration von Hand erwies sich als zu komplex und der Einsatz des Specj-Kits, der auf der offiziellen Webseite des Benchmarks (2) empfohlen wird, war sehr viel schwieriger als auf der Projektseite (45) versprochen. Trotz monatelanger Recherchen und dem Austausch mit einer Reihe von Experten ist es dem Autor nicht gelungen, einen fehlerfreien Benchmarklauf durchzuführen. Hinzu kam noch die Tatsache, dass aufgrund von Fehlern eine Rekonfiguration des Betriebssystems durchgeführt werden musste. Außerdem funktionierte die Interaktion mit dem MySQL-Datenbankserver nicht sehr verlässlich,

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

Mehr

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Connection Architecture Teil 4 JCA

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Connection Architecture Teil 4 JCA UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 4 JCA el0100 copyright W. G. Spruth, wgs 04-09 Enterprise

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Programmierung von Client/Server- Anwendungen

Programmierung von Client/Server- Anwendungen Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

Liste V Enterprise JavaBeans

Liste V Enterprise JavaBeans Liste V Enterprise JavaBeans Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung zur Vertiefungslehrveranstaltung Spezielle Methoden der Softwaretechnik SS

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Application Server und Continuous Integration

Application Server und Continuous Integration Application Server und Continuous Integration Outline 2 Einleitung Application Server Java EE Enterprise Applikationen vs. Web Applikationen Web Application Life Cycle Servlets JavaServer Pages verschiedene

Mehr

Architekturübersicht. April 2005. IBM Rational Portfolio Manager. Architekturübersicht

Architekturübersicht. April 2005. IBM Rational Portfolio Manager. Architekturübersicht April 2005 IBM Rational Portfolio Manager Architekturübersicht Seite 2 Inhalt 3 Architekturübersicht 3 Datenbankschicht 3 Anwendungsschicht 4 Darstellungsschicht 6 Systemanforderungen 7 Beispielkonfigurationen

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung Methoden und Werkzeuge zur Softwareproduktion WS 2003/04 Karsten Beyer Dennis Dietrich Überblick Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung 2 Motivation Funktionstest

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

JBoss 7 als Plattform für hochverfügbare Anwendungen

JBoss 7 als Plattform für hochverfügbare Anwendungen JBoss 7 als Plattform für hochverfügbare Anwendungen Orientierungspunkt 04/2013 24.05.2013, OIO Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld Java EE seit 1998 Konzeption und Realisierung

Mehr

Security Technologien in Java EE 6

Security Technologien in Java EE 6 Security Technologien in Java EE 6 Java Forum Stuttgart 2010 Sebastian Glandien Acando GmbH sebastian.glandien@acando.de Agenda I. Einleitung II. Java Authentication SPI for Containers (JSR-196) I. Message

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Stabilisierung von J2EE-Anwendungen durch APM

Stabilisierung von J2EE-Anwendungen durch APM Stabilisierung von J2EE-Anwendungen durch APM juergen.moors@de.quest.com Agenda Was ist Application Performance Management? Anwendungen Wo liegt das Problem? APM Best Practices APM Was ist APM? Was ist

Mehr

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Copyright 2014, Oracle and/or its affiliates. All rights reserved. 1 Oracle Fusion Middleware Ordnung im Ganzen Matthias Weiss Direktor Mittelstand Technologie ORACLE Deutschland B.V. & Co. KG 2 Agenda Begriffe & Ordnung Fusion Middleware Wann, was, warum Beispiel für

Mehr

Transaktionsmonitore und Applikationsserver

Transaktionsmonitore und Applikationsserver Transaktionsmonitore und Applikationsserver Marc Monecke monecke@informatik.uni-siegen.de Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D-57068 Siegen 13. Juni 2003

Mehr

Module für eine Java-Administrationsschulung

Module für eine Java-Administrationsschulung Module für eine Java-Administrationsschulung Schulungsmodule 1 Java Administration allgemein...2 1.1 Java und die Virtual Machine...2 1.2 Java EE Bestandteile...2 1.3 Java Management Extensions...2 1.4

Mehr

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS)

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS) (IGS) SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Services (AMS) Martin Kadner, Product Manager SAP Hosting, GTS Klaus F. Kriesinger, Client Services Executive,

Mehr

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK Inhaltsverzeichnis jetzt lerne ich Vorwort 17 1 Einleitung 19 1.1 Zentrale Konzepte 20 1.1.1

Mehr

Java 2 Enterprise Edition

Java 2 Enterprise Edition Java 2 Enterprise Edition Informatikseminar Enterprise JavaBeans, e-commerce und UML Peter Haase peter@informatik.uni-rostock.de Inhaltsverzeichnis 1 Einführung in die J2EE 4 2 Das J2EE Applikationsmodell

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany Enterprise JavaBeans Einführung Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Inhalt Allgemeines Motivation Rollen Aufbau einer EJB Arten von Beans Enterprise JavaBeans

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119 1... SAP NetWeaver... 25 1.1... Plattform für die Enterprise Service-Oriented Architecture... 26... 1.1.1... Enterprise-SOA-Definition... 26... 1.1.2... Vorteile einer serviceorientierten Architektur...

Mehr

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht Enterprise JavaBeans Überblick 1. Überblick Komponententechnologien 2. Einführung 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

Automatisiertes Testen von Java EE-Applikationen mit Arquillian

Automatisiertes Testen von Java EE-Applikationen mit Arquillian CONCEPTS DEVELOPMENT INTEGRATION Automatisiertes Testen von Java EE-Applikationen mit Arquillian Sebastian Lammering CDI AG Firmenkurzportrait Die CDI ist ein IT-Beratungsunternehmen mit Sitz in Dortmund.

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2014 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Centaurus-Platform - JSP/Servlets für Webhosting

Centaurus-Platform - JSP/Servlets für Webhosting Centaurus-Platform - JSP/Servlets für Webhosting by Thorsten Kamann, Peter Roßbach NOTICE: Die Centaurus-Platform basiert auf einem Tomcat 5 Release. Im Wesentlichen bieten wir sinnvolle Erweiterungen

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Managed Services Zeitgewinn für die SAP Basis am Beispiel von EMCLink.net für SAP R/3

Managed Services Zeitgewinn für die SAP Basis am Beispiel von EMCLink.net für SAP R/3 Managed Services Zeitgewinn für die SAP Basis am Beispiel von EMCLink.net für SAP R/3 1 Wo liegt das Problem? Was jeder Basismanager wissen sollte... jedoch oft nicht weiß Wie sieht meine Infrastruktur

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

1 Einführung 1.1 Motivation

1 Einführung 1.1 Motivation 1 Einführung 1.1 Motivation J2EE und JBoss beides zwei der Hauptthemen heutiger Enterprise-Applikationen. J2EE (alias Java 2 Platform, Enterprise Edition) ist ein De-facto-Standard, der Einzug in die Entwicklung

Mehr

Technische Dokumentation

Technische Dokumentation Technische Dokumentation www.corporater.com Technische Dokumentation Corporater Enterprise Management Suite v3.0 1 Inhaltsverzeichnis Technische Produktdokumentation, Corporater Enterprise Management Suite

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Seminar Applicationserver Alireza Salemi Mailto: info@salemi.de

Seminar Applicationserver Alireza Salemi Mailto: info@salemi.de BEA WebLogic Server 6.1 Seminar Applicationserver Alireza Salemi Mailto: info@salemi.de Inhalt Einführung BEA WebLogic J2EE 1.3 Container Managed Persistence WAP Mission critical Support für EJBs Zusammenfassung

Mehr

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften

Mehr

Webinar: Einführung in ICEfaces

Webinar: Einführung in ICEfaces Webinar: Einführung in ICEfaces präsentiert von VOIP-Audio ist standardmässig aktiviert Alternatives Einwählen: +41 (0) 415 0008 65 ICESOFT TECHNOLOGIES INC ICESOFT Donnerstag, TECHNOLOGIES 26. März 2009

Mehr

Inhaltsverzeichnis. Applikationsserver flexible Softwareinfrastruktur für verteilte Anwendungen

Inhaltsverzeichnis. Applikationsserver flexible Softwareinfrastruktur für verteilte Anwendungen Applikationsserver flexible Softwareinfrastruktur für verteilte Anwendungen Autor: Thomas Mattern Product Marketing Manager In-Q-My Technologies Kölnerstr. 265 51149 Köln www.inqmy.com Inhaltsverzeichnis

Mehr

Inhaltsverzeichnis. 1 Ein Einstieg mit Profil 1. 2 Aufsetzen der Entwicklungsumgebung 19

Inhaltsverzeichnis. 1 Ein Einstieg mit Profil 1. 2 Aufsetzen der Entwicklungsumgebung 19 xi 1 Ein Einstieg mit Profil 1 1.1 Java EE 7 der Standard für Enterprise Java.................. 1 1.1.1 Struktur einer Enterprise-Java-Anwendung............. 1 1.1.2 Die Java Enterprise Edition (Java EE)..................

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

ORACLE Application Express (APEX) und Workflows. Copyright 2014. Apps Associates LLC. 1

ORACLE Application Express (APEX) und Workflows. Copyright 2014. Apps Associates LLC. 1 ORACLE Application Express (APEX) und Workflows Copyright 2014. Apps Associates LLC. 1 Apps Associates Weltweit tätiger Dienstleister für Geschäfts- und Technologieberatung 2002 Gründung der Apps Associates

Mehr

Internet Integration für

Internet Integration für für Systemprogrammierer systemorientierte Mitarbeiter Version 1.0 I März 2011 Autor: Wolfram Greis European Mainframe Academy GmbH Max von Laue Straße 9 D 86156 Augsburg Tel. +49 821 56756 10 info@mainframe

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung mit dem SAP Web Application Server

Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung mit dem SAP Web Application Server 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung

Mehr

JAVA. Ein kurzer Überblick. Thomas Karp

JAVA. Ein kurzer Überblick. Thomas Karp JAVA Ein kurzer Überblick Thomas Karp WAS IST JAVA? Java ist eine fast rein objektorientierte Sprache nicht JavaScript eine professionelle Sprache eine im Unterricht weit verbreitete Sprache für verschiedene

Mehr

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB) silbergrau Consulting & Software GmbH Enterprise Java Beans (EJB) Fachhochschule Hagenberg WS 2002 / 2003 Silbergrau Consulting & Software GmbH Dr. Andreas Erlach Inhaltsübersicht Application Server J2EE

Mehr

Execution Server Integrationshandbuch

Execution Server Integrationshandbuch Visual Rules Suite - Execution Platform Execution Server Integrationshandbuch Version 5.4.1 Bosch Software Innovations Americas: Asia: Europe: Bosch Software Innovations Corp. Bosch Software Innovations

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

JSP und Servlet Programmierung

JSP und Servlet Programmierung Seminarunterlage Version: 5.02 Copyright Version 5.02 vom 1. März 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004 METEOR Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts Thorsten Ludewig Juni 2004 1 Übersicht Was ist METEOR Architektur Technische Realisierung Zusammenfassung Zukünftige Entwicklungen

Mehr

Virtualisierung im IT-Betrieb der BA

Virtualisierung im IT-Betrieb der BA Virtualisierung, essenzielles Werkzeug in der IT-Fabrik Martin Deeg, Anwendungsszenarien Cloud Computing, 31. August 2010 Virtualisierung im IT-Betrieb der BA Virtualisierung im IT-Betrieb der BA Effizienzsteigerung

Mehr

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Cloud Computing Betriebssicherheit von Cloud Umgebungen Urs Zumstein Leiter Performance Care Team Urs.Zumstein@DevoTeam.ch 079 639 42 58 Agenda Definition von Cloud Services Anforderungen an die Betriebssicherheit

Mehr

AS/point, Ihr Partner die nächsten 10 und mehr Jahre -

AS/point, Ihr Partner die nächsten 10 und mehr Jahre - AS/point, Ihr Partner die nächsten 10 und mehr Jahre - technologisch betrachtet http://www.aspoint.de 1 Unsere vier Säulen heute e-waw modulare Warenwirtschaft für iseries evo-one Organisation und CRM

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Enterprise Java Beans

Enterprise Java Beans Enterprise Java Beans Beispiel Minibank nur: Kunde, Konto, Überweisung personen.person Attributes Name:String Vorname:String überweisungen.überweisung Attributes Verwendungszweck:String Datum:Date betrag:integer

Mehr