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.
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.
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.