Hinweise zur Leistung optimierter lokaler Adapter für Liberty

Die WOLA-APIs (WebSphere Optimized Local Adapter, optimierte lokale WebSphere-Adapter) sind so konzipiert, dass sie eine optimale Leistung für Aufrufe zwischen einem externen Adressraum und Anwendungen in Liberty for z/OS bieten. Die APIs erstellen durch die Unterstützung differenzierter Interaktionen zwischen Anwendungen in diesen Umgebungen neue Arten von Anwendungsmustern. Durch Auswahl der besten Konfigurationsoptionen für Ihr System können Sie die Leistungsvorteile maximieren, die die Verwendung optimierter lokaler Adapter bietet.

Werte für die minimale und maximale Verbindungsanzahl für den Aufruf der API Register auswählen

Die Auswahl eines zu hohen Werts für die minimale Verbindungsanzahl für den Aufruf der API Register kann die Leistung beeinträchtigen. Da jede hergestellte Verbindung so lange bestehen bleibt, bis die API Unregister aufgerufen wird, erhöht die Festlegung eines zu hohen Werts für die minimale Verbindungsanzahl den verbrauchten Hauptspeicher und die Zeit, die für die Ausführung jedes Aufrufs der APIs Register und Unregister benötigt wird. Wählen Sie den kleinsten Wert für die minimale Verbindungsanzahl aus, der Ihren Anforderungen entspricht. Wenn beispielsweise Hunderte simultaner Threads eine Registrierung gemeinsam nutzen könnten, kann es sinnvoll sein, mit einem hohen Wert für die minimale Verbindungsanzahl mehr Hauptspeicher und mehr Zeit für die Registrierung einzuräumen. Wenn Sie weniger gleichzeitige Threads erwarten, legen Sie einen niedrigeren Wert für die minimale Verbindungsanzahl fest.

Wird ein zu niedriger Wert für die maximale Verbindungsanzahl ausgewählt, kann dies die Leistung ebenfalls beeinträchtigen, wenn der Client bei der Verbindungsanforderung auf eine Verbindung warten muss. Wird der Wert für die maximale Verbindungsanzahl überschritten, wartet der aufrufende Thread für die Anzahl der für den Wartezeitparameter für die APIs Connection Get, Invoke, Receive Request Any oder Host Service angegebenen Sekunden darauf, dass eine Verbindung verfügbar wird. Läuft diese Zeit ab, werden Rückgabe- und Ursachencodes zurückgegeben, die darauf hinweisen, dass vor Ablauf der Wartezeit kein Verbindungshandle für die Anforderung angefordert werden konnte. Wählen Sie einen Wert für die maximale Verbindungsanzahl aus, der für die erwarteten Anforderungen Ihrer Umgebung am besten geeignet ist.

Werte für die maximale Verbindungsanzahl beim Start eines CICS-Link-Servers auswählen

Wenn Sie eine Link-Server-Task unter Customer Information Control System (CICS) starten, ohne die Parameter für die minimale (MNC) und die maximale Verbindungsanzahl (MXC) anzugeben, wird für MNC standardmäßig der Wert 1 und für MXC der Wert 10 verwendet. Der Wert des Parameters MXC gibt die Anzahl der Linkaufruftasks (BBO#) an, die von der Link-Server-Task (BBO$) gestartet und gleichzeitig ausgeführt werden können. Der Wert begrenzt auch die Anzahl gleichzeitig ausgeführter Threads im Liberty-Server, die CICS-Zielprogramme ausführen und starten können.

Wählen Sie einen MXC-Wert aus, der die erwartete Ausführungsdauer der CICS-Standardzielprogramme widerspiegelt, die unter dieser Instanz des Link-Servers gestartet werden. Wenn die CICS-Zielprogramme beispielsweise hauptsächlich eine lange Laufzeit haben, ist ein höherer MXC-Wert angemessen, damit die Anforderungen vom Liberty-Server an CICS übergeben werden. Wenn die Zielprogramme keine lange Laufzeit haben, ist ein niedrigerer MXC-Wert effizienter.

Gemeinsam genutzter 64-Bit-Speicher

Wenn das OLA-Feature (optmierter lokaler Adapter) in einem Liberty-Server aktiviert ist, werden dem Server 32 MB gemeinsam genutzter Speicher zugeordnet, der oberhalb des 2-GB-Bereichs unter z/OS liegt. Dieser Speicher wird von allen Liberty-Servern mit dem Namen wolaGroup gemeinsam genutzt und speichert die Kontrollstrukturen für die gemeinsam genutzten optimierten lokalen Adapter.

Zusätzlicher gemeinsam genutzter Speicher, der oberhalb des 2-GB-Bereichs liegt, wird zum Speichern von Nachrichten reserviert, die zwischen einem Client und einem Liberty-Server übergeben werden. Die zum Übergeben von Nachrichten erforderliche Speicherkapazität richtet sich nach der durchschnittlichen Größe der übergebenen Nachrichten. Außerdem muss ausreichend gemeinsamer Speicher zum Speichern aller Nachrichtendaten, die zu irgendeiner Zeit existieren, vorhanden sein. Zusätzlicher Speicher wird bei Bedarf reserviert.

Wenn eine Anwendung weiterhin die API "Register" aufruft und eine Schleife bildet, ohne die API "Unregister" aufzurufen und ohne beendet zu werden (wodurch diese Registrierungen automatisch bereinigt werden), kann der gemeinsam genutzte OLA-Speicherpuffer für die WOLA-Gruppe überlaufen. Tritt dieser Fall ein, werden API-Aufrufe mit OOM-Ursachencodes (Out Of Memory, Fehler aufgrund nicht ausreichender Speicherkapazität) zurückgegeben.

Sie können die für Ihre Anwendung erforderliche Kapazität des gemeinsam genutzten WOLA-Speichers mit einer Berechnung grob schätzen. Jede Clientregistrierung verbraucht 384 Bytes gemeinsam genutzten Speichers und zusätzlich 192 Bytes gemeinsam genutzten Speichers für jede Verbindung. Eine Registrierung mit maximal 100 Verbindungen verbraucht ungefähr 20 KB gemeinsam genutzten Speicher. Jeder Client-Thread, der warten muss, bis eine Verbindung verfügbar wird, falls alle Verbindungen belegt sind, verbraucht zusätzlich 80 Bytes. Jeder Service, der von der Registrierung ausgeführt wird, verbraucht zusätzlich 384 Bytes.

Angenommen, eine WOLA-Gruppe hat 200 Registrierungen. Jede Registrierung enthält 200 Verbindungen und für jede Registrierung warten maximal 1.000 Threads ständig auf eine Verbindung. Von dieser Konfiguration werden 24 MB Gesamtspeicher genutzt. Es bleibt dabei ausreichend Speicher übrig, um ungefähr 25.500 Services gleichzeitig bzw. 125 Services pro Registrierung gleichzeitig auszuführen.
200 Registrierungen x 384 Bytes =                      76.800 Bytes
200 Registrierungen x 200 Verbindungen x 192 Bytes = 7.680.000 Bytes
200 Registrierungen x 1000 wartende Threads x 80 Bytes =    16.000.000 Bytes
-----------------------------------------------------------------
                                                 23.756.800 Bytes


33.554.432 Bytes – 23.756.800 Bytes =             9.797.632 verbleibende Bytes
                                               /        384 Bytes pro Service
-----------------------------------------------------------------
                                                     25.514 Services

Hinweise zur Leistung optimierter lokaler Adapter für CICS-Link-Server

Sie können optimierte lokale Adapter für einen CICS-Link-Server verwenden, um ohne großen Aufwand vorhandene CICS-Anwendungsprogramme über Anwendungen aufzurufen, die im Liberty-Server ausgeführt werden. Wenn Sie den Link-Server starten, wird die OLA-Link-Server-Task (BBO$) gestartet und empfängt Programmlinkanforderungen vom Liberty-Server. Wird eine Linkanforderung empfangen, initialisiert die Link-Server-Task (BBO$) die Programmlink-Task (BBO#), die wiederum den Befehl EXEC CICS LINK an das Zielprogramm absetzt, eine Antwort empfängt und diese an den Liberty-Server-Caller sendet. Zum Ausführen dieser Aktionen wird die Identität auf Threadebene der Anwendung im Liberty-Server weitergegeben und der CICS-Zieltask bestätigt, indem der Parameter SEC=Y im BBOC-Befehl START_SRVR definiert wird.

Sie können die Leistung verbessern, indem Sie einen Link-Server mit SEC=N ausführen und die Identität der Benutzer-ID verwenden, die den Link-Server gestartet hat. Dieser Ansatz erfüllt aber möglicherweise nicht die Sicherheits- und Prüfvorschriften Ihrer Organisation. Wenn Sie den Link-Server mit SEC=N ausführen, können Sie die Leistung weiter verbessern, indem Sie außerdem REU=Y im BBOC-Befehl START_SRVR angeben. Wenn Sie REU=Y festlegen, verwendet der Link-Server die Programmlinkaufruftasks (BBO#) bei Programmaufrufanforderungen wieder.
Wichtig: Wenn Sie den Link-Server mit SEC=N und REU=Y ausführen, wird die Übergabe einer separaten Linktransaktions-ID von der JCA der optimierten lokalen Adapter nicht mehr unterstützt. Anforderungen nach separaten Transaktions-IDs lösen in der Anwendung eine Ausnahme des Typs ResourceException aus. Wenn Sie versuchen, den Link-Server mit SEC=Y und REU=Y auszuführen, wird die Option für Wiederverwendung auf No gesetzt, weil der Link-Server für jede Anforderung eine neue Programmlink-Task starten und die weitergegebene Identität bestätigen muss.

Wenn Sie einen Link-Server mit REU=Y ausführen, bleiben Programmlink-Tasks (BBO#) aktiv, bis der BBOC-Befehl STOP_SRVR oder UNREGISTER für die Registrierung eingegeben wird. Wenn die Ausführung zudem mit einem hohen Wert für die maximale Verbindungsanzahl (MXC) stattfindet und gleichzeitig sehr viele Anforderungen eingehen, erreicht die Anzahl der aktiven Programmlink-Tasks (BBO#) möglicherweise den Schwellenwert für die maximale Anzahl gleichzeitig ausgeführter CICS-Tasks. Weitere Informationen zum Festlegen des Schwellenwerts für die maximale Anzahl gleichzeitig ausgeführter CICS-Tasks finden Sie in der Dokumentation für Ihre Version von CICS.

Um die beste Leistung beim Aufruf einer Anwendung unter CICS über den Liberty-Server zu erreichen, müssen Sie die APIs "Host Service", "Receive Request Any" und "Receive Request Specific" direkt in Ihrem Anwendungsprogramm codieren. Werden die APIs direkt codiert, ist keine integrierte Unterstützung für Tasks zur Weitergabe von Identitäten, die vom Link-Server bereitgestellt werden, verfügbar.

Hinweise zur Verwendung des JCA-Ressourcenadapters

Wenn Sie den OLA-JCA-Ressourcenadapter verwenden, ist für jede über das ConnectionFactory-Objekt angeforderte Verbindung zusätzliche Speicherleistung erforderlich. Wenn Ihre Anwendung mehrere Aufrufe eines externen Adressraums oder von CICS in derselben Anwendungsmethode tätigt, können Sie eine bessere Leistung erzielen, indem Sie dieselbe Verbindung für jede Interaktion unter Verwendung desselben JCA-Interaktionsobjekts in einer Anwendungsmethode verwenden.

Wenn Sie das ConnectionFactory-JCA-Objekt für optimierte lokale Adapter erstellen, können Sie die minimale und maximale Größe des JCA-Verbindungspools für dieses ConnectionFactory-Objekt ändern. Der Verbindungspool stellt logische Verbindungen dar, die an physische Verbindungen gebunden sind. Diese physischen Verbindungen werden beim Aufruf der API "Register" während einer Interaktion angegeben. Um eine optimale Leistung zu erzielen, müssen Sie die Größe des JCA-Verbindungspools auf die Größe des Pools physischer Verbindungen setzen, die Sie während des Aufrufs der API "Register" angeben. Wenn Ihr JCA-Verbindungspool zu klein ist, muss Ihre Anwendung möglicherweise auf ein JCA-Verbindungsobjekt warten, obwohl physische Verbindungen verfügbar sind.


Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Dateiname: cwlp_dat_perfconsid.html