[z/OS]

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.

Pour optimiser le traitement des beans gérés par message, prenez en compte tous les paramètres suivants conjointement :
  • 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
Il est difficile de recommander des valeurs à sélectionner pour ces différents paramètres étant donné la diversité des charges de travail qu'il est possible d'exécuter sur un même serveur. Vous devez envisager de nombreuses possibilités, dont les facteurs suivants :
  • 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

  1. Associez la propriété Nombre maximum de sessions du port d'écoute à une valeur au moins deux fois supérieure au nombre maximal d'unités d'exécution de tâche (worker) serviteur disponibles sur tout le serveur. La valeur de cette propriété détermine la limite supérieure (limite supérieure = nombre maximal de sessions) et est utilisée par le régulateur pour décider de bloquer ou d'autoriser les demandes.
    1. Démarrez la console d'administration.
    2. Dans le panneau de navigation, cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere->nom_serveur > [Communications] Messagerie > Service d'écoute des messages > [Propriétés supplémentaires] Ports d'écoute > port-d'écoute Le panneau Collection de ports d'écoute de messages s'affiche.
    3. Sélectionnez le nom du port d'écoute que vous souhaitez utiliser. Le panneau Paramètres de port d'écoute s'affiche.
    4. Associez la propriété Nombre maximal de sessions à la valeur à utiliser comme limite supérieure par le régulateur de beans gérés par message. La valeur minimale suggérée est calculée à l'aide de la formule suivante :
      2 * (maximum number of servants) * (number of worker threads in one servant)

      Here "servants" means the same as "server instances" on the administrative console. To calculate the number of worker threads in a single servant, see the description of "Workload profile" in ORB services advanced settings.

    To learn more about setting the Listener Port maximum sessions property, see the information about message-driven beans and tuning settings on z/OS.

  2. Set the IBM MQ queue connection factory properties.
    1. To view this administrative console page, click Ressources > JMS->Fabriques de connexions de file d'attente.
    2. Select the queue connection factory specified for the listener port.
    3. From the Additional Properties, select the Connection Pool panel.
    4. Set the Max Connections property for the Connection Pool. Allow one connection for each message-driven bean. This property value might include message-driven beans mapped onto different listener ports, if those listener ports were each, in turn, mapped onto the same connection factory. To learn more about this setting, see the information about message-driven beans and tuning settings on z/OS.
    5. From the Additional Properties of the queue connection factory, select the Session Pool panel.
    6. Set the Max Connections property for the session pool. Allow one session for each worker thread in a single servant. Set this property to at least the number of worker threads available to a single servant. To learn more about this setting, see the information about message-driven beans and tuning settings on z/OS.
  3. Set the IBM MQ-related properties. Make sure that the backing IBM MQ queue manager has been configured with enough resources to support the intended JMS workload coming from WebSphere Application Server (and other clients). In particular, consider your queue manager CTHREAD, IDBACK, and IDFORE parameter settings. For more information on these IBM MQ settings, see the IBM MQ information center.

Exemple

  1. 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
  2. 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).

  3. 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 [z/OS]Optimisation de la prise en charge de la régulation MDB pour le débogage dans z/OS.


Icône indiquant le type de rubrique Rubrique de tâche



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=tprf_tunezmdb
Nom du fichier : tprf_tunezmdb.html