![[z/OS]](../images/ngzos.gif)
Optimisation du traitement des beans gérés par message sur z/OS à l'aide d'IBM MQ comme fournisseur de messagerie en mode ASF
ous pouvez optimiser le traitement des beans gérés par message lorsque vous exécutez WebSphere Application Server sur la plateforme z/OS, où IBM MQ est le fournisseur de messagerie et le bean géré par message a été déployé en mode ASF (Application Server Facilities).
Avant de commencer
Pour optimiser le traitement des beans gérés par message, vous devez prendre en compte plusieurs paramètres conjointement. Vous devez envisager diverses valeurs et possibilités pour répondre aux diverses charges de travail qu'il est possible d'exécuter sur un serveur donné.
Lorsqu'un bean géré par message est mappé (c'est à dire qu'il écoute) vers une file d'attente, ou vers une rubrique par le biais d'un abonnement durable, un message JMS entre dans un premier temps dans le contrôleur du serveur application et on dit que le serveur est à l'"écoute du contrôleur" pour ces messages. L'expression "écoute du contrôleur" est utilisée tout au long de cette description relative à l'optimisation du traitement des beans gérés par message.
Pourquoi et quand exécuter cette tâche
Lorsque vous optimisez le traitement des beans gérés par message sur le serveur, vous devez également ajuster toute la charge de travail du serveur ainsi que l'interaction associée.
- Définitions des classes de service WLM
- Sélection du profil de charge de travail WebSphere Application Server
- Paramètres du port d'écoute du service d'écoute des messages
- Paramètres du pool de fabriques de connexions JMS
- Paramètres du gestionnaire de files d'attente IBM MQ
- le nombre de beans gérés par message ;
- les choix de configuration du serveur, notamment si deux beans gérés par message doivent être mappés vers des ports d'écoute identiques ou différents ;
- l'importance du travail des beans gérés par message par rapport aux autres types de travaux (HTTP, IIOP) qui s'exécutent sur le serveur.
Les paramètres suggérés ci-après constituent un point de départ et partent du principe que le serveur est configuré avec une application unique comprenant un seul bean géré par message installé et s'exécutant sur le serveur.
Des informations plus avancées ("Ecoute du contrôleur" sur z/OS) expliquent les raisons de ces suggestions et décrivent en détail la fonction de port d'écoute. Ces éléments combinés peuvent vous aider à effectuer vos sélections de paramètres pour vos systèmes et vos serveurs.
Procédure
Exemple
- If your server is configured with the maximum server
instances value set to 3, (whatever
the minimum number might be), and if your workload profile is LONGWAIT (which means that each servant contains 40 worker
threads), set your listener port maximum sessions value to at least
240 = 2 * 3 * 40
- Suppose that your application contains two individual message-driven
beans, each of which has an onMessage() implementation that forwards
the message to another JMS destination. Therefore, each message-driven
bean needs its own JMS connection factory to complete this task. Suppose
the Administrator has mapped each message-driven bean JMS connection
factory resource reference onto the same administratively-defined
connection factory used by the listener port that each of these message-driven
beans is mapped onto.
In this case, you need to set the connection factory Connection Pool Max Connections value to 42. One connection for each of the two message-driven beans to be used by the listener port, and one connection potentially for each of the 40 onMessage() dispatches that night be running concurrently. (Remember that the connection pool is a per-servant pool).
- Set the connection factory Session Pool Max Connections to 40, the number of worker threads in a single servant, regardless of the number of servants.
For debugging tips, refer to Optimisation de la prise en charge de la régulation MDB pour le débogage dans z/OS.