Sensibilisation autour du Work Manager

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Nos plateformes OSB peuvent parfois être fortement sollicitées, pouvant, en cas de surcharge, provoquer des indisponibilités de services voire de toute la plateforme.
Afin de se prémunir de genre de désagréments, Oracle propose un mécanisme de « Work Manager » qui permet de protéger les environnements.

Définition

Un « Work Manager » ou « gestionnaire de travaux » est un mécanisme permettant de contrôler le nombre de threads d’exécution alloués en parallèle à un service donné au sein de l’OSB.
Cela permet donc d’établir une notion de priorisation des services en fonction de leur criticité et du temps de réactivité attendu, mais également d’éviter de bloquer l’ensemble des services de façon simultanée en cas de pic de charge.

Par défaut, si aucun Work Manager n’est défini, le service utilise un pool de threads commun géré par le nœud d’administration au sein de Weblogic. En cas de saturation de ce Work Manager, l’ensemble des services s’en retrouve pénalisé.

 

 

 

 

 

 

 

 

Il est donc fortement recommandé de cloisonner les services en utilisant des Work Managers distincts. La stratégie à adopter étant bien sûr propre à chaque plateforme : par priorité, par criticité, par domaine fonctionnel…

 

Il est ainsi possible de fixer un nombre minimum ou maximum de threads pour chaque Work Manager mais également de définir un comportement à appliquer en cas d’atteinte de la limite maximum.

Création de Work Managers

Par la console d’administration

Les Work Managers sont définis dans la console Weblogic par le menu Environnement => Gestionnaires de travaux.

Les 2 propriétés principales sont le « minimum thread constraint » et le « maximum thread constraint ». Elles permettent de fixer respectivement le nombre de threads d’exécution simultanés minimum et maximum alloués au Work Manager.

Le « capacity constraint » permet, quant à lui, de préciser le nombre de requêtes mises en file d’attente une fois la « contrainte maximum » atteinte. Si la « capacity contrainte » est atteinte, les messages sont rejetés, ce qui permet de protéger la plateforme d’une éventuelle surcharge. Par défaut, la valeur est positionnée à « -1 » ce qui met tous les messages entrant en fil d’attente.

Par script

Il est également possible de créer les Work Manager par script pour plus de facilité dans le cadre de l’industrialisation de projet.

Voici donc un exemple de script WLST qui crée un Work Manager avec les 3 contraintes associées (minimum, maximum et capacity).

Affectation des Work Managers

Une fois le Work Manager créé, il ne reste plus qu’à l’associer au service concerné (proxy service ou business service) dans l’onglet transport, dans la propriété « dispatch policy ».

 

 

 

 

 

 

 

 

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *