Die Größe Ihres EJB-Caches (Enterprise JavaBeans) kann sich auf die Leistung des Anwendungsservers auswirken.
Einer der Schritte bei der Optimierung Ihres EJB-Containers in Bezug auf die Leistung ist die
Optimierung des EJB-Caches.
Vorbereitende Schritte
Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server
so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log,
trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung
mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie
mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von
HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
Informationen zu diesem Vorgang
Die folgende Prozedur beschreibt, wie Sie mithilfe des Diagnosetraceservice die am besten
geeignete Cachegröße bestimmen.
Vorgehensweise
- Aktivieren Sie den EJB-Cache-Trace. Informationen zur Arbeit mit dem Traceservice finden Sie im Artikel "Mit Traces arbeiten".
![[IBM i]](../images/iseries.gif)
Informationen zu den Einstellungen des Traceservice finden Sie im Artikel "Einstellungen des Diagnosetraceservice".
Konfigurieren Sie Ihren Trace mit der folgenden Tracezeichenfolge:
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
all=enabled
![[IBM i]](../images/iseries.gif)
Setzen Sie Maximale Dateigröße auf mindestens 200 MB. Wenn
Sie den Standardwert von 20 MBübernehmen, könnte sich dieses einzelne Traceprotokoll mit einer Größe von
20 MB füllen, und es könnten einige Daten aufgrund des Traceumlaufs verloren gehen.
![[IBM i]](../images/iseries.gif)
Setzen Sie die Einstellung Maximale Anzahl der Protokolldateien auf 5.
Fünf Dateien sollten ausreichen, aber wenn Sie feststellen, dass alle fünf Dateien voll sind und ein Traceumlauf stattfindet,
erhöhen Sie diesen Wert.
![[IBM i]](../images/iseries.gif)
Stoppen Sie Ihren Server, löschen Sie die vorhandenen Protokolle, und starten Sie
anschließend den Server.
Stoppen Sie den Server, und starten Sie ihn dann erneut.
- Führen Sie typische Szenarien aus, um Cache-Trace-Daten zu erfassen. Indem Sie
ein typisches Szenario mit aktiviertem Trace ausführen, erhalten Sie die EJB-Cache-Trace-Daten, die in den folgenden
Schritten analysiert werden sollen.
- Prüfen und analysieren Sie die Traceausgabe.
- Öffnen Sie das Traceprotokoll. Prüfen Sie, ob das Protokoll eine oder beide der folgenden
Tracezeichenfolgen enthält:
![[IBM i]](../images/iseries.gif)
BackgroundLru 3 EJB Cache: Sweep (1,40) - Cache limit not reached : 489/2053
BackgroundLru > EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry
Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
ThreadId: 0000006a
FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINEST
ExtendedMessage: EJB Cache: Sweep (23,40) - Cache limit not reached : 0/2053
Trace: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
ThreadId: 0000006d
FunctionName: EJB Cache: Sweep (75,37) - Cache limit exceeded : 3801/2053
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINER
ExtendedMessage: Entry
In den Tracezeichenfolgen, die die Wörter
Cache limit enthalten, finden Sie eine Verhältnisangabe, z. B. 3997/2053. Die erste Zahl ist die Anzahl
der Enterprise-Beans, die derzeit im EJB-Cache gespeichert sind (sie so genannte Kapazität). Die zweite
Zahl ist die EJB-Cacheeinstellung (weitere Informationen hierzu finden Sie in den späteren Schritten).
Sie verwenden dieses Verhältnis, insbesondere die Kapazität, in Ihrer Analyse.
Suchen Sie auch
nach den Nachrichten
Cache limit not reached und
Cache limit exceeded.
- Cache limit not reached
- Ihr Cache ist angemessen groß oder sogar größer. Wenn der Cache größer ist,
verschwenden Sie Hauptspeicher. In diesem Fall sollten Sie die Cachegröße reduzieren und auf einen angemesseneren Wert setzen.
- Cache limit exceeded
- Die Anzahl der derzeit verwendeten Beans ist höher als die angegebene Kapazität. Dies weist darauf hin, dass ihr Cache
nicht optimiert ist. Die Kapazität kann die EJB-Cacheeinstellung überschreiten, weil die Einstellung kein fester Grenzwert
ist. Der EJB-Container hört nicht damit auf, dem Cache Beans hinzuzufügen, wenn der Grenzwert erreicht ist. Das
kann bedeuten, dass eine Anforderung für eine Bean nicht erfüllt wird oder zumindest verzögert wird, wenn
der Cache voll ist, bis die Cacheauslastung unter den Grenzwert fällt. Das Cachelimit kann überschritten werden,
aber der EJB-Container versucht, den Cache zu bereinigen und seine Größe unter die Einstellung für "Größe des EJB-Caches"
zu bringen.
Falls das Cachelimit überschritten wird, kann ein Tracepunkt wie der folgende
angezeigt werden:
![[IBM i]](../images/iseries.gif)
BackgroundLru < EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit
EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053
Beachten Sie die Zeichenfolge
Evicted =. Wenn Sie diese Zeichenfolge sehen, verwenden Sie
Stateful-Session-Beans oder Entity-Beans, die für das Caching der Option A oder der Option B konfiguriert sind.
Bereinigte Objekte bedeuten, dass Sie die ausgewählte Caching-Option nicht vollständig nutzen. Zunächst sollten
Sie versuchen, die Größe des EJB-Caches zu erhöhen.
Falls die Fortsetzung der Anwendungsausführung zu weiteren Bereinigungen führt,
bedeutet dies, dass die Anwendung zwischen den Bereinigungen des EJB-Caches
mehr Beans aufruft bzw. mehr neue Beans
erstellt, als der Cache aufnehmen kann, und dass
KEINE vorhandenen Beans wiederverwendet werden.
Sie sollten Option C für das Caching Ihrer Entity-Beans in Betracht ziehen oder
Ihre Anwendung dahingegen prüfen, ob sie Stateful-Session-Beans nicht entfernt, wenn sie nicht mehr benötigt werden.
Anmerkung: Entity-Beans, die
mit dem Caching der Option C konfiguriert wurden, werden nur im Cache gespeichert, wenn
sie sich in einer Transaktion befinden, und werden dort für die Dauer der gesamten Transaktion gehalten. Deshalb
werden sie während einer Cachebereinigung nicht entfernt, sondern erst dann aus dem Cache entfernt, wenn die Transaktion abgeschlossen ist. Wenn
Sie nur Stateless-Session-Bean und/oder Entity-Beans mit dem Caching der Option C verwenden, können Sie
das Bereinigungsintervall für den EJB-Cache erhöhen.
Informationen zum Festlegen des Bereinigungsintervalls finden Sie in der Beschreibung der Einstellungen für den EJB-Cache.
Stateless-Session-Beans sind NICHT im EJB-Cache enthalten, und da Entity-Beans, für die das Caching der
Option C verwendet wird, von der Caching-Strategie (LRU) nie entfernt werden, besteht keine Notwendigkeit, die Bereinigung häufig
durchzuführen. Wenn Sie nur Stateless-Session-Beans oder nur das Caching der Option C verwenden, sollten
Sie im gezeigten Tracebeispiel nur "Evicted = 0" sehen.
- Analysieren Sie Ihr Traceprotokoll. Suchen Sie die Tracezeichenfolge Cache limit exceeded.
- Möglicherweise finden Sie mehrere Instanzen dieser Zeichenfolge.
Überprüfen Sie alle Instanzen, um den höchsten Kapazitätswerts für die Beans im EJB-Cache zu ermitteln. Definieren
Sie die Größe für den EJB-Cache erneut, und verwenden Sie einen Wert, der 110 % dieser Zahl entspricht.
Die Definition der EJB-Cachegröße wird in einem späteren Schritt erläutert.
- Möglicherweise finden Sie keine Instanzen dieser Zeichenfolge. Das bedeutet, dass
die Kapazität des EJB-Caches nicht überschritten wurde (was Ihr Endziel ist).
Das Fehlen dieser Zeichenfolge während der Erstanalyse könnte aber auch bedeuten, dass eine zu hohe Cachegröße gewählt wurde und
unnötig Hauptspeicher belegt wird. In diesem Fall müssen Sie Ihren Cache optimieren, indem Sie die
Cachegröße so weit reduzieren, dass das Cachelimit nicht überschritten wird, und anschließend auf den optimalen Wert
setzen. Die Definition der EJB-Cachegröße wird in einem späteren Schritt erläutert.
Das Endziel ist, das Cachelimit auf einen Wert zu setzen, bei dem keine Ressourcen verschwendet werden, der aber
auch nicht überschritten wird. Bei einer guten Konfiguration wird als ein Trace ausgegeben, der nur die Nachricht
Cache limit not reached und ein Verhältnis ausweist, bei dem der Kapazitätswert
an die 100 % der EJB-Cacheeinstellung heranreicht.
Anmerkung: Es wird empfohlen, keinen Wert für die Cachegröße festzulegen, der unter dem
Standardwert von 2053 liegt.
- Ändern Sie die Cacheeinstellungen auf der Basis Ihrer Analyse. Diesbezügliche Anweisungen finden Sie in den Informationen zu den Einstellungen für den EJB-Cache.
![[IBM i]](../images/iseries.gif)
Stoppen Sie Ihren Server, löschen Sie alle Protokolle, und starten
Sie Ihren Server erneut.
Stoppen Sie den Server, und starten Sie ihn dann erneut.
- Wiederholen Sie die vorherigen Schritte, bis Sie mit den Einstellungen zufrieden sind.
- Inaktivieren Sie den Trace für den EJB-Cache. Wenn der Cache richtig optimiert ist,
können Sie den Trace entfernen, alte Protokolle entfernen und Ihren Server erneut starten.
Nächste Schritte
Mit Hilfe Ihrer Analyse können Sie den EJB-Cache aus der Perspektive eines EJB-Containers optimal einstellen, aber möglicherweise
nicht aus der Perspektive eines WebSphere Application Server. Ein großer Cache bietet eine höhere Trefferquote
und eine bessere Leistung des EJB-Caches, belegt aber mehr Hauptspeicher. Der vom Cache belegte Hauptspeicher
steht anderen Bereichen des Produkts nicht zur Verfügung, was zu einer Beeinträchtigung der Gesamtleistung führen
kann. In einem System mit genügend Hauptspeicherkapazität stellt dies möglicherweise kein Problem dar, und die Gesamtleistung
kann durch eine richtige Optimierung des EJB-Caches zunehmen.
Sie sollten diesen Aspekt (Systemleistung versus EJB-Cacheleistung) beim Konfigurieren des Caches jedoch berücksichtigen.