Remarques sur les performances des adaptateurs locaux optimisés pour Liberty

Les API de WebSphere Optimized Local Adapters (WOLA) ont été conçues pour permettre des performances optimales lors des appels entre un espace adresse externe et des applications sur Liberty pour z/OS. Elles établissent de nouveaux types de canevas d'application en prenant en charge des interactions à granularité fine entre les applications dans ces environnements. En choisissant les options de configuration les plus adaptées à votre système, vous pouvez profiter au maximum de l'amélioration des performances liée à l'utilisation des adaptateurs locaux optimisés.

Sélection du nombre minimal et du nombre maximal de connexions pour l'appel de l'API Register

La sélection d'un nombre minimal de connexions pour l'appel de l'API Register trop élevé peut dégrader les performances. Etant donné que chaque connexion établie est conservée jusqu'à ce que l'API Unregister soit appelée, un nombre minimal de connexions trop élevé consomme plus de mémoire et augmente le temps nécessaire pour effectuer chaque appel d'API Register et Unregister. Sélectionnez le nombre minimal de connexions le plus petit adapté à vos besoins ; par exemple, si des centaines d'unités d'exécution simultanées peuvent potentiellement partager un enregistrement, il est judicieux de dédier une quantité plus élevée de mémoire et de temps à l'enregistrement, avec un nombre minimal de connexions élevé. Si vous prévoyez un nombre d'unités d'exécution simultanées faible, définissez un nombre minimal de connexions plus faible.

La sélection d'une valeur trop faible pour le nombre maximal de connexions peut également dégrader les performances si le client doit attendre une connexion lorsqu'il en demande une. Lorsque le nombre maximal de connexions est dépassé, l'unité d'exécution appelante attend le nombre de secondes spécifié dans le paramètre de temps d'attente pour les API Connection Get, Invoke, Receive Request Any ou Host Service qu'une connexion devienne disponible. Au cours de ce délai, des codes retour et anomalie, qui indiquent qu'un descripteur de connexion n'a pas pu être acquis pour la demande avant la fin du temps d'attente, sont renvoyés. Sélectionnez un nombre maximal de connexions adapté aux besoins prévisionnels pour votre environnement.

Sélection du nombre maximal de connexions lorsque vous démarrez un serveur de liaison CICS

Lorsque vous démarrez une tâche de serveur de liaison sous Customer Information Control System (CICS) sans spécifier les paramètres de nombre minimal de connexions (MNC) et de nombre maximal de connexions (MXC), le nombre minimal de connexions est 1 par défaut et le nombre maximal de connexions est 10 par défaut. La valeur du paramètre MXC spécifie le nombre de tâches d'appel de liaison (BBO#) pouvant être démarrées et exécutées simultanément par la tâche de serveur de liaison (BBO$). Par conséquent, la valeur limite également le nombre d'unités d'exécution simultanées sur le serveur Liberty qui peuvent exécuter et démarrer des programmes cible CICS.

Sélectionnez une valeur MXC qui reflète la durée prévue des programmes CICS cible classiques qui sont démarrés dans cette instance du serveur de liaison. Par exemple, si l'exécution des programmes CICS cibles est généralement longue, une valeur MXC plus grande conviendrait pour un flux efficace des requêtes du serveur Liberty vers CICS. Si l'exécution des programmes cible est courte, une valeur MXC plus petite est plus efficace.

Mémoire partagée 64 bits

Lorsque la fonction des adaptateurs locaux optimisés est activée sur le serveur Liberty, le serveur obtient 32 Mo de mémoire partagée, qui se trouvent au-dessus de la barre des 2 Go sous z/OS. Cette mémoire est partagée par tous les serveurs Liberty dont le nom est wolaGroup et stocke les structures de contrôle des adaptateurs locaux optimisés partagés.

La quantité de mémoire partagée supplémentaires située au-dessus de la barre des 2 Go est allouée au stockage des messages transmis entre un client et un serveur Liberty. La quantité de stockage requise pour transmettre les messages dépend de la taille moyenne des messages qui sont transmis, et la mémoire partagée doit être suffisante pour contenir toutes les données de message existantes à tout moment. La quantité de mémoire supplémentaire est allouée en fonction des besoins.

Si une application continue d'appeler l'API Register et crée une boucle sans appeler l'API Unregister et sans s'arrêter, ce qui nettoie automatiquement ces enregistrements, elle peut dépasser la capacité du tampon de la mémoire partagée des adaptateurs locaux optimisés pour le groupe WOLA. Si tel est le cas, les appels d'API sont renvoyés avec des codes anomalie signalant une insuffisance de mémoire.

Vous pouvez estimer grossièrement la quantité de mémoire partagée WOLA dont votre application a besoin. Chaque enregistrement client consomme 384 octets de mémoire partagée, plus 192 octets de mémoire partagée pour chaque connexion. Un enregistrement dont le nombre maximal de connexions est 100 consomme environ 20 Ko de mémoire partagée. Chaque unité d'exécution client, qui doit attendre qu'une connexion devienne disponible si toutes les connexions sont utilisées, consomme 80 octets supplémentaires. Chaque service que l'enregistrement héberge consomme 384 octets supplémentaires.

Par exemple, supposez que vous disposez de 200 enregistrements dans votre groupe WOLA. Chaque enregistrement contient 200 connexions et un maximum de 1000 unités d'exécution en attente d'une connexion à tout moment. La quantité de mémoire totale consommée par cette configuration est d'environ 24 Mo, ce qui laisse assez de mémoire partagée pour héberger approximativement 25500 services simultanément ou 125 services simultanés par enregistrement.
200 enregistrements x 384 octets =                      76800 octets
200 enregistrements x 200 connexions x 192 octets = 7680000 octets
200 enregistrements x 1000 unités en attente x 80 octets =    16000000 octets
-----------------------------------------------------------------
                                                 23756800 octets


33554432 octets – 23756800 octets =             9797632 octets restants
                                               /        384 octets par service
-----------------------------------------------------------------
                                                     25514 services

Remarques sur les performances du serveur de liaison CICS avec les adaptateurs locaux optimisés

Vous pouvez utiliser des adaptateurs locaux optimisés pour un serveur de liaison CICS afin d'appeler facilement des programmes d'application CICS existants depuis des applications qui s'exécutent sur le serveur Liberty. Lorsque vous démarrez le serveur de liaison, la tâche du serveur de liaison des adaptateurs locaux optimisés (BBO$) lance et reçoit des demandes de liaison du serveur Liberty. Lorsqu'une demande de liaison est reçue, la tâche du serveur de liaison (BBO$) initie la tâche de liaison de programme (BBO#), qui à son tour envoie une commande EXEC CICS LINK au programme cible, reçoit une réponse, et l'envoie à l'appelant du serveur Liberty. Pour que ces actions puissent être effectuées, l'identité de niveau unité d'exécution de l'application sur le serveur Liberty est propagée et vérifiée sur la tâche CICS cible, via la définition du paramètre SEC=Y dans la commande BBOC START_SRVR.

Vous pouvez améliorer les performances en exécutant un serveur de liaison avec SEC=N et en utilisant l'identité de l'ID utilisateur qui a initié le serveur de liaison ; toutefois, il se peut que cette approche ne réponde pas aux exigences de sécurité et d'audit de votre organisation. Si vous décidez d'exécuter le serveur de liaison avec SEC=N, vous pouvez encore améliorer les performances en spécifiant également REU=Y dans la commande BBOC START_SRVR. Lorsque vous définissez REU=Y, le serveur de liaison réutilise les tâches d'appel de liaison de programme (BBO#) entre les demandes d'appel de programme.
Important : Si vous exécutez le serveur de liaison avec SEC=N et REU=Y, le JCA de l'adaptateur local optimisé ne prend plus en charge la transmission d'un ID de transaction de liaison distinct. Les demandes d'ID de transaction distinct génèrent une exception ResourceException dans l'application. Si vous tentez d'exécuter le serveur de liaison avec SEC=Y et REU=Y, l'option de réutilisation prend de force la valeur No car le serveur de liaison doit démarrer une nouvelle tâche de liaison de programme pour chaque demande et vérifier l'identité propagée.

Si vous exécutez un serveur de liaison avec REU=Y, les tâches de liaison de programme (BBO#) restent actives jusqu'à ce qu'une commande BBOC STOP_SRVR ou UNREGISTER soit entrée pour l'enregistrement. Si vous opérez avec un nombre élevé de connexions maximales (MXC) et qu'un grand nombre de demandes arrivent en même temps, le nombre de tâches de liaison de programme actives (BBO#) peut atteindre le seuil maximal de tâches CICS simultanées. Pour plus d'informations sur la définition du seuil de nombre maximal de tâches simultanées CICS, voir la documentation relative à votre version de CICS.

Pour une rapidité optimale lorsque vous appelez une application sous CICS depuis le serveur Liberty, codez les API Host Service, Receive Request Any ou Receive Request Specific directement dans votre programme d'application. Toutefois, le codage direct des API ne fournit pas le support intégré de la propagation de l'identité mis à disposition par le serveur de liaison.

Remarques relatives à l'utilisation de l'adaptateur de ressources JCA

Lorsque vous utilisez l'adaptateur de ressources JCA des adaptateurs locaux optimisés, chaque connexion obtenue de l'objet ConnectionFactory requiert une surcharge de mémoire supplémentaire. Si votre application effectue plusieurs appels d'un espace adresse externe ou CICS dans la même méthode d'application, vous obtiendrez de meilleurs performances en utilisant la même connexion pour chaque interaction et le même objet d'interaction JCA dans une méthode d'application.

Lorsque vous créez l'objet JCA ConnectionFactory pour les adaptateurs locaux optimisés, vous pouvez modifier la taille minimale et la taille maximale du pool de connexions JCA pour cet objet ConnectionFactory. Le pool de connexions représente les connexions logiques qui sont liées à des connexions physiques spécifiées lorsque vous appelez l'API Register au cours d'une interaction. Pour des performances optimales, la taille du pool de connexions JCA doit être identique à la taille du pool de connexions physiques que vous avez définie au cours de l'appel de l'API Register. Si votre pool de connexions JCA est trop petit, votre application devra peut-être attendre un objet de connexions JCA, même si des connexions physiques sont disponibles.


Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_dat_perfconsid.html