![[z/OS]](../images/ngzos.gif)
Leistungshinweise für optimierte lokale Adapter
Wenn Sie die APIs für optimierte lokale Adapter von WebSphere Application Server for z/OS verwenden, gibt es verschiedene Bereiche, die bezüglich der Leistung berücksichtigt werden müssen.
Die APIs für optimierte lokale Adapter sind so konzipiert, dass sie eine optimale Leistung für Aufrufe zwischen einem externen Adressraum und Anwendungen in WebSphere Application Server for z/OS bieten und neue Arten von Anwendungsmustern einrichten, die differenziertere Interaktionen zwischen Anwendungen in diesen Umgebungen unterstützen. In den folgenden Informationen werden Aspekte beschrieben, die bezüglich der optimierten lokalen Adapter und der Leistung berücksichtigt werden müssen. Diese Inhalte sollen Ihnen das Verständnis der Konfigurationsoptionen für die Verwendung optimierter lokaler Adapter erleichtern, um so die beste Leistung zu erzielen. Die Benchmark-Ergebnisse von Vergleichen optimierter lokaler Adapter mit anderen Technologien für synchrone Aufrufe zwischen WebSphere Application Server und externen Adressräumen auf demselben System (z. B. SOAP over HTTP) sind hier nicht dokumentiert. Diesbezügliche Informationen finden Sie in der Veröffentlichung "WebSphere Application Server for z/OS Performance Report".
Auswahl der Mindestanzahl und Maximalanzahl an Verbindungen für Aufrufe der API "Registrieren"
Die Auswahl eines zu hohen Wert für die Mindestanzahl an Verbindungen im Aufruf der API "Registrieren" wird nicht empfohlen und kann sich negativ auf die Leistung auswirken. Beim Aufruf der API "Registrieren" wird ein Aufruf vom externen Adressraum an die Steuerregion von WebSphere Application Server abgesetzt, um jede einzelne Verbindung einzurichten und dem Verbindungspool der optimierten lokalen Adapter hinzuzufügen. Wenn diese Verbindungen mit einem Server aufgebaut sind, bleiben die Verbindungen so lange aktiv, bis ein Aufruf der API "Unregister" (Registrierung aufheben) empfangen wird, woraufhin WOLA die Verbindungen zum Server trennt und die Verbindungen aus dem Pool verfügbarer Verbindungen entfernt. Die Festlegung eines zu hohen Mindestwerts führt zu einem höheren Speicherverbrauch und höheren Pfadlängenkosten für die APIs "Registrieren" und "Registrierung zurücknehmen". Wählen Sie einen Wert für die Mindestanzahl an Verbindungen aus, der sich für die Anforderungen am besten eignet. Wenn erwartet wird, dass sich Hunderte gleichzeitiger Threads eine Registrierung teilen, macht es Sinn, die Kosten für die Verbindungen während der Registrierung in Kauf zu nehmen. Ist die erwartete Anzahl gleichzeitiger Threads, die sich eine Registrierung teilen, jedoch geringer, wird empfohlen, einen niedrigeren Wert für die Mindestanzahl an Verbindungen festzulegen.
Der Parameter für die maximale Anzahl an Verbindungen in der API "Registrieren" ist ein Grenzwert für die Anzahl an Verbindungen im Verbindungspool der optimierten lokalen Adapter für eine Registrierung. Dieser Wert kann für die Dauer der Registrierung nicht erhöht werden. Sobald die Anzahl gleichzeitiger Anforderungen zum Abrufen einer Verbindung diesen Wert überschreitet, wartet der aufrufende Thread die mit dem Parameter für die Wartezeit in der API "Verbindung abrufen", "Aufrufen", "Anforderungen in jeder Verbindung empfangen" bzw. "Hostservice" festgelegte Anzahl an Sekunden ab, ob eine Verbindung verfügbar wird. Nach Ablauf dieses Zeitlimits werden ein Rückkehrcode und ein Ursachencode zurückgegeben, die anzeigen, dass bis zum Ablauf der Wartezeit keine Verbindungskennung für die Anforderung abgerufen werden konnte. Die maximale Größe des Verbindungspools für eine einzelne Registrierung kann festgelegt werden. Dieser Wert wird von der zellenweiten Umgebungsvariablen "WAS_DAEMON_ONLY_adapter_max_conn" abgeleitet. Der vordefinierte Standardwert für diese Variable ist 100. Der Wert kann in der Administrationskonsole geändert werden. Sie müssen den Dämon erneut starten, nachdem die Einstellung geändert wurde.
Auswirkungen der Einstellungen für die Mindest- und Maximalanzahl an Verbindungen auf den CICS-Link-Server für die optimierten lokalen Adapter
Wenn eine Link-Server-Task unter Customer Information Control System (CICS) mit BBOC START_SRVR gestartet wird und die Parameter für die Mindestanzahl an Verbindungen (MNC) und die maximale Anzahl an Verbindungen (MXC) nicht übergeben werden, wird für die MNC-Registrierungseinstellung standardmäßig 1 und für die MXC-Einstellung standardmäßig 10 verwendet. Das bedeutet, dass die Anzahl der Link-Aufruftasks (BBO#-Tasks), die gleichzeitig von der startenden Link-Server-Task (BBO$) gestartet und ausgeführt werden können, 10 ist. Dieser Wert lässt sich in die Anzahl gleichzeitiger Threads von WebSphere Application Server übersetzen, die CICS-Zielprogramme ausführen und starten können. Die Einstellung für den Parameter MXC des Link-Servers muss die erwartete Dauer der typischen CICS-Zielprogramme widerspiegeln, die erwartungsgemäß unter dieser Instanz des Link-Servers gestartet werden. Wenn es sich bei den CICS-Zielprogrammen hauptsächlich um Programme mit langer Laufzeit handelt, ist ein höherer MXC-Wert angemessen, damit die Anforderungen effizient von WebSphere Application Server an CICS übertragen werden können. Wenn die Zielprogramme eine kurze Laufzeit haben, ist eine niedrigere MXC-Einstellung effizienter.
Bei der Bestimmung der richtigen MXC-Einstellung muss auch berücksichtigt werden, wie viele Servant-Regionen von WebSphere Application Server mit einem Link-Server über einen bestimmten Registrierungsnamen kommunizieren. Wenn es nur eine einzige Servant-Region gibt und diese mit der Einstellung ISOLATE für die Threading-Option ausgeführt wird, kann nur jeweils ein einziger Thread Anforderungen an CICS in diesem Servant senden, d. h., Sie setzen den MXC-Wert auf die Anzahl der Servants mal 1, um sicherzustellen, dass keine Engpässe auftreten. Wenn die Region mit der Threading-Einstellung LONGWAIT ausgeführt wird, bei der bis zu 40 Threads pro Servant aktiv sein können, muss der Parameter MXC in Abhängigkeit von der erwarteten Anzahl an Anforderungen und den Typen der aufgerufenen CICS-Programme (lange oder kurze Laufzeit) entsprechend der erwarteten Anzahl gleichzeitiger Anforderungen über die Servants an den Link-Server unter einem bestimmten Registrierungsnamen gesetzt werden. Möglicherweise müssen Sie ein bisschen experimentieren, um die optimale MXC-Einstellung zu finden. Beginnen Sie mit einer niedrigeren Zahl, und erhöhen Sie diese dann nach und nach. Verwenden Sie dann den Wert, bei dem der Durchsatz am besten ist.
Gemeinsam genutzter 64-Bit-Speicher
Die Unterstützung optimierter lokaler Adapter setzt voraus, dass der Server von WebSphere Application Server for z/OS im 64-Bit-Modus ausgeführt wird. Wenn die Dämongruppe zum ersten Mal gestartet wird und die Variable "WAS_DAEMON_ONLY_enable_adapter" auf true oder 1 gesetzt ist, ordnet WebSphere Application Server einen gemeinsam genutzten Speicherpuffer im Speicher oberhalb der 64-Bit-Grenze zu und initialisiert diesen. Die Standardgröße dieses Bereichs sind 32 MB. In diesem Bereich befinden sich alle gemeinsam genutzten Steuerstrukturen für die optimierten lokalen Adapter. In diesem Bereich werden keine Nachrichtendaten zwischengespeichert. Nachrichten- und Kontextdaten werden zwischen externen Adressräumen und Servant-Regionen von WebSphere Application Server über eine lokale adressraumübergreifende Kommunikationstechnologie von WebSphere Application Server for z/OS übertragen, die Nachrichtendaten im Adressraum des Servers zwischenspeichert. Für größere Nachrichten ist dies im Speicher oberhalb der 64-Bit-Grenze. Derzeit unterstützt die lokale Kommunikation von WebSphere Application Server eine maximale Nachrichtengröße von 2 GB, und in der anfänglichen Unterstützung optimierter lokaler Adapter ist dies die größte unterstützte Größe für eine einzelne Nachricht.
F <Servername>,DISPLAY,ADAPTER,REGISTRATIONS
Anhand der Ausgabe des Befehls "Display"
sollten Sie den Job bestimmen können, der den Speicher belegt und die Registrierungen nicht freigibt,
und das Problem durch einen Neustart beheben können.Wenn durch die Analyse festgestellt wird, dass die standardmäßig zugeordneten 32 MB nicht ausreichen, um die Anforderungen der Dämongruppe zu erfüllen, kann dieser Wert mit der zellenweiten Umgebungsvariablen "WAS_DAEMON_ONLY_adapter_max_shrmem" geändert werden. Ändern Sie diesen Wert nur nach sorgfältiger Überlegung. Eine Änderung des Werts erfordert eine Neuerstellung der des Speicherpuffers für die optimierten lokalen Adapter, und dies kann nur über ein einleitendes Programmladen des Systems realisiert werden.
Sie können den benötigen Speicher grob schätzen. Jede Clientregistrierung belegt 392 Bytes des gemeinsam genutzten Speichers. Hinzukommen 112 Bytes des gemeinsam genutzten Speichers für jede Verbindung. Eine Registrierung mit maximal 100 Verbindungen belegt somit ungefähr 12 KB des gemeinsam genutzten Speichers. Jeder Client-Thread, der auf die Verfügbarkeit einer Verbindung warten muss (wenn alle Verbindungen im Gebrauch sind), belegt zusätzliche 80 Bytes. Jeder Service, der von der Registrierung ausgeführt wird, belegt weitere 336 Bytes.
200 Registrierungen x 392 Bytes=78.400 Bytes
200 Registrierungen x 200 Verbindungen x 112 Bytes=4.480.000 Bytes
200 Registrierungen x 1000 wartende Threads x 80 Bytes= + 16.000.000 Bytes
--------------------------------
20.558.400 Bytes
33.554.432 Bytes – 20.558.400 Bytes=12.996.032 Bytes verbleibend
/ 336 Bytes pro Service
----------------------------------
38.678 Services
Wenn Sie die Größe des gemeinsam genutzten Speichers erhöhen oder verringern,
müssen Sie daran denken, dass gemeinsam genutzter Speicher oberhalb der 64-Byte-Grenze
in 1-MB-Abschnitten zugeordnet wird. WebSphere Application Server rundet den angegebenen Wert auf die nächste
ganze MB-Zahl auf. Maximale Anzahl gleichzeitiger abgehender Aufrufe von WebSphere Application Server steuern
Es gibt eine dämonweiter Standardeinstellung, die die maximale Anzahl gleichzeitiger abgehender Aufrufe von WebSphere Application Server für eine einzelne Registrierung steuert, die mit optimierten lokalen Adaptern unterstützt wird. Die Variable für diese Steuerung ist "WAS_DAEMON_ONLY_adapter_max_serv". Der Standardwert ist 100.Dieser Wert bedeutet, dass maximal 100 unterschiedliche Zielservices unter einer einzelnen Registrierung ausgeführt werden können (gleichzeitige Aufrufe der APIs "Hostservice", "Anforderungen in jeder Verbindung empfangen" oder "Anforderungen in einer bestimmten Verbindung empfangen"). Wenn Sie diesen Wert ändern, muss der Dämon erneut gestartet werden.
Beim Standardwert 100 führen alle Versuche, einen Thread für den 101. Server für einen bestimmten Registrierungsnamen über eine der drei APIs für diesen Zweck einzurichten, zu einem Rückkehrcode und einem Ursachencode ungleich null, die darauf hinweisen, dass der Wert von "adapter_max_serv" erreicht ist. Wenn eine Anwendung in WebSphere Application Server diesen Service sucht und dieser nicht sofort verfügbar ist, wartet die Anwendung standardmäßig 30 Sekunden, bevor eine Ausnahme empfangen wird, die darauf hinweist, dass das Zeitlimit beim Warten auf den angeforderten Service überschritten wurde. Im Servant-Protokoll von WebSphere Application Server wird diese Ausnahme mit dem Nebencode C9C24C15 aufgezeichnet. Der Standardwert von 30 (Sekunden) für dieses Zeitlimit kann über die Anwendung mit der Methode "setConnectionWaitTimeout()" in der JCA-Schnittstelle "ConnectionSpecImpl" geändert werden.
Leistungshinweise für den CICS-Link-Server für optimierte lokale Adapter
Die Unterstützung optimierter lokaler Adapter für den CICS-Link-Server kann verwendet werden, um eine einfache Methode für den Aufruf vorhandener CICS-Anwendungsprogramme in Anwendungen bereitzustellen, die in WebSphere Application Server for z/OS ausgeführt werden. Wenn Sie den Link-Server über die BBOC-Transaktion oder das CICS-PLTPI-Programm BBOACPL2 starten, wird die Link-Server-Task für optimierte lokale Adapter (BBO$) gestartet, die Program-Link-Anforderungen von WebSphere Application Server empfängt. Anschließend wird die Program-Link-Task (BBO#) eingeleitet, die wiederum einen Aufruf "EXEC CICS LINK" an das Zielprogramm absetzt, die Antwort empfängt und die Antwort an den Aufrufenden in WebSphere Application Server zurücksendet. Teil dieser Unterstützung ist die Weitergabe und Zusicherung der Anwendungsthreadidentität von WebSphere Application Server an die CICS-Zieltask. Die Weitergabe und Zusicherung der Identität wird mit dem Parameter "SEC=Y" im Befehl "BBOC START_SRVR" angefordert.
Wenn Sie einen Link-Server mit SEC=N ausführen und die Identität der Benutzer-ID verwenden, die den Link-Server gestartet hat, erzielen Sie zwar eine bessere Leistung, aber diese Vorgehensweise entspricht möglicherweise nicht den Sicherheits- und Prüfanforderungen Ihrer Organisation.
Die Ausführung mit der Option "REU=Y" bedeutet, dass gestartete Program-Link-Tasks (BBO#s) aktiv bleiben, bis ein Befehl "BBOC STOP_SRVR" oder "BBOC UNREGISTER" für die Registrierung eingegeben wird. Wenn Sie für die Ausführung einen hohen MXC-Wert im Befehl "BBOC START_SRVR" angeben und eine hohe Anzahl an Anforderungen gleichzeitig eingeht, kann es zu einer hohen Anzahl an BBO#-Tasks kommen, die erst beendet werden, wenn der Link-Server gestoppt wird. Dies ist ein weiterer Aspekt, den Sie berücksichtigen müssen, wenn Sie entscheiden, ob "REU=Y" verwendet werden soll und welcher Wert ein angemessener MXC-Wert ist.
Wenn Sie sich zum Ziel gesetzt haben, die beste Leistung für Aufrufe in einer Anwendung unter CICS über WebSphere Application Server zu erreichen, sollten Sie die APIs "Hostservice" (BBOA1SRV), "Anforderungen in jeder Verbindung empfangen" (BBOA1RCA) und "Anforderungen in einer bestimmten Verbindung empfangen" (BBOA1RCS) direkt in Ihrem Anwendungsprogramm codieren. In diesem Fall gibt es keine integrierte Unterstützung für die Weitergabe von Identitäten, wie sie der Link-Server bereitstellt, aber wenn dies nicht erforderlich ist und die Leistung die obere Priorität ist, kann die direkte Verwendung der APIs die beste Option sein.
JCA-Hinweise
Wenn Sie den JCA-Ressourcenadapter für optimierte lokale Adapter verwenden, müssen Sie den zusätzlichen Aufwand für jede vom ConnectionFactory-Objekt abgerufene Verbindung berücksichtigen. Wenn Ihre Anwendung mehrere Aufrufe an einen externen Adressraum oder an CICS in derselben Anwendungsmethode absetzen muss, bietet die Verwendung derselben Verbindung für jede Interaktion eine bessere Leistung als das Abrufen einer separaten Verbindung für jede einzelne Interaktion. Außerdem kann ein JCA-Interaktionsobjekt wiederholt in derselben Anwendungsmethode verwendet werden.
Wenn Sie das JCA-ConnectionFactory-Objekt für optimierte lokale Adapter erstellen, können Sie die Mindest- und Maximalgrößen des JCA-Verbindungspools für dieses ConnectionFactory-Objekt ändern. Dieser Verbindungspool stellt logische Verbindungen dar, die während einer Interaktion an physische Verbindungen (die im BBOA1REG-Registrierungsaufruf angegeben sind) gebunden werden. Um eine optimale Leistung zu erzielen, muss die Größe des JCA-Verbindungspools mit der Größe des Pools physischer Verbindungen, die während des BBOA1REG-Aufrufs gesetzt wird, identisch sein. Wenn Ihr JCA-Verbindungspool zu klein ist, muss Ihre Anwendung möglicherweise auf ein JCA-Verbindungsobjekt warten, selbst wenn physische Verbindungen verfügbar sind. Ihr physischer Verbindungspool wird von allen Servant-Regionen gemeinsam genutzt. Wenn Sie also mehrere Servant-Regionen haben, können Sie die Größe des JCA-Verbindungspools für jede Servant-Region verringern, um die Gesamtanzahl der JCA-Verbindungen für alle Servant-Regionen an die Größe des physischen Verbindungspools anzupassen.