[z/OS]

Paramètres du régulateur MDB pour les beans gérés par message sur z/OS

Vous pouvez ajuster une multitude de paramètres pour "le régulateur du bean géré par message", pour contrôler la quantité de travail du bean géré par message traitée par le serveur à un moment donnée.

Seuils haut et bas du régulateur MDB

Remarque : Cette rubrique suppose que vous mappez un seul port d'écoute à une destination. Bien que les valeurs de seuil du régulateur soient calculées individuellement pour chaque port d'écoute, il existe une seule unité d'exécution d'agent de file d'attente pour chaque destination, quel que soit le nombre de ports d'écoute. Par exemple, lorsque les ports d'écoute A et B sont mappés vers la file d'attente Q, si le port B atteint le seuil bas, il libère le régulateur de l'unité d'exécution de l'agent de file d'attente unique de la file d'attente Q, même si le port d'écoute A est susceptible d'avoir atteint son seuil haut (et pourrait donc créer un blocage si les ports d'écoute étaient mappés vers des destinations différentes). Plus précisément, il est impossible de mapper plusieurs ports d'écoute vers une même destination et de définir un seuil haut de 1 pour chaque port d'écoute si vous souhaitez exécuter un traitement en série sur les beans gérés par message sur chaque port d'écoute. Il est donc vivement conseillé de mapper un seul port d'écoute vers chaque destination.

La prise en charge du régulateur MDB entretient un comptage du nombre actuel de messages en cours pour chaque port d'écoute.

Lorsqu'une référence de message est envoyée à MRH, le nombre en cours augmente d'une unité, puis il est comparé à la valeur de seuil élevée du port d'écoute.
  • Si le comptage en cours est inférieur ou égal à la valeur du seuil haut, l'enregistrement de travail est alors mis dans la file d'attente VLM.
  • Si le comptage en cours excède la valeur du seuil haut, l'unité d'exécution agent de file d'attente exécutant le MRH est bloqué, passant en état d'attente. On dit que le régulateur "bloque".

Le comptage en cours est décrémenté d'une unité dès lors que le contrôleur est averti qu'un enregistrement de travail pour le port d'écoute est terminé (que la transaction de l'application ait été validée ou non). Une fois décrémenté, le comptage en cours est comparé à la valeur du seuil bas pour ce port d'écoute. Si le comptage en cours descend au niveau du seuil bas, l'unité d'exécution agent de file d'attente qui était bloquée précédemment est sorti de son état de veille (averti). A ce point, les nouveaux enregistrements de travail peuvent être mis en attente dans la file WLM. On dit alors que le régulateur a été "débloqué".

Les valeurs du seuil bas et du seuil haut sont définies en externe par le paramètre Maximum de sessions du port d'écoute. La valeur du seuil haut est définie en interne de manière à être égale à la valeur Maximum de sessions qui est définie en externe. La valeur du seuil bas est calculée et définie en interne à l'aide de la formule suivante : seuil bas = (seuil haut / 2), avec une valeur arrondie à l'entier inférieur le plus proche.

Imaginons par exemple que le paramètre Maximum sessions ait pour valeur 2 avec les valeurs 2 et 1 affectées au seuil haut et au seuil bas respectivement. Voici un récapitulatif du traitement :
  • Le contrôleur commence à traiter un autre message et le nombre en cours passe à 3. Or, ce nombre est supérieur au seuil haut, ce qui provoque la mise en pause de l'unité d'exécution du contrôleur jusqu'à ce que le seuil bas soit atteint.
  • Le bean géré par message dans le serviteur pour le premier message est renvoyé, le nombre en cours est décrémenté de 3 à 2 et par conséquent, n'a pas atteint le seuil bas.
  • Le bean géré par message dans le serviteur pour le second message est renvoyé, le nombre en cours est décrémenté de 2 à 1. Le seuil bas est atteint et le traitement et la répartition des messages vers le SR se poursuivent.
Lorsque la valeur 2 est affectée au paramètre Nombre maximal de sessions, dès que le seuil haut est atteint dans le contrôleur, plus aucun autre message n'est traité tant que les beans gérés par message ne sont pas tous traités dans le serviteur.

Cependant, si le service d'écoute de messages a été configuré avec la valeur "true" affectée à la propriété personnalisée MDB.THROTTLE.THRESHOLD.LOW.EQUALS.HIGH, la valeur du seuil bas est alors définie en interne à l'identique de celle du seuil haut (qui est la propriété Nombre maximal de sessions du port d'écoute définie en externe).

Remarque : Une unité d'exécution agent de file d'attente pour chaque destination, plutôt que pour chaque port d'écoute. Par conséquent, si deux ports d'écoute sont mappés sur la même file d'attente, une condition de blocage de régulateur sur un port d'écoute entraîne également le blocage de la mise en file d'attente des enregistrements de travail du second port d'écoute. Le second port d'écoute est bloqué même si ce dernier n'a pas atteint sa valeur de seuil haut. Pour simplifier, ne partagez pas une destination sur plusieurs ports d'écoute.

Régulation MDB - Optimisation

Affectez à la propriété "Nombre maximal de sessions" une valeur égale à deux fois le nombre d'unités d'exécution disponibles dans tous les serviteurs dans le serveur évolutif (2*WT) pour ne pas laisser une unité d'exécution inactive suite au blocage d'une régulation MDB si elle est disponible dans un serviteur. En d'autres termes, vous ne souhaitez avoir ni une file d'attente VLM vide, ni une tâche de servant disponible, ni un régulateur bloqué.

Avec la recommandation de base invitant à utiliser une valeur de 2*WT, un régulateur bloqué est alors débloqué au moment où les conditions suivantes se vérifient :
  • Une tâche de servant est disponible
  • La file d'attente VLM ne contient rien
  • Une référence de message est parcourue, mais pour laquelle aucune requête de travail n'a été ajoutée à la file d'attente WLM (le régulateur s'est bloqué)

En outre, en réglant le seuil haut à 2*(WT+N), vous avez la garantie que, au moment où la tâche du servant se libère et débloque le régulateur, des commandes en attente de N messages pré-traités et en attente dans la file WLM sont prêts à être répartis. Toutefois, si vous définissez une valeur élevée, vous surchargez la file d'attente WLM, ce que cherchait à éviter la régulation. Notez que ce scénario suppose que la file d'attente (ou le sujet) est complètement chargée de messages à traiter.

Pour cette raison, le fait d'augmenter la valeur du seuil haut autorise le serveur à constituer une petite réserve de messages pré-traités, en attente dans la file WLM en cas de pic de charge de travail. Toutefois, l'augmentation du seuil haut induit un accroissement des risques qu'un message expire avant d'avoir été distribué à l'application. En d'autres termes, le serveur pourrait atteindre la limite d'expiration MDB. Le message donné est finalement à nouveau envoyé au serveur, mais plus tard, et le traitement est effectué jusqu'à ce que ce temps soit écoulé. De même, une valeur de seuil haut très élevée dériverait en réalité la fonction de régulateur MDB, auquel cas la file d'attente WLM pourrait être surchargée ; le serveur pourrait échouer.

Régulation MDB - Optimisation alternative

Bien que le serveur évolutif soit conçu dans l'optique de maximiser le rendement, il est possible d'utiliser les paramètres du port d'écoute pour atteindre d'autres objectifs de gestion de flux de travaux.

Par exemple, un seuil haut fixé à "1" garantit que les messages sont traités dans l'ordre où ils arrivent à destination.

D'autres raisons économiques peuvent également être invoquées, selon la capacité ou selon d'autres facteurs, pour restreindre un port d'écoute particulier à moins d'accès concurrents que le serveur ne pourrait prendre en charge. Bien que cette configuration soit prise en charge, le régulateur pourrait être bloqué lorsque des tâches en veille sont disponibles.

Exemple de régulateur MDB

Supposons que votre serveur est configuré avec une valeur maximale d'instance de serveurs fixée à 3, avec un profil de charge de travail IOBOUND. Vous avez deux unités centrales, par conséquent, WebSphere Application Server créera six tâches dans chaque servant. Votre application (un seul bean géré par message mappé sur une file d'attente) gère chaque message d'une manière assez rapide (donc, le risque d'expiration est plus faible) et vous souhaitez que le temps total entre l'arrivée d'un message sur votre file d'attente MDB et la fin de la répartition MDB de ce message soit aussi réduit que possible.

Pour accélérer le temps de réponse en cas d'augmentation de charge de travail, vous optez pour un retard plus important. Vous définissez la valeur du maximum de sessions du port d'écoute à 100 = 2 * (3 * 6 + 32).

Remarque : Toute valeur supérieure ou égale à 36 = 2 * 3 * 6 tiendrait occupées toutes tâches de servant disponibles. Dans la pratique, il n'est pas vital de choisir le meilleur "facteur de réserve" possible ; il suffit d'une bonne estimation arrondie à une valeur approximative. Par exemple, vous pouvez choisir la valeur 100 dans le cas présent.

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