IBM WebSphere Application Server Advanced Edition

Handbuch zur Optimierung

Neuerungen bei der Leistungsoptimierung

Zwischenspeichern dynamischer Fragmente

Zusätzliche Referenzinformationen

Prozeduren von Leistungsanalyse-Tools

Leistungsüberwachung unter Windows NT/2000 starten

Neuerungen bei der Leistungsoptimierung

Leistungsoptimierungsprogramm
Zwischenspeichern von dynamischen Fragmenten

Das Leistungsoptimierungsprogramm ist ein Tool, das im Lieferumfang von WebSphere Application Server Advanced Edition enthalten ist und die gängigsten Leistungseinstellungen für den Anwendungsserver umfasst. Mit diesem Tool können Sie die Einstellungen für Anwendungen, Servlets, Enterprise-Beans, Datenquellen und die erwartete Arbeitslast optimieren. Folgende Parameter können gesetzt werden:

Webcontainer - maximale Thread-Größe
ORB-Merkmale - Übergabe durch Referenz, Größe des ORB-Thread-Pools
Datenquelle - Größe des Verbindungspools, Größe des Anweisungs-Cache
Datenbank (nur DB2) - Ruft DB2SmartGuide auf, der daraufhin die der Datenquelle zugeordnete DB2-Datenbank optimiert
Java Virtual Machine (JVM) - ursprüngliche und maximale Freispeichergröße

Zum Aufrufen der JVM über die Administrationskonsole wählen Sie Konsole > Assistenten > Leistungsoptimierungsprogramm aus.

Weitere Informationen finden Sie im InfoCenter-Artikel 6.6.21.

Zwischenspeichern von dynamischen Fragmenten

Das Zwischenspeichern von dynamischen Fragmenten ist die Fähigkeit, die Ausgabe dynamischer Servlets und JSP-Dateien zwischenzuspeichern - eine Technologie, die die Anwendungsleistung erheblich verbessert. Dieser Zwischenspeicher arbeitet in der JVM eines Anwendungs-Servlets und fängt Aufrufe der service()-Methode eines Servlets ab. Dabei prüft er, ob er den Aufruf aus dem Zwischenspeicher beantworten kann, anstatt das Servlet erneut auszuführen. Da J2EE-Anwendungen hohe Lese-Schreib-Raten aufweisen und einen kleinen Grad an Latenzzeit in der Aktualität ihrer Daten tolerieren, kann das Zwischenspeichern von Fragmenten deutliche Verbesserungen bezüglich Antwortzeit, Durchsatz und Skalierbarkeit des Servers erzielen.

Nachdem ein Servlet ausgeführt wurde (und die Ausgabe generiert hat, die zwischengespeichert wird), wird ein Cache-Eintrag mit dieser Ausgabe generiert. Außerdem treten Nebeneffekte der Ausführung ein (d. h., andere Servlets oder JSP-Dateien werden aufgerufen), und es werden Metadaten zum Eintrag erzeugt, einschließlich Daten zu Zeitlimit und Eintragspriorität. Eindeutige Einträge werden durch eine ID-Zeichenfolge gekennzeichnet, die von dem Objekt HttpServletRequest für jeden Servlet-Aufruf generiert wird. Folglich wird ein Servlet entsprechend den Anforderungsparametern zwischengespeichert, die der URI für den Aufruf des Servlets oder der Sitzungsinformationen verwendet. Weil JSP-Dateien von WebSphere Application Server in Servlets kompiliert werden, sind JSPs und Servlets austauschbar (außer bei der Deklaration von Elementen innerhalb einer XML-Datei).

Festsetzung:

Wählen Sie in der Administrationskonsole den Anwendungsserver aus, der optimiert werden soll.
Klicken Sie auf Services > Webcontainerservice > Merkmale bearbeiten.
Wählen Sie das Register Zwischenspeicherung von Servlets und wählen Sie das Markierungsfeld Zwischenspeicherung von Servlets aktivieren aus.
Klicken Sie auf OK und speichern Sie die Änderungen.
Starten Sie den Anwendungsserver erneut.

Weitere Informationen finden Sie im InfoCenter-Artikel 4.5 Zwischenspeichern dynamischer Fragmente.

Symptomtabelle

Die Symptomtabelle erlaubt Ihnen den direkten Einstieg in die Optimierung. Sie dient dazu, Ihnen eine schnellen Suche nach Symptomen zu ermöglichen und stellt zu jedem Symptom einen Link zu den zugehörigen Informationen bereit. Die Tabelle enthält folgende Arten von Informationen:

Das Symptom
Die Spalte links listet die Symptome und Beschreibungen auf. Symptome können speziell oder allgemein sein.
Zusätzliche Informationen
Die Spalte rechts enthält einen Link, der Sie zu zusätzlichen Informationen über das Symptom führt

Symptom	Zusätzliche Informationen
Durchsatz und Antwortzeit entsprechen nicht den Erwartungen.	Prozessorgeschwindigkeit
AIX: Fehler bei der Speicherzuordnung Solaris: Zu viele Dateien geöffnet	AIX-Dateideskriptoren (ulimit) oder Solaris-Dateideskriptoren (ulimit)
Solaris: Der Server wird während Spitzenbelastungszeiten blockiert, minutenlange Antwortzeiten, die Prozessorauslastung bleibt hoch, während sämtliche Aktivitäten in den Systemprozessen stattfinden, und netstat zeigt an, dass mehrere Sockets für Port 80 im Status CLOSE_WAIT oder FIN_WAIT_2 geöffnet sind.	Solaris tcp_close_wait_interval/tcp_time_wait_interval und Solaris tcp_fin_wait_2_flush_interval
Windows NT/2000: Netstat zeigt an, dass zu viele Sockets im Status TIME_WAIT sind.	Windows NT/2000 TcpTimedWaitDelay
HP-UX 11: Unerwünschter Durchsatz und die Priorität des Anwendungsservers wurde nicht angepasst.	Betriebssystempriorität des WebSphere-Application-Server-Prozesses anpassen
Unter Belastung gelangen Client-Anforderungen nicht zum Webserver, weil ihr Zeitlimit abläuft oder weil sie zurückgewiesen werden.	Für HP-UX 11 siehe HP-UX 11 tcp_conn_request_max Für IIS Windows NT/2000 siehe Parameter ListenBackLog Für IBM HTTP Server unter NT siehe ListenBackLog
Windows NT/2000: Die Leistung von WebSphere Application Server verringert sind, nachdem ein Anwendungsserver eines anderen Herstellers installiert wurde.	Merkmale der IIS-Berechtigung
Die Metrik für den Grenzwert in Prozent im Resource Analyzer zeigt an, dass der Thread-Pool des Webcontainers zu klein ist.	Maximale Anzahl der ThreadsMax-Verbindungen für Webcontainer
Netstat zeigt, dass zu viele Sockets im Status TIME_WAIT für Port 9080 geöffnet sind.	Maximalanzahl der Keepalives für Webcontainertransport
Während der Auslagerung von Speicherseiten finden zu viele Ein-/Ausgabeoperationen auf der Platte statt.	Einstellungen des Freispeichers
Die Metrik für Belegung in Prozent im Resource Analyzer zeigt für einen Pool für Datenquellenverbindungen an, dass die Poolgröße zu hoch ist.	Größe des Pools für WebSphere-Datenquellenverbindungen
Die Metrik für den Cache für vorbereitete Anweisungen (Prepared Statement Cache) im Resource Analyzer zeigt an, dass die Größe des Cache für vorbereitete Anweisungen für die Datenquelle zu niedrig ist.	Größe des Cache für vorbereitete Anweisungen
Beim Schreiben von DB2-Protokollsätzen finden zu viele Ein-/Ausgabeoperationen statt.	DB2 MinCommit
Die Metrik für Grenzwert in Prozent im Resource Analyzer zeigt an, dass der Thread-Pool für Object Request Broker zu klein ist.	Warteschlangen und Enterprise-Beans
Die JVMPI-Schnittstelle (Java Virtual Machine Profiler Interface) von Resource Analyzer zeigt eine Überbelegung der Objekte an, wenn für die Garbage Collection zu viel Zeit benötigt wird.	Die Überbelegung von Objekten erkennen
Die Metrik für belegten Speicher im Resource Analyzer zeigt Speicherlecks an und Java zeigt die Ausnahmebedingung `Out of Memory` (Kein Speicher) an.	Speicherlecks erkennen
Durchsatz, Antwortzeit und Skalierbarkeit entsprechen nicht den Erwartungen.	Falls dies die Anwendung erlaubt, nutzen Sie das Zwischenspeichern dynamischer Fragmente.

Grundlagen der Optimierung

Mit Hilfe der Optimierungsprozeduren können Sie für WebSphere Application Server eine Vielzahl von Leistungsverbesserungen erzielen. Dieses Handbuch zur Optimierung zeigt Ihnen, wie die Optimierung funktioniert, indem es allgemeine Empfehlungen gibt und spezielle Optimierungsmethoden beschreibt. Außerdem enthält es Hinweise und Tipps zu den verschiedenen Faktoren und Variablen, die zur Leistungsoptimierung beitragen können.

Verwenden Sie die Beispiele und Informationen im Handbuch zur Optimierung, um mehr über die Optimierung zu erfahren. Die Optimierung ist ein fortlaufender Lernprozess. Ihre Ergebnisse können von den Ergebnissen in diesem Handbuch abweichen.

Faktoren, die die Optimierung beeinflussen

Nachfolgend sind alle Komponenten aufgeführt, die die Leistung des WebSphere Application Server beeinflussen können:

Die verwendete Anwendung
Hardwarekapazität und -einstellungen
Einstellungen des Betriebssystems
Webserver
WebSphere-Application-Server-Prozess
Java Virtual Machine (JVM)
Datenbank

Jede dieser Komponenten verfügt über eigene Optimierungsoptionen mit unterschiedlicher Bedeutung und Wirkung. Die oben genannten Komponenten werden detailliert im Abschnitt Einzelne Leistungsparameter in dieser Dokumentation erläutert.

Zu Ihrer Unterstützung werden in diesem Handbuch Prozeduren zum Festlegen von Parametern in anderen Produkten beschrieben. Weil diese Produkte Änderungen unterliegen können, sollten Sie diese Prozeduren lediglich als Empfehlungen betrachten.

Arten der Optimierung

Es gibt zwei Arten der Optimierung: die Anwendungsoptimierung und die Parameteroptimierung.

Obwohl die Anwendungsoptimierung manchmal die größten Optimierungsverbesserungen erzielt, konzentriert sich dieses Handbuch auf die einzelnen Leistungsparameter und ihr Zusammenwirken.

Das White Paper WebSphere Application Server Development Best Practices for Performance and Scalability behandelt die Anwendungsoptimierung und beschreibt die am besten geeigneten Entwicklungsmethoden für Webanwendungen, die Servlets, JSP-Dateien (Java Server Pages) und JDBC (Java Database Connectivity) enthalten, und die am besten geeigneten Entwicklungsmethoden für Unternehmensanwendungen, die Enterprise-Bean-Komponenten enthalten.

Optimierung der Parameter

Die Optimierung der Parameter umfasst das Ändern der Einstellungen von WebSphere Application Server zum Zweck der Leistungsoptimierung. Die in diesem Handbuch empfohlenen Werte sind allgemeine Richtlinien. Die optimalen Einstellungen für Ihre Umgebung können davon erheblich abweichen. Außerdem sollten Sie bedenken, dass nach dem Beseitigen eines Engpasses ein anderer Engpass auftreten kann, der damit nicht zusammenhängt. In diesem Fall werden Sie erst dann eine Leistungsverbesserung feststellen, wenn Sie beide Engpässe beseitigt haben.

Dieser Abschnitt beschreibt zwei Arten von Optimierungsparameter:

Optimierungsparameter mit großen Auswirkungen auf die Leistung
Optimierungsparameter zur Vermeidung von Fehlern

Optimierungsparameter mit großen Auswirkungen auf die Leistung

Diese Parameter erzielen hohe Leistungsverbesserungen. Sie bilden eine Teilgruppe aller Parameter und haben hohe Auswirkungen auf die Leistung. Da sie von den Anwendungen abhängig sind, können die geeigneten Parametereinstellungen für Anwendung und Umgebung verschieden sein.

Die folgende Tabelle listet verschiedene Optimierungsparameter mit hoher Leistungsverbesserung auf:

Prüfliste für die Leistung der Anwendungsassemblierung

Systemwarteschlangen von WebSphere Application Server anpassen

Wertübergabe versus Referenzübergabe (NoLocalCopies)

TCP-Parameter unter Solaris anpassen

Java-Speicher optimieren

MaxRequestsPerChild anpassen: unter Linux mit IBM HTTP Server

Größe des Pools für Datenquellenverbindungen in WebSphere Application Server anpassen

Größe des Cache für vorbereitete Anweisungen anpassen

Intervall zum erneuten Laden der Konfiguration des Webservers

Größe des Cache für vorbereitete Anweisungen anpassen

Cache mit permanenter Sitzung verwenden

Parameter zur Vermeidung von Fehlern optimieren

Die folgenden Parameter helfen Ihnen dabei, funktionale Fehler zu vermeiden:

Parameter ListenBackLog: anwendbar bei Verwendung von Windows NT/2000 mit IIS unter hoher Client-Auslastung

Transporttyp: Verwenden Sie INET-Sockets unter Solaris (Standardeinstellung für WebSphere Application Server).

Anzahl von DB2-Verbindungen: wenn Sie mehr Verbindungen herstellen, als DB2 standardmäßig festlegt

Überschreitung des Grenzwerts bei Thread-Zuordnung zulassen wurde ausgewählt und das System ist überlastet, weil zu viele Threads zugeordnet wurden.

TCP-Sockets für DB2 unter Linux verwenden: für lokale Datenbanken

Größe des Pools für WebSphere-Datenquellenverbindungen: Achten Sie darauf, dass genügend Verbindungen vorhanden sind, damit die zusätzlichen Verbindungen aufgebaut werden können, die zur Transaktionsverarbeitung mit Entity-EJBs erforderlich sind, und damit ein gegenseitiges Sperren vermieden wird.

Warteschlangen in WebSphere Application Server anpassen

WebSphere Application Server verfügt über mehrere Komponenten, die in Wechselbeziehung zueinander stehen und harmonisch optimiert werden müssen, um die speziellen Anforderungen Ihrer End-to-End-e-business-Anwendung zu unterstützen. Diese Anpassungen erlauben es Ihrem System, einen maximalen Durchsatz zu erzielen, während gleichzeitig die Stabilität des Systems erhalten bleibt.

Warteschlangennetz

WebSphere Application Server baut ein Warteschlangennetz auf. Dies ist ein Netz von untereinander verbundenen Warteschlangen, die die verschiedenen Komponenten der Anwendungs-Serving-Plattform darstellen. Diese Warteschlangen umfassen Netz, Webserver, Webcontainer, EJB-Container, Datenquelle und eventuell einen Verbindungsmanager zu einem Back-End-System des Benutzers. Jede dieser Ressourcen stellt eine Warteschlange mit Anforderungen dar, die darauf warten, die Ressource zu nutzen.

Die WebSphere-Warteschlangen sind lastabhängige Ressourcen. Die durchschnittliche Servicezeit für eine Anforderung ist abhängig von der Anzahl gleichzeitig vorhandener Clients.

Geschlossene Warteschlangen versus offene Warteschlangen

Die meisten Warteschlangen, aus denen das Warteschlangennetz besteht, sind geschlossene Warteschlangen. Im Gegensatz zu einer offenen Warteschlange beschränkt eine geschlossene Warteschlange die maximale Anzahl der Anforderungen in der Warteschlange.

Eine geschlossene Warteschlange ermöglicht die exakte Steuerung der Systemressourcen. Beispielsweise wird mit der Einstellung "Maximalanzahl der Verbindungen" des Webcontainers die Größe der Warteschlange des Webcontainers gesteuert. Wenn das durchschnittliche Servlet in einem Webcontainer während jeder Anforderung 10 MB an Objekten erstellt, begrenzt der Wert 100 für "Maximalanzahl der Verbindungen" den Speicher, der vom Webcontainer verwendet werden darf, auf 1 GB.

In einer geschlossenen Warteschlange kann eine Anforderung einen der folgenden Status haben: aktiv oder wartend. Eine aktive Anforderung führt entweder eine Arbeit aus oder wartet auf die Antwort einer untergeordneten Warteschlange. Beispiel: Eine aktive Anforderung im Webserver führt entweder eine Arbeit aus (z. B. statisches HTML abrufen) oder wartet darauf, dass eine Anforderung im Webcontainer beendet wird. Im Status "Warten" wartet die Anforderung darauf, aktiv zu werden. Die Anforderung bleibt so lange im Status "Warten", bis eine der aktiven Anforderungen die Warteschlange verlässt.

Alle von WebSphere Application Server unterstützten Webserver sind geschlossene Warteschlangen genauso wie die Datenquellen unter WebSphere Application Server. Webcontainer können als offene oder geschlossene Warteschlangen konfiguriert werden. In der Regel sollten sie geschlossen sein. EJB-Container sind offene Warteschlangen. Wenn keine Threads im Pool zur Verfügung stehen, wird für die Dauer der Anforderung ein neuer Thread erstellt.

Wenn Enterprise-Beans durch Servlets aufgerufen werden, begrenzt der Webcontainer die Gesamtzahl der gleichzeitig aktiven Anforderungen für einen EJB-Container, da der Webcontainer selbst begrenzt ist. Dies gilt nur für den Fall, dass Enterprise-Beans von dem Ausführungs-Thread des Servlets aufrufen werden. Sie können jedoch ungehindert eigene Threads erstellen und zahllose Anforderungen an den EJB-Container senden. Dies ist einer Gründe, warum Servlets keine eigenen Arbeits-Threads erstellen sollten.

Warteschlangeneinstellungen in WebSphere Application Server

Nachfolgend sind die verschiedenen Warteschlangeneinstellungen aufgeführt:

IBM HTTP Server: MaxClients (für UNIX) und ThreadsPerChild (für Windows NT/2000)
Microsoft Internet Information Server: MaxPoolThreads und PoolThreadLimit
Webcontainer

Maximalanzahl der Verbindungen
Maximalanzahl der Keepalives für Transport
Maximalanzahl der Anforderungen pro Keepalive für Webcontainertransport

Größe des Thread-Pools für Object Request Broker
Größe des Pools für WebSphere-Datenquellenverbindungen
Größe des Zwischenspeichers für vorbereitete Anweisungen

Die Einstellungen festlegen

Der folgende Abschnitt erläutert eine Methode zur Konfiguration der Warteschlangen unter WebSphere Application Server. Sie können die dynamischen Elemente des Systems und folglich die Optimierungsparameter ändern, indem Sie Ressourcen verschieben (z. B. indem Sie den Datenbankserver auf eine andere Maschine verschieben) oder indem Sie sie durch leistungsstärkere Ressourcen ersetzen, z. B. durch schnellere CPUs mit höherer Speicherkapazität. Auf diese Weise können Sie die Optimierungsparameter für eine spezifische Konfiguration der Produktionsumgebung anpassen.

Warteschlangen außerhalb von WebSphere

Die erste Regel der Optimierung erfordert, dass die Anzahl der Anforderungen in den Warteschlangen von WebSphere Application Server auf ein Mindestmaß reduziert wird. Es ist im allgemeinen besser, dass Anforderungen im Netz (vor dem Webserver) und nicht im WebSphere Application Server warten. In dieser Konfiguration werden nur Anforderungen im Warteschlangennetz akzeptiert, die zur Verarbeitung bereit sind. Um diese Konfiguration festzulegen, müssen die Warteschlangen, die am Anfang des Verarbeitungsprozesses stehen (d. h., die dem Client am nächsten sind) etwas größer sein, und die Warteschlangen, die im Verarbeitungsprozess folgen (d. h. weiter vom Client entfernt sind) müssen fortlaufend kleiner werden.

Die Warteschlangen in diesem Warteschlangennetz werden umso kleiner, je weiter sie vom Ausgangspunkt des Verarbeitungsprozesses entfernt sind. Wenn 200 Clients den Webserver erreichen, bleiben 125 Anforderungen im Warteschlangennetz, da der Webserver nur 75 Client-Anforderungen gleichzeitig verarbeiten kann. Wenn die 75 Anforderungen vom Webserver an den Webcontainer übergeben werden, bleiben 25 in der Warteschlange des Webservers, und die verbleibenden 50 werden vom Webcontainer verarbeitet. Dieser Vorgang wird durch die Datenquelle fortgesetzt, bis 25 Benutzer das Ziel, d. h. den Datenbankserver, erreichen. Da an jedem Punkt im vorausgehenden Prozessverlauf Arbeit für eine Komponente ansteht, muss keine Komponente in diesem System auf Arbeit warten. Der Großteil der Anforderungen wartet im Netz, außerhalb von WebSphere Application Server. Da keine Komponente überlastet wird, führt dies zu einer größeren Stabilität. Routing-Software wie der Network Dispatcher von IBM kann wartende Benutzer an anderer Server in einem Cluster von WebSphere Application Server leiten.

Eine Durchsatzkurve zeichnen

Führen Sie unter Verwendung eines Testbeispiels, das repräsentativ für Ihre Produktionsanwendung ist (das z. B. alle wichtigen Codepfade ausführt) oder unter Verwendung der Produktionsanwendung selbst eine Reihe von Tests durch, um die maximale Leistung der Systemkomponenten (den sogenannten Sättigungspunkt) zu bestimmen. Sie sollten diese Tests erst ausführen, nachdem die meisten Engpässe aus der Anwendung entfernt wurden. Ziel dieser Tests ist es, die CPUs zu fast 100 % auszulasten.

Starten Sie den Ausgangstest mit großen Warteschlangen. Dadurch ist ein maximaler gemeinsamer Zugriff im System möglich. Starten Sie z. B. den ersten Test mit einer Warteschlangengröße von 100 an jedem Server im Warteschlangennetz: Webserver, Webcontainer und Datenquelle.

Starten Sie als Nächstes eine Reihe von Tests zum Zeichnen einer Durchsatzkurve, wobei Sie die gleichzeitig angemeldeten Benutzer nach jedem Test erhöhen. Führen Sie z. B. jeden Versuch mit 1 Benutzer, 2 Benutzern, 5, 10, 25, 50, 100, 150 und 200 Benutzern durch. Zeichnen Sie nach jeder Ausführung den Durchsatz (Anforderungen pro Sekunde) und die Antwortzeiten (Sekunden pro Anforderung) auf.

Die Kurve aus Ihrem Ausgangstest sollte der folgenden typischen Durchsatzkurve ähneln:

Der Durchsatz von WebSphere Application Server ist eine Funktion der Anzahl gleichzeitig stattfindender Anforderungen in einem Gesamtsystem. Bereich A mit der niedrigen Belastung zeigt, dass sich der Durchsatz bei zunehmender Zahl gleichzeitig angemeldeter Benutzer nahezu linear mit der Anzahl der Anforderungen erhöht. Dies spiegelt die Tatsache wider, dass bei gleichzeitigen Anforderungen bei niedriger Belastung nur eine geringe Überlastung in den Systemwarteschlangen von WebSphere Application Server auftritt. Ab einem bestimmten Punkt entsteht eine Überlastung, und der Durchsatz erhöht sich immer langsamer, bis er einen Sättigungspunkt erreicht, der den maximalen Durchsatzwert darstellt und durch einen Engpass im WebSphere-Application-Server-System bestimmt wird. Die beste Art von Engpass liegt vor, wenn die CPUs der WebSphere-Application-Server-Maschinen überlastet sind. Dies ist deshalb erstrebenswert, weil ein CPU-Engpass durch Hinzufügen von zusätzlichen oder leistungsstärkeren CPUs beseitigt werden kann.

Im Bereich der hohen Belastung, Bereich B, bleibt der Durchsatz bei wachsender Belastung durch gleichzeitige Client-Anforderungen relativ konstant. Allerdings erhöht sich die Antwortzeit proportional zur Benutzerlast. Wenn die Benutzerlast folglich im Bereich der hohen Belastung verdoppelt wird, verdoppelt sich auch die Antwortzeit. An einem bestimmten Punkt, dargestellt durch Bereich C, den Umkehrbereich, wird eine der Systemkomponenten erschöpft. Ab diesem Punkt nimmt der Durchsatz ab. Beispielsweise könnte das System den Umkehrbereich erreichen, wenn die Netzverbindungen am Webserver die Grenzwerte des Netzadapters erreichen oder wenn die Grenzwerte des Betriebssystems für Dateikennungen überschritten werden.

Wird der Sättigungspunkt erreicht, weil die CPUs des Systems zu fast 100 % belegt sind, fahren Sie mit dem nächsten Schritt fort. Wird die CPU nicht zu 100 % belegt, liegt wahrscheinlich ein Engpass vor, der durch die Anwendung verstärkt wird. Beispielsweise könnte die Anwendung eine übermäßig hohe Anzahl von Java-Objekten erstellen, die Engpässe bei der Garbage Collection in Java verursachen.

Engpässe bei der Anwendung können auf zwei Arten beseitigt werden: durch Beseitigen des Engpasses oder durch Klonen des Engpasses. Die beste Methode ist das Beseitigen des Engpasses. Untersuchen Sie die Gesamtauslastung der Objekte mit Hilfe eines Java-basierten Anwendungs-Profiler. Dazu können Profiler wie z. B. Performance Trace Data Visualizer (PTDV), JProbe und Jinsight verwendet werden.

Warteschlangenanpassungen

Die Anzahl gleichzeitig angemeldeter Benutzer am Durchsatzsättigungspunkt entspricht der maximalen Anzahl gleichzeitiger Anforderungen an die Anwendung. Beispiel: Wenn der Sättigungspunkt der Anwendung für WebSphere Application Server bei 50 Benutzern lag, ergeben möglicherweise 48 Benutzer die beste Kombination aus Durchsatz und Antwortzeit. Dieser Wert wird "Max Application Concurrency" (maximale Anzahl gleichzeitiger Anwendungszugriffe) bezeichnet. Dieser Wert sollte als Grundlage für die Anpassung der Systemwarteschlangen von WebSphere Application Server dienen. Denken Sie daran, dass es sinnvoll ist, wenn die meisten Benutzer im Netz warten. Verringern Sie daher die Größen der Warteschlangen, je weiter entfernt sie vom Client liegen. Beispiel: Bei einem Wert für maximale Anzahl gleichzeitiger Anwendungszugriffe (Max Application Concurrency) von 48 sollten die Systemwarteschlangen auf folgende Anfangswerte gesetzt werden: Webserver 75, Webcontainer 50, Datenquelle 45. Führen Sie mehrere zusätzliche Tests durch, bei denen Sie diese Werte leicht erhöhen oder verringern, um die besten Einstellungen zu ermitteln.

Mit Hilfe des Resource Analyzer kann die Anzahl der gleichzeitig angemeldeten Benutzer durch die Metrik "Anzahl der gleichzeitig aktiven Threads" für den Thread-Pool der Servlet-Maschine bestimmt werden.

In Leistungstests konnte der Durchsatz um 10 - 15 % erhöht werden, wenn die Maximalanzahl der Keepalives für Webcontainertransport auf die Maximalanzahl der Webcontainer-Threads gesetzt wurde.

Warteschlangeneinstellungen für Zugriffsmuster anpassen

In vielen Fällen wird nur ein Bruchteil der Anforderungen in einer Warteschlange an die nächste untergeordnete Warteschlange übergeben. In einer Site mit vielen statischen Seiten werden viele Anforderungen vom Webserver beantwortet und daher nicht an den Webcontainer übergeben. In solchen Fällen kann die Warteschlange des Webservers erheblich größer sein als die des Webcontainers. Im vorherigen Abschnitt wurde die Warteschlange des Webservers auf 75 und nicht auf einen Wert näher an der maximalen Anzahl gleichzeitiger Anwendungszugriffe (Max Application Concurrency) gesetzt. Ähnliche Anpassungen müssen vorgenommen werden, wenn unterschiedliche Komponenten unterschiedliche Ausführungszeiten haben.

Beispiel: In einer Anwendung, die 90 % ihrer Zeit in einem komplexen Servlet verbringt und nur 10 % ihrer Zeit für eine kurze JDBC-Abfrage verbraucht, verwenden durchschnittlich 10 % der Servlets Datenbankverbindungen, so dass die Warteschlange für Datenbankverbindungen bedeutend kleiner sein kann als die Warteschlange des Webcontainers. Umgekehrt sollten die Warteschlangenwerte für den Webcontainer und die Datenquelle erhöht werden, wenn ein Großteil der Ausführungszeit eines Servlets für die Erstellung komplexer Datenbankabfragen verwendet wird. Überwachen Sie stets die Auslastung von CPU und Speicher für den WebSphere Application Server und die Datenbankserver, um sicherzustellen, dass weder CPU noch Speicher erschöpft werden.

Warteschlangen und Enterprise-Beans

Methodenaufrufe von Enterprise-Beans werden nur dann in eine Warteschlange gestellt, wenn der Client, der die Methode aufruft, ein ferner Client ist, d. h., wenn der EJB-Client auf einer anderen Java Virtual Machine läuft (anderer Adressraum) als die Enterprise-Bean. Umgekehrt läuft die EJB-Methode auf demselben Ausführungs-Thread wie der EJB-Client (ohne Speichern in einer Warteschlange), wenn der EJB-Client (entweder ein Servlet oder eine andere Enterprise-Bean) auf derselben JVM installiert ist.

Ferne Enterprise-Beans kommunizieren unter Verwendung des Protokolls RMI/IIOP. Methodenaufrufe, die über RMI/IIOP eingeleitet werden, werden von einem ORB auf der Serverseite verarbeitet. Der Thread-Pool fungiert als Warteschlange für ankommende Anforderungen. Wenn jedoch eine ferne Methodenanforderung erfolgt und im Thread-Pool keine Threads mehr zur Verfügung stehen, wird ein neuer Thread erstellt. Dieser Thread wird gelöscht, nachdem die Methodenanforderung beendet wurde. Wenn daher der ORB zur Verarbeitung ferner Methodenanforderungen verwendet wird, ist der EJB-Container auf Grund seiner unbegrenzten Verwendung von Threads eine offene Warteschlange. Die nachfolgende Abbildung zeigt die Warteschlangenoptionen von Enterprise-Beans.

Bei der Konfiguration des Thread-Pools ist es wichtig, die Aufrufmuster des EJB-Clients zu verstehen. Wenn ein Servlet eine geringe Anzahl von Aufrufen für ferne Enterprise-Beans tätigt und jeder Methodenaufruf relativ schnell erfolgt, sollte die Anzahl der Threads im ORB-Thread-Pool auf einen Wert gesetzt werden, der kleiner ist als der Wert für die Thread-Pool-Größe des Webcontainers.

Resource Analyzer zeigt eine Metrik mit der Bezeichnung "Grenzwert in Prozent" an, die die Zeitperiode festlegt, während der alle konfigurierten Threads verwendet werden. Ist dieser Wert fortlaufend eine zweistellige Zahl, dann könnte der ORB ein Engpass sein und die Anzahl der Threads sollte erhöht werden.

Der Grad, in dem der Wert des ORB-Thread-Pools erhöht werden muss, ist eine Funktion der Anzahl gleichzeitig laufender Servlets (d. h. Clients), die Enterprise-Beans aufrufen, und der Dauer jedes Methodenaufrufs. Wenn die Methodenaufrufe länger sind, sollte die Größe des ORB-Thread-Pools auf die Größe des Webcontainers gesetzt werden, weil sich ferne Methodenaufrufe nur geringfügig überschneiden. Wenn das Servlet nur kurze oder schnelle ORB-Aufrufe an den ORB ausführt, kann der ORB-Thread-Pool klein sein. Ein ORB-Thread kann von mehreren Servlets verwendet werden. In diesem Fall kann der ORB-Thread-Pool klein sein, vielleicht nur halb so groß wie der Thread-Pool des Webcontainers. Wenn die Anwendung viel Zeit im ORB verbringt, sollten sich die Größen von Webcontainer und ORB besser entsprechen.

Warteschlangen und Cluster

Die Möglichkeiten des Klonens von Anwendungsservern kann bei der Konfiguration hochskalierbarer Produktionsumgebungen sehr wertvoll sein. Dies gilt besonders für den Fall, dass in der Anwendung Engpässe auftreten, die die vollständige CPU-Auslastung von SMP-Servern (SMP = Symmetric Multiprocessing) verhindert. Wenn Sie Systemwarteschlangen von WebSphere Application Server in Cluster-Konfigurationen anpassen, denken Sie daran, dass beim Hinzufügen eines Servers zu einem Cluster der untergeordnete Server die doppelte Last empfängt.

Zwei Webcontainer-Klone befinden sich zwischen einem Webserver und einer Datenquelle. Es wird davon ausgegangen, dass der Webserver, die Servlet-Maschinen und die Datenquelle (aber nicht die Datenbank) alle auf einem einzigen SMP-Server laufen. Unter diesen Voraussetzungen müssen folgende Überlegungen hinsichtlich der Warteschlangen angestellt werden:

Die Einstellungen für die Warteschlange des Webservers können auf den doppelten Wert gesetzt werden, damit genügend Arbeit an jeden Webcontainer verteilt wird.
Die Thread-Pools des Webcontainers können verkleinert werden, um zu verhindern, dass eine Systemressource wie z. B. die CPU oder eine andere Ressource, die von den Servlets verwendet wird, erschöpft wird.
Die Datenquelle kann verkleinert werden, um zu vermeiden, dass der Sättigungspunkt des Datenbankservers erreicht wird.
Die Parameter für den Java-Freispeicher können für jede Instanz des Anwendungsservers verringert werden. Bei den Versionen der JVM mit WebSphere Application Server muss der Freispeicher aller JVMs im physischen Speicher verbleiben. Wenn daher ein Cluster mit vier JVMs auf einem System läuft, muss ausreichend physischer Speicher für alle vier Freispeicher zur Verfügung stehen.

Secure Socket Layer optimieren

SSL (Secure Socket Layer) muss folgende zwei Arten von SSL-Leistungen erbringen:

Handshake
Massendatenverschlüsselung/-entschlüsselung

Übersicht über Handshake und Massendatenverschlüsselung/-entschlüsselung

Wenn eine SSL-Verbindung hergestellt wird, findet ein SSL-Handshake statt. Nachdem die Verbindung aufgebaut wurde, führt SSL für jede Lese-/Schreiboperation eine Massendatenverschlüsselung/-entschlüsselung (bulk encryption/decryption) durch. Die Leistungsverminderung durch einen SSL-Handshake ist viel höher als die durch die Massendatenverschlüsselung/-entschlüsselung.

Verbesserung der SSL-Leistung

Zur Verbesserung der SSL-Leistung muss die Anzahl der einzelnen SSL-Verbindungen und -Handshakes verringert werden.

Wird die Anzahl der Verbindungen verringert, erhöht sich die Leistung der geschützten Datenübertragungen über SSL-Verbindungen sowie die Leistung der nicht geschützten Datenübertragungen über einfache TCP-Verbindungen. Eine Möglichkeit, SSL-Verbindungen zu verringern, besteht in der Verwendung eines Browsers mit Unterstützung von HTTP 1.1. Die Verringerung von SSL-Verbindungen ist nicht möglich, wenn einige Benutzer keinen Upgrade auf HTTP 1.1 durchführen können.

Häufiger wird die Anzahl der Verbindungen (TCP und SSL) zwischen zwei WebSphere-Application-Server-Komponenten verringert. Mit Hilfe der folgenden Richtlinien können Sie sicherstellen, dass der HTTP-Transport des Anwendungsservers so konfiguriert ist, dass das Webserver-Plug-In nicht wiederholt neue Verbindungen zum Anwendungsserver öffnen muss.

Die maximale Anzahl Keepalives sollte mindestens auf die maximale Anzahl Anforderungen pro Thread des Webservers gesetzt werden (oder auf die maximale Anzahl Prozesse für IHS unter UNIX). Mit anderen Worten, stellen Sie scher, dass das Webserver-Plug-In für jede mögliche Verbindung zum Anwendungsserver eine Keepalive-Verbindung erhalten kann. Andernfalls schließt der Anwendungsserver die Verbindung, nachdem eine einzige Anforderung verarbeitet wurde. Außerdem sollte die maximale Anzahl Threads im Thread-Pool des Webcontainers größer sein als die maximale Anzahl Keepalives, um zu verhindern, dass alle Webcontainer-Threads von Keepalive-Verbindungen belegt werden.
Die maximale Anzahl Anforderungen pro Keepalive-Verbindung kann ebenfalls erhöht werden. Der Standardwert ist 100, d. h., der Anwendungsserver schließt die Verbindung vom Plug-In nach 100 Anforderungen. Anschließend müsste das Plug-In eine neue Verbindung öffnen. Mit diesem Parameter wird verhindert, dass Denial of Service-Attacken stattfinden, wenn eine Verbindung zum Anwendungsserver hergestellt wird, und fortlaufend Anforderungen gesendet werden, um Threads im Anwendungsserver zu belegen.
Falls das System mehrere SSL-Handshakes ausführt, verwenden Sie einen Hardwarebeschleuniger.

Die Hardwarebeschleuniger, die derzeit von WebSphere Application Server unterstützt werden, erhöhen lediglich die Leistung des SSL-Handshake, nicht die der Massendatenverschlüsselung/-entschlüsselung. Ein Beschleuniger dient in der Regel nur dem Webserver, weil Webserververbindungen kurzlebig sind. Alle anderen SSL-Verbindungen in WebSphere Application Server sind langlebig. Diese Verbindungen profitieren nicht von einer Hardwareeinheit, die lediglich SSL-Handshakes beschleunigt.

Verwenden Sie eine alternative Cipher Suite mit einer besseren Leistung.

Die Leistung einer Cipher Suite ist je nach Software und Hardware verschieden. Wenn eine Cipher Suite in der Software eine bessere Leistung erzielt, bedeutet dies nicht, dass für die Hardware dasselbe zutrifft. Einige Algorithmen sind in der Hardware in der Regel ineffizient (z. B. DES und 3DES), aber eine spezielle Hardware kann effiziente Implementierungen derselben Algorithmen ermöglichen.

Die Leistung der Massendatenverschlüsselung/-entschlüsselung wird durch die Cipher Suite bestimmt, die für eine einzelne SSL-Verbindung verwendet wird. Die Testsoftware zur Berechnung der Daten verwendete sowohl für die Client- als auch für die Serversoftware IBM JSSE und verwendete keine Hardwareverschlüsselung. Die Zeit für den Verbindungsaufbau war nicht Gegenstand des Testes, sondern die Zeit zum Übertragen der Daten über eine hergestellte Verbindung. Daher zeigen die Daten die relative SSL-Leistung für verschiedene Cipher Suites für langlebige Verbindungen.

Bevor eine Verbindung hergestellt wird, hat der Client für jedes Testbeispiel eine einzige Cipher Suite aktiviert. Nachdem die Verbindung hergestellt wurde, wurde vom Client die Zeit gemessen, die zum Schreiben einer ganzen Zahl in den Server benötigt wurde und die Zeit, die der Server benötigte, um die angegebene Anzahl Bytes zurück in den Client zu schreiben. Durch Variieren der Datenmenge ergeben sich Auswirkungen auf die relative Leistung der Cipher Suites, die vernachlässigt werden können. Das folgende Diagramm zeigt die Leistung jeder Cipher Suite.

Eine Analyse der oben dargestellten Daten ergibt Folgendes:
- Die Leistung der Massendatenverschlüsselung wird nur beeinträchtigt durch das, was nach dem WITH im Namen der Cipher Suite folgt. Dies entspricht der Erwartung, weil der Teil vor dem WITH den Algorithmus identifiziert, der nur während des SSL-Handshake verwendet wird.
- MD5 und SHA sind die zwei Hash-Algorithmen, mit denen die Datenintegrität hergestellt wird. MD5 ist um 25 % schneller als SHA, aber SHA ist gegenüber MD5 die sicherere Methode.
- DES und RC2 sind langsamer als RC4. Triple DES ist die sicherste Methode, aber die Leistungsverminderung ist sehr hoch, wenn nur die Software verwendet wird.
- Die Cipher Suite mit der besten Leistung, die dennoch Sicherheit bietet, ist SSL_RSA_WITH_RC4_128_MD5. Obwohl SSL_RSA_EXPORT_WITH_RC4_40_MD5 unter dem Aspekt der Verschlüsselung schwächer ist als RSA_WITH_RC4_128_MD5, bietet sie bei der Massendatenverschlüsselung dieselbe Leistung. Solange die SSL-Verbindung eine langlebige Verbindung ist, kann daher der Unterschied in der Leistung der hohen und mittleren Sicherheitsstufe vernachlässigt werden. Es empfiehlt sich, für alle Komponenten, die an der Kommunikation nur zwischen WebSphere-Application-Server-Produkten teilnehmen, die hohe Sicherheitsstufe (high) anstatt der mittleren Sicherheitsstufe (medium) zu verwenden. Stellen Sie sicher, dass es sich bei den Verbindungen um langlebige Verbindungen handelt.
Prüfliste für die Leistung der Anwendungsassemblierung
Zum Assemblieren der J2EE-Komponenten und -Module in J2EE-Anwendungen werden in WebSphere Application Server, Version 4.0 Anwendungsassemblier-Tools verwendet. Im allgemeinen besteht das Assemblieren aus dem Definieren von Anwendungskomponenten und ihren Attributen, einschließlich Enterprise-Beans, Servlets und Ressourcenverweise. Viele dieser Konfigurationseinstellungen und -attribute der Anwendung spielen eine wichtige Rolle bei der Laufzeitleistung der implementierten Anwendung. Nachfolgend ist eine Prüfliste der Einstellungen aufgeführt zusammen mit "Empfehlungen" für die Konfiguration der optimalen Einstellungen.
Die Prüfliste umfasst die folgenden Einstellungen:
- Enterprise-Bean-Module
- Webmodul
Enterprise-Bean-Module

Entity-EJBs - Bean-Cache
WebSphere Application Server erlaubt eine hohe Flexibilität bei der Verwaltung der Datenbankdaten mit Entity-EJBs. Die Konfigurationseinstellungen Aktivieren bei und Laden bei der Entity-EJBs legen fest, wie und wann Daten aus der zugehörigen Datenbankzeile einer Enterprise-Bean geladen und zwischengespeichert werden sollen. Diese Konfigurationseinstellungen erlauben es, dass die Commit-Optionen A, B oder C für Enterprise-Beans wie in der Spezifikation EJB 1.1 festgelegt angegeben werden können.
Empfehlungen
Eine detaillierte Erläuterung der Einstellungen Aktivieren bei und Laden bei finden Sie unten, ebenso spezielle Einstellungen, die Sie setzen müssen, um jede der Enterprise-Bean-Commit-Optionen A, B und C festzulegen.
Die Commit-Option A bietet eine maximale Enterprise-Bean-Leistung durch Caching der Datenbankdaten außerhalb des Transaktionsbereichs. Im allgemeinen ist die Commit-Option A nur anwendbar, wenn der EJB-Container exklusiven Zugriff auf eine gegebene Datenbank besitzt. Andernfalls wird die Datenintegrität verletzt. Die Commit-Option B erlaubt ein aggressiveres Caching der Entity-EJB-Objektinstanzen, das eine höhere Leistung zur Folge haben kann als Commit-Option C, aber auch mehr Speicherkapazität benötigt. Die Commit-Option C ist die gängigste Konfiguration, die tatsächlich für Entity-EJBs verwendet wird.
- Bean-Cache - Aktivieren bei Diese Einstellung definiert den Punkt, an dem eine Enterprise-Bean aktiviert und in den Cache gestellt wird. Das Entfernen einer Bean aus dem Cache und das Inaktivieren einer Bean werden ebenfalls über diese Einstellung gesteuert. Gültige Werte sind Einmal und Transaktion. Der Wert Einmal gibt an, dass die Bean aktiviert ist, wenn sie zum ersten Mal im Serverprozess aufgerufen wird, und auf Anweisung des Containers wieder inaktiviert wird (und aus dem Cache entfernt wird), z. B. wenn der Cache voll ist. Der Wert Transaktion zeigt an, dass die Bean beim Start einer Transaktion aktiviert und am Ende der Transaktion wieder inaktiviert (und aus dem Cache entfernt) werden soll. Der Standardwert ist Transaktion.
- Bean-Cache - Laden bei Diese Einstellung gibt an, wann die Bean ihren Status aus der Datenbank laden soll. Der Wert dieses Merkmals impliziert, ob der Container exklusiven oder gemeinsamen Zugriff auf die Datenbank hat. Gültige Werte sind Aktivierung und Transaktion. Der Wert Aktivierung gibt an, dass die Bean geladen werden soll, wenn sie aktiviert wird (Einmal oder Transaktion) und impliziert, dass der Container exklusiven Zugriff auf die Datenbank hat. Der Wert Transaktion gibt an, dass die Bean beim Start einer Transaktion geladen werden soll, und impliziert, dass der Container gemeinsamen Zugriff auf die Datenbank hat. Der Standardwert ist Transaktion.
  Die Einstellungen der Merkmale Aktivieren bei und Laden bei legen fest, welche Commit-Optionen verwendet werden.
  - Verwenden Sie für Commit-Option A (impliziert exklusiven Datenbankzugriff) die Einstellungen Aktivieren bei = Einmal und Laden bei = Aktivierung. Diese Option verringert die Datenbankein-/-ausgabe (Aufrufe der Funktion ejbLoad werden vermieden), serialisiert aber alle Transaktionen, die auf die Bean-Instanz zugreifen. Option A kann zu einer höheren Speicherbelegung führen, weil eine größere Anzahl von Objekten im Cache verwaltet wird, liefert aber bessere Antwortzeiten, wenn die Bean-Instanzen nicht generell von mehreren Transaktionen gleichzeitig aufgerufen werden.
  - Verwenden Sie für Commit-Option B (impliziert gemeinsamen Datenbankzugriff) die Einstellungen Aktivieren bei = Einmal und Laden bei = Transaktion. Option B kann zu einer höheren Speicherbelegung führen, weil eine größere Anzahl Objekte im Cache verwaltet wird. Weil jedoch jede Transaktion eine eigene Objektkopie erstellt, können jederzeit mehrere Kopien einer Instanz im Speicher vorhanden sein (eine pro Transaktion). Dies hat zur Folge, dass die Datenbank bei jeder Transaktion geöffnet werden muss. Wenn eine Enterprise-Bean zahlreiche Aufrufe der Funktion ejbActivate enthält, empfiehlt sich die Verwendung von Option B, weil das erforderliche Objekt bereits im Cache enthalten ist. Anderenfalls erzielen Sie mit dieser Option keine besseren Ergebnisse als mit Option A.
  - Verwenden Sie für Commit-Option C (impliziert gemeinsamen Datenbankzugriff) die Einstellungen Aktivieren bei = Transaktion und Laden bei = Transaktion. Diese Option verringert möglicherweise die Speicherauslastung, weil weniger Objekte im Cache verwaltet werden. Allerdings können jederzeit mehrere Kopien einer Instanz im Speicher vorhanden sein (eine pro Transaktion). Diese Option kann Konkurrenzsituationen bei Transaktionen für Enterprise-Bean-Instanzen verringern, auf die gleichzeitig zugegriffen wird, die aber nicht aktualisiert werden.
Methodenerweiterungen - Isolationsstufe
Die Enterprise-Bean-Methodenerweiterungen unter WebSphere Application Server bieten Einstellungen, mit denen die Stufe der Transaktionsisolation festgelegt werden kann, die beim Datenzugriff verwendet wird. Die gültigen Werte sind:
Empfehlungen
Nachfolgend werden Einstellungen für Isolationsstufen definiert, die verschiedene Grade der Integrität von Laufzeitdaten festlegen, die von der zugehörigen Datenbank bereitgestellt werden. Als Erstes sollten Sie eine Einstellung auswählen, die den Voraussetzungen der Datenintegrität entspricht, die von der gegebenen Anwendung und den speziellen Datenbankmerkmalen gefordert werden.
Die Isolationsstufe spielt außerdem eine wichtige Rolle für die Leistung. Höhere Isolationsstufen verringern die Leistung durch eine höhere Anzahl von Zeilensperren und einen größeren Datenbankaufwand und verringern gleichzeitig die gemeinsamen Datenzugriffe. Die verschiedenen Datenbanken verhalten sich bezüglich der Isolationseinstellungen unterschiedlich. Im allgemeinen ist die Einstellung Wiederholbares Lesen geeignet für DB2-Datenbanken. Festgeschriebene lesen wird im allgemeinen für Oracle verwendet. Wiederholbares Lesen wird von Oracle nicht unterstützt und bei Angabe dieser Einstellung wird die höchste serialisierbare Isolationsstufe verwendet.

Die Isolationsstufe kann auf Bean- oder Methodenebene festgelegt werden. Daher können Sie für unterschiedliche Methoden unterschiedliche Isolationseinstellungen konfigurieren. Dies ist dann ein Vorteil, wenn einige Methoden eine höhere Isolation erfordern als andere. Auf diese Weise kann eine maximale Leistung erzielt werden, während die Voraussetzungen der Datenintegrität gewahrt werden. Allerdings können für Methodenaufrufe innerhalb einer einzigen Enterprise-Bean-Transaktion keine unterschiedlichen Isolationsstufen festgelegt werden. In diesem Fall wird eine Ausnahmebedingung während der Laufzeit zurückgegeben.

Isolationsstufen
Serialisierbar
Diese Stufe verhindert die folgenden Arten von Leseoperationen:
- Fehlerhafte Leseoperationen: Eine Transaktion liest eine Datenbankzeile, die nicht festgeschriebene Änderungen aus einer zweiten Transaktion enthält.
- Nicht wiederholbare Leseoperationen: Eine Transaktion liest eine Zeile, eine zweite Transaktion ändert dieselbe Zeile und die erste Transaktion liest dann die Zeile erneut und erhält einen anderen Wert.
- Phantom-Leseoperationen: Eine Transaktion liest alle Zeilen, die eine SQL-WHERE-Bedingung betreffen und eine zweite Transaktion fügt eine Zeile ein, die ebenfalls die WHERE-Bedingung betrifft. Die erste Transaktion wendet dann dieselbe WHERE-Bedingung an und erhält die von der zweiten Transaktion eingefügte Zeile.
Wiederholbares Lesen
Diese Stufe verhindert fehlerhafte und nicht wiederholbare Leseoperationen. Phantom-Leseoperationen sind jedoch zugelassen.

Festgeschriebene lesen
Diese Stufe verhindert fehlerhafte Leseoperationen, lässt aber nicht wiederholbare Leseoperationen und Pseudoleseoperationen zu.

Nicht festgeschriebene lesen
Diese Stufe lässt fehlerhafte, nicht wiederholbare und Phantom-Leseoperationen zu.

Der Container verwendet das Isolationsstufenattribut der Transaktion wie folgt:
- Sitzungs-Beans und Entity-Beans mit Bean-verwalteter Persistenz (Bean-Managed Persistence, BMP).
  Für jede von der Bean verwendete Datenbankverbindung legt der Container beim Start einer Transaktion die Isolationsstufe fest, sofern die Insolationsstufe nicht explizit von der Bean in der Verbindung definiert wird.
- Entity-Beans mit containerverwalteter Persistenz (Container-Managed Persistence, CMP)
  Der Container generiert Datenbank-Zugriffscode, der die angegebene Isolationsstufe implementiert.
Methodenerweiterungen - Wert für geplanten Zugriff
Die Enterprise-Bean-Methodenerweiterungen unter WebSphere Application Server bieten Einstellungen, mit denen einzelne Enterprise-Bean-Methoden als Nur-Lese-Methoden festgelegt werden können. Diese Einstellung legt fest, ob die Methode Entity-Attributdaten aktualisieren kann (oder andere Methoden aufrufen kann, die Daten in derselben Transaktion aktualisieren können).
Empfehlungen
Standardmäßig gelten alle Enterprise-Bean-Methoden als Aktualisierungsmethoden. Folglich werden EJB-Entity-Daten nach Beendigung der Enterprise-Bean-Transaktion immer zurück in die Datenbank geschrieben. Wird für Enterprise-Methoden der "Wert für geplanten Zugriff" auf "Lesen" gesetzt, so dass sie die Entity-Attribute nicht aktualisieren, bedeutet dies eine signifikante Leistungssteigerung, weil der EJB-Container von WebSphere Application Server EJB die (unnötige) Datenbankaktualisierung überspringen kann. Anmerkung: WebSphere Application Server, Version 4.01 bietet eine zusätzliche Verhaltensweise für Suchmethoden für CMP-Entity-EJBs. Standardmäßig startet WebSphere Application Server eine Abfrage nach aktualisiertem Inhalt ("Select for Update") für die CMP-Enterprise-Bean-Suchmethoden wie findByPrimaryKey. Dadurch wird die Datenbankzeile für die Dauer der Enterprise-Bean-Transaktion exklusiv gesperrt. Wenn für die Enterprise-Bean-Suchmethode jedoch der Wert für geplanten Zugriff auf "Lesen" gesetzt wurde, wird der Container für die Auswahl kein "For Update" (für die Aktualisierung) ausführen, so das die Datenbankzeile nur für das Lesen gesperrt wird.
Containertransaktionen
Die Merkmale der Containertransaktion legen fest, wie der Container Transaktionsbereiche verwaltet, wenn er den Aufruf an die individuelle Geschäftsmethode der Enterprise-Bean delegiert. Gültige Werte sind:
Empfehlungen
Das Containertransaktionsattribut kann separat für eine oder mehrere Enterprise-Bean-Methoden festgelegt werden. Enterprise-Bean-Methoden, für die kein Transaktionsverhalten erforderlich ist, können mit dem Wert Unterstützt konfiguriert werden, um den Aufwand für die Containertransaktionsverwaltung zu verringern.
Gültige Werte:
Nie
Dieser gültige Wert weist den Container dazu an, Bean-Methoden ohne Transaktionskontext aufzurufen. Wenn der Client eine Bean-Methode aus einem Transaktionskontext heraus aufruft, löst der Container die Ausnahmebedingung java.rmi.RemoteException aus.
Wenn der Client eine Bean-Methode von außerhalb eines Transaktionskontextes aufruft, verhält sich der Container so, als wäre das Transaktionsattribut Nicht unterstützt definiert. Der Client muss die Methode ohne Transaktionskontext aufrufen.

Verbindlich
Dieser gültige Wert weist den Container dazu an, die Bean-Methode immer innerhalb des Transaktionskontextes aufzurufen, der dem Client zugeordnet ist. Wenn der Client versucht, die Bean-Methode ohne einen Transaktionskontext aufzurufen, dann löst der Container die Ausnahmebedingung javax.jts.TransactionRequiredException für den Client aus. Der Transaktionskontext wird an ein beliebiges Enterprise-Bean-Objekt oder an eine Ressource übergeben, auf die eine Methode der Enterprise-Bean zugreift.
Enterprise-Bean-Clients, die auf diese Entity-Beans zugreifen, müssen dies in einer vorhandenen Transaktion tun. Für andere Enterprise-Beans muss die Enterprise-Bean- oder Bean-Methode den Wert Bean-gesteuert implementieren oder einen der Werte Erforderlich oder Erfordert neue(n) verwenden. Für andere EJB-Clients als Enterprise-Beans muss der Client über die Schnittstelle javax.transaction.UserTransaction eine Transaktion aufrufen.

Erfordert neue(n)
Dieser gültige Wert weist den Container dazu an, die Bean-Methode immer in einem neuen Transaktionskontext aufzurufen, unabhängig davon, ob der Client die Methode von innerhalb oder von außerhalb eines Transaktionskontextes aufruft. Der Transaktionskontext wird an alle Enterprise-Bean-Objekte oder -Ressourcen übergeben, die von dieser Bean-Methode verwendet werden.

Erforderlich
Dieser gültige Wert weist den Container dazu an, die Bean-Methode innerhalb eines Transaktionskontextes aufzurufen. Wenn ein Client eine Bean-Methode aus einem Transaktionskontext heraus aufruft, ruft der Container die Bean-Methode aus dem Client-Transaktionskontext heraus auf. Wenn ein Client eine Bean-Methode außerhalb eines Transaktionskontextes aufruft, erstellt der Container einen neuen Transaktionskontext und ruft die Bean-Methode dann in diesem Kontext auf. Der Transaktionskontext wird an alle Enterprise-Bean-Objekte oder -Ressourcen übergeben, die von dieser Bean-Methode verwendet werden.

Unterstützt
Dieser gültige Wert weist den Container dazu an, die Bean-Methode innerhalb eines Transaktionskontextes aufzurufen, wenn der Client die Bean-Methode aus einer Transaktion heraus aufruft. Wenn der Client die Bean-Methode ohne einen Transaktionskontext aufruft, dann ruft der Container die Bean-Methode ohne einen Transaktionskontext auf. Der Transaktionskontext wird an alle Enterprise-Bean-Objekte oder -Ressourcen übergeben, die von dieser Bean-Methode verwendet werden.

Nicht unterstützt
Dieser gültige Wert weist den Container dazu an, Bean-Methoden ohne Transaktionskontext aufzurufen. Wenn ein Client eine Bean-Methode aus einem Transaktionskontext heraus aufruft, hebt der Container die Zuordnung zwischen der Transaktion und dem aktuellen Thread auf, bevor er die Methode für die Instanz der Enterprise-Bean aufruft. Der Container stellt dann die aufgehobene Zuordnung wieder her, wenn der Methodenaufruf zurückgegeben wird. Der aufgehobene Transaktionskontext wird an keine Enterprise-Bean-Objekte oder Ressourcen übergeben, die von dieser Bean-Methode verwendet werden.

Bean-gesteuert
Dieser Wert teilt dem Container mit, dass die Bean-Klasse die Transaktionsgrenze direkt festlegt. Dieses Merkmal kann nur für Sitzungs-Beans festgelegt werden und nicht für einzelne Bean-Methoden.

Webmodul

Webanwendung - Verteilbar
Die Kennzeichnung als "Verteilbar" gibt für J2EE-Webanwendungen an, dass die Webanwendung so programmiert ist, dass sie in einem verteilten Servlet-Container implementiert werden kann.
Empfehlungen
Webanwendungen sollten nur dann als verteilbar gekennzeichnet werden, wenn sie in einem WebSphere-Application-Server-Cluster oder einer Klonumgebung implementiert werden.
Webanwendung - Intervall für erneutes Laden
Das Intervall für erneutes Laden gibt das Zeitintervall (in Sekunden) an, in dem das Dateisystem der Webanwendung nach aktualisierten Dateien durchsucht wird, z. B. nach Servlet-Klassendateien oder JSPs.
Empfehlungen
Das Intervall für erneutes Laden kann auf unterschiedlichen Ebenen für die verschiedenen Anwendungskomponenten definiert werden. Im allgemeinen legt das Intervall für erneutes Laden die Zeit fest, während der der Anwendungsserver wartet, bevor er erneut prüft, ob abhängige Dateien aktualisiert wurden und neu geladen werden müssen. Das Überprüfen der Zeitmarken im Dateisystem ist eine aufwändig Operation, die nicht zu häufig ausgeführt werden sollte. Der Standardwert von 3 Sekunden eignet sich gut für eine Testumgebung, weil die Website aktualisiert werden kann, ohne dass der Anwendungsserver erneut gestartet werden muss. In Produktionsumgebungen findet die Überprüfung normalerweise ein paar Mal am Tag statt.
Webanwendung - Erneutes Laden aktiviert
Diese Option legt fest, ob das erneute Laden von Dateien aktiviert ist.
Webanwendung - Webkomponenten - Beim Starten laden
Diese Option legt fest, ob das Servlet beim Starten der Webanwendung geladen werden soll. Der Standardwert ist "false" (nein).
Empfehlungen
Viele Servlets führen den Prozess der Ressourcenzuordnung sowie andere Anfangsverarbeitungen in der Servlet-Methode init() durch. Diese Initialisierungsroutinen können zur Laufzeit aufwändig sein. Bei Angabe von Beim Starten laden für diese Servlets findet die Verarbeitung statt, wenn der Anwendungsserver gestartet wird. Auf diese Weise werden Laufzeitverzögerungen vermieden, die beim ersten Zugriff eines Servlets auftreten können.
Java-Speicher optimieren
Der folgende Abschnitt beschreibt die Optimierung des Java-Speichers. Unternehmensanwendungen, die in Java geschrieben wurden, beinhalten oftmals komplexe Objektbeziehungen und verwenden eine Vielzahl von Objekten. Obwohl Java den Speicher für den Lebenszyklus eines Objekts automatisch verwaltet, ist es wichtig, die Verwendungsmuster der Anwendung für Objekte zu verstehen. Achten Sie insbesondere darauf, dass Folgendes gegeben ist:
- Die Anwendung darf die Objekte nicht überbelegen.
- Die Anwendung verliert keine Objekte (d. h. keinen Speicher).
- Die Parameter für den Java-Freispeicher wurden für die Verwendung von Objekten gesetzt.

Engpass durch Garbage Collection

Die Untersuchung der Garbage Collection in Java kann Ihnen Einblicke in die Verwendung des Speichers durch die Anwendung geben. Die Garbage Collection ist eine der Stärken von Java. Dadurch dass der Anwendungsschreiber sich nicht um die Speicherverwaltung kümmern muss, sind Java-Anwendungen zuverlässiger als Anwendungen, die in anderen Programmiersprachen geschrieben wurden, die die Garbage Collection nicht unterstützen. Allerdings sind die Anwendungen nur solange zuverlässig, solange Objekte nicht missbraucht werden. Die Garbage Collection belegt normalerweise zwischen 5 % und 20 % der gesamten Ausführungszeit einer ordnungsgemäß funktionierenden Anwendung. Läuft sie unkontrolliert, kann die Garbage Collection einer der größten Engpässe für eine Anwendung darstellen, insbesondere auf SMP-Servermaschinen.

Die Garbage Collection als Messinstrument

Mit Hilfe der Garbage Collection können Sie die Leistungsfähigkeit einer Anwendung messen. Durch Überwachen der Garbage Collection während der Ausführung einer festen Arbeitslast können Benutzer erkennen, ob die Anwendung Objekte überbelegt. Mit der Garbage Collection können sogar Speicherlecks entdeckt werden.

Mit Hilfe der Garbage Collection und der Statistiken zum Freispeicher im Resource Analyzer können Sie die Leistungsfähigkeit der Anwendung überprüfen. Durch Überwachen der Garbage Collection können Speicherlecks und Überbelegungen von Objekten erkannt werden.

Für diese Art der Untersuchung sollten Sie die Mindest- und maximale Freispeichergröße auf denselben Wert setzen. Wählen Sie eine repräsentative, wiederholbare Arbeitsbelastung, die der Produktionsnutzung so nahe wie möglich kommt (inklusive Benutzerfehler usw.). Außerdem muss die Anwendung mehrere Minuten laufen, bis sich der Anwendungsstatus stabilisiert.

Die Überbelegung von Objekten erkennen

Um festzustellen, ob die Anwendung Objekte überbelegt, überprüfen Sie im Resource Analyzer die Zähler für den JVMPI-Profiler. Die durchschnittliche Zeit zwischen den Aufrufen der Garbage Collection sollte fünf- bis sechsmal höher sein als die durchschnittliche Dauer einer einzelnen Garbage Collection. Ist dies nicht der Fall, verbraucht die Anwendung mehr als 15 % ihrer Zeit für die Garbage Collection. Überprüfen Sie auch die Anzahl der freigegebenen, zugeordneten und verschobenen Objekte.

Wenn die Informationen auf einen Engpass bei der Garbage Collection hinweisen, kann dieser auf zwei Arten beseitigt werden. Die kostengünstigste Leistungsoptimierung erzielen Sie dann, wenn Sie Objekt-Caches und -Pools implementieren. Verwenden Sie einen Java-Profiler, um die geeigneten Objekte zu bestimmen. Wenn die Anwendung nicht optimiert werden kann, sollten Sie versuchen, zusätzlichen Speicher, Prozessoren und Klone hinzuzufügen. Durch zusätzlichen Speicher kann jeder Klon eine angemessene Freispeichergröße verwalten. Zusätzliche Prozessoren erlauben die Ausführung der Klone im Parallelbetrieb.

Speicherlecks feststellen

Speicherlecks in Java sind gefährlich und tragen zu Engpässen bei der Garbage Collection bei. Sie sind gefährlicher als eine Überbelegung des Speichers, weil Speicherlecks das System letztendlich instabil machen. Mit der Zeit findet die Garbage Collection immer häufiger statt, bis der Freispeicher schließlich erschöpft ist und Java die schwerwiegenden Ausnahmebedingung Out of Memory (Kein Speicher) meldet. Speicherlecks treten auf, wenn die Referenzen eines nicht benötigten Objekts nie gelöscht werden. Dies tritt oftmals in Klassen von Objektgruppen auf, z. B. in Hash-Tabellen, da die Tabelle selbst immer eine Referenz zum Objekt besitzt, selbst nachdem echte Referenzen gelöscht wurden.

Häufig wird beklagt, dass Anwendungen unmittelbar nach ihrer Implementierung in der Produktionsumgebung abstürzen. Oft geschieht dies auf Grund einer zu hohen Arbeitslast. Dies trifft insbesondere zu für Anwendungen mit Speicherlecks, bei denen die hohe Arbeitslast das Speicherleck vergrößert und schließlich kein Speicher mehr zugeordnet werden kann.

Beim Testen auf Speicherlecks müssen höhere Zahlen verwendet werden. Speicherlecks werden in der Anzahl der Bytes oder Kilobytes gemessen, für die keine Garbage Collection durchgeführt werden kann. Die schwierige Aufgabe besteht darin, diese Größen von den erwarteten Größen für nutzbaren und nicht nutzbaren Speicher zu unterscheiden. Diese Aufgabe kann leichter durchgeführt werden, wenn die Zahlen vergrößert werden, was größere Lücken zur Folge hat und damit eine einfachere Erkennung von Abweichungen. Die folgende Liste enthält wichtige Informationen zum Erkennen von Speicherlecks:

Tests mit langer Laufzeit
Probleme durch Speicherlecks treten erst nach einer gewissen Zeit zu Tage, daher müssen zum Erkennen von Speicherlecks Tests mit langer Laufzeit durchgeführt werden. Tests mit kurzer Laufzeit können falschen Alarm auslösen. Eine der Fragen, die sich in Java stellt, ist die Frage, ob überhaupt ein Speicherleck vorhanden ist, wenn die Speicherbelegung merkbar angestiegen ist, sei es abrupt oder langsam über einen bestimmten Zeitraum. Es ist möglich, dass diese Art der ansteigenden Speicherbelegung zulässig ist und die erstellten Objekte zu einem viel späteren Zeitpunkt referenziert werden. Mit anderen Worten, wie können Objekte mit verzögerter Verwendung unterschieden werden von Objekten, die überhaupt nicht verwendet werden? Wenn Sie Anwendungen ausreichend lange ausführen, werden Sie besser erkennen können, ob die Objekte tatsächlich nach einer Verzögerung verwendet werden. Aus diesem Grund kann der Test auf Speicherlecks nicht mit anderen Arten von Tests kombiniert werden, z. B. mit dem Funktionstest, die normalerweise sehr früh im Prozess stattfinden. Allerdings kann dieser Test zusammen mit bestimmten Arten von Tests wie Belastungs- oder Haltbarkeitstests durchgeführt werden.
Systemtest
Einige Probleme durch Speicherlecks treten nur dann auf, wenn verschiedene Komponenten eines großen Projektes miteinander kombiniert und ausgeführt werden. Dies trifft insbesondere dann zu, wenn die Schnittstellen zwischen den Komponenten bekannte oder nicht bekannte Nebeneffekte erzeugen. Der Systemtest ist eine gute Möglichkeit, um diese Bedingungen zu erzeugen.
Wiederholte Tests
In manchen Fällen treten Probleme durch Speicherlecks als Folge von wiederholten Ausführungen desselben Tests aus. Das Ziel eines Tests auf Speicherlecks besteht darin, eine große Abweichung herzustellen zwischen nicht nutzbarem und genutztem Speicher, ausgedrückt in ihren jeweiligen relativen Größen. Durch vielfache Wiederholung desselben Szenarios wird die Zahl fortlaufend multipliziert. Dies ist besonders dann hilfreich, wenn die Speicherlecks, die aufgrund der Ausführung eines Tests auftreten, so minimal sind, dass sie bei einer einzigen Ausführung kaum auffallen.
Wiederholte Tests können auf Systemebene oder Modulebene ausgeführt werden. Der Vorteil des Tests auf Modulebene ist die bessere Kontrolle. Ist ein Modul so definiert, dass alles, was in dem Modul stattfindet, nur innerhalb dieses Moduls stattfindet, ohne externe Nebeneffekte wie Speicherbelegung zu erzeugen, ist das Testen auf Speicherlecks viel einfacher. Zunächst wird die Speicherbelegung vor Ausführung des Moduls aufgezeichnet. Anschließend wird eine festgelegte Reihe von Testbeispielen wiederholt ausgeführt. Am Ende der Testausführung entspricht die aktuelle Speicherbelegung der wiederholten Speicherbelegung, die vorher aufgezeichnet wurde, und es wird überprüft, ob sie sich erheblich geändert hat. Bedenken Sie , dass die Garbage Collection erzwungen werden muss, wenn die aktuelle Speicherbelegung aufgezeichnet werden soll. Fügen Sie dazu System.gc() im Modul ein, in dem die Garbage Collection stattfinden soll, oder verwenden Sie ein Profiler-Tool, das die Ausführung dieses Ereignisses erzwingt.
Test mit gleichzeitigen Zugriffen
Einige Probleme durch Speicherlecks können nur dann auftreten, wenn mehrere Threads in der Anwendung laufen. Leider sind Synchronisationspunkte aufgrund der komplizierten Programmlogik sehr anfällig dafür, Speicherlecks zu erzeugen. Eine nachlässige Programmierung kann dazu führen, dass Referenzen beibehalten oder nicht freigegeben werden. Das Entstehen von Speicherlecks wird häufig erleichtert oder beschleunigt durch eine wachsende Zahl gleichzeitiger Zugriffe im System. Normalerweise wird die Zahl gleichzeitiger Zugriffe erhöht, indem die Anzahl Clients im Testtreiber erhöht wird.

Überlegen Sie bei der Auswahl der Testbeispiele, die zum Testen auf Speicherlecks verwendet werden sollen, folgende Punkte:

Ein gutes Testbeispiel wird in den Bereichen der Anwendung ausgeführt, in denen Objekte erstellt werden. In der Regel ist dazu die Kenntnis der Anwendung erforderlich. Das Szenario kann das Erstellen von Datenräumen umfassen, d. h. das Hinzufügen eines neuen Datensatzes, das Erstellen einer HTTP-Sitzung, die Ausführung einer Transaktion und das Suchen eines Datensatzes.
Überprüfen Sie die Bereiche, in denen Gruppen von Objekten verwendet werden. Normalerweise bestehen Speicherlecks aus Objekten derselben Klasse. Auch Objektgruppenklassen wie Vektor oder Hash-Tabelle sind häufige Orte, an denen Referenzen auf Objekte implizit gespeichert werden, indem entsprechende Einfügemethoden aufgerufen werden. Beispielsweise wird von der Methode get eines Hash-Tabellenobjektes die Referenz auf das abgerufene Objekt nicht gelöscht.

Der Resource Analyzer hilft Ihnen bei der Erkennung von möglichen Speicherlecks. Optimale Ergebnisse erhalten Sie, wenn Sie Versuche mit zunehmender Dauer ausführen, z. B. Anforderungen von 1000, 2000 und 4000 Seiten. Das Resource-Analyzer-Diagramm zur Speicherbelegung sollte die Form eines Sägezahns haben. Jeder Rückgang im Diagramm entspricht einer Garbage Collection. Speicherlecks liegen vor, wenn eine der folgenden Situationen zutrifft:

Die Menge an Speicher, der direkt nach jeder Garbage Collection belegt wird, steigt erheblich an. Das Sägezahnmuster ähnelt eher einer Treppe.
Das Sägezahnmuster hat eine unregelmäßige Form.

Weist die Belegung des Freispeichers während hoher Arbeitsbelastung auf ein mögliches Speicherleck hin (d. h. der Anwendungsserver hat fortlaufend eine CPU-Auslastung von fast 100 %) und scheint es, als würde der Freispeicher während einer nachfolgenden geringeren oder extrem niedrigen Arbeitsbelastung wiederhergestellt werden, dann ist dies ein Indiz für eine Fragmentierung des Freispeichers. Eine Fragmentierung des Freispeichers kann auftreten, wenn die JVM genügend Objekte bereitstellen kann, um während der Garbage-Collection-Zyklen alle Anforderungen nach Speicherzuordnung zu erfüllen, jedoch nicht die Zeit hat, kleine freie Speicherbereiche im Freispeicher zu größeren, aneinander angrenzenden Bereichen zu komprimieren.

Eine andere Art der Freispeicherfragmentierung findet statt, wenn kleine Objekte (mit weniger als 512 Bytes) freigegeben werden. Diese Objekt werden freigegeben, aber der Speicher wird nicht wiederhergestellt, so dass eine Speicherfragmentierung stattfindet.

Eine Fragmentierung des Freispeichers kann dadurch vermieden werden, dass das Flag -Xcompactgc in den Befehlszeilenargumenten für die erweiterten JVM-Einstellungen aktiviert wird. Das Flag -Xcompactgc stellt sicher, dass jeder Garbage-Collection-Zyklus die Fragmentierung beseitigt. Dies hat jedoch eine kleine Leistungsverminderung zur Folge.

Java-Freispeicherparameter

Die Java-Freispeicherparameter wirken sich auch auf das Verhalten der Garbage Collection aus. Durch Erhöhen der Freispeichergröße können mehr Objekte erstellt werden. Da es länger dauert, bis ein großer Freispeicher voll ist, läuft die Anwendung länger, bis eine Garbage Collection stattfindet. Ein größerer Freispeicher benötigt auch mehr Zeit zur Komprimierung. Die Garbage Collection dauert ebenfalls länger.

Zur Leistungsanalyse sollten die Anfangsgröße und die Maximalgröße des Freispeichers gleich groß sein.

Die Abbildung zeigt drei CPU-Profile, von denen jedes eine feste Arbeitslast mit unterschiedlichen Java-Freispeichereinstellungen ausführt. Beim mittleren Profil sind die Einstellungen "Anfängliche Größe des Freispeichers" und "Maximalgröße des Freispeichers" auf 128 MB gesetzt. Es gibt vier Ausführungen der Garbage Collection. Die Gesamtzeit der Garbage Collection beträgt ca. 15 % der gesamten Ausführung. Wenn die Freispeicherparameter auf 256 MB verdoppelt werden (oberes Profil), erhöht sich die Länge der Arbeitszeit zwischen den Garbage Collection. Es gibt nur drei Garbage Collection, aber die Länge jeder Garbage Collection hat ebenfalls zugenommen. Im dritten Profil beträgt der Freispeicher 64 MB und zeigt eine entgegengesetzte Auswirkung. Bei einem kleineren Freispeicher verkürzen sich auch die Zeiten für und zwischen den Garbage Collection. Bei allen drei Konfigurationen beträgt die Gesamtzeit für die Garbage Collection ca 15 %. Damit wird ein wichtiges Konzept hinsichtlich des Java-Freispeichers und seiner Beziehung zur Objektverwendung verdeutlicht. In Java-Anwendungen hat die Garbage Collection immer Folgen für die Leistung.

Führen Sie mehrere Tests mit verschiedenen Einstellungen für den Java-Freispeicher durch, beispielsweise mit 128 MB, 192 MB, 256 MB und 320 MB. Überwachen Sie bei jedem Test die Gesamtspeicherbelegung. Wenn Sie den Freispeicher zu stark erhöhen, können Speicherseiten ausgelagert werden. (Verwenden Sie den Befehl vmstat oder die Leistungsüberwachung unter Windows NT/2000, um zu überprüfen, ob Speicher ausgelagert wird.) Ist dies der Fall, verringern Sie die Freispeichergröße oder fügen Sie dem System mehr Speicher hinzu. Vergleichen Sie folgende Statistiken, nachdem alle Tests ausgeführt wurden:

Anzahl der Aufrufe der Garbage Collection
Durchschnittliche Dauer eines einzigen Garbage-Collection-Aufrufs
Verhältnis zwischen der Länge eines einzelnen Garbage-Collection-Aufrufs und der durchschnittlichen Zeit zwischen den Aufrufen

Falls der nicht belegte Freispeicher bei 85 % oder mehr liegt, sollten Sie den Wert für maximale Freispeichergröße verringern, weil der Anwendungsserver und die Anwendung den dem Freispeicher zugeordneten Speicher nicht vollständig nutzen.

TCP-Parameter unter Solaris

Kurzbeschreibung: Die Optimierung dieser Parameter wirkt sich positiv auf die Leistung von Solaris aus. StartupServer.sh setzt folgende Parameter:
```
    tcp_close_wait_interval/tcp_time_wait_interval unter Solaris
    tcp_fin_wait_2_flush_interval unter Solaris
    tcp_keepalive_interval unter Solaris
```
Es gibt noch viele andere TCP-Parameter, deren Änderung sich ebenfalls positiv auf die Leistung Ihrer Umgebung auswirken kann. Weitere Informationen zur Optimierung des TCP/IP-Stack finden Sie auf der Website Tuning your TCP/IP Stack and More.
Empfohlene Anpassung: Wenden Sie diese Parameter an, wenn Sie WebSphere Application Server unter Solaris verwenden.
Bevor die drei TCP-Parameter geändert wurden, blockierte der Server während bestimmter Spitzenzeiten. Der Befehl netstat zeigte an, dass viele der für Port 80 geöffneten Sockets den Status CLOSE_WAIT oder FIN_WAIT_2 aufwiesen.

Topologie des Workload Management

Kurzbeschreibung: WebSphere Application Server stellt verschiedene Topologien für Workload Management (WLM, d. h. zur Verwaltung der Arbeitslast) bereit. Die folgenden beiden Topologien (Topologie A und B) sind Beispiele für eine Arbeitslast, die von einer Maschine gesendet wird:
- Topologie A umfasst einen Webserver und ein WebSphere-Application-Server-Plug-In für vier Maschinen (von denen jede ein Klon der anderen ist und einen Webcontainer und EJB-Container enthält).
- Topologie B umfasst einen Webserver, ein Plug-In und einen Webcontainer für vier Maschinen (von denen jede einen EJB-Container enthält).
In beiden Topologien ist die die ORB-Referenzübergabe (ORB = Object Request Broker) ausgewählt und die Backend-Datenbank befindet sich auf einer separaten dedizierten Maschine.
Empfohlene Anpassung: Topologie A hat den Vorteil, dass der Webcontainer und EJB-Container in einer einzelnen JVM laufen. In Topologie B wird die ORB-Option zur Referenzübergabe zwischen der Webcontainer-Maschine und den EJB-Containermaschinen ignoriert. In Topologie A verwendet der EJB-Container denselben Thread, der vom Webcontainer übergeben wird. Mit anderen Worten, die Anforderung muss nicht von einem Thread in einer JVM an einen anderen Thread in einer anderen JVM übergeben werden.
Außerdem könnte eine fünfte Maschine hinzugefügt werden, falls die Prozessorauslastung der vier Maschinen nahe 100 % liegt. Alternativ dazu können die Prozessoren der vier Maschinen entlastet werden, falls der Webserver nicht voll ausgelastet ist und im Webcontainer keine hohe Verarbeitung stattfindet, indem Topologie B verwendet wird.
Ergebnis: Der Durchsatz in Topologie A war um 21 % besser als in Topologie B. In beiden Fällen fand die Arbeitslast auf derselben Hardware statt: Die Webserver-Maschine war eine RS/6000 (4x450MHz) und die vier EJB-Containermaschinen waren alle RS/6000 (4x333MHz). Keine der Maschinen hatte eine Prozessorauslastung von über 85 %.
Empfohlener Wert: Topologie A hat einen Vorteil, allerdings gibt es viele Faktoren im Zusammenhang mit der Anwendung und der Umgebung, die die Ergebnisse beeinflussen.

Anzahl von DB2-Verbindungen

Empfohlener Wert: Beim Konfigurieren der Datenquelleneinstellungen für die Datenbanken muss die DB2-Einstellung MaxAppls größer sein als die maximale Anzahl der Verbindungen für die Datenquelle. Wenn Sie Klone einrichten möchten, muss der Wert der Einstellung MaxAppls das Ergebnis aus der Multiplikation der maximalen Anzahl von Verbindungen mit der Anzahl der Klone sein.
Dieselbe Beziehung gilt für die Anzahl der Verbindungen des Sitzungsmanagers. Die Einstellung MaxAppls muss mindestens der Anzahl von Verbindungen entsprechen. Wenn Sie für Sitzung und Datenquellen dieselbe Datenbank verwenden, muss MaxAppls gleich der Summe sein aus der Anzahl der Verbindungen für den Sitzungsmanager und für die Datenquellen.
MaxAppls = (Anzahl Verbindungen für die Datenquelle + Anzahl Verbindungen im Sitzungsmanager) x Anzahl Klone

Achten Sie darauf, dass nach der Berechnung der MaxAppls-Einstellungen für die Datenbank WAS und für jede der Anwendungsdatenbanken die MaxAgents-Einstellung für DB2 größer oder gleich der Summe aller MaxAppls-Einstellungen ist.
```
 
MaxAgents = Summe aller MaxAppls-Einstellungen für alle Datenbanken
```
Zugehörige Parameter: Siehe DB2 MaxAppls und DB2 MaxAgents

Einzelne Leistungsparameter

Hardware

Dieser Abschnitt erläutert die Auswahl und Konfiguration der Hardware, auf der Ihre Anwendungsserver laufen werden.

Prozessorgeschwindigkeit

Kurzbeschreibung: Eignet sich für andere Engpässe, z. B. bei der Ein-/Ausgabe, bei der Anwendung oder bei gemeinsamen Zugriffen, bei denen der Prozessor auf andere Ereignisse wartet. In diesem Fall führt eine höhere Prozessorgeschwindigkeit häufig zu besserem Durchsatz und besseren Antwortzeiten.

Systemspeicher

Kurzbeschreibung: Sie können die Leistung voraussichtlich erhöhen, indem Sie die Speicherkapazität erhöhen, um die Auslagerung von Speicher auf die Festplatte zu vermeiden.
Jeder Prozessor sollte über mindestens 512 MB Speicherkapazität verfügen.
Empfohlene Anpassung: Wenn das System Speicher auslagert (und die Prozessorauslastung aufgrund dieser Speicherauslagerung gering ist), sollten Sie diesen Parameter anpassen.

Netze

Kurzbeschreibung: Verwenden Sie Netzkarten und Netz-Switches im Vollduplex-Betrieb. Der Halbduplex-Betrieb vermindert die Leistung.

Prüfen Sie, ob die Übertragungsgeschwindigkeit des Netzes den erforderlichen Durchsatz unterstützt. Stellen Sie sicher, dass 10/100 Ethernet-Netze 100 MB verwenden.

Weitere Informationen über die Auflösung von Hostnamen auf dem Client-Host mit Verwaltungsfunktion finden Sie im White Paper WebSphere Application Server Admin Best Practices for Performance and Scalability .

Einstellungen des Betriebssystems

Dieser Abschnitt behandelt die Optimierung von Betriebssystemen in der Serverumgebung.

TCP/IP-Parameter unter Windows NT/2000

TcpTimedWaitDelay unter Windows NT/2000

Kurzbeschreibung: Bestimmen Sie die Zeit, die ablaufen muss, bevor TCP eine geschlossene Verbindung freigeben und ihre Ressourcen erneut verwenden darf. Dieses Intervall zwischen Schließen und Freigabe wird als Status TIME_WAIT oder 2MSL (doppelte maximale Segmentlebensdauer) bezeichnet. Während dieser Zeit kann die Verbindung mit sehr viel geringerem Aufwand für Client und Server erneut geöffnet werden als eine neue Verbindung. Wird der Wert für diesen Eintrag verkleinert, kann TCP geschlossene Verbindungen schneller freigeben, und auf diese Weise eine größere Anzahl Ressourcen für neue Verbindungen bereitstellen.
Empfohlene Anpassung: Dieser Parameter sollte angewendet werden, falls die ausgeführte Anwendung eine schnelle Freigabe und Erstellung neuer Verbindungen erfordert, und ein niedriger Durchsatz vorhanden ist, weil zu viele Verbindungen den Status TIME_WAIT aufweisen.
Parameter anzeigen oder einstellen:
1. Führen Sie den Befehl regedit aus, um HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters aufzurufen und erstellen Sie ein neues REG_DWORD mit dem Namen TcpTimedWaitDelay.
2. Setzen Sie den Wert auf die Dezimalzahl 30 (Hexadezimalwert 0x0000001e).
3. Führen Sie für das System einen Neustart durch.
4. Bei Ausführung des Befehls netstat können Sie feststellen, dass eine geringere Anzahl von Verbindungen den Status TIME_WAIT aufweist.
Standardwert: 0xF0 (240 Sekunden = 4 Minuten)
Empfohlener Wert: der Mindestwert 0x1E (30 Sekunden)
Zugehörige Parameter: Parameter MaxUserPort unter Windows NT/2000

Parameter MaxUserPort unter Windows NT/2000

Kurzbeschreibung: Legt die höchste Port-Nummer fest, die TCP zuordnen kann, wenn eine Anwendung einen verfügbaren Benutzer-Port vom System anfordert.
Parameter anzeigen oder einstellen:
1. Führen Sie den Befehl regedit aus, um HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters aufzurufen und erstellen Sie ein neues REG_DWORD mit dem Namen MaxUserPort.
2. Führen Sie für das System einen Neustart durch.
Empfohlener Wert: mindestens die Dezimalzahl 32768.
Zugehörige Parameter: die TCP/IP-Parameter unter Windows NT/2000 TCP/IP

Anmerkung: Diese beiden Parameter sollten zusammen verwendet werden, wenn WebSphere Application Server auf dem Betriebssystem Windows NT/2000 optimiert wird.

AIX (4.3.3)

AIX-Dateideskriptoren

Kurzbeschreibung: Gibt die erlaubte Anzahl der geöffneten Dateien an.
Empfohlene Anpassung: Bei den meisten Anwendungen ist die Standardeinstellung in der Regel ausreichend. Wenn der gesetzte Parameterwert zu niedrig ist, wird ein Fehler über Speicherzuordnung (Memory Allocation) angezeigt. Dieser Fehler tritt auf, wenn vier Klone auf einem 24-Wege-S80-System ausgeführt werden und der Wert ulimit in "unlimited" (unbegrenzt) geändert werden muss.
Parameter anzeigen oder einstellen: Informieren Sie sich anhand der UNIX-Referenzseiten zu ulimit über die Syntax für die verschiedenen Shells. Um in der Korn-Shell (ksh) den Parameter ulimit auf 2000 zu setzen, geben Sie folgenden Befehl ein:
```
ulimit -n 2000
```
Geben Sie bei großen SMP-Maschinen mit Klonen folgenden Befehl aus:
```
ulimit -unlimited 
```
Mit dem Befehl ulimit -a werden die aktuellen Werte für alle Begrenzungen der Systemressourcen angezeigt.
Standardwert: Für AIX lautet die Standardeinstellung 2000.

Solaris

Solaris-Dateideskriptoren (ulimit)

Kurzbeschreibung: Gibt die erlaubte Anzahl der geöffneten Dateien an.
Empfohlene Anpassung: Wenn der Wert für diesen Parameter zu niedrig ist, wird in der Datei stderr.log von WebSphere Application Server die Meldung Fehler: Zu viele Dateien geöffnet (Too many files open) angezeigt.
Parameter anzeigen oder einstellen: Informieren Sie sich anhand der UNIX-Referenzseiten zu ulimit über die Syntax für die verschiedenen Shells. Für die Korn-Shell (ksh) lautet der Befehl wie folgt:
```
ulimit -n 1024
```
Mit dem Befehl ulimit -a werden aktuellen Werte für alle Begrenzungen der Systemressourcen angezeigt.
Standardwert: Das Skript startupServer.sh von WebSphere Application Server setzt diesen Parameter auf 1024, wenn der Wert unter 1024 liegt.

Solaris-Parameter TCP_CLOSE_WAIT_INTERVAL und TCP_TIME_WAIT_INTERVAL

Kurzbeschreibung: Diese Parameter legen für TCP fest, wie lange Steuerblöcke für beendete Verbindungen gespeichert werden sollen. Nachdem die Anwendungen die TCP-Verbindung beendet haben, werden die Steuerblöcke für die Dauer der angegebenen Zeit gespeichert.
Empfohlene Anpassung: Bei hohem Verbindungsaufkommen kann ein großer Rückstand an TCP-Verbindungen entstehen und die Serverleistung vermindern.
Der Server kann während Spitzenauslastungszeiten blockieren. In diesem Fall zeigt der Befehl netstat, dass viele der für Port 80 geöffneten Sockets den Status CLOSE_WAIT oder FIN_WAIT_2 aufweisen. Sichtbare Verzögerungen traten für die Dauer von vier Minuten auf. Während dieser Zeit sendete der Server keine Antworten, aber die CPU-Auslastung blieb hoch, wobei sämtliche Aktivitäten in den Systemprozessen stattfanden.
Parameter anzeigen oder einstellen: Ermitteln Sie das aktuelle Intervall mit Hilfe des Befehls get und legen Sie mit dem Befehl set ein Intervall von 60 Sekunden fest. Beispiel:
```
ndd -get /dev/tcp tcp_time_wait_interval
ndd -set /dev/tcp tcp_time_wait_interval 60000
```
Standardwert: Der Standardwert für die Wartezeit unter Solaris beträgt 2400000 Millisekunden.
Empfohlener Wert: Der Parameter TCP_CLOSE_WAIT_INTERVAL kann auf den Mindestwert von 30000 Millisekunden gesetzt werden. Als Anfangswert wird vom WebSphere-Application-Server-Skript startupServer.sh ein Wert von 60000 Millisekunden gesetzt.
Zugehörige Parameter: Siehe TCP-Parameter unter Solaris

Parameter TCP_FIN_WAIT_2_FLUSH_INTERVAL unter Solaris

Kurzbeschreibung: Das Zeitgeberintervall, welches verhindert, dass eine Verbindung im Status FIN_WAIT_2 bleibt.
Empfohlene Anpassung: Bei hohem Verbindungsaufkommen kann ein großer Rückstand an TCP-Verbindungen entstehen und die Serverleistung vermindern.
Der Server kann während Spitzenauslastungszeiten blockieren. Der Befehl netstat zeigte an, dass viele der für Port 80 geöffneten Sockets den Status CLOSE_WAIT oder FIN_WAIT_2 aufwiesen. Sichtbare Verzögerungen traten für die Dauer von vier Minuten auf. Während dieser Zeit sendete der Server keine Antworten, aber die CPU-Auslastung blieb hoch, wobei sämtliche Aktivitäten in den Systemprozessen stattfanden.
Parameter anzeigen und einstellen: Bestimmen Sie mit Hilfe der folgenden Befehle das aktuelle Intervall und setzen Sie das Intervall auf 67,5 Sekunden:
```
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
```
Standardwert: Der Standardwert unter Solaris beträgt 675000.
Empfohlener Wert: 67500
Zugehörige Parameter: Siehe TCP-Parameter unter Solaris

Parameter TCP_KEEPALIVE_INTERVAL unter Solaris

Kurzbeschreibung: Das Zeitgeberintervall, welches verhindert, dass eine aktive Verbindung im Status ESTABLISHED bleibt, falls einer der Peers niemals antwortet.
Empfohlene Anpassung: Falls Übertragungen von Clients oder Peers fehlschlagen, legt dieser Wert fest, wie lange eine Verbindung geöffnet bleibt.
Parameter anzeigen oder einstellen: Ermitteln Sie mit Hilfe der folgenden Befehle den aktuellen Wert und setzen Sie den Wert auf 300 Sekunden:
```
ndd -get /dev/tcp tcp_keepalive_interval
ndd -set /dev/tcp tcp_keepalive_interval 300000
```
Standardwert: 7200000
Empfohlener Wert: 300000
Zugehörige Parameter: Siehe TCP-Parameter unter Solaris

Andere TCP-Parameter unter Solaris

Unsere Kunden konnten mit der Änderung anderer Solaris-TCP-Parameter, einschließlich der nachfolgenden, positive Ergebnisse erzielen:

tcp_conn_req_max_q
tcp_comm_hash_size
tcp_xmit_hiwat

Obwohl sich nach Erhöhen dieser Einstellungen keine großen Unterschiede bei der Leistung ergaben, könnte das System dennoch von der Änderung profitieren.

Zugehörige Parameter: Siehe TCP-Parameter unter Solaris

Kernel-Parameter semsys:seminfo_semume unter Solaris

Kurzbeschreibung: Der Parameter zur Kernel-Optimierung semsys:seminfo_semume begrenzt die Anzahl der "Max Semaphore"-Widerrufeinträge (Undo) pro Prozess und muss größer sein als der Standardwert (10 unter Solaris 7). Da dies ein Maximalwert ist, wird zusätzlicher Speicher erst verwendet, wenn er benötigt wird.
Parameter anzeigen und einstellen: Dieser Wert wird als SEMUME angezeigt, wenn Sie den Befehl /usr/sbin/sysdef ausführen. Möglicherweise ist für diesen Optimierungsparameter ein Eintrag in der Datei /etc/system vorhanden.
Legen Sie über den Eintrag /etc/system Folgendes fest:
```
set semsys:seminfo_semume = 1024
```
Standardwert: 10 unter Solaris 7

Kernel-Parameter semsys:seminfo_semopm unter Solaris

Parameter anzeigen oder einstellen: Dieser Wert wird als SEMOPM angezeigt, wenn Sie den Befehl /usr/sbin/sysdef ausführen. Möglicherweise ist für diesen Optimierungsparameter ein Eintrag in der Datei /etc/system vorhanden.
Legen Sie über den Eintrag /etc/system Folgendes fest:
```
semsys:seminfo_semopm = 200
```

HP-UX 11

Durch Ändern der Einstellungen von HP-UX 11 kann die Leistung von WebSphere Application Server deutlich verbessert werden.

Die Größe der virtuellen Seite für WebSphere Application Server JVM auf 64 KB setzen

Parameter anzeigen oder einstellen: Der Befehl wird wie folgt eingegeben:
```
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
```
Die Befehlsausgabe enthält die aktuellen Kenndaten des Betriebssystems für den ausführbaren Prozess.
Empfohlene Anpassung:
Standardwert:

Detaillierte Informationen zu dieser Änderung finden Sie auf der folgenden Webseite von Hewlett Packard.

Parameter tcp_conn_request_max unter HP-UX 11

Kurzbeschreibung: Dieser Parameter gibt die maximale Anzahl der Verbindungsanforderungen an, die das Betriebssystem in einer Warteschlange speichern kann, wenn der Server keine Threads verfügbar hat. Bei hohem Verbindungsaufkommen entsteht ein großer Rückstand an TCP-Verbindungen und Client-Verbindungen werden gelöscht.
Empfohlene Anpassung: Diese Einstellung kann die Leistung erheblich verbessern, wenn Clients beim Verbindungsaufbau das Zeitlimit überschreiten. Diese Situation kann durch Ausführung des Befehls netstat -p tcp geprüft werden.
Suchen Sie nach folgendem Wert:
```
connect requests dropped due to full queue
```
Parameter anzeigen oder einstellen: Setzen Sie zum Beheben des Problems den Parameter TCP_CONN_REQUEST_MAX wie folgt auf den Wert 1024:
ndd -set /dev/tcp tcp_conn_request_max 1024
Detaillierte Informationen zu dieser Änderung finden Sie auf der folgenden Webseite von Hewlett Packard.
Standardwert: Der Standardwert für die maximale Anzahl von TCP-Verbindungsanforderungen lautet 20.

Empfohlene Kernel-Parameter für HP-UX 11

Kurzbeschreibung: Die besten Ergebnisse werden bei Verwendung von DB2 oder Oracle mit folgenden Einstellungen für Kernel-Parameter erzielt:

Kernel-Parameter	WebSphere-Application-Server-Optimierung	DB2-Optimierung	Oracle-Optimierung
maxdsiz	Nicht angepasst	Nicht angepasst	Nicht angepasst
maxdsiz_64b	Nicht angepasst	Nicht angepasst	Nicht angepasst
maxuprc		512
maxfiles	2,048
maxfiles_lim	2,048
nkthreads	10,000
max_thread_proc	2,048
nproc		1,028
nflocks		8,192
ninode		2,048
nfile		8,192
msgseg		32,767
msgmnb		65,535
msgmax		65,535
msgtql		1,024
msgmap		258
msgmni		256
msgssz		16
semmni		512	70
semmap		514
semmns		1,024	200
semmnu		1,024
shmmax		966.367.642	1 GB
shmmseg		16	10
shmmni		300	100

Empfohlene Anpassung: Siehe die Tabelle oben.
Parameter anzeigen oder einstellen: Setzen Sie die Kernel-Parameter mit dem HP-UX-Dienstprogramm SAM. Anweisungen dazu finden Sie in der Dokumentation zum verwendeten Betriebssystem.
Standardwert: Siehe die Tabelle oben.

Weitere Informationen über Kernel-Parameter unter HP-UX 11 finden Sie auf der folgenden Webseite von Hewlett Packard.

Der Webserver

Das Produkt WebSphere Application Server stellt Plug-Ins für verschiedene Marken und Versionen von Webservern bereit. Jede Betriebssystemkombination eines Webservers verfügt über spezielle Optimierungsparameter, die sich auf die Anwendungsleistung auswirken.

In diesem Abschnitt werden die Einstellungen der Webserver zur Leistungsverbesserung behandelt.

Intervall zum erneuten Laden der Konfiguration des Webservers

Kurzbeschreibung: Die Verwaltungsfunktion von WebSphere Application Server protokolliert eine Vielzahl von Konfigurationsinformationen zu den Ressourcen von WebSphere Application Server. Einige dieser Informationen, z. B. URIs, die auf Ressourcen von WebSphere Application Server zeigen, werden auch vom Webserver benötigt. Diese Konfigurationsdaten werden über das WebSphere-Application-Server-Plug-In in Intervallen, die mit diesem Parameter festgelegt werden, an den Webserver gesendet. Durch regelmäßige Aktualisierungen können neue Servlet-Definitionen hinzugefügt werden, ohne dass die Server von WebSphere Application Server gestartet werden müssen. Die dynamische Neuerstellung dieser Konfigurationsdaten beeinträchtigt jedoch die Leistung.
Empfohlene Anpassung: In einer stabilen Fertigungsumgebung.
Parameter anzeigen oder einstellen: Der Parameter <RefreshInterval=xxxx>, in dem xxxx für die Anzahl Sekunden steht, wird in der Datei websphere_root/config/plug-in.xml festgelegt.
Standardwert: Das Standardintervall für erneutes Laden beträgt 60 Sekunden.

IBM HTTP Server (IHS) - AIX und Solaris

IHS ist ein Mehrprozessserver mit einem Thread. Weitere Informationen finden Sie auf der folgenden Webseite über das Optimieren des IBM HTTP Server.

MaxClients

Kurzbeschreibung: Der Wert des Parameters MaxClients kann die Anwendungsleistung stark beeinträchtigen, insbesondere, wenn dieser Wert zu hoch ist. Ein höherer Wert erzielt nicht immer bessere Ergebnisse. Der optimale Wert ist abhängig von der verwendeten Anwendung.
Parameter anzeigen oder einstellen: Editieren Sie die Anweisung MaxClients in der Datei des IBM HTTP Server httpd.conf. Diese Datei befindet sich im Verzeichnis Stammverzeichnis_des_IBM_HTTP_Server/conf.
Standardwert: 150
Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen

MinSpareServers, MaxSpareServers und StartServers

Kurzbeschreibung: Diese Einstellungen wirken sich auf die Leistung der Anwendung aus. Sie erzielen optimale Leistungsergebnisse, wenn Sie die Parameter MaxSpareServers und StartServers auf denselben Wert setzen. Dadurch reduzieren Sie die CPU-Belastung zum Erstellen und Löschen von httpd-Prozessen. Die angegebene Anzahl von Prozessen wird vorab zugeordnet und verwaltet, so dass wenige Prozesse erstellt und gelöscht werden, wenn die Arbeitslast die angegebene Anzahl von Prozessen erreicht (basierend auf MinSpareServers).
Empfohlene Anpassung:
Parameter anzeigen oder einstellen: Editieren Sie folgenden Anweisungen in der Datei httpd.conf, die im Verzeichnis Stammverzeichnis_von_IBM_HTTP_Server/conf gespeichert ist:
- MinSpareServers
- MaxSpareServers
- StartServers
Standardwert:
- MinSpareServers 5
- MaxSpareServers 10
- StartServers 5

iPlanet Web Server, Enterprise Edition - AIX und Solaris

Die Standardkonfiguration der iPlanet Web Server Enterprise Edition stellt einen Einzelprozessserver mit mehreren Threads zur Verfügung.

Aktive Threads

Kurzbeschreibung: Nachdem der Server die mit diesem Parameter festgelegte Begrenzung erreicht hat, werden neue Verbindungen erst wieder beantwortet, nachdem die alten Verbindungen beendet wurden.
Empfohlene Anpassung: Wenn diese Einstellung zu niedrig ist, wird die Serverleistung gedrosselt und es entstehen längere Antwortzeiten.
Durch Überprüfen der Statistik perfdump können Sie feststellen, ob die Leistung des Webservers gedrosselt ist. Suchen Sie nach folgenden Daten:
- Der Zähler WaitingThreads: Ist dieser Wert beinahe oder gleich Null, akzeptiert der Server keine neuen Verbindungen.
- Der Zähler BusyThreads: Ist der Zähler "WaitingThreads" beinahe oder gleich Null, hat "BusyThreads" wahrscheinlich seinen Grenzwert erreicht.
- Der Zähler ActiveThreads: Hat dieser Zähler seinen Grenzwert fast erreicht, setzt sich der Server wahrscheinlich selbst eine Begrenzung.

Parameter anzeigen oder einstellen: Mit dem Parameter Maximum number of simultaneous requests (Maximale Anzahl an gleichzeitigen Anforderungen) in der Schnittstelle des Enterprise Server Manager können Sie die Zahl der aktiven Threads im Web Server, Enterprise Edition steuern. Diese Einstellung entspricht dem Parameter RqThrottle in der Datei magnus.conf.
Standardwert: 512

Microsoft Internet Information Server (IIS) - Windows NT/2000

IIS-Berechtigungsmerkmale

Kurzbeschreibung: Der Webserver verfügt über mehrere Merkmale, die sich erheblich auf die Leistung des Anwendungsservers auswirken können. Die Standardeinstellungen können in der Regel übernommen werden. Da es jedoch möglich ist, dass sich die Standardeinstellungen anderer Produkte ohne Wissen des Benutzers ändern, müssen die IIS-Einstellungen für die Berechtigungen des Ausgangsverzeichnisses des Webservers überprüft werden. Diese Berechtigungen sollten auf Script und nicht auf Execute gesetzt sein. Sind die Berechtigungen auf Execute gesetzt, werden keine Fehlernachrichten zurückgegeben, aber die Leistung von WebSphere Application Server verschlechtert sich.
Parameter anzeigen oder einstellen: Führen Sie in der Microsoft-Verwaltungskonsole (Microsoft Management Console) folgende Schritte aus, um diese Berechtigungen zu überprüfen oder zu ändern:
1. Wählen Sie die Website aus (normalerweise die Standardwebsite). Klicken Sie mit der rechten Maustaste, und wählen Sie die Option Eigenschaften aus. Klicken Sie auf das Register Ausgangsverzeichnis.
2. Setzen Sie die Berechtigungen des Ausgangsverzeichnisses: Stellen Sie bei den Einstellungen der Anwendung sicher, dass das Markierungsfeld Script in der Liste Berechtigungen ausgewählt und das Markierungsfeld Execute inaktiviert ist.

Anmerkung: Möglicherweise müssen Sie auch die Berechtigungen für sePlugin überprüfen:

Blenden Sie die Optionen zum Webserver ein.
Klicken Sie mit der rechten Maustaste auf sePlugin, und wählen Sie Eigenschaften aus.
Vergewissern Sie sich, dass die Execute-Berechtigungen auf "Execute" gesetzt sind.

Anzahl der erwarteten Treffer pro Tag

Kurzbeschreibung: Dieser Parameter steuert den Speicherbereich, den IIS für Verbindungen zuordnet.
Parameter anzeigen oder einstellen: Setzen Sie mit Hilfe des Fensters "Leistung" diesen Parameter in der Anzeige Website-Eigenschaften der Microsoft-Verwaltungskonsole auf "Über 100000".
Standardwert: Kleiner als 100000.

Parameter ListenBackLog

Kurzbeschreibung: Wenn Sie IIS unter Windows NT/2000 verwenden, treten bei hoher Auslastung wahrscheinlich fehlgeschlagene Verbindungen auf (normalerweise bei mehr als 100 Clients). Der Grund dafür ist in der Regel der, dass IIS Verbindungen zurückweist.
Sie können diese Situation verbessern, indem Sie mit dem Parameter ListenBackLog die Anzahl der Anforderungen erhöhen, die IIS in seiner Warteschlange speichern kann.
Empfohlene Anpassung: Wenn Sie bei hoher Auslastung in einem Netscape-Browser in unregelmäßigen Abständen die Fehlermeldung Netscape konnte Server nicht finden (Netscape unable to locate server) erhalten, sollten Sie den Wert für diesen Parameter erhöhen.
Parameter anzeigen oder einstellen:
1. Legen Sie den Parameter ListenBackLog mit der Registrierungsdatenbank des Betriebssystems fest.
2. Geben Sie an der DOS-Eingabeaufforderung den Befehl regedit ein, um auf die Registrierungsdatenbank zuzugreifen.
3. Suchen Sie im Fenster zur Registrierungsdatenbank den Parameter im folgenden Verzeichnis:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\ ListenBackLog
4. Klicken Sie mit der rechten Maustaste auf den Parameter, um ihn zu ändern. Passen Sie die Einstellung entsprechend der Serverauslastung an.
Standardwert: 25 (dezimal)
Empfohlener Wert: Um bei keine Leistungseinbußen hinnehmen zu müssen und gleichzeitig eine bessere Verteilung der Arbeitslast zu erzielen, kann der Parameter ListenBackLog maximal auf 200 gesetzt werden.

MaxPoolThreads, PoolThreadLimit

Kurzbeschreibung: MaxPoolThreads steuert die Anzahl der Threads pro CPU in dem Thread-Pool, der für IIS zur Ausführung von CGI-Prozessen (CGI = Common Gateway Interface) zur Verfügung steht (jeder Prozess benötigt einen Thread). PoolThreadLimit legt den oberen Grenzwert für MaxPoolThreads fest. Die Standardbegrenzung für Threads, die IIS auf einer Maschine erstellen kann, entspricht der doppelten Anzahl MB im RAM einer Maschine (z. B. wird ein Server mit 512 MB RAM auf 1024 Threads begrenzt).
Parameter anzeigen oder einstellen: Die Parameter MaxPoolThreads und PoolThreadLimit werden mit Hilfe der folgenden Einträge in der Registrierungsdatenbank festgelegt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\MaxPoolThreads
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\PoolTheadLimit

IBM HTTP Server - Linux

MaxRequestsPerChild

Kurzbeschreibung: Die Anweisung MaxRequestsPerChild begrenzt die Anzahl von Anforderungen, die ein einzelner Kind-Serverprozess bearbeitet. Wenn die Anzahl der Anforderungen den Wert für den Parameter MaxRequestsPerChild erreicht, wird der Kindprozess beendet. Der Durchsatz eines einfachen Servlets kann sich um 50 % erhöhen.
Empfohlene Anpassung:
Parameter anzeigen oder einstellen:
1. Editieren Sie die Datei httpd.conf des IBM HTTP Server, die im Verzeichnis Stammverzeichnis_des_IBM_HTTP_Server/conf enthalten ist (siehe die Anweisung MaxRequestsPerChild).
2. Ändern Sie den Wert des Parameters.
3. Speichern Sie die Änderungen und starten Sie den IBM HTTP Server erneut.
Standardwert: 30
Empfohlener Wert: Der Wert 500 ergab bei einem Test mit einem einfachen Servlet das beste Ergebnis.

IBM HTTP Server - Windows NT/2000

Der IBM HTTP Server ist einfach zu konfigurieren. Die Standardeinstellungen können in der Regel übernommen werden.

ThreadsPerChild

Kurzbeschreibung: Dieser Parameter setzt die Anzahl der Threads fest, die auf dem IBM HTTP Server gleichzeitig ausgeführt werden können. Legen Sie diesen Wert so fest, dass kein Engpass entsteht und eine ausreichende Menge an Datenübertragungen zum Anwendungsserver durchgelassen werden.
Parameter anzeigen oder einstellen:
1. Editieren Sie die Datei httpd.conf des IBM HTTP Server, die sich im Verzeichnis Stammverzeichnis_des_IBM_HTTP_Server/conf befindet (siehe die Anweisung ThreadsPerChild).
2. Ändern Sie den Wert des Parameters.
3. Speichern Sie die Änderungen und starten Sie den IBM HTTP Server erneut.
Thread-Auslastung anzeigen: Sie können auf zwei Arten feststellen, wie viele Threads unter Belastung verwendet werden:
1. Verwenden Sie den Systemmonitor unter Windows NT/2000:
  
  Klicken Sie zum Öffnen auf Start > Programme > Verwaltung > Systemmonitor.
  Klicken Sie im "Systemmonitor" auf Bearbeiten > Diagramm erweitern. Legen Sie anschließend Folgendes fest:
  - Objekt: IBM HTTP Server
  - Instanz: Apache
  - Datenquelle: Warten auf Verbindung
  - Berechnen Sie anschließend die Anzahl der belegten Threads, indem Sie die Anzahl der wartenden Threads (Windows NT/2000 Leistungsüberwachung) von den insgesamt verfügbaren Threads (ThreadsPerChild) subtrahieren.
2. Verwenden Sie den Serverstatus von IBM HTTP Server (diese Option funktioniert auf allen Plattformen, nicht nur unter Windows NT/2000).
  Gehen Sie wie folgt vor, um den Serverstatus von IBM HTTP Server zu verwenden:
  1. Editieren Sie die Datei httpd.conf von IBM HTTP Server wie folgt:
    - Entfernen Sie das Kommentarzeichen "#" vor folgenden Zeilen:
      - #LoadModule status_module modules/ApacheModuleStatus.dll
      - #<Location /server-status>
      - #SetHandler server-status
      - #</Location>
  2. Speichern Sie die Änderungen und starten Sie den IBM HTTP Server erneut.
  3. Rufen Sie in einem Webbrowser folgenden URL auf, und klicken Sie auf Erneut laden, um den Status zu aktualisieren: http://IhrHost/server-status.
    Wenn der Browser eine Aktualisierung unterstützt, können Sie alternativ dazu http://IhrHost/server-status?refresh=5 aufrufen, um die Anzeige alle 5 Sekunden zu aktualisieren. Folgendes wird Ihnen angezeigt (zusammen mit weiteren Informationen): 5 Anforderungen werden derzeit verarbeitet, 45 Server sind inaktiv.
Standardwert: 50 (für IBM HTTP Server 1.3.19).
Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen

ListenBackLog

Kurzbeschreibung: Wenn mehrere Clients Verbindungen zum IBM HTTP Server anfordern und alle Threads (siehe ThreadsPerChild) belegt sind, werden die zusätzlichen Client-Anforderungen in einer Warteschlange gespeichert. Die Anweisung ListenBackLog legt die Länge dieser Warteschlange mit anstehenden Verbindungsanforderungen fest. Wenn Sie jedoch die Standardeinrichtung FRCA (Fast Response Cache Accelerator) verwenden, wird die Anweisung ListenBackLog nicht verwendet, weil FRCA über eine eigene interne Warteschlange verfügt.
Parameter anzeigen oder einstellen: Für den Fall, dass FRCA nicht verwendet wird:
1. Editieren Sie die Datei httpd.conf von IBM HTTP Server.
2. Fügen Sie die Anweisung ListenBackLog hinzu oder überprüfen Sie sie, dass sie vorhanden ist.
Standardwert: Für HTTP Server 1.3.19:
1024 mit aktiviertem FRCA
511 mit inaktiviertem FRCA (Standard)
Empfohlener Wert: Verwenden Sie die Standardeinstellungen.

Der WebSphere-Application-Server-Prozess

Jeder WebSphere-Application-Server-Prozess verfügt über mehrere Parameter, die sich auf die Anwendungsleistung auswirken. Jeder Anwendungsserver im Produkt WebSphere Application Server umfasst einen EJB-Container und einen Webcontainer.

Mit der Administrationskonsole von WebSphere Application Server können Sie Anwendungen, Webcontainer, EJB-Container, Anwendungsserver und Knoten in der Verwaltungsdomäne konfigurieren und anpassen.

Betriebssystempriorität des WebSphere-Application-Server-Prozesses anpassen

Kurzbeschreibung: Durch eine bessere Prozesspriorität des Anwendungsservers im Betriebssystem kann die Leistung verbessert werden. Auf UNIX-Systemen bewirkt eine niedriger Einstellung, dass der Prozess eine höhere Priorität erhält. Weitere Informationen über Prozessprioritäten finden Sie in folgenden Veröffentlichungen:
- Für AIX siehe das Handbuch zur AIX-Leistungsoptimierung, Versionen 3.2 und 4
- Informationen über die Optimierung eines Hewlett-Packard-Systems finden Sie auf der folgenden Webseite von Hewlett Packard.
Empfohlene Anpassung: Die Priorität kann jederzeit angepasst werden.
Ergebnis: Durch Verbesserung der Priorität eines Anwendungsservers wurde unter AIX eine Leistungssteigerung von bis zu 5 % erzielt. Unter Solaris und HP konnten ebenfalls Verbesserungen erzielt werden.
Parameter anzeigen oder einstellen:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, der optimiert werden soll.
2. Klicken Sie auf das Register Erweitert.
3. Geben Sie den gewünschten Wert im Feld Prozesspriorität ein und klicken Sie auf Anwenden.
4. Speichern Sie die Änderungen und führen Sie für den Anwendungsserver einen Neustart durch.
Parameterverwendung anzeigen: Unter UNIX können Sie mit dem Befehl ps -efl die aktuelle Prozesspriorität anzeigen.
Standardwert: 20
Empfohlener Wert: 0

Webcontainer

Um Servlet-Anforderungen vom Webserver an die Webcontainer weiterzuleiten, erstellt das Produkt eine Transportwarteschlange zwischen dem Webserver-Plug-In und jedem Webcontainer.

Maximalgröße von Threads in Webcontainern

Kurzbeschreibung: Legen Sie mit dem Parameter für die Maximalgröße von Threads die maximale Anzahl Threads fest, die zu einem Pool zusammengefasst werden können, um Anforderungen an die Webcontainer zu verarbeiten. Die Anforderungen werden über eine der HTTP-Transportmöglichkeiten an den Webcontainer gesendet.
Parameter anzeigen oder einstellen:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, den Sie optimieren möchten, und klicken Sie auf das Register Services.
2. Klicken Sie auf Webcontainerservice und anschließend auf Merkmale bearbeiten.
3. Klicken Sie im Fenster Webcontainerservice auf das Register Allgemein.
4. Geben Sie den gewünschten Wert im Feld Maximalgröße von Threads ein.
5. Kehren Sie zur Anzeige Services zurück und klicken Sie auf Anwenden, damit die Änderungen gespeichert werden.
6. Stoppen Sie den Anwendungsserver und starten Sie ihn erneut.

Resource Analyzer zeigt eine Metrik mit der Bezeichnung "Grenzwert in Prozent" an, die die Zeitperiode festlegt, während der die Threads verwendet werden. Ist dieser Wert fortlaufend eine zweistellige Zahl, dann könnte der Webcontainer ein Engpass sein und die Anzahl der Threads sollte erhöht werden.

Standardwert: 50
Anmerkung: Für Linux-Systeme wird der Wert 25 empfohlen.
Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen und Größe des Cache für vorbereitete Anweisungen

Maximalanzahl der Keepalives für Webcontainertransport

Kurzbeschreibung: Dies ist die maximale Anzahl an gleichzeitigen Verbindungen zum Webcontainer, die aktiv (alive) sein dürfen (d. h., die in mehreren Anforderungen verarbeitet werden sollen). Das Webserver-Plug-In hält die Verbindungen zum Anwendungsserver so lange wie möglich geöffnet. Wenn der Wert dieses Merkmals jedoch zu klein ist, wird die Leistung beeinträchtigt, weil das Plug-In für jede Anforderung eine neue Verbindung öffnen muss, anstatt über eine Verbindung mehrere Anforderungen zu senden. Der Anwendungsserver akzeptiert bei hoher Auslastung möglicherweise keine neue Verbindung, wenn zu viele Sockets den Status TIME_WAIT aufweisen.

Die Client-Anforderung war eine HTTP-1.0-Anforderung, obwohl das Webserver-Plug-In immer HTTP-1.1-Anforderungen sendet.
Die maximale Anzahl gleichzeitiger Keepalives wurde erreicht. Ein Keepalive darf für die Lebensdauer einer Verbindung nur einmal abgerufen werden, d. h. nach Beendigung der ersten Anforderung aber vor dem Lesen der zweiten Anforderung.
Die maximale Anzahl gleichzeitiger Anforderungen für eine Verbindung wurde erreicht. Auf diese Weise werden Denial of Service-Attacken vermieden, bei denen ein Client versucht, eine Keepalive-Verbindung unbegrenzt geöffnet zu halten.
Ein Zeitlimit wurde überschritten beim Warten auf das Lesen der nächsten Anforderung oder beim Warten auf der Lesen des restlichen Teils der aktuellen Anforderung.

Parameter anzeigen oder einstellen:
1. Rufen Sie in der Administrationskonsole die Anzeige Webcontainerservice auf.
2. Wählen Sie das Register Transport aus und legen Sie den Wert für Maximalanzahl der Keepalives fest.
Standardwert: Der Standardwert lautet 45, das entspricht 90 % der Standardmaximalanzahl an Threads im Thread-Pool des Webcontainers.
Empfohlener Wert: Der Wert sollte auf mindestens 90 % der Maximalanzahl an Threads im Thread-Pool des Webcontainers gesetzt werden. Falls er 100 % der Maximalanzahl an Threads im Thread-Pool des Webcontainers entspricht, könnten alle Threads durch Keepalive-Verbindungen verbraucht werden, so dass für die Verarbeitung neuer Verbindungen keine Threads verfügbar bleiben.

Maximalanzahl der Anforderungen pro Keepalive für Webcontainertransport

Kurzbeschreibung: Die maximale Anzahl Anforderungen, die auf einer einzelnen Keepalive-Verbindung zulässig ist. Auf diese Weise werden Denial of Service-Attacken vermieden, bei denen ein Client versucht, eine Keepalive-Verbindung geöffnet zu halten. Das Webserver-Plug-In hält die Verbindungen zum Anwendungsserver so lange wie möglich geöffnet, um eine optimale Leistung zu ermöglichen.
Parameter anzeigen oder einstellen:
1. Rufen Sie in der Administrationskonsole die Anzeige Webcontainerservice auf.
2. Wählen Sie das Register Transport aus und legen Sie den Wert für Maximalanzahl der Keepalives fest.
Standardwert: Der Standardwert beträgt 100.
Empfohlener Wert: Werden Anforderungen des Anwendungsservers nur vom Plug-In empfangen, sollten Sie den Wert erhöhen, um die Leistung zu verbessern.

Cache für URL-Aufrufe

Kurzbeschreibung: Im Aufruf-Cache werden Informationen zur Zuordnung von Anforderungs-URLs zu Servlet-Ressourcen gespeichert.
Für jeden Thread wird ein Cache mit der angeforderten Größe erstellt. Die Anzahl der Threads wird durch die Einstellung für die Maximalgröße von Threads bestimmt.

Anmerkung: Ein größerer Cache benötigt einen größeren Java-Freispeicher, daher muss die maximale Größe des Java-Freispeichers eventuell erhöht werden. Wenn jeder Cache-Eintrag beispielsweise 2 KB erfordert, die Maximalgröße von Threads auf 25 gesetzt ist und die Größe des URL-Aufruf-Caches 100 beträgt, dann sind 5 MB Java-Freispeicher erforderlich.
Empfohlene Anpassung: Wenn mehr als 50 eindeutige URLs aktiv verwendet werden (jede JSP-Seite ist ein eindeutiger URL), sollten Sie diesen Parameter erhöhen.
Parameter anzeigen oder einstellen: Die Cache-Größe kann für den Anwendungsserver zusammen mit anderen JDK-Parametern wie folgt festgelegt werden:
1. Klicken Sie in der Administrationskonsole auf den Anwendungsserver, den Sie optimieren möchten.
2. Klicken Sie auf das Register JVM-Einstellung.
3. Klicken Sie in derselben Anzeige im Bereich Systemmerkmale auf Hinzufügen.
4. Fügen Sie den Namen invocationCacheSize und den Wert 50 hinzu.
5. Klicken Sie auf Anwenden, um die Änderungen zu speichern.
6. Stoppen Sie den Anwendungsserver und starten Sie ihn erneut.
Standardwert: 50
Zugehörige Parameter: Siehe Einstellungen der Freispeichergröße

Überschreitung des Grenzwerts bei Thread-Zuordnung zulassen

Kurzbeschreibung: Ist diese Option ausgewählt, können mehr Webcontainer-Threads zugeordnet werden, als im Feld "Maximalgröße von Threads" angegeben.
Parameter anzeigen oder einstellen:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, den Sie optimieren möchten, und klicken Sie auf das Register Services.
2. Klicken Sie auf Webcontainerservice und anschließend auf Merkmale bearbeiten.
3. Klicken Sie im Fenster Webcontainerservice auf das Register Allgemein.
4. Zum Auswählen einer neuen Einstellung klicken Sie auf das Markierungsfeld.
5. Kehren Sie zur Anzeige Services zurück und klicken Sie auf Anwenden, damit die Änderungen gespeichert werden.
6. Stoppen Sie den Anwendungsserver und starten Sie ihn erneut.
Standardwert: Standardmäßig ist das Markierungsfeld nicht ausgewählt (der Thread-Pool darf den als Maximalgröße von Threads festgelegten Wert nicht überschreiten). Empfohlener Wert: Diese Option dient zur Verarbeitung kurzzeitiger, hoher Arbeitslasten, die die konfigurierte maximale Thread-Größe überschreiten. Gehen Sie bei Auswahl dieser Option jedoch vorsichtig vor, weil zu viele Threads zu einer Überlastung des Systems führen können.

EJB-Container

Cache-Einstellungen

Kurzbeschreibung: Zum Ermitteln der absoluten Cache-Grenze multiplizieren Sie die Anzahl der Enterprise-Beans, die in einer gegebenen Transaktion aktiv sind, mit der Gesamtzahl der erwarteten gleichzeitig ablaufenden Transaktionen. Zählen Sie dann die Anzahl der aktiven Sitzungs-Bean-Instanzen hinzu.
Die Informationen zur Bean-Leistung können Sie im Resource Analyzer anzeigen.
Parameter anzeigen oder einstellen: Editieren Sie die Merkmale des EJB-Container-Service für den Anwendungsserver, den Sie optimieren.
Standardwert:
Cache-Größe = 2047
Empfohlene Cache-Grenze = 2000
Intervall zum Löschen des Cache = 1000

CMP-Enterprise-Beans auf mehrere Enterprise-Bean-Module aufteilen

Kurzbeschreibung: Die Ladezeit für Hunderte von Beans kann verbessert werden, indem die Beans auf mehrere JAR-Dateien verteilt und in eine EAR-Datei gepackt werden. Auf diese Weise kann der Verwaltungsserver die Beans schneller starten (8 - 10 Minuten im Vergleich zu über einer Stunde, wenn nur eine einzige JAR-Datei verwendet wird).

Sicherheit

Sicherheit inaktivieren

Kurzbeschreibung: Die Sicherheit ist eine globale Einstellung. Wenn sie aktiviert ist, verringert sich die Leistung um 10 bis 20 Prozent. Sie sollten die Sicherheitseinstellung daher inaktivieren, wenn Sie sie nicht benötigen.
Parameter anzeigen oder einstellen: Klicken Sie in der Administrationskonsole auf Konsole > Sicherheitscenter.
Standardwert: Standardmäßig ist die Sicherheit nicht aktiviert.

Das Zeitlimit des Sicherheits-Cache für die verwendete Umgebung optimieren

Kurzbeschreibung: Wenn die Sicherheit von WebSphere Application Server aktiviert ist, kann das Zeitlimit des Sicherheits-Cache die Leistung beeinflussen. Das Zeitlimit gibt an, wie oft die Sicherheits-Caches aktualisiert werden.
Sicherheitsinformationen zu Beans und Berechtigungen werden im Cache zwischengespeichert. Wenn das Zeitlimit für den Cache überschritten wird, werden alle dort gespeicherten Informationen ungültig. Nachfolgende Anforderungen nach Informationen führen zu einer Suche in der Datenbank. Gelegentlich muss für den Abruf von Informationen ein LDAP-Bind (Lightweight Directory Access Protocol) oder eine native Authentifizierung aufgerufen werden. Beide Operationen sind relativ aufwändige Operationen, die zu Lasten der Leistung gehen.

Probieren Sie anhand der Verwendungsmuster und Sicherheitsanforderungen für Ihre Site aus, welche Lösung für die Anwendung am besten ist.
Ergebnis: Bei einem einfachen 20-minütigen Leistungstest, bei dem das Zeitlimit für den Cache so gesetzt wurde, dass es nicht überschritten wurde, konnte eine 40-prozentige Leistungssteigerung erzielt werden.
Parameter anzeigen oder einstellen: Klicken Sie in der Administrationskonsole auf Konsole > Sicherheitscenter Allgemein > Zeitlimit für Sicherheits-Cache.
Standardwert: Der Standardwert ist 600.

Arten und Größen von Sicherheits-Caches (Systemparameter)

Die folgenden Systemmerkmale legen die Anfangsgröße der primären und sekundären Hash-Tabelle des Cache fest, die Auswirkungen auf das Rehashing und die Verteilung des Hash-Algorithmus hat. Je größer die Zahl der verfügbaren Hash-Werte, desto seltener tritt eine Hash-Kollision auf und desto länger ist die Abrufzeit. Besteht eine Hash-Tabelle aus mehrere Einträgen, dann sollte eine größere Tabelle erstellt werden. Auf diese Weise verläuft das Einfügen von Einträgen effizienter als wenn die Größe der Tabelle beim automatischen Rehashing bestimmt wird. Rehashing bewirkt, dass jedesmal jeder Eintrag verschoben wird.

com.ibm.websphere.security.util.LTPAAuthCacheSize

Kurzbeschreibung: Dieser Cache speichert Berechtigungen zur Basisauthentifizierung auf dem Sicherheitsserver. Wenn ein LTPA-Token (Lightweight Third Party Authentication) abläuft, wird aus den Berechtigungen zur Basisauthentifizierung in diesem Cache ein neues Token generiert. Sind keine Berechtigungen zur Basisauthentifizierung vorhanden, muss der Anforderungs-Browser die Berechtigungen zur Basisauthentifizierung an den Sicherheitsserver senden. Der Browser fordert vom Benutzer Benutzer-ID und Kennwort an, wenn kein Cookie mit diesen Berechtigungen existiert.

com.ibm.websphere.security.util.LTPATokenCacheSize

Kurzbeschreibung: Dieser Cache speichert LTPA-Berechtigungen im Cache, wobei das LTPA-Token als Suchwert verwendet wird. Bei Verwendung eines LTPA-Token zum Anmelden, wird die LTPA-Berechtigung zum ersten Mal auf dem Sicherheitsserver erstellt. Dieser Cache vermeidet die Verwendung des Sicherheitsservers bei nachfolgenden Anmeldungen unter Verwendung eines LTPA-Token.

com.ibm.websphere.security.util.CredentialCacheSize

Kurzbeschreibung: Für eine gegebene Benutzer-ID und ein gegebenes Kennwort, die zur Anmeldung verwendet werden, gibt dieser Cache ein konkretes Berechtigungsobjekt zurück, entweder Local OS oder LTPA, ohne dass die Authentifizierung am Sicherheitsserver wiederholt werden muss. Nachdem das Berechtigungsobjekt abgelaufen ist, muss die Authentifizierung wiederholt werden.

com.ibm.websphere.security.util.LTPAValidationCacheSize

Kurzbeschreibung: Für ein gegebenes Berechtigungs-Token zur Anmeldung gibt dieser Cache das konkrete LTPA-Berechtigungsobjekt zurück, ohne dass eine Überprüfung auf dem Sicherheitsserver erforderlich ist. Nachdem das Token abgelaufen ist, muss es erneut überprüft werden.

com.ibm.websphere.security.util.PermissionCacheSize

Kurzbeschreibung: Dieser Cache speichert die Berechtigungsobjekte von WebSphere Application Server, die beim Aufruf einer getGrantedPermissions-Methode abgerufen werden. Falls derselbe Principal erneut auf dieselbe Ressource zugreift, werden die Berechtigungen schnell aus dem Cache abgerufen, anstatt aus dem Repository auf dem Verwaltungsserver. Dieser Cache wird von Enterprise-Bean- und weberteilten Berechtigungen gemeinsam benutzt.

com.ibm.websphere.security.util.AdminBeanCacheSize

Kurzbeschreibung: Speichert Informationen, einschließlich der erforderlichen Berechtigungen, über Enterprise-Beans, die im Verwaltungsserver implementiert wurden.

com.ibm.websphere.security.util.BeanCacheSize

Kurzbeschreibung: Speichert Informationen, einschließlich der erforderlichen Berechtigungen und RunAs-Modus, zu den Enterprise-Beans, die in einem Container auf dem Anwendungsserver implementiert wurden.

SSL-Sitzungen richtig konfigurieren

Kurzbeschreibung: Der Wert SSLV3Timeout gibt das Zeitintervall an, nach dem SSL-Sitzungen neu ausgehandelt werden. Er ist bereits hoch eingestellt, so dass eine Änderung wahrscheinlich keine spürbare Verbesserung bringt. Standardmäßig beträgt der Wert 9600 Sekunden.
Das Feature SAS (Secure Association Service) stellt nur dann eine SSL-Verbindung her, wenn diese von einer JVM (zu einer anderen JVM) wegführt. Wenn sich daher alle Beans innerhalb derselben JVM befinden, hat die von SAS verwendete SSL keine negativen Auswirkungen auf die Leistung.
Parameter anzeigen und einstellen: Ändern Sie den Wert SSLV3Timeout und andere SAS-Merkmale, indem Sie die Dateien sas.server.props und sas.client.props editieren. Die Dateien befinden sich im Verzeichnis Stammverzeichnis_der_Produktinstallation\properties, wobei Stammverzeichnis_der_Produktinstallation das Verzeichnis ist, in dem WebSphere Application Server installiert ist.
Standardwert: Der Standardwert ist 9600 Sekunden.

Object Request Broker (ORB)

Zum Festlegen dieser Parameter wählen Sie für Object Request Broker für den Standardserver oder für einen zusätzlichen Anwendungsserver, der in der Verwaltungsdomäne konfiguriert ist, das Register Services und anschließend Merkmale bearbeiten aus.

Wertübergabe versus Referenzübergabe (NoLocalCopies)

Kurzbeschreibung: Die EJB 1.1-Spezifikation besagt, dass Methodenaufrufe eine Wertübergabe sein müssen. Wertübergabe bedeutet, dass die Parameter bei jedem fernen Methodenaufruf in den Stapel kopiert werden, ehe der Aufruf ausgeführt wird. Dies kann sehr leistungsaufwändig sein. Es ist möglich, eine Referenzübergabe anzugeben, die die ursprüngliche Objektreferenz übergibt, ohne eine Kopie des Objekts zu erstellen.
Ergebnis: Wenn der EJB-Client und EJB-Server in derselben Instanz von WebSphere Application Server installiert sind, kann die Angabe einer Referenzübergabe die Leistung um bis zu 50 % verbessern.
Empfohlene Anpassung: Die Referenzübergabe verbessert die Leistung nur dann, wenn nicht primitive Objekttypen als Parameter übergeben werden. Aus diesem Grund werden int und floats immer kopiert, unabhängig vom Aufrufmodell.
WARNUNG: Referenzübergaben können zu unerwarteten Ergebnissen führen. Wenn eine Objektreferenz von der fernen Methode geändert wird, wird die Änderung möglichweise nur vom aufrufenden Modul bemerkt.
Parameter anzeigen oder einstellen:
1. Wählen Sie für Object Request Broker den Anwendungsserver aus, der optimiert werden soll, und klicken Sie auf das Register Services.
2. Klicken Sie auf das Register Erweitert.
3. Aktivieren Sie die Option Nach Referenz übergeben, und klicken Sie auf OK.
4. Klicken Sie auf Anwenden, um die Änderungen zu speichern.
5. Stoppen Sie den Anwendungsserver und starten Sie ihn erneut.
Standardwert: Wertübergabe

Falls der Anwendungsserver eine hohe Arbeitslast für Enterprise-Bean-Anforderungen erwartet, ist die ORB-Konfiguration von kritischer Bedeutung. Achten Sie auf folgende Merkmale:

com.ibm.CORBA.ServerSocketQueueDepth

Kurzbeschreibung: Dieses Merkmal entspricht der Länge der Empfangswarteschlange für den TCP/IP-Stack.
Empfohlene Anpassung: Falls viele Clients gleichzeitig Verbindungen zum ORB auf der Serverseite herstellen, kann dieser Parameter auf einen höheren Wert gesetzt werden, um hohe Auslastungen (bis zu 1000 Clients) zu unterstützen.
Parameter anzeigen oder einstellen:

Klicken Sie in der Administrationskonsole auf den Anwendungsserver, den Sie optimieren möchten.
Klicken Sie auf das Register JVM-Einstellungen und anschließend auf die Option Erweiterte JVM-Einstellungen (eventuell müssen Sie nach unten blättern, um diese Option zu sehen).
Geben Sie im Feld Befehlszeilenparameter Folgendes ein:
-Dcom.ibm.CORBA.ServerSocketQueueDepth=200.

Standardwert: Der Standardwert ist 50.

com.ibm.CORBA.MaxOpenConnections und Maximalgröße des Cache für ORB-Verbindungen

Kurzbeschreibung: Dieses Merkmal hat zwei Namen und entspricht der Größe der ORB-Verbindungstabelle. Es legt den Standardwert für die Anzahl der gleichzeitig stattfindenden ORB-Verbindungen fest, die verarbeitet werden können.
Empfohlene Anpassung: Falls viele Clients gleichzeitig Verbindungen zum ORB auf der Serverseite herstellen, kann dieser Parameter auf einen höheren Wert gesetzt werden, um hohe Auslastungen (bis zu 1000 Clients) zu unterstützen.
Parameter anzeigen oder einstellen: Dieses Merkmal kann über ein spezielles Feld oder über das Feld für JVM-Befehlszeilenparameter festgelegt werden. Das spezielle Feld ist auf 256 Zeichen begrenzt. Wird der Parameter auf einen höheren Wert gesetzt, sollte daher das Feld für JVM-Befehlszeilenparameter verwendet werden. Gehen Sie wie folgt vor, um das spezielle Feld zu verwenden:
1. Wählen Sie für Object Request Broker den Anwendungsserver aus, der optimiert werden soll, und klicken Sie auf das Register Services.
2. Wählen Sie das Register Allgemein aus.
3. Aktualisieren Sie die Informationen im Feld "Maximalgröße des Verbindungs-Cache" und klicken Sie auf OK.
4. Klicken Sie auf Anwenden, um die Änderungen zu speichern.
5. Starten Sie den Anwendungsserver erneut.
Gehen Sie wie folgt vor, um das Merkmal über das Feld für JVM-Befehlszeilenparameter festzulegen:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, der optimiert werden soll.
2. Klicken Sie auf das Register JVM-Einstellungen und anschließend auf die Option Erweiterte JVM-Einstellungen (eventuell müssen Sie nach unten blättern, um diese Option zu sehen).
3. Geben Sie im Feld Befehlszeilenparameter Folgendes ein:
  -Dcom.ibm.CORBA.MaxOpenConnections=800.
Standardwert: Der Standardwert ist 240. .

Größe des Thread-Pools für Object Request Broker

Kurzbeschreibung: Dieses Merkmal bezieht sich auf die Größe des ORB-Thread-Pools. Ein Arbeits-Thread aus dem Pool wird dazu verwendet, Anforderungen einer Verbindung zu verarbeiten.
Empfohlene Anpassung: Falls viele Clients gleichzeitig Verbindungen zum ORB auf der Serverseite herstellen, kann dieser Parameter auf einen höheren Wert gesetzt werden, um hohe Auslastungen (bis zu 1000 Clients) zu unterstützen.
Parameter anzeigen oder einstellen:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, den Sie optimieren möchten, und klicken Sie auf das Register Services.
2. Wählen Sie Object Request Broker und anschließend Merkmale bearbeiten aus.
3. Die Größe des Thread-Pools erscheint in der Anzeige Allgemeine Merkmale.
Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen
Standardwert: 20

JNI ReaderManager und ReaderThreads verwenden

Kurzbeschreibung: Der ORB verfügt über eine Gruppe von Threads, die als ReaderThreads bezeichnet werden und mit denen die Ein-/Ausgabe über Socket-Datenströme erfolgt. Ein ReaderManager-Thread ordnet jeder IIOP-Verbindung, die von WebSphere Application Server und seinen Clients hergestellt wird, einen Lese-Thread zu. Standardmäßig wird für jede hergestellte IIOP-Verbindung (IIOP = Internet Inter-Orb Protocol) ein neuer Thread erstellt. Dieser Thread wird beim Schließen der Verbindung gelöscht. Sie haben die Möglichkeit, eine andere Art von Thread zu verwenden, den sogenannten JNIReader, in dem dem Lese-Thread mehrere Verbindungen zugeordnet werden. JNIReader kann daher für eine Reihe von Sockets im Multiplex-Betrieb arbeiten. Der zugehörige Verwaltungs-Thread mit dem Namen JNIReaderManager ordnet die Verbindungen den JNIReader-Threads zu. Er verwendet einen Algorithmus zur Zeitzuteilung für die Threads.
Die Verwendung der JNIReaders erfordert weniger Speicher, weil eine feste Anzahl von Threads erstellt werden muss. Sie ist außerdem zeitsparend, weil die Thread-Erstellung nur während der Initialisierung stattfindet und Threads nicht gelöscht werden. JNIReader ist eine C-native Implementierung und sollte schneller sein als der standardmäßig festgelegte Lese-Thread.
Empfohlene Anpassung: JNIReader sollten unbedingt eingesetzt werden für Anwendungen mit hoher Enterprise-Bean-Verarbeitung (200 bis 1000 oder mehr Enterprise-Bean-Clients, einschließlich Servlets, die Enterprise-Bean-Methoden aufrufen).
Parameter anzeigen oder einstellen: Um die JNIReader zu verwenden, müssen Sie die ORB-Merkmale festlegen. Dies kann sowohl auf dem Verwaltungsserver als auch auf dem Anwendungsserver erfolgen.
Zum Festlegen der Merkmale im Anwendungsserver gehen Sie wie folgt vor:
1. Wählen Sie das Register JVM-Einstellungen aus.
2. Klicken Sie auf Erweiterte JVM-Einstellungen.
3. Geben Sie im Feld Befehlszeilenparameter Folgendes ein:
  -Dcom.ibm.CORBA.numJNIReaders=xx
  -Dcom.ibm.CORBA.ReaderManagerImpl=com.ibm.CORBA.iiop.JNIReaderManager
  Anmerkung: xx steht für die Zahl der JNIReader-Threads, die zugeordnet werden sollen. Es gibt keine absolute Zahl, die dafür ausgewählt werden sollte. Als allgemeine Richtlinie empfiehlt es sich jedoch, diese Zahl auf die Anzahl der im System verfügbaren Prozessoren zu setzen plus 1 (d. h. xx = Anzahl der Prozessoren im System + 1).
4. Klicken Sie auf OK und anschließend auf Anwenden.
Zum Festlegen der Merkmale im Verwaltungsserver gehen Sie wie folgt vor:
1. Editieren Sie die Datei admin.config und fügen Sie dieselben Einträge wie oben in Schritt 3 zu com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs hinzu.
2. Speichern Sie die Änderungen und führen Sie für den Verwaltungsserver einen Neustart durch.

WARNUNG: Vergewissern Sie sich, dass die Implementierung der JNI-Bibliothek von JNIReader im Verzeichnis bin von WebSphere Application Server befindet. Für die Intel-Plattform lautet die Bibliothek Selector.dll und für UNIX lautet die Bibliothek libSelector.a oder libSelector.so. Falls unter Unix das Präfix "lib" fehlt, sollte die Datei umbenannt werden.

Java Virtual Machines (JVMs)

Die JVM optimieren

Die JVM verfügt über mehrere Optimierungsparameter, die sich auf die Leistung der WebSphere Application Server (bei denen es sich hauptsächlich um Java-Anwendungen handelt) sowie auf die Leistung Ihrer eigenen Anwendungen auswirken.

Modus -server unter Sun JDK 1.3 HotSpot

Kurzbeschreibung: Die HotSpot JVM verfügt über eine adaptive JVM-Technologie, die Algorithmen zur Optimierung der Bytecodeausführung während einer längeren Zeit enthält. Die JVM läuft in zwei Modi, -server und -client. Die Leistung kann signifikant gesteigert werden, wenn der Modus -server verwendet wird und eine ausreichende Menge Aufwärmzeit für eine HotSpot JVM verfügbar ist, während der fortlaufende Bytecodes ausgeführt werden.
Empfohlene Anpassung: In den meisten Fällen sollte der Modus -server verwendet werden. Dieser Modus ergibt während längerer Zeitperioden eine effizientere Laufzeitausführung. Die Option -client kann verwendet werden, wenn Sie eine schnellere Startzeit und einen geringeren Speicher (Memory Footprint) auf Kosten einer niedrigeren Leistung bevorzugen.
Parameter anzeigen oder einstellen: In WebSphere Application Server Version 4.0 ist die Option -server standardmäßig aktiviert. Befolgen Sie diese Schritte, um zum Modus -client zu wechseln:
1. Wählen Sie in der Administrationskonsole den Anwendungsserver aus, der optimiert werden soll.
2. Klicken Sie auf JVM-Einstellungen und anschließend auf Systemmerkmale.
3. Fügen Sie unter Systemmerkmale das folgende Namenspaar hinzu: HotSpotOption / client.
Empfohlener Wert: -server

Neue Pool-Größe für unterschiedliche Altersstufen (Generation) unter Sun JDK 1.3 HotSpot

Kurzbeschreibung: Die meisten Algorithmen für die Garbage Collection funktionieren in der Weise, dass durch Iteration jedes Objekts im Freispeicher geprüft wird, welche Objekte freigegeben werden können. Die HotSpot JVM verwendet die Generational Garbage Collection, die separate Speicherpools für Objekte unterschiedlicher Alterstufen verwendet. Für jeden Pool kann unabhängig vom anderen eine Garbage Collection durchgeführt werden. Die Größen dieser Speicher-Pools können angepasst werden. Zusätzlicher Arbeitsaufwand kann vermieden werden, indem die Größe der Speicherpools so definiert wird, dass kurzlebige Objekte niemals mehr als einen Garbage-Collection-Zyklus durchlaufen.
Empfohlene Anpassung: Wenn die Garbage Collection ein Engpass in Ihrem System ist, sollten Sie die Einstellungen für den Pool der Altersstufe (Generation) anpassen.
Parameter anzeigen oder einstellen:

Wählen Sie in der Administrationskonsole den Anwendungsserver aus, der optimiert werden soll.
Klicken sie auf JVM-Einstellungen > Erweiterte JVM-Einstellungen > Befehlszeilenparameter. Folgende Werte müssen festgelegt werden:
-XX:NewSize (untere Grenze)
-XX:MaxNewSize (obere Grenze).

Empfohlener Wert: Legen Sie den Pool zwischen 25 bis 50 % der gesamten Freispeichergröße fest.

JIT-Compiler (Just In Time)

Kurzbeschreibung: Der JIT-Compiler (Just In Time) kann die Leistung erheblich verbessern.
Empfohlene Anpassung: Übernehmen Sie immer die Standardeinstellung, d.h. aktiviertes JIT.

Einstellungen der Freispeichergröße

Kurzbeschreibung: Mit diesen Einstellungen werden die maximale Freispeichergröße und die Anfangsgröße des Freispeichers für die JVM gesetzt.
Im allgemeinen verbessert ein großer Java-Freispeicher den Durchsatz, bis der Freispeicher nicht mehr im physischen Speicher enthalten ist. Nachdem der Freispeicher auf die Festplatte ausgelagert wurde, sinkt die Java-Leistung dramatisch. Daher muss die maximale Freispeichergröße so niedrig sein, dass der Freispeicher im physischen Speicher verbleiben kann.

Der physische Speicher muss gemeinsam von der JVM und den anderen Anwendungen, z. B. der Datenbank, verwendet werden. Verwenden Sie sicherheitshalber einen kleineren Freispeicher (z. B. 64 MB für Maschinen mit geringerer Speicherkapazität).

Verwenden Sie die maximale Freispeichergröße von 128 MB für eine kleinere Maschine (mit weniger als 1 GB physischem Speicher), 256 MB für Systeme mit 2 GB Speicherkapazität und 512 MB für größere Systeme. Der optimale Wert ist abhängig von der verwendeten Anwendung.

Wenn Leistungsausführungen durchgeführt und wiederholbare Ergebnisse gefordert werden, setzen Sie die Anfangsgröße und die maximale Größe auf denselben Wert. Dadurch kann der Freispeicher während der Ausführung nicht ansteigen. Für Produktionssysteme, bei denen die Arbeitsspeichergröße der Java-Anwendungen nicht bekannt ist, sollte die Anfangsgröße ein Viertel der maximalen Größe betragen. Die JVM versucht dann, die Freispeichergröße an den Arbeitsbereich der Java-Anwendung anzupassen.
Parameter anzeigen oder einstellen: Legen Sie im Register "JVM-Einstellungen" des Anwendungsservers Folgendes fest:
- Ursprüngliche Java-Freispeichergröße
- Maximalgröße des Java-Freispeichers

Kurzbeschreibung: In den meisten Fällen sollte die Klassen-Garbage-Collection aktiviert sein. Dies ist die Standardeinstellung.
Parameter anzeigen oder einstellen: Durch Inaktivieren der Klassen-Garbage-Collection können mehr Klassen wiederverwendet werden, was in einigen Fällen zu geringen Leistungsverbesserungen geführt hat.
Verwenden Sie zum Festlegen der JVM-Parameter das Merkmal "Befehlszeilenparameter" des Standardservers oder eines zusätzlichen Anwendungsservers, den Sie in der Verwaltungsdomäne konfigurieren:
1. Klicken Sie in der Administrationskonsole auf den Anwendungsserver, den Sie optimieren möchten.
2. Klicken Sie auf das Register Services.
3. Klicken Sie im Register Erweitert auf JVM-Einstellungen.
4. Geben Sie unter Befehlszeilenparameter den Eintrag -Xnoclassgc ein.

Die Datenbank

WebSphere Application Server ist eng mit einer unterstützten Datenbank Ihrer Wahl verbunden. Informationen zu unterstützten Datenbanken finden Sie auf der Website mit den Produktvorraussetzungen unter www.ibm.com/software/webservers/appserv/library.html. WebSphere Application Server verwendet die Datenbank als permanenten Sicherungsspeicher zur Verwaltung sowie zur Speicherung von Sitzungsstatus und Enterprise-Bean-Daten für Ihre Anwendung.

Wenn die Anwendung WebSphere Application Server, JDBC-Datenbankverbindungs-Pooling oder Enterprise-Beans verwendet, sollten Sie der Konfiguration dieser Ressourcen und ihrer Datenbankeinstellungen in der Verwaltungsdomäne besondere Beachtung schenken. Während der Installation von WebSphere Application Server wird standardmäßig eine Datenbank mit dem Namen WASnn erstellt (nn steht dabei für die Releasenummer), die Sie jedoch umbenennen können. In dieser Dokumentation wird vorausgesetzt, dass Sie den Namen WAS40 übernommen haben.

Datenbankposition

Kurzbeschreibung: Die DB2-Datenbank kann sich auf derselben Maschine wie der WebSphere Application Server befinden oder auf einer fernen Maschine. Allerdings sollten bei einer OLTP-Anwendung mit hoher Ein-/Ausgabe, das Betriebssystem, die DB2-Protokolle, -Tabellen und -Indizes über eigenen Plattenbereich verfügen, um eine parallele Ein-/Ausgabe zu erlauben.
Empfohlene Anpassung: Wenn auf Ihrer Maschine ein Engpass auftritt, weil ihre Verarbeitungskapazität erschöpft ist (Engpass bei der CPU), kann die Leistung bedeutend verbessert werden, wenn Sie die Datenbank auf einer separaten Maschine installieren.
Aus Gründen der Skalierbarkeit wurde die Datenbank wahrscheinlich auf einer separaten Maschine installiert, insbesondere, wenn Cluster verwendet werden. Dies trifft auf die Datenbank von WebSphere Application Server zu, auf jede Anwendungsdatenbank und auf die Sitzungsdatenbank von WebSphere Application Server (wenn permanente Sitzungen verwenden werden).
Standardwert: Die Standardinstallation installiert die Datenbank auf der lokalen Maschine.

Größe des Pools für Datenquellenverbindungen in WebSphere Application Server

Kurzbeschreibung: Beim Zugriff auf eine Datenbank ist die Herstellung der ersten Datenbankverbindung ein aufwändiger Vorgang. WebSphere Application Server unterstützt die APIs von JDBC 2.0 Standard Extension für Verbindungs-Pooling und Wiederverwendung von Verbindungen. Der Verbindungspool wird für direkte JDBC-Aufrufe in der Anwendung sowie für Enterprise-Beans, die die Datenbank benutzen, verwendet.
Werden Klone verwendet, existiert für jeden Klon ein Datenquellenpool. Dies ist wichtig für die Konfiguration der maximalen Datenbankserververbindungen.
Ergebnis: Wenn Sie die Möglichkeiten des Verbindungs-Pooling nutzen, kann die Leistung um das 20-fache gesteigert werden.
Parameter anzeigen oder einstellen: Legen Sie in der Administrationskonsole die Optionen für die Pools für Datenbankverbindungen fest. Weitere Informationen dazu enthält der InfoCenter-Artikel 6.6.14.
Standardwert: Mindestgröße des Verbindungspools: 1, Maximalgröße des Verbindungspool: 10
Parameterauslastung anzeigen: Aktivieren Sie die Zähler im Resource Analyzer:
1. Starten Sie den Resource Analyzer.
2. Wählen Sie den Anwendungsserver aus, der optimiert werden soll.
3. Blenden Sie die Kategorie mit den Datenbankverbindungspools ein.
4. Wählen Sie die gewünschte Datenquelle aus.
5. Klicken Sie auf die Datenquelle, um sie auf "Hoch" zu setzen. Dies ist erforderlich, um den Zähler Belegung in Prozent (percentUsed) abzurufen.
6. Klicken Sie auf Ausführen, um das Erfassen statistischer Daten zu starten, und achten Sie auf Folgendes:
  - Poolgröße = durchschnittliche Anzahl von Verbindungen im Pool zur Datenbank
  - Belegung in Prozent = durchschnittliche Prozentzahl der verwendeten Poolverbindungen
  - Gleichzeitig wartende Verbindungen = durchschnittliche Anzahl Threads, die auf eine Verbindung warten

Ermitteln Sie mit Hilfe des Resource Analyzer die optimale Anzahl Poolverbindungen, durch die die Werte für diese Zahlen verringert werden. Ist der Wert für "Belegung in Prozent" fortlaufend niedrig, sollten Sie sich überlegen, die Anzahl der Verbindungen im Pool zu verringern.

Empfohlener Wert: In der Regel erhalten Sie eine bessere Leistung, wenn der Wert für die Größe des Verbindungspools kleiner ist als der Wert für die maximalen Verbindungen im Webcontainer. Niedrigere Einstellungen (10 - 30 Verbindungen) wirken sich positiver auf die Leistung aus als höhere Einstellungen (über 100).
Auf UNIX-Plattformen wird ein separater DB2-Prozess für jede Verbindung erstellt. Dies wirkt sich schnell nachteilig auf die Leistung von Systemen mit geringer Speicherkapazität aus, und Fehler können auftreten.

Jede Entity-EJB-Transaktion erfordert eine zusätzliche Verbindung zur Datenbank, die die Transaktion verarbeitet. Dies sollten Sie unbedingt berücksichtigen, wenn Sie die Anzahl der Datenquellenverbindungen berechnen. Ein gegenseitiges Sperren kann eintreten, wenn die Anwendung mehr als eine gleichzeitig bestehende Verbindung pro Thread erfordert und der Datenbankverbindungspool zu klein ist für die Anzahl der Threads. Angenommen, jeder Anwendungs-Thread erfordert zwei gleichzeitig bestehende Datenbankverbindungen, und die Anzahl der Threads entspricht der maximalen Größe für Verbindungspools. Ein gegenseitiges Sperren tritt dann ein, wenn die folgenden Aussagen beide wahr sind:
- Jeder Thread hat seine erste Datenbankverbindung, und alle werden verwendet.
- Jeder Thread wartet auf eine zweite Datenbankverbindung, und keine wird frei, da alle Threads belegt sind.

Um ein gegenseitiges Sperren in einem solchen Fall zu vermeiden, muss der Wert für den Datenbankverbindungspool um mindestens Eins größer sein, so dass mindestens einer der wartenden Threads seine zweite Datenbankverbindung beenden und damit Datenbankverbindungen freigeben kann.

Zum Vermeiden einer gegenseitigen Sperre codieren Sie die zu verwendende Anwendung in der Weise, dass maximal eine Verbindung pro Thread existiert. Wenn die Anwendung so codiert wurde, dass sie die Zahl C an gleichzeitig bestehenden Datenbankverbindungen pro Thread benötigt, muss der Verbindungspool mindestens die folgende Anzahl von Verbindungen unterstützen, wobei T für die maximale Anzahl Threads steht:

T * (C - 1) + 1

Die Einstellungen des Verbindungspools beziehen sich direkt auf die Anzahl der Verbindungen, die der Datenbankserver unterstützt. Wird die maximale Anzahl der Verbindungen im Pool erhöht und werden die entsprechenden Einstellungen in der Datenbank nicht erhöht, tritt ein Fehler in Ihrer Anwendung auf und SQL-Ausnahmefehler werden in der Datei stderr.log angezeigt.

Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen, Größe des Cache für vorbereitete Anweisungen und Anzahl Verbindungen zu DB2

Größe des Cache für vorbereitete Anweisungen

Kurzbeschreibung: Die Datenquelle von WebSphere Application Server optimiert die Verarbeitung von vorbereiteten Anweisungen. Eine vorbereitete Anweisung (Prepared Statement) ist eine vorkompilierte SQL-Anweisung, die in einem Objekt für vorbereitete Anweisung gespeichert ist. Mit diesem Objekt kann dann die SQL-Anweisung mehrere Male ausgeführt werden.
Anmerkung: Vorbereitete Anweisungen sind zur Verarbeitung von parametrischen SQL-Anweisungen optimiert, die von einer Vorkompilierung profitieren. Wenn der in der Datenquelle angegebene JDBC-Treiber die Vorkompilierung unterstützt, wird die vorbereitete Anweisung bei ihrer Erstellung zur Vorkompilierung an die Datenbank gesendet. Einige Treiber unterstützen keine Vorkompilierung. In diesem Fall wird die Anweisung erst bei Ausführung der vorbereiteten Anweisung an die Datenbank gesendet.

Die Datenquelle von WebSphere Application Server verwaltet einen Pool mit Datenbankverbindungen sowie einen zugeordneten Cache mit Objekten für vorbereiteten Anweisungen. Vorbereitete Anweisungen werden mit einer Kennung zwischengespeichert, die jede Verbindung identifiziert, die die Anweisungen ausführt. Die Beziehung zwischen den verwendeten SQL-Anweisungen, dem Cache mit den vorbereiteten Anweisungen, einer Datenquelle und einer Datenbank sollte genauer betrachtet werden. Angenommen, eine Anwendung verwendet 5 SQL-Anweisungen: 2 Select-Anweisungen, 1 Delete-Anweisung, 1 Insert-Anweisung und 1 Update-Anweisung.

Die Datenquelle oben ist mit einem Maximum an drei gleichzeitig bestehenden Verbindungen zur Datenbank konfiguriert. Die Verbindungen wurden bereits erstellt, und viele SQL-Anweisungen wurden ausgeführt. Der Cache für die vorbereiteten Anweisungen kann zehn Anweisungen speichern. Für Verbindung 1 und 2 wurden drei vorbereitete Anweisungen zwischengespeichert, für Verbindung 3 vier Anweisungen. Da Anweisungen bei ihrer Verwendung in vorbereitete Anweisungen kompiliert werden, widerspiegelt der Cache für die vorbereiteten Anweisungen die Datenbankbelegungsmuster der Anwendung. Der Cache für die vorbereiteten Anweisungen implementiert eine FIFO-Warteschlange (First-In, First-Out). Ein Objekt für vorbereitete Anweisung, das eine bestimmte SQL-Anweisung darstellt, kann im Cache für vorbereitete Anweisungen mehrmals auftreten. So kann es insbesondere ein Mal pro Verbindung im Verbindungspool vorkommen. Die Anweisungen 1 und 2 können z. B. drei Mal auftreten (ein Mal pro Verbindung). Anweisung 3 tritt für Verbindung 3 nicht auf, und die Anweisungen 4 und 5 treten nur für Verbindung 3 auf. Die Ausführung der Anweisungen 4 und 5 kann daher etwas länger dauern, wenn sie für die Verbindungen 1 und 2 auftreten, da sie für diese Verbindungen erneut kompiliert werden müssen. Es ist bei diesem Beispiel besser, die Größe des Cache für die vorbereiteten Anweisungen auf 15 zu setzen (5 vorbereitete Anweisungen für jede der drei Verbindungen).
Ergebnis: Bei Testanwendungen verbesserte ein optimierter Cache für vorbereitete Anweisungen den Durchsatz um 10 bis 20 %.
Parameter anzeigen oder einstellen: Klicken Sie in der Administrationskonsole auf Ressourcen > JDBC-Merkmale > Datenbanktreiber > Datenquelle > Verbindungs-Pooling > Größe des Anweisungs-Cache.
Empfohlener Wert: Ist der Cache nicht groß genug, werden nützliche Einträge gelöscht, um Platz für neue Einträge zu machen. Im allgemeinen gilt Folgendes: Je mehr vorbereitete Anweisungen in der Anwendung verwendet werden, desto größer sollte der Cache sein.
Der Resource Analyzer kann Sie bei der Optimierung dieser Einstellung unterstützen. Diese Einstellung sollte optimiert werden, um die Anzahl der gelöschten Einträge im Cache zu minimieren. Verwenden Sie eine Standardarbeitslast, die eine typische Anzahl ankommender Client-Anforderungen darstellt und verwenden Sie eine festgelegte Zahl von Wiederholungen sowie eine feste Gruppe von Konfigurationseinstellungen.

Befolgen Sie zur Verwendung des Resource Analyzer diese Anweisungen:
1. Starten Sie den Resource Analyzer.
2. Klicken Sie auf Datenbankverbindungen > Überwachungseinstellungen.
3. Vor dem Starten der Vergleichsarbeitslast klicken Sie mit der rechten Maustaste auf Datenbankverbindungen, Werte löschen, auf Zurücksetzen auf Null (falls erforderlich) und auf Starten.
4. Starten Sie die Arbeitslast und führen Sie sie vollständig aus. Notieren Sie anschließend den Wert, der für "Löschvorgänge im Cache für vorbereitete Anweisungen" gemeldet wird.
5. Stoppen Sie den Anwendungsserver und passen Sie folgende Einstellungen an: Klicken Sie auf Datenquelle > Verbindungs-Pooling > Wert für Größe des Anweisungs-Cache.
6. Führen Sie die Arbeitslast erneut aus und notieren Sie den Wert, der im Resource Analyzer für "Löschvorgänge im Cache für vorbereitete Anweisungen" gemeldet wird.
Der beste Wert für Datenquelle > Verbindungs-Pooling > Größe des Anweisungs-Cache ist die Einstellung, bei der entweder der Wert Null oder der niedrigste Wert für "Löschvorgänge im Cache für vorbereitete Anweisungen" zurückgegeben wird. Dies zeigt den optimalen Wert für eine typische Arbeitslast an.
Zugehörige Parameter: Siehe Systemwarteschlangen von WebSphere Application Server anpassen, Maximalanzahl der Verbindungen und Größe des Pools für Datenquellenverbindungen für WebSphere Application Server

Weitere JDBC-Parameter
Neben der Größe des Cache für vorbereitete Anweisungen können Sie auch weitere spezielle Merkmale für JDBC-Treiber einstellen. Mit Oracle können Sie z. B. die Anzahl der Zeilen erhöhen, die beim Anzeigen der Ergebnisse mit der folgenden Anweisung abgerufen werden sollen:
name="defaultRowPrefetch", value="25"
Geben Sie diese benutzerdefinierten Merkmale im Register Allgemein für die Datenbank ein.

DB2

DB2 verfügt über viele Parameter, die zur Optimierung der Datenbankleistung konfiguriert werden können. Ausführliche Informationen zur Optimierung von DB2 finden Sie in der Dokumentation "DB2 UDB Administration Guide: Performance".

TCP-Sockets für DB2 unter Linux verwenden

Kurzbeschreibung: Auf Linux-Plattformen müssen Sie die DB2-Anwendungsdatenbanken so konfigurieren, dass sie zur Kommunikation mit der Datenbank TCP-Sockets verwenden, unabhängig davon, ob sich der DB2-Server nun auf einer lokalen Maschine mit WebSphere Application Server oder auf einer fernen Maschine befindet.
Parameter anzeigen oder einstellen: Die Anweisungen zur Konfiguration von DB2 unter Linux finden Sie in der Installationsdokumentation von WebSphere Application Server für die verschiedenen Betriebssysteme. Sie enthält Spezifikationen zur Einstellung von DB2COMM für TCP/IP sowie Angaben zu den entsprechenden Änderungen in der Datei etc/service.
Standardwert: gemeinsam benutzter Speicher für lokale Datenbanken
Empfohlener Wert: Ändern Sie unter Linux die Spezifikation für Ihre DB2-Anwendungsdatenbanken und alle Sitzungsdatenbanken von "gemeinsam benutzter Speicher" (shared memory) in "TCP-Sockets". Selbst das Verwaltungs-Repository, normalerweise eine DB2-Datenbank mit dem Namen WAS40, muss TCP verwenden.

DB2 MaxAppls

Zugehörige Parameter: Siehe Anzahl von DB2-Verbindungen

DB2 MaxAgents

Zugehörige Parameter: Siehe Anzahl von DB2-Verbindungen

DB2 buffpage

Kurzbeschreibung: Buffpage ist ein Parameter der Datenbankkonfiguration. Ein Pufferpool ist ein Speicherbereich, in dem Datenbankseiten mit Tabellenzeilen oder Indexeinträgen temporär gelesen und geändert werden. Zweck des Pufferpools ist eine Verbesserung der Leistung des Datenbanksystems. Daten sind im Speicher viel schneller zugänglich als auf der Platte.

Parameter anzeigen oder einstellen: Zum Anzeigen des aktuellen Werts von Buffpage für die Datenbank x geben Sie folgenden DB2-Befehl ein: get db cfg for x. Suchen Sie nach dem Wert für BUFFPAGE.

Soll BUFFPAGE auf den Wert n gesetzt werden, führen Sie folgenden DB2-Befehl aus: update db cfg for x using BUFFPAGE n, wobei NPAGES wie folgt auf -1 gesetzt werden muss:

    db2   <-- wechseln Sie zum DB2-Befehlsmodus, andernfalls funktioniert die nachfolgende
   "select"-Anweisung nicht
    connect to x    <-- (wobei x für den Namen der verwendeten DB2-Datenbank steht) 
select * from syscat.bufferpools 
(notieren Sie sich den Standardnamen, z. B.: IBMDEFAULTBP)
(wenn NPAGES bereits -1 ist, muss der folgende Befehl nicht ausgeführt werden) 
alter bufferpool IBMDEFAULTBP size -1
(Führen Sie die "select"-Anweisung oben erneut aus und NPAGES sollte dann auf -1 gesetzt sein.)

Parameterverwendung anzeigen: Erstellen Sie einen Snapshot (eine Momentaufnahme) der Datenbank, während die Anwendung läuft, und berechnen Sie die Trefferquote im Pufferpool.
1. Erstellen Sie den Snapshot durch Ausführung folgender DB2-Befehle:
  - update monitor switches using bufferpool on
  - get monitor switches (um festzustellen, ob die Überwachung des Pufferpools aktiviert ist)
  - reset monitor all (um die Überwachungszähler zurückzusetzen)
2. Führen Sie die Anwendung aus.
3. Führen Sie folgende Befehle aus:
  - get snapshot for all databases (Führen Sie diesen Befehl aus, bevor alle Anwendungen die Verbindung zur Datenbank beenden, andernfalls gehen die Statistiken verloren.)
  - update monitor switches using bufferpool off (Dieser Schritt muss unbedingt ausgeführt werden!)
4. Zum Berechnen der Trefferquote prüfen Sie folgende Statistiken des Snapshot für die Datenbank:
  - Buffer pool data logical reads (logische Leseoperationen für Pufferpooldaten)
  - Buffer pool data physical reads (physische Leseoperationen für Pufferpooldaten)
  - Buffer pool index logical reads (logische Leseoperationen für Pufferpoolindex)
  - Buffer pool index physical reads (physische Leseoperationen für Pufferpoolindex)
5. Die Trefferquote des Pufferpools zeigt den Prozentsatz der Zeit an, während dem der Datenbankmanager keine Seite von der Platte laden musste, um eine Seitenanforderung zu beantworten. Dies bedeutet, dass die Seite bereits im Pufferpool enthalten war. Je größer die Trefferquote im Pufferpool, desto niedriger ist die Häufigkeit der Ein-/Ausgabeoperationen auf der Platte. Die Trefferquote im Pufferpool kann wie folgt berechnet werden:
  - P = buffer pool data physical reads + buffer pool index physical reads
  - L = buffer pool data logical reads + buffer pool index logical reads
  - Trefferquote = (1-(P/L)) * 100%

DB2-Abfrageoptimierungsstufe

Kurzbeschreibung: Wenn eine Datenbankabfrage in DB2 ausgeführt wird, wird der effizienteste Zugriffsplan mit Hilfe verschiedener Methoden berechnet. Der Parameter für die Abfrageoptimierungsstufe legt die Menge an Arbeit und Ressourcen fest, die DB2 zur Optimierung des Zugriffsplans verwendet. Der gültige Bereich liegt zwischen Null und 9.
Bei einer Optimierungsstufe von 9 verwendet DB2 sehr viel Zeit und sämtliche verfügbaren statistischen Daten, um den Zugriffsplan zu optimieren.

Weitere Informationen finden Sie in der DB2-Dokumentation und auf der Website zu IBM DB2.
Parameter anzeigen oder einstellen: Die Optimierungsstufe wird für die einzelnen Datenbanken über die Befehlszeile oder mit dem DB2 Control Center eingestellt. Anweisungen des statischen SQL verwenden die Optimierungsstufe, die in den Befehlen prep und bind festgelegt ist. Ist keine Optimierungsstufe angegeben, verwendet DB2 die Standardoptimierung, die mit dem Parameter dft_queryopt festgelegt ist. Anweisungen des dynamischen SQL verwenden die Optimierungsklasse, die das aktuelle Sonderregister für Abfrageoptimierung festlegt. Dieses wird während der SQL-Anweisung Set gesetzt. Beispielsweise setzt die folgende Anweisung die Optimierungsklasse auf 1:
Set current query optimization = 1
Wurde das aktuelle Abfrageoptimierungsregister nicht gesetzt, werden dynamische Anweisungen mit Hilfe der als Standard definierten Abfrageoptimierungsklasse gebunden.
Standardwert: 5
Empfohlener Wert: Legen Sie die Optimierungsstufe entsprechend den Anforderungen der Anwendung fest. Verwenden Sie hohe Stufen nur bei sehr komplizierten Abfragen.

DB2 reorgchk

Kurzbeschreibung: Die Leistung der SQL-Anweisungen kann nach vielen Aktualisierungen, Lösch- oder Einfügevorgängen beeinträchtigt sein. Sie können die Leistung verbessern, indem Sie die aktuellen Statistiken zu den Daten abrufen und erneut binden.
Parameter anzeigen oder einstellen: Mit dem folgenden DB2-Befehl wird runstats in allen Benutzer- und Systemtabellen für die Datenbank ausgeführt, mit der Sie gerade verbunden sind:

reorgchk update statistics on table all

Binden Sie anschließend die Pakete erneut, indem Sie den Befehl bind ausführen.
Um zu überprüfen, ob runstats ausgeführt wurde, sollte der folgende Befehl unter DB2 CLP ausgeführt werden:
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
Wurde runstats nicht ausgeführt, wird für nleaf und nlevels der Eintrag -1 und für stats_time ein leerer Eintrag "-" angezeigt.

Wurde runstats bereits ausgeführt, wird die Zeitmarke der Echtzeitausführung von runstats unter stats_time angezeigt. Wenn Sie glauben, dass die Zeitmarke der Ausführung von runstats zu alt ist, sollten Sie runstats erneut ausführen.

DB2 MinCommit

Kurzbeschreibung: Mit diesem Parameter kann das Schreiben von Protokolleinträgen auf einen Datenträger so lange verzögert werden, bis eine Mindestanzahl von Commit-Operationen (Festschreibungen) ausgeführt wurde. Auf diese Weise wird der Aufwand für das Schreiben von Protokolleinträgen für den Datenbankmanager reduziert. Ist MinCommit z. B. auf 2 gesetzt, würde eine zweite Commit-Operation bewirken, dass die die Ausgabe für die erste und die zweite Commit-Operation in das Transaktionsprotokoll geschrieben wird. Eine Ausnahme liegt vor, wenn ein Zeitlimit von einer Sekunde bewirkt, dass die erste Commit-Operation ausgegeben wird, falls innerhalb einer Sekunde keine zweite Commit-Operation erfolgt.
Ergebnis: Für Trade EJB_ALT standen 90 % der Plattenein-/-ausgabeoperationen im Zusammenhang mit dem DB2-Transaktionsprotokoll. Durch Änderung des Wertes für MinCommit von 1 in 2 wurde die Anzahl der Plattenein-/-ausgabeoperationen um 50 % reduziert. Wurde MinCommit auf 4 gesetzt, wurde die Anzahl der Plattenein-/-ausgabeoperationen (im Vergleich zu MinCommit 1) auf 33 % gesenkt. Die Prozessorauslastung auf der DB2-Maschine wurde um 35 % reduziert (Anfangsprozentsatz 20 %) und die Plattenein-/-ausgabewartezeit wurde um 50 % verringert (Anfangsprozentsatz 10 %). Für diese spezielle Konfiguration (DB2-Maschine war am Anfang nicht stark ausgelastet) kann festgestellt werden, dass Gesamtdurchsatz und -antwortzeit sich nicht verbesserten.
Empfohlene Anpassung: Dieser Parameter sollte angepasst werden, wenn die Plattenein-/-ausgabewartezeit mehr als 5 % beträgt und das DB2-Transaktionsprotokoll von mehreren Quellen verwendet wird. Wenn eine Vielzahl von Quellen eine Menge von Aktivitäten verursachen, gilt es als wenig wahrscheinlich, dass eine einzelne Commit-Operation auf eine andere Commit-Operation (oder auf das Zeitlimit von einer Sekunde) warten muss. Dieser Parameter sollte nicht angepasst werden, wenn eine Anwendung einen einzelnen Thread verwendet, der eine Reihe von Commit-Operationen ausführt (für jede Commit-Operation würde das Zeitlimit von einer Sekunde gültig).
Parameter anzeigen oder einstellen: Gehen Sie wie folgt vor, um den aktuellen Wert für eine bestimmte Datenbank anzuzeigen:
1. Führen Sie folgenden DB2-Befehl aus: get db cfg for xxxxxx (wobei xxxxxx für den Namen der Anwendungsdatenbank steht). Dieser Befehl zeigt die Konfigurationsparameter für die Datenbank an.
2. Prüfen Sie den Parameter "Group commit count (MINCOMMIT)".
3. Setzen Sie mit folgendem DB2-Befehl einen neuen Wert: update db cfg for xxxxxx using mincommit n (wobei n ein Wert zwischen 1 und 25 ist).
Die neue Einstellung tritt sofort in Kraft.

Nachfolgend sind mehrere Metriken aufgeführt, die mit DB2 MinCommit zusammenhängen:
1. Die Plattenein-/-ausgabewartezeit kann unter AIX mit dem Befehl vmstat 5 angezeigt werden. Der Befehl zeigt alle 5 Sekunden Statistiken an. Prüfen Sie die Spalte wa unter dem CPU-Bereich (CPU area).
2. Der Prozentsatz an Zeit, während der eine Platte aktiv ist, kann unter AIX mit dem Befehl iostat 5 angezeigt werden. Dieser Befehl zeigt alle 5 Sekunden Statistiken an. Prüfen Sie die Spalte %tm_act.
3. Der DB2-Befehl get snapshot for db on xxxxxx (in dem xxxxxx für den Namen der Anwendungsdatenbank steht) zeigt die Zähler für die Lese- und Schreiboperationen der Protokollseiten.
Standardwert: Der Standardwert ist 1.
Empfohlener Wert: MinCommit sollte auf 1 oder (falls die Umstände dies erlauben) auf 2 gesetzt werden.

Sitzungsverwaltung

Zusätzliche Informationen zum Festlegen von Parametern für die Sitzungsverwaltung finden Sie im InfoCenter-Artikel 4.4.1.1Programmierungsmodell und Umgebung für Sitzungen.

WebSphere Application Server Enterprise Extensions Message Listener

WebSphere Application Server Enterprise Extensions bietet Unterstützung für Extended Messaging Support. Dieser Abschnitt enthält Empfehlungen zur Optimierung der JMS-Listener-Funktion, die Teil von Extended Messaging Support ist.

Parameter "Maximum Sessions" (maximale Anzahl Sitzungen)

Kurzbeschreibung: Dieser Parameter zeigt die maximale Anzahl gleichzeitiger Nachrichten-Bean-Instanzen an, die verfügbar sind, um jeweils eine Nachricht auf einmal zu verarbeiten.
Empfohlene Anpassung: Sind viele Nachrichten zur Verarbeitung vorhanden und ist der Nachrichtendurchsatz sehr niedrig (d. h. die Anzahl Nachrichten, die pro Minute verarbeitet werden), dann sollte dieser Parameter angepasst werden, um einen optimalen Durchsatz zu erzielen.
Ergebnis: Durch Änderung des Parameters vom Standardwert in den empfohlenen Wert wurde eine Verbesserung um 35 % erzielt. Die Daten zu Arbeitslast/Konfiguration sind wie folgt:
- Nachrichtengröße = 10 Bytes; permanente Nachrichten; 1 Anwendungsserver empfängt Anforderungen an 1 Warteschlange
- Systemkonfiguration = Netfinity 700 MHz; 4-Wege; 4 GB RAM
Parameter anzeigen oder einstellen: Dieser Parameter wird in der XML-Datei jmsconfig.xml gesetzt, die im Verzeichnis %WAS_HOME%\config enthalten ist. Der aktuelle Wert wird wie folgt festgelegt:
<MaxSessions> x <MaxSessions> (wobei x der Wert für die Anzahl Sitzungen ist)
Wird dieser Wert geändert, sollte der Anwendungsserver erneut gestartet werden, damit die Änderung wirksam wird.
Die Verwendung dieses Parameters wird angezeigt, wenn die Trace für die Komponente cmm aktiviert wird.
Standardwert: Der Standardwert für WebSphere Application Server Enterprise Extensions 4.0.1 ist 5.
Empfohlener Wert: Der empfohlene Wert liegt zwischen 1 und 20.
Der Wert 1 sollte dann verwendet werden, wenn die Nachrichten seriell verarbeitet werden sollen, d. h., nur eine Nachrichten-Bean-Instanz wird verwendet, um die Nachrichten nacheinander zu verarbeiten.

Der Wert 20 liefert den besten Durchsatz. Eine weitere Erhöhung des Werts ergibt keinen besseren Durchsatz. Basierend auf der Art der Nachrichten, der Menge der Arbeit und den verfügbaren Ressourcen, sollte ein Wert zwischen 10 und 20 verwendet werden, um einen maximalen Nachrichtendurchsatz zu erzielen.

Mehrere Anwendungsserver empfangen Anforderungen an derselben Warteschlange

Kurzbeschreibung: Hierbei verwenden vertikal geklonte WebSphere Application Server dieselben Warteschlangen eines einzelnen Warteschlangenmanagers, um den Nachrichtendurchsatz zu erhöhen sowie zum Zweck der Ausfallsicherheit.
Eine Erhöhung des Nachrichtendurchsatzes ist abhängig von verschiedenen Faktoren wie Systemressourcen und Listener-Konfiguration. Der Faktor der Systemressourcen bezieht sich auf die Anzahl und Leistung der Prozessoren. Der Faktor der Listener-Konfiguration bezieht sich auf die Anzahl Sitzungen, die verwendet wird, und auf die JMS-Interaktionen. Die JMS-Interaktionen beinhalten die Konkurrenzsituation, die sich durch den gemeinsamen Zugriff auf die zugrunde liegenden MQ-Server-Managerressourcen ergibt.
Empfohlene Anpassung: Dieser Parameter sollte in folgenden Situationen verwendet werden:
1. wenn ein besserer Nachrichtendurchsatz erforderlich ist
2. wenn ein ausfallsicherer Modus erforderlich ist, um die Nachrichten aus einer Warteschlange abzurufen
Parameter anzeigen oder einstellen: Reicht von einem einzelnen System mit geklonten Servern bis zu WebSphere Application Server, die in großem Umfang geklont wurden und mit MQSeries-Warteschlangenmanagern in Cluster zusammengefasst wurden.
Standardwert: Standardmäßig wird ein einzelner Anwendungsserver-Listener für eine einzelne Warteschlange verwendet.
Empfohlener Wert: Falls genügend Systemressource verfügbar sind, kann der Nachrichtendurchsatz erhöht werden, indem mehrere Anwendungsserver eine einzige Warteschlange gemeinsam verwenden. Bei eingeschränkten Systemressourcen liefern ein einzelner Server und Listener einen besseren Nachrichtendurchsatz.

Zusätzliche Referenzinformationen

WebSphere Application Server Development Best Practices for Performance and Scalability: Diese Dokumentation beschreibt die Entwicklung der am besten geeigneten Methoden für Webanwendungen, die Servlets, JSP-Dateien und JDBC-Verbindungen enthalten und für Unternehmensanwendungen, die Enterprise-Bean-Komponenten enthalten.
Dokumente zur iSeries-Leistung, einschließlich Informationen zur Leistung des WebSphere Application Server 4.0 für iSeries und Links zum PTDV Tool, Workload Estimator Tool und anderen Dokumenten.
Redbook: WebSphere Application Server V3.5 Handbook (SG24-6161-00)
Redbook: WebSphere Application Server V3 Performance Tuning Guide (SG24-5657-00)

Prozeduren von Leistungsanalyse-Tools

Systemmonitor unter Windows NT/2000 starten

Führen Sie folgende Schritte aus:
Wählen Sie im Menü Start die Optionen Programme > Verwaltung > Systemmonitor aus.