Les données de transaction sont souvent recueillies pour les comparer à des seuils ou pour calculer les pourcentages périodiques éventuels de réussite. Par exemple, toutes les cinq minutes une transaction virtuelle est effectuée avec un système et le résultat (temps de réponse en millisecondes), est enregistré comme illustré ci-dessous :
[…] 1/1/2004 00:00 432 1/1/2004 00:05 560 1/1/2004 00:10 329 1/1/2004 00:15 250 01/01/04 00:20 275 01/01/04 00:25 2860 01/01/04 00:30 140 […]
Dans d'autres situations, au lieu d'utiliser des transactions virtuelles, il se peut que des accès aux transactions réelles aient lieu dans un système. Dans ces cas, des centaines voire des milliers de transactions peuvent être accomplies toutes les heures.
Dans les deux cas susmentionnés, le chargement d'un tel volume d'informations dans CA Business Service Insight doit être évité si possible.
Le rassemblement des données par périodes est la meilleure façon de réduire les quantités de données. Lorsque le seuil de réussite est fixé, vous pouvez accomplir l'agrégation en laissant l'adaptateur compter le nombre de transactions réussies dans la période ainsi agrégée. Par exemple, si le seuil de réussite dans l'exemple précédent est défini à 500 millisecondes, seules cinq transactions sur sept ont réussi dans la période affichée. Le problème avec cette approche est le seuil fixe : que se passera-t-il s'il est nécessaire de changer le seuil plus tard ? Dans une telle situation, les données brutes doivent être relues et testées par l'adaptateur avec le nouveau seuil.
Par conséquent, dans une situation optimale l'adaptateur doit agréger les données de transaction de manière flexible, sans perdre de données significatives.
Une solution limitée consiste à laisser l'adaptateur tester les transactions avec plusieurs seuils. Il existe deux méthodes pour ce faire :
Les deux options présentent les mêmes problèmes : les seuils ne peuvent être changés à l'avenir que dans un petit ensemble de valeurs prédéfinies.
Hypothèse : les seuils potentiels sont des multiples d'un certain nombre. Par exemple, tous les seuils (en millisecondes) sont un multiple de 250. Ainsi, 0, 250, 500, 1750 et 3000 millisecondes sont donc tous des seuils potentiels.
Suivant cette hypothèse, la solution suggérée est d'agréger les transactions en arrondissant toutes les valeurs sur le multiple commun, et en comptant le nombre de transactions pour chaque valeur arrondie. Event Type = {RangeFrom, RangeTo, TransactionCount}
Par exemple, les événements suivants seront générés afin d'agréger les données affichées ci-dessus, où le multiple commun est 250 millisecondes :
{1, 250, 2}
{251, 500, 3}
{501, 750, 1}
{751, 1000, 1}
Commentaires :
L'horodatage de ces événements serait le même. Par exemple, tous les événements agrégés peuvent se produire le 01/01/07 à 00:00., et il peut y avoir un autre ensemble d'événements pour l'échantillon d'heure suivant, le 01/01/07 à 01:00, en supposant une agrégation horaire)
RangeTo est calculé en arrondissant la transaction au commun multiple (voir ci-dessous).
RangeFrom est égal à RangeTo moins le multiple, plus 1. Cette valeur est spécifiée pour des raisons de clarté uniquement, et vous pouvez l'ignorer.
Par exemple, une agrégation horaire s'afficherait comme suit (remplacez MULTIPLE par la valeur multiple) :
select trunc (time_stamp, 'hh') "TimeStamp",
round (response_time/MULTIPLE, 0)*MULTIPLE-MULTIPLE+1 "RangeFrom",
round (response_time/MULTIPLE, 0)*MULTIPLE "RangeTo",
count (*) "TransactionCount"
from t_log
group by trunc (time_stamp, 'hh'),
round (response_time/MULTIPLE, 0)*MULTIPLE
Dans la logique applicative, la condition suivante peut être appliquée aux événements :
If eventDetails("RangeTo")<=Threshold Then
SuccessfulTransactions=SuccessfulTransactions+eventDetails("TransactionCount")
End If
Quelques perspectives pour conclure :
|
Copyright © 2013 CA.
Tous droits réservés.
|
|