[z/OS]

Remarques relatives aux performances des adaptateurs locaux optimisés

Quand vous utilisez les API des adaptateurs locaux optimisés de WebSphere Application Server for z/OS, vous devez prendre en compte plusieurs domaines relatifs aux performances.

Les API des adaptateurs locaux optimisés sont conçues pour fournir des performances optimales pour les appels entre un espace d'adressage externe et les applications installées sur WebSphere Application Server for z/OS. Elles établissent des nouveaux types de modèles d'application qui permettent des interactions plus précises entre les applications dans ces environnements. Les informations suivantes décrivent les aspects à connaître pour optimiser les performances des adaptateurs locaux optimisés. Elles vous aideront à mieux comprendre les options de configuration utilisables avec les adaptateurs locaux optimisés pour obtenir les meilleures performances possibles. Les résultats des bancs d'essai, qui comparent les adaptateurs locaux optimisés à d'autres technologies d'appel synchrone entre WebSphere Application Server et les espace d'adressage d'un même système, par exemple SOAP sur HTTP, ne sont pas détaillés dans cette rubrique. Pour obtenir ces informations, reportez-vous au document WebSphere Application Server for z/OS Performance Report.

Sélection des valeurs de connexions minimales et maximales pour les appels de l'API Register

Si vous choisissez une valeur trop élevée pour le nombre minimum de connexions pour les appels de l'API Register, vous risquez une dégradation des performances. Un appel de l'espace d'adressage externe vers la région de contrôle de WebSphere Application Server établit les connexions et les ajoute au pool de connexions des adaptateurs locaux optimisés pendant l'appel de l'API Register. Lorsque ces connexions sont établies avec un serveur, les connexions sont maintenues jusqu'à ce que l'appel à l'API d'annulation d'enregistrement soit reçu, moment auquel WOLA déconnecte les connexions du serveur et les supprime du pool des connexions disponibles. Si la valeur minimale est trop élevée, davantage de mémoire sera consommée et les API Register et Unregister utiliseront des chemins plus longs. Choisissez un nombre minimal de connexions adapté à vos besoins. Si vous pensez que plusieurs centaines d'unités d'exécution simultanées pourraient partager un enregistrement, il sera judicieux de prévoir un grand nombre de connexions possibles pendant l'enregistrement. En revanche, si vous pensez que ce nombre sera faible, il est conseillé de définir une valeur plus faible pour le nombre minimum de connexions.

Le paramètre de connexions maximales de l'API Register permet de limiter le nombre de connexions disponibles dans le pool de connexions des adaptateurs locaux optimisés pour un même processus d'enregistrement. Ce nombre restera fixe pendant toute la durée de vie de l'enregistrement. Quand le nombre de requêtes Connection Get simultanées dépasse cette valeur, l'unité d'exécution appelante laisse passer le délai défini par le paramètre de délai d'attente des API Connection Get, Invoke, Receive Request Any ou Host Service, dans l'attente d'une connexion disponible. Une fois ce délai arrivé à expiration, un code retour et un code raison sont renvoyés pour indiquer qu'aucun descripteur de connexion n'a été obtenu pour la requête avant l'expiration du délai. Vous pouvez aussi définir une taille maximale pour le pool de connexions pour un même processus d'enregistrement. Cette valeur provient de la variable d'environnement de cellule WAS_DAEMON_ONLY_adapter_max_conn. La valeur par défaut de cette variable est 100. Il est possible d'en changer via la console d'administration. Vous devez redémarrer le démon si vous modifiez ce paramètre.

Effet des paramètres de connexions minimales et maximales sur le serveur Link CICS des adaptateurs locaux optimisés

Quand vous lancez une tâche du serveur Link de CICS (Customer Information Control System) avec BBOC START_SRVR, si les paramètres de connexions minimales (MNC) et de connexions maximales (MXC) ne sont pas communiqués, le paramètre MNC de l'API Register prend la valeur par défaut 1 et le paramètre MXC prend la valeur par défaut 10. Cela signifie que vous pouvez lancer et exécuter simultanément 10 tâches d'appel Link (tâches BBO#) avec la tâche de démarrage du serveur Link (tâche BBO$). WebSphere Application Server pourra lancer le même nombre d'unités d'exécution simultanées pour exécuter et démarrer les programmes cible CICS. La valeur du paramètre MXC du serveur Link doit refléter la durée d'exécution prévue des programmes cible CICS que cette instance du serveur Link devra démarrer. Si les programmes CICS cible sont majoritairement à exécution longue, la valeur de MXC devra être suffisamment élevée pour que les requêtes circulent facilement de WebSphere Application Server vers CICS. Si ces programmes cible sont brefs, il est préférable d'affecter une plus petite valeur au paramètre MXC.

Pour choisir la meilleure valeur pour le paramètre MXC, vous devez déterminer combien de régions serviteur de WebSphere Application Server communiquent avec un serveur Link sous un même nom d'enregistrement. S'il n'existe qu'une seule région serviteur et qu'elle s'exécute avec l'option d'unité d'exécution ISOLATE, cela signifie qu'elle n'envoie qu'une seule unité d'exécution à la fois à CICS. Dans ce cas, la valeur de MXC doit être égale à (nombre de serviteurs X 1) pour éviter les goulots d'étranglement. Si l'option d'unité d'exécution est LONGWAIT, jusqu'à 40 unités d'exécution peuvent être actives par serviteur, selon le nombre de requêtes attendues et les types de programmes CICS appelés (à exécution longue ou brève). Dans ce cas, la valeur du paramètre MXC doit être définie selon le nombre attendu de requêtes simultanées exécutées entre les serviteurs et le serveur Link sous un même nom d'enregistrement. Déterminer la valeur optimale du paramètre MXC peut demander quelques essais. Commencez avec une valeur basse et augmentez-la graduellement puis fixez-la quand vous constatez un débit optimal.

Mémoire partagée 64 bits

La prise en charge des adaptateurs locaux optimisés requiert d'exécuter le serveur WebSphere Application Server for z/OS en mode 64 bits. Quand le groupe de démons démarre pour la première fois et que le paramètre WAS_DAEMON_ONLY_enable_adapter a la valeur true ou 1, WebSphere Application Server alloue et initialise un tampon partagé en mode 64 bits, donc au-dessus de la barre des 2 Go. La taille par défaut de cette zone de mémoire est de 32 Mo. C'est dans cet espace que résident les structures de contrôle partagées des adaptateurs locaux optimisés. En revanche, les données des messages n'y sont pas mises en cache. Les données des messages et des contextes circulent entre les espaces d'adressage externes et les régions serviteur de WebSphere Application Server à l'aide d'un espace inter-adresse dédié à la communication locale de WebSphere Application Server for z/OS qui permet de transférer les données des messages dans l'espace d'adressage du serveur. Les messages volumineux sont stockés en mode 64 bits, donc au-dessus de la barre des 2 Go. Actuellement, la communication locale de WebSphere Application Server admet une taille maximale de message de 2 Go et, dans le support initial des adaptateurs locaux optimisés, il s'agit de la taille maximale admissible pour un même message.

Si une application appelle sans cesse l'API Register et tourne en boucle sans appeler l'API Unregister ni prendre fin (ce qui fermerait automatiquement les deux API), elle risque de saturer la mémoire tampon partagée des adaptateurs locaux optimisés associés au groupe de démons. Dans cette situation, les appels d'API reviennent avec des codes raison signalant une insuffisance de mémoire. Pour identifier ce type de situation, entrez la commande suivante sur l'un des serveurs WebSphere Application Server dans le groupe de démons concerné :
F <nom_serveur>,DISPLAY,ADAPTER,REGISTRATIONS 	 	
La sortie affichée vous permet de déterminer quel travail consomme les enregistrements sans les libérer puis de corriger le problème en redémarrant ce travail.

Si, après l'analyse, vous constatez que la valeur par défaut 32 Mo est insuffisante pour satisfaire les besoins du groupe de démons, vous pouvez la modifier à l'aide de la variable d'environnement de cellule WAS_DAEMON_ONLY_adapter_max_shrmem. Ne modifiez cette valeur qu'après un examen minutieux. Cela demande de recréer la mémoire tampon partagée des adaptateurs locaux optimisés et de réamorcer le système.

Vous pouvez obtenir une estimation approximative de la quantité de mémoire nécessaire. Chaque enregistrement de client consomme 392 octets de mémoire partagée, plus 112 octets de mémoire partagée pour chaque connexion. Un enregistrement assorti d'un maximum de 100 connexions consomme donc environ 12 Ko de mémoire partagée. Chaque unité d'exécution de client, qui doit attendre qu'une connexion soit disponible quand toutes les connexions sont occupées, consomme 80 octets de plus. Chaque service hébergé par l'enregistrement consomme en plus 336 octets.

Par exemple, imaginons que votre groupe de démons contient 200 enregistrements. Chaque enregistrement contient 200 connexions et au maximum 1000 unités d'exécution attendent une connexion à chaque instant. La quantité totale de mémoire consommée par cette configuration est d'environ 20 Mo. Cela laisse assez de mémoire partagée pour héberger environ 38000 services simultanément, soit 190 services simultanés par enregistrement.
200 enregistrements x 392 octets =78400 octets 		
200 enregistrements x 200 connexions x 112 octets = 4480000 octets 		
200 enreg. x 1000 unités en attente x 80 octets = +	16000000 octets 							 	
-------------------------------- 									
20558400 octets 	 		


33554432 octets – 20558400 octets = 12996032 octets restants 							     
/	     336 octets par service 							     
---------------------------------- 								        
38678 services 
Quand vous augmentez ou diminuez la taille de la mémoire partagée, n'oubliez pas que la mémoire partagée en sus de la mémoire de barre est affectée par sections de 1 Mo. WebSphere Application Server arrondit la valeur que vous spécifiez au Mo supérieur.

Contrôle du nombre maximum d'appels sortant simultanément de WebSphere Application Server

Les adaptateurs locaux optimisés possèdent un paramètre par défaut appliqué à tous les démons qui permet de contrôler le nombre maximum d'appels sortants simultanés que WebSphere Application Server peut exécuter pour un même enregistrement. Ce paramètre est la variable WAS_DAEMON_ONLY_adapter_max_serv. La valeur par défaut est 100. Cette valeur signifie que 100 services cible au plus peuvent s'exécuter sous le même nom d'enregistrement (100 appels simultanés aux API Host Service, Receive Request Any ou Receive Request Specific). Si vous changez cette valeur, vous devez redémarrer le démon utilisé.

Avec la valeur par défaut 100, si vous tentez de configurer une unité d'exécution en tant que 101eme serveur pour un nom d'enregistrement donné avec l'une des trois API prévues à cette fin, vous obtenez un code raison et un code retour différent de zéro qui indique que la valeur de adapter_max_serv a été atteinte. Si une application de WebSphere Application Server recherche ce service et qu'il n'est pas immédiatement disponible, cette application attend 30 secondes (valeur par défaut) puis reçoit un message d'exception qui indique que le délai d'attente du service est arrivé à expiration. Cette exception est consignée dans le fichier journal du serviteur WebSphere Application Server sous le code d'incident mineur C9C24C15. La valeur par défaut de ce délai d'attente, 30 secondes, peut être modifiée par l'application à l'aide de la méthode setConnectionWaitTimeout() dans l'objet JCA (Java™ EE Connector Architecture) ConnectionSpecImpl.

Remarques relatives aux performances du serveur Link CICS des adaptateurs locaux optimisés

Les adaptateurs locaux optimisés prennent en charge le serveur Link de CICS. Cette prise en charge vous permet d'appeler facilement des applications CICS à partir des applications exécutées dans WebSphere Application Server for z/OS. Quand vous démarrez le serveur Link à l'aide d'une transaction BBOC ou du programme CICS PLTPI BBOACPL2, la tâche de serveur Link des adaptateurs locaux optimisés (tâche BBO$) démarre et reçoit des requêtes de liens de programme de la part de WebSphere Application Server. La tâche Program Link (BBO#) s'initialise ensuite puis envoie une instruction EXEC CICS LINK au programme cible, reçoit une réponse et la renvoie au programme appelant dans WebSphere Application Server. Une partie de cette prise en charge entraîne la propagation et l'assertion de l'identité de niveau unité d'exécution de l'application WebSphere Application Server sur la tâche cible CICS. La propagation et l'application de cette identité sont demandées via le paramètre SEC=Y de la commande BBOC START_SRVR.

Vous obtiendrez de meilleures performances si vous exécutez un serveur Link avec le paramètre SEC=N et que vous utilisez comme identité l'ID de l'utilisateur ayant initialisé ce serveur, mais en procédant de cette manière, vous risquez de sortir des règles de sécurité et de contrôle de votre organisation.

S'il est établi que le serveur Link peut s'exécuter avec le paramètre SEC=N, vous optimiserez les performances en l'exécutant également avec le paramètre BBOC START_SRVR REU=Y. Avec REU=Y, le serveur Link peut réutiliser les tâches d'appel Program Link (transactions BBO#) entre deux requêtes d'appel de programme.
Important : Si vous exécutez le serveur Link dans cette configuration, la prise en charge JCA des adaptateurs locaux optimisés, qui permet de communiquer un ID de transaction LINK pour chaque requête, est désactivée. Si une application émet une telle requête, une exception de type ResourceException lui sera renvoyée. De plus, si vous tentez de sélectionner REU=Y et SEC=Y, l'option de réutilisation prend la valeur Non car le serveur Link doit démarrer une nouvelle tâche Program Link pour chaque requête avec l'identité propagée et appliquée.

Si vous exécutez le serveur Link avec l'option REU=Y, les tâches Program Link (BBO#s) restent actives après leur lancement jusqu'à ce qu'une commande BBOC STOP_SRVR ou BBOC UNREGISTER soit exécutée pour l'enregistrement. Si vous utilisez une valeur élevée pour MXC avec la commande BBOC START_SRVR et qu'un grand nombre de requêtes arrivent en même temps, le nombre de tâches BBO# peut devenir très élevé et elles ne prendront fin qu'à l'arrêt du serveur Link. C'est un autre aspect à prendre en compte pour choisir d'utiliser ou non REU=Y et pour déterminer la meilleure valeur possible pour le paramètre MXC.

Si votre objectif est d'obtenir les meilleures performances pour appeler une application CICS depuis WebSphere Application Server, vous pouvez coder les API Host Service (BBOA1SRV), Receive Request Any (BBOA1RCA) ou Receive Request Specific (BBOA1RCS) directement dans le programme de votre application. Dans cette situation, la propagation des identités ne sera pas prise en charge de manière intégrée comme avec le serveur Link mais, si cela n'est pas indispensable et que les performances sont une priorité assez forte, l'utilisation directe des API peut être la meilleure option.

Remarques relatives à JCA

Quand vous utilisez l'adaptateur de ressources JCA des adaptateurs locaux optimisés, pensez qu'une charge supplémentaire est générée par chaque connexion délivrée par l'objet ConnectionFactory. Si votre application a besoin d'envoyer plusieurs appels à un espace d'adressage externe ou à CICS dans une même méthode de cette application, il est préférable d'utiliser la même connexion pour chaque interaction plutôt que de demander une nouvelle connexion à chaque fois. De plus, vous pouvez réutiliser un même objet d'interaction JCA avec la même méthode d'application.

Quand vous créez la fabrique de connexions JCA pour les adaptateurs locaux optimisés, il est possible de modifier la taille minimum et la taille maximum du pool de connexions JCA associé à cette fabrique de connexions. Ce pool de connexions représente les connexions logiques qui sont liées aux connexions physiques (spécifiées dans l'appel d'enregistrement BBOA1REG) au cours d'une interaction. Pour optimiser les performances, la taille du pool de connexions JCA doit être identique à celle du pool de connexions physiques défini pendant l'appel BBOA1REG. Si votre pool de connexions JCA est trop petit, votre application risque d'attendre un objet connexion JCA même si des connexions physiques sont disponibles. Votre pool de connexions physiques est partagé par toutes les régions serviteur et, s'il existe plusieurs régions serviteur, vous voudrez peut-être réduire la taille du pool de connexions JCA de chaque région serviteur afin de conserver un nombre total de connexions JCA en rapport avec la taille du pool de connexions physiques pour l'ensemble des régions serviteur.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_perfconsid
Nom du fichier : cdat_perfconsid.html