![[z/OS]](../images/ngzos.gif)
Gestion de l'espace adresse des demandes de travail
Le produit propage les demandes de contexte de performances des travaux en utilisant des enclaves WLM (Workload Management). Chaque transaction possède sa propre enclave et elle est gérée en fonction de sa classe de service.
Le contrôleur d'un serveur, considéré comme un gestionnaire de files d'attente par la fonction de gestion de la charge de travail, utilise l'enclave associée à une demande client pour gérer la priorité du travail. Si la priorité du travail est élevée, le système de gestion de la charge de travail peut l'acheminer vers un serviteur à priorité élevée du serveur. Si la priorité du travail est faible, le système de pondération de charge de travail peut l'acheminer vers un serviteur à faible priorité. L'objectif consiste à répartir les travaux en fonction de leur priorité sur un même serveur.

- Le produit utilise son propre ensemble de règles pour créer une enclave pour une demande client provenant du réseau.
- Certains sous-systèmes, tels que IBM® HTTP Server, créent des enclaves et les transmettent au serveur d'applications qui les transmet ensuite à son tour.
- Le produit traite les travaux par lots comme s'il s'agissait de clients distants.
Pour communiquer le contexte de performances à la fonction de gestion de la charge de travail, vous devez classifier les charges de travail en fonction des qualifiants de travail.
Abréviation du qualifiant de travail | Qualifiant de travail | Entité du produit correspondante |
---|---|---|
CN | Nom de la collection | Nom du cluster |
UI | ID utilisateur | ID utilisateur sous lequel s'exécute le travail |
Pour plus d'informations sur les règles de classification et les qualifiants de charge de travail,voir la rubrique Classification de la charge de travail z/OS et le document z/OS z/OS MVS Planning : Workload Management.
Outre les charges de travail des clients, vous devez prendre en compte les performances des serveurs d'exécution du produit et des serveurs d'applications métier. En général, les contrôleurs du serveur agissent en tant que routeurs de travaux et ils doivent avoir une priorité élevée. Etant donné que la fonction de gestion de la charge de travail démarre et arrête les serviteurs de manière dynamique, ces derniers requièrent également une priorité élevée pour être initialisés rapidement. Une fois réinitialisés, les serviteurs exécutent les travaux en fonction de la priorité de l'enclave du client ; la priorité que vous avez affectée au serviteur n'est plus prise en compte.
En résumé, utilisez la table suivante pour définir les objectifs de performance pour chaque classe :
Si vous classifiez... | ... affectez l'élément à : | Explication |
---|---|---|
Démon de service de localisation | SYSSTC ou STC à haute vitesse et importance haute | Le système le traite comme s'il s'agissait d'une tâche démarrée et doit acheminer rapidement les demandes de travail. |
Contrôleur | SYSSTC ou STC à haute vitesse et importance haute | Un contrôleur doit acheminer les travaux rapidement, mais vous devez équilibrer la priorité de votre serveur d'applications métier avec les autres travaux contenus sur le système. |
Servant | STC dont la vitesse et l'importance sont moins élevées que celles du contrôleur | Un objectif inférieur doit être affecté au serviteur par rapport au contrôleur car le serviteur est moins important que le contrôleur. ![]() |
L'environnement d'applications | Utilisez les règles de classification CB, l'objectif de temps de réponse en pourcentage, par exemple 80 % des transactions s'exécutent en 0,25 seconde. | |
Applications client | Dans le cas d'une application à exécution longue, il convient d'utiliser un objectif de rapidité par rapport aux autres travaux du système. |