Manuel d'implémentation › Exemples d'étude de cas › Ecriture d'exemples de logique applicative efficaces › Etude de cas 15 : Métriques groupées

Etude de cas 15 : Métriques groupées

La description d'une partie d'un logiciel peut généralement être divisée en deux parties, le QUOI et le COMMENT. QUOI signifiant la description de ce que la partie du code fait. Le COMMENT pour la façon dont il le fait. Si l'on se concentre souvent sur le QUOI, le COMMENT tend plutôt à être ignorer. La raison en est simple et dans beaucoup de cas, elle est justifiée. Vous réduisez ainsi la connexion entre vos composants et ne surchargez pas votre esprit avec des informations le plus souvent non pertinentes. Dans beaucoup de cas en revanche, ignorer le COMMENT implique des performances médiocres.

Cette étude de cas aborde la manière dont le moteur calcule des métriques groupées (réponse au COMMENT) et décrit le coût de performance impliqué pour certaines implémentations. Elle examine également plusieurs façons de réduire ce coût en changeant l'implémentation.

Que sont les métriques groupées ?

Les métriques groupées sont des métriques intégrant un certain groupe de ressources dans leur définition. Ce groupe est appelé groupe de la métrique et chacune des ressources dans ce groupe est appelée élément de groupe. Lors du calcul d'une métrique groupée, un calcul séparé est effectué pour chaque élément groupé. Les calculs de ces éléments sont identiques excepté pour :

• Context.ClusterItem : Valeur de la propriété Context.ClusterItem, égale à l'élément groupé en cours de calcul.
• Enregistrements par élément groupé : Lorsqu'une métrique est enregistrée en événements par élément groupé, chaque élément groupé reçoit des données brutes et des événements de réutilisabilité.

De quelle manière les métriques groupées sont-elles calculées ?

Ce qu'il importe de comprendre à propos du calcul d'une métrique groupée est que tous les éléments groupés sont calculés en parallèle. Nous n'entendons pas par là qu'ils sont calculés par fils différents, mais que lors du traitement des événements devant être gérés par les différents éléments groupés, ces événements sont traités de façon séquentielle, et pour chacun d'entre deux les éléments groupés appropriés sont appelés pour traiter l'événement. Par exemple, beaucoup d'événements doivent être traités par de nombreux éléments groupés. Il existe deux procédures à cette fin :

Exemple : option 1

For each cluster item C
     For each event E that should be handled by C
          Let C handle E

Exemple : option 2

For each event E
     For each cluster item C that should handle E
          Let C handle E

Le moteur gère les métriques groupées en utilisant l'option 2.

Autre point important : l'exécution du VBScript dans le PslWriter est accomplie par un composant appelé Contrôle de script. Il n'existe qu'une seule instance de ce composant pour chaque métrique et cette instance est réutilisée pour le calcul des divers éléments groupés. Vu que les éléments groupés sont calculés en parallèle et que le composant Script Control ne peut contenir les données que d'un seul élément groupé à chaque instant, nous devons fréquemment basculer les données dans le composant Script Control.

Pour expliquer cela, un code fictif plus détaillé effectuant le calcul est présenté ci-dessous.

1-     For each metric M
2-          Let X be the earliest event not yet handled by M
3-          Let T be the timestamp of the latest state before X
4-          Let L be the list of all events registered by M (all cluster items) starting from timestamp T until the current time
5-          For each event E in L
6-               For each cluster item C that should handle E
7-                    Let C’ be the cluster item that is currently loaded into the script control
8-                    Take the values of the global variables from the script control and store them aside for C’
9-                    Take the values of the global variables stored aside for C and load them into the script control
10-                    Handle event E

Tout le processus consistant à rechercher le moment d'un événement qui n'était pas encore pris en compte pour ensuite calculer depuis ce point est nommé Nouveau calcul. Le processus visant à remplacer les valeurs des variables globales (étapes 8 et 9 du code ci-dessus) est appelé Commutation de contexte.

Les deux problèmes principaux que vous pouvez facilement observer dans le code ci-dessus sont les suivants :

• Le nouveau calcul s'effectue pour l'ensemble des éléments groupés. Une fois que l'instant T (étape 3 dans le code ci-dessus) est trouvé, tous les éléments groupés effectuent un nouveau à partir de ce point. Cela signifie qu'à chaque fois qu'un élément groupé reçoit un nouvel événement, tous les éléments groupés sont recalculés.
• La commutation de contexte est très courante. Vous pouvez le voir facilement car la commutation de contexte (étapes 8 et 9 du code ci-dessus) est localisée dans la boucle intérieure.

Nouveau calcul de métriques groupées

• Description du problème

  Comme nous l'avons déjà expliqué, tous les éléments groupés d'une métrique groupée sont recalculés dans leur ensemble. Cela signifie que si nous avons une métrique groupée sur 1000 éléments groupés et que l'un d'entre eux nécessite un nouveau calcul de l'année précédente, suite à un nouvel événement reçu, alors les 1000 éléments groupés sont recalculés pour toute l'année précédente.

• Solutions possibles

  Les propositions de solutions suivantes peuvent aider à réduire ce problème, mais ils ne sont pas toujours applicables et chacun a ses inconvénients. Il importe de comprendre le problème et son coût approximatif et de comparer ce coût au coût des solutions suggérées.

  • Lorsque le nombre d'éléments groupés est faible, nous pouvons considérer de définir chaque élément comme métrique à part. L'inconvénient de cette approche est bien sûr le coût de maintenance qu'elle engendre, maintenir plusieurs métriques mais également ne pas pouvoir effectuer de rapport pour la métrique entière et parcourir un élément groupé spécifique
  • Lorsque le nombre d'éléments groupés est grand mais qu'un seul ou quelques uns d'entre eux sont fréquemment recalculés, nous pouvons étudier la possibilité de mettre ces éléments groupés dans une métrique à part et de laisser tous les autres éléments groupés dans l'autre métrique
  • Utilisez fréquemment un gel de calcul pour le contrat/métrique approprié afin que cette métrique n'ait jamais de nouveaux calculs trop longs
  • Procédez à quelques changements dans les adaptateurs et sources de données pour ne plus avoir de long nouveaux calculs (c.-à-d. ne pas envoyer d'événements dont l'horodatage date de plus d'un mois)

Commutation de contexte

• Description du problème

  Comme précédemment expliqué, la commutation de contexte se fait dans la boucle la plus intérieure. En d'autres termes, pour chaque événement devant être géré par chaque élément groupé. Lorsqu'une métrique reçoit de nombreux événements et que chacun est géré par beaucoup d'éléments groupés, cette quantité peut être très élevée. Ajoutez à cela que l'opération de commutation de contexte est assez coûteuse (par rapport au traitement de l'événement lui-même dans la logique applicative) et un problème se pose.

  Le coût de l'opération de commutation est proportionnel à la taille des données qui sont "commutées". Les données que nous basculons durant la commutation de contexte sont les valeurs de toutes les variables globales dans notre logique applicative (également appelées "l'état"). Ainsi, plus vous avez de variables globales et plus leur taille est grande, plus la commutation de contexte est coûteuse.

  Il n'est pas recommandé d'utiliser des plans de logique applicative dans des métriques groupées, particulièrement si la taille de ces plans peut être grande.

• Solutions possibles
  • Réduisez le temps de chaque commutateur de contexte

    L'idée est de réduire la taille de l'état (variables globales). Vous pouvez adopter cette approche en réécrivant la logique applicative pour qu'elle ne contienne aucun plan. Bien sûr ce n'est pas toujours possible, mais néanmoins recommandé lorsque c'est le cas.

  • Réduire la quantité des commutateurs de contexte

    Lorsque le groupement est petit, il est possible de créer une métrique à part pour chaque élément groupé.

    Evitez les métriques groupées qui comprennent de nombreux éléments groupés s'enregistrant auprès des mêmes événements. L'idée ici est la suivante :

    Si chaque événement est géré par un seul élément groupé, alors le montant de la "commutation de contexte" est proportionnelle au nombre d'événements

    Si chaque événement est géré par tous les éléments groupés, le montant de la "commutation de contexte" est proportionnel au nombre d'événements fois le nombre d'éléments groupés.

    Créez une métrique non groupée qui calculera le résultat pour tous les éléments groupés d'origine (maintenant simples ressources et plus éléments groupés). Faites en sorte que cette métrique envoie le résultat de chaque élément groupé en tant qu'événement. Créez une autre métrique groupée pour recevoir les événements de la première métrique, puis rapportez les valeurs reçues dans ces événements en tant que résultats. L'idée ici est que la grande quantité des événements de données brutes sera traitée par une métrique non groupée, tandis que la métrique groupée traitera un seul événement par période par élément groupé.