![[z/OS]](../images/ngzos.gif)
MDB-Verarbeitung unter z/OS mithilfe von IBM MQ als Messaging-Provider im ASF-Modus optimieren
Sie können die MDB-Verarbeitung (Message-driven Beans) optimieren, wenn Sie mit WebSphere Application Server auf der Plattform z/OS arbeiten, IBM MQ der Messaging-Provider ist und die MDB im ASF-Modus (Application Server Facilities) implementiert wurde.
Vorbereitende Schritte
Zum Optimieren der MDB-Verarbeitung müssen Sie zahlreiche Einstellungen zusammen berücksichtigen. Aufgrund der Vielzahl möglicherweise Workloads für jeden Server sind zahlreiche verschiedene Werte und Möglichkeiten zu berücksichtigen.
Wenn eine MDB einer Warteschlange zugeordnet ist (d. h. diese Warteschlange überwacht) oder über eine permanente Subskription einem Topic zugeordnet ist, geht eine JMS-Nachricht zuerst in den Anwendungsserver im Controller ein, d. h., dass der Server "diese Nachrichten im Controller überwacht". Der Begriff der "Überwachung im Controller" wird in der gesamten Beschreibung der Anpassung der MDB-Verarbeitung verwendet.
Informationen zu diesem Vorgang
Wenn Sie die MDB-Verarbeitung im Server optimieren, müssen Sie auch die Optimierung der gesamten Workload für den Server und die Interaktion zwischen MDB und Server berücksichtigen.
- WLM-Serviceklassendefinitionen
- Auswahl des Auslastungsprofils von WebSphere Application Server
- Einstellungen für den des Listener-Port des Nachrichten-Listener-Service
- Einstellungen für das Pooling der JMS-Verbindungsfactory
- Einstellungen für den IBM MQ-Warteschlangenmanager
- Anzahl der MDBs
- Optionen für die Verwaltungskonfiguration, z. B. ob zwei MDBs denselben oder unterschiedlichen Listener-Ports zugeordnet werden sollen
- Bedeutung der Anforderungen für MDBs in Relation zu anderen (HTTP, IIOP) Anforderungstypen, die im Server bearbeitet werden.
Die im Folgenden vorgeschlagenen Einstellungen sind ein Ausgangspunkt, vorausgesetzt, dass im Server eine einzige Anwendung konfiguriert ist, die eine einzige MDB enthält, die in diesem Server installiert und ausgeführt wird.
Es folgen ausführlichere Beschreibungen, die die Gründe für die vorgeschlagenen Einstellungen und die Funktion von Listener-Ports "im Controller" unter z/OS ausführlicher erläutern. Die Beschreibungen unterstützen Sie bei der Auswahl eigener Einstellungen für Ihre Systeme und Server.
Vorgehensweise
Beispiel
- Wenn die Eigenschaft Maximale Anzahl der Serverinstanzen für Ihren Server auf den Wert
3 (die Mindestanzahl ist hier nicht von Bedeutung) und Ihre Auslastungsprofil auf
LONGWAIT (d. h., jeder Servant enthält 40 Worker-Threads) gesetzt ist,
setzen Sie die Eigenschaft Maximale Anzahl an Sitzungen für Ihren Listener-Port auf mindestens
.240 = 2 * 3 * 40
- Angenommen, Ihre Anwendung enthält zwei MDBs, die jeweils eine Implementierung der Methode
onMessage() haben, die die Nachricht an ein anderes JMS-Ziel weiterleitet.
In diesem Fall benötigt jede MDB eine eigene JMS-Verbindungsfactory für diese Task. Angenommen, der
Administrator hat jede Ressourcenreferenz der MDB-JMS-Verbindungsfactory
derselben administrativ definierten Verbindungsfactory zugeordnet, die von dem Listener-Port verwendet wird,
dem jede dieser MDBs zugeordnet ist.
In diesem Fall müssen Sie die Eigenschaft für die maximale Anzahl der Verbindungen für den Verbindungspool der Verbindungsfactory auf 42 setzen (jeweils eine Verbindung für jede der beiden MDBs, die der Listener-Port verwenden soll, und potenziell eine Verbindung für jede der 40 onMessage()-Zuteilungen, die gleichzeitig ausgeführt werden können). (Denken Sie daran, dass der Verbindungspool Servant-bezogen ist.)
- Setzen Sie die maximale Anzahl der Verbindungen für den Sitzungspool der Verbindungsfactory auf 40 (die Anzahl der Worker-Threads in einem Servant, unabhängig von der Anzahl der Servants).
Debugging-Tipps finden Sie im Artikel Unterstütung der MDB-Regulierung für Debugging in z/OS optimieren.