Optimierung des EJB-Containers
Wenn Sie Anwendungen verwenden, die sich auf die Größe des EJB-Container-Cache auswirken, kann sich eine falsche Größeneinstellung auf die Leistung der Anwendungen auswirken. Die über Container realisierte Transaktionspersistenz (CMP) wird in diesem Artikel erläutert. Es ist aber wichtig, zu wissen, dass Entity-Beans in einem Modul der EJB Version 3.x nicht unterstützt werden.
Größe des EJB-Cache
Die Überwachung von Tivoli Performance Viewer (TPV) ist eine äußerst hilfreiche Methode, mit der Sie feststellen können, ob die Größe für den EJB-Container-Cache optimal für Ihre Anwendung eingestellt ist.
Wenn die Anwendung den Cache ausfüllt und damit Einträge aus dem Cache gelöscht werden müssen, zeigt Tivoli Performance Viewer eine hohe Anzahl an ejbStores()-Aufrufen und eine wahrscheinlich niedrigere Prozessorauslastung auf der Workstationmaschine an als erwartet.
EJB-Cachegröße = (höchste Anzahl der in einer Transaktion registrierten Entity-Beans der
Option B oder C * maximale Anzahl paralleler Transaktionen) +
(höchste Anzahl eindeutiger Entity-Beans der Option A, auf die nach Einschätzung
bei typischer Auslastung der Anwendung zugegriffen wird) +
(Anzahl der bei typischer Auslastung aktiven Stateful-Session-Beans) +
(Anzahl der bei typischer Auslastung verwendeten Stateless-Session-Beans)
Für diese Angaben gilt Folgendes: Entity-Beans der Option B und C werden nur für die Dauer der Transaktion, in der sie
registriert sind, im EJB-Cache gespeichert. Der erste Teil der Formel berechnet
deshalb die durchschnittlichen Anforderungen an den EJB-Cache für diese Art von Beans.
Entity-Beans der Option A werden unbegrenzt im EJB-Cache gespeichert und nur dann
aus dem Cache entfernt, wenn die Anzahl der im Cache zu speichernden Beans die
definierte Cachegröße übersteigt.
Wenn Ihre Anwendung schreibgeschützte Beans verwendet, behandeln Sie sie im Rahmen
dieser Leistungsberechnung als Beans der Option A.
Stateful-Session-Beans werden so lange im EJB-Cache gespeichert, bis sie von
der Anwendung entfernt werden oder sie ihr Sitzungszeitlimit erreichen.
Für jeden EJB-Typ wird nur eine Stateless-Session-Bean-Instanz im Cache gespeichert,
während die Methoden für diese Stateless-Session-Bean ausgeführt werden.
Wenn zwei oder mehr Methoden gleichzeitig für denselben Stateless-Session-Bean-Typ
implementiert werden, hat jede Methode eine eigene Bean-Instanz, aber es wird für
alle Instanzen nur eine Cacheposition verwendet.
Diese Formel berechnet den oberen Grenzwert für die maximal mögliche Anzahl von Enterprise-Beans, die im Anwendungsserver gleichzeitig aktiv sein können. Da der Cache des EJB-Containers im Hinblick auf die Leistung so erstellt wird, dass alle Beans Platz haben, wird die beste Leistung erzielt, wenn für die Cachegröße ein höherer Wert als das mit der obigen Formel errechnete Ergebnis definiert wird.
Sie können die Größe des EJB-Cache in der Administrationskonsole unter
festlegen.Während Sie die EJB-Cachegröße anpassen, können Sie auch den Parameter "Verwaltungsthread für EJB-Container" für die Anforderungen Ihrer Anwendung optimieren. Der Verwaltungsthread wird von der Einstellung Bereinigungsintervall gesteuert. Diese Einstellung definiert, wie oft ein Dämonthread in Application Server aktiviert wird, um Bean-Instanzen aus dem Cache zu entfernen, die in der letzten Zeit nicht mehr verwendet wurden, und damit die Anzahl der Bean-Instanzen stets unterhalb des Wertes für die Cachegröße zu halten. Auf diese Weise ist der EJB-Container in der Lage, Einträge schnell im Cache zu speichern und dort zu suchen. Übernehmen Sie die Standardeinstellung für dieses Intervall. In einigen Situationen kann jedoch die Wahl eines kürzeren Intervalls von Vorteil sein.
Informationen zum Optimieren des EJB-Cache mit dem EJB-Cache-Trace-Service finden Sie im Artikel zur Optimierung des Caches und zur Verwendung des Trace-Service.
Optimierung von EJB-Stateful-Session-Beans
Das Zeitlimit für Stateful-Session-Beans wird je nach Version von WebSphere Application Server auf verschiedene Arten und mit verschiedenen Geltungsbereichen konfiguriert.
WebSphere Application Server Version 6.1 und früher unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi.
WebSphere Application Server Version 7.0 unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi für (EJB-2.x-Module) und in der Datei ibm-ejb-jar-ext.xml (für EJB-3.x-Module).
WebSphere Application Server Version 8.x unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi (für EJB-2.x-Module) und in der Datei ibm-ejb-jar-ext.xml (für EJB-3.x-Module) sowie des XML-Elements "stateful-timeout" und der Annotation "@StatefulTimeout". Außerdem können Sie mit der Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout" einen serverweiten (globalen) Zeitlimitwert für Stateful-Session-Beans konfigurieren.

Ein Modul von Java EE Version 5 oder einer höheren Version kann jedoch in einer Anwendung, die Dateien einer älteren Java EE-Version als Version 5 enthält, koexistieren.
Die Dateien ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi und ibm-portlet-ext.xmi können die Dateierweiterung ".xmi" weiterhin verwenden.
sptcfgStateless-Session-Beans haben keinen Zeitlimitwert, weil sie keinen Dialogstatus haben und keinem bestimmten Client zugeordnet sind.
Sie können Rational Application Developer verwenden, um die Datei ibm-ejb-jar-ext.xmi zu aktualisieren, in der der Zeitlimitwert für statusabhängige Sitzungen für Beans in einem EJB-2.x-Modul konfiguriert wird. Weitere Informationen finden Sie in den Artikeln zum Definieren von Sitzungszeitlimiteinstellungen für eine Bean im Information Center von Rational Application Developer Information.
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
timeout="15">
Sie können die Datei ibm-ejb-jar-ext.xml ändern, um das Zeitlimit für statusabhängige Sitzungen für Beans in einem EJB-3.x-Modul festzulegen. Im Folgenden sehen Sie Beispielcode, der den Zeitlimitwert für statusabhängige Sitzungen für die Bean "myBean" auf 15 Minuten setzt:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
timeout="15">
<enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
</ejbExtensions>
Sie können das Zeitlimit für Stateful-Session-Beans mithilfe der Annotation "@StatefulTimeout" konfigurieren. Die Annotation "@StatefulTimeout" akzeptiert einen erforderlichen Parameter mit Wert, der die Länge des Zeitlimits angibt, und einen optionalen Parameter für die Einheit. Wenn der optionale Parameter für die Einheit nicht angegeben wird, wird die die Standardeinheit (Minuten) verwendet. Die Annotation "@StatefulTimeout" wurde in EJB 3.1 eingeführt.
Verwenden Sie beispielsweise die Annotation "@StatefulTimeout", um einen Zeitlimitwert von 100 Sekunden festzulegen:
@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)
Sie können das Zeitlimit für Stateful-Session-Beans mit dem XML-Element "stateful-timeout" im Implementierungsdeskriptor ejb-jar.xml konfigurieren. Das Element "stateful-timeout" wurde in EJB 3.1 eingeführt.
Mit dem folgenden Beispielcode wird der Zeitlimitwert auf 100 Sekunden gesetzt:
<stateful-timeout>
<timeout>100</timeout>
<unit>Seconds</unit>
</stateful-timeout>
Die Annotation "@StatefulTimeout" und das XML-Element "stateful-timeout" sind spezifikationsdefinierte Mechanismen für die Deklaration von Zeitlimitwerten Pro Bean (Einführung in EJB 3.1). Vor EJB 3.1 gab es keine spezifikationsdefinierte Methode für die Deklaration eines Stateful-Session-Bean-Zeitlimits pro Bean. Wenn Sie das XML-Element "stateful-timeout" oder die Annotation "@StatefulTimeout" verwenden, steht der Wert -1 für kein Bean-Zeitlimit, und der Wert 0 bedeutet, dass die Bean sofort entfernt werden kann.
Sie können das Stateful-Session-Bean-Zeitlimit mit der Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout" auf globaler (serverweiter) Basis definieren. Die Zeiteinheit für com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout sind Minuten. Der angegebene Wert muss 0 oder höher sein. Wenn ein ungültiger Wert angegeben wird, wird stattdessen der Standardwert von 10 Minuten verwendet. Der globale Zeitlimitwert kann nicht mit XML oder Annotationen konfiguriert werden. Der globale Zeitlimitwert gilt für alle Stateful-Session-Beans, die im Server ausgeführt werden, einschließlich der Stateful-Session-Beans in Modulen der EJB Versionen 2.x und 3.x.
- XML-Element "stateful-timeout"
- Annotation "@StatefulTimeout"
- ibm-ejb-jar-ext.xml oder ibm-ejb-jar-ext.xmi
- Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout"
- Wenn Sie nicht explizit einen Wert auf Bean- oder Serverebene definieren, wird der Standardzeitlimitwert von 10 Minuten angewendet.
Dcom.ibm.websphere.ejbcontainer.poolSize
Wenn die Anwendung die meisten Bean-Instanzen im Pool verwendet, wird dies von Tivoli Performance Viewer angezeigt. Vergrößern Sie in einem solchen Fall die Bean-Pools, deren Kapazität erschöpft ist, indem Sie den angepassten Eigenschaften der JVM den folgenden Parameter hinzufügen:
-Dcom.ibm.websphere.ejbcontainer.poolSize=<Anwendungsname>#<Modulname>#
<Enterprise-Bean-Name>=<Mindestgröße>,<maximale_Größe>
Für diese Angaben gilt Folgendes:
Das Element <Anwendungsname> steht für den Namen der Java EE-Anwendung, der im Implementierungsdeskriptor der EJB-Datei für die Bean definiert ist, deren Poolgröße definiert wird.
Das Element <Modulname> steht für den Namen der JAR-Datei des EJB-Moduls für die Bean, deren Poolgröße definiert wird.
Das Element <Bean-Name> steht für den Namen der Java EE-Enterprise-Bean, der im Implementierungsdeskriptor des EJB-Moduls für die Bean definiert ist, deren Poolgröße definiert wird.
Das Element <Mindestgröße> steht für die Anzahl der Bean-Instanzen, die der Container im Pool verwaltet, unabhängig davon, wie lange die Beans bereits im Pool vorhanden sind. (Beans, die diesen Wert überschreiten, werden nach und nach aus dem Pool gelöscht, um die Speicherbelegung zu optimieren.)
Das Element <maximale_Größe> gibt die Anzahl der Bean-Instanzen im Pool an, bei deren Erreichen keine weiteren Bean-Instanzen in den Pool aufgenommen werden (d. h. sobald der Pool diese Größe erreicht, werden alle weiteren Beans verworfen und nicht mehr dem Pool hinzugefügt, wodurch sichergestellt wird, dass die Anzahl der Beans im Pool einen oberen Grenzwert hat, damit die Speicherbelegung nicht unbegrenzt zunimmt).
Um die Anzahl der Instanzen im Pool bei einer festen Größe zu halten, können die Elemente "Mindestgröße" und "Maximalgröße" auf denselben Wert gesetzt werden. Es ist ein separater Instanzenpool für jeden aktiven EJB-Typ im Anwendungsserver vorhanden, die zu Beginn jeweils leer sind. Die Anzahl der Instanzen steigt an, wenn Beans verwendet und anschließend in den Pool gestellt werden.
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327
Diese Anweisung definiert eine Mindestgröße von 125
und eine maximale Größe von 1327 Instanzen für die Bean "ivtEJBObject"
in der Datei ivtEJB.jar in der Anwendung "ivtApp". Die Anwendung "ivtApp" wird durch den tatsächlichen Anwendungsnamen ersetzt. Die Datei ivtEJB.jar durch die JAR-Datei ersetzt, die die Bean enthält, deren Poolgröße erhöht werden muss, und "ivtEJBObject" steht für den Bean-Namen der Enterprise-Bean, deren Poolgröße erhöht werden muss. Es werden mindestens 125 Beans im Pool gespeichert. Maximal werden 1327 Beans im Pool gespeichert. Legen Sie diese Werte so fest, dass keine weiteren Beans mehr aus dem Pool gelöscht werden. In den meisten Fällen müssen diese beiden Einstellungen auf denselben Wert gesetzt werden, wenn genügend Speicher verfügbar ist, weil der Pool dann weder vergrößert noch verkleinert wird.
Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation
Sie müssen wissen, wie Ihre Anwendungen die Erstellung von Primärschlüsselobjekten für CMP-Beans und BMP-Beans in Application Server behandeln.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Anwendung primitive Typen für die Primärschlüssel von Enterprise-Beans verwendet, können keine Vorteile erzielt werden, weil diese Objekte bereits unveränderlich sind und der Kopiermechanismus dies berücksichtigt. Wenn die Anwendung jedoch viele komplexe Primärschlüssel verwendet, d. h. ein Objekt für einen Primärschlüssel oder mehrere Felder, können Sie mit diesem Parameter eine signifikante Verbesserung erzielen.
Dcom.ibm.ws.pm.deferredcreate
Der Persistenzmanager wird vom EJB-Container verwendet, um Daten von CMP-Entity-Beans persistent in der Datenbank zu speichern.

-Dcom.ibm.ws.pm.deferredcreate=true
Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Transaktionen der EJB-Anwendung einfügeintensiv sind, kann die Anwendung von dieser Optimierung profitieren. Die Auswirkungen auf die Leistung sind wesentlich geringer, wenn die Anwendung nur sehr wenige Einfügeoperationen durchführt.
Dcom.ibm.ws.pm.batch
Wenn eine EJB-Anwendung in einer einzigen Transaktion auf mehrere CMP-Beans zugreift, entspricht die Anzahl der Operationen, die an die Datenbank abgesetzt werden, je nach Art der für die Beans ausgeführten Operationen (z. B. Aktualisierungs-, Einfüge- und Leseoperationen) direkt den für die CMP-Beans ausgeführten Operationen. Wenn das verwendete Datenbanksystem Stapel von Aktualisierungsanweisungen unterstützt, können Sie dieses Flag aktivieren und damit eine Leistungssteigerung bei allen Interaktionen mit der Datenbank erzielen, die mehr als zwei Aktualisierungen in einer Transaktion beinhalten.

-Dcom.ibm.ws.pm.batch=true
Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Anwendung CMP-Beans nie oder nur sehr selten oder nur eine einzige Bean pro Transaktion aktualisiert, ist mit dieser Optimierung keine Leistungsverbesserung zu erzielen. Falls die Anwendung jedoch mehrere Beans pro Transaktion aktualisiert, ist die Verwendung dieses Parameters von Vorteil für die Leistung Ihrer Anwendungen.
Datenbank | Unterstützt Aktualisierung im Stapelbetrieb | Unterstützt Aktualisierung im Stapelbetrieb mit optimistischer Parallelitätssteuerung |
---|---|---|
DB2 | Ja | Nein |
Oracle | Ja | Nein |
DB2 Universal Driver | Ja | Ja |
Informix | Ja | Ja |
SQLServer | Ja | Ja |
Apache Derby | Ja | Ja |

com.ibm.ws.pm.useLegacyCache
Gibt den Namen der Java-Klasse an, die das Produkt verwendet, um die Schnittstelle javax.rmi.CORBA.UtilDelegate zu implementieren.

com.ibm.ws.pm.useLegacyCache=false
com.ibm.ws.pm.grouppartialupdate und com.ibm.ws.pm.batch
Das Feature für Teilaktualisierungen verbessert in bestimmten Szenarien die Leistung von Anwendungen mit Enterprise-Beans. Der Persistenzmanager unterstützt zwei unterschiedliche Typen von Cachingmechanismen: den traditionellen Cache und den zweistufigen Cache. Normalerweise bietet der zweistufe Cache aufgrund seiner Optimierungen in diesem Modus eine bessere Leistung als der traditionelle Cache.

'com.ibm.ws.pm.grouppartialupdate=true' und 'com.ibm.ws.pm.batch=true'