I dati della transazione vengono spesso raccolti in modo da corrispondere alle soglie o per essere in grado di calcolare le eventuali percentuali periodiche di successo. Ad esempio, ogni cinque minuti viene eseguita una transazione virtuale rispetto al sistema e al risultato (tempo di risposta in millisecondi) e archiviata come mostrato di seguito:
[…] 1/1/2004 00:00 432 1/1/2004 00:05 560 1/1/2004 00:10 329 1/1/2004 00:15 250 1/1/2004 00:20 275 1/1/2004 00:25 2860 1/1/2004 00:30 140 […]
In altri casi, invece di utilizzare transazioni virtuali, è possibile accedere alle transazioni effettive eseguite in un sistema. In questi casi, è possibile eseguire centinaia o migliaia di transazioni ogni ora.
In entrambi i casi descritti, è necessario evitare, per quanto possibile, il caricamento di un tale volume di informazioni in CA Business Service Insight.
L'aggregazione dei dati per periodi di tempo è il modo migliore per ridurre le quantità dei dati. Quando viene fissata la soglia in base alla quale il successo è misurato, l'aggregazione può essere eseguita consentendo all'adapter di contare il numero di transazioni nel periodo aggregato che hanno avuto esito positivo. Ad esempio, se la soglia di successo nell'esempio precedente è impostata su 500 millisecondi, solo cinque transazioni su sette sono state completate correttamente entro il periodo visualizzato. Il problema con questo approccio è la soglia fissata: cosa succederebbe se, successivamente, un utente desiderasse modificare la soglia? In una situazione simile, i dati non elaborati devono essere riletti e verificati dall'adapter rispetto alla nuova soglia.
Di conseguenza, l'adapter deve aggregare i dati delle transazioni in un modo ottimale e flessibile senza perdere dati significativi.
Una soluzione limitata è consentire all'adapter di verificare le transazioni rispetto a diverse soglie. Esistono due modi per tale scopo:
Entrambe le opzioni presentano lo stesso problema, ossia le soglie possono essere modificate in futuro solo all'interno di un piccolo gruppo di valori predefiniti.
Presupposto: tutte le soglie potenziali sono un multiplo di un dato numero. Ad esempio, tutti i valori di soglia (in millisecondi) sono multipli di 250, quindi 0, 250, 500, 1750 e 3000 millisecondi sono tutti possibili soglie.
In base a questo presupposto, la soluzione suggerita è aggregare le transazioni arrotondando tutti i valori al multiplo comune e contando quante transazioni rientrano in ogni valore arrotondato. Event Type = {RangeFrom, RangeTo, TransactionCount}
Ad esempio, gli eventi seguenti verranno generati per aggregare i dati visualizzati sopra, in cui il multiplo comune è 250 millisecondi:
{1}, 250, 2
{251, 500, 3}
501, 750, {1}
751, 1000, {1}
Commenti:
La data/ora di tali eventi è la stessa. Ad esempio, tutti gli eventi aggregati potrebbero verificarsi il 1/1/2007 00:00 e potrebbe esserci un altro insieme di eventi per il prossimo campione il 1/1/2007 01:00, supponendo un'aggregazione ogni ora.
RangeTo viene calcolato arrotondando una transazione al multiplo comune (consultare la sezione successiva).
RangeFrom è RangeTo meno il multiplo, più 1. È specificato solo per motivi di chiarezza, ed è possibile ignorarlo.
Ad esempio, l'aggregazione per ora dovrebbe essere come segue (sostituire MULTIPLE con il valore del multiplo):
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
Nella business logic, la seguente condizione può essere applicata agli eventi:
If eventDetails("RangeTo")<=Threshold Then
SuccessfulTransactions=SuccessfulTransactions+eventDetails("TransactionCount")
End If
Alcune riflessioni conclusive:
|
Copyright © 2013 CA.
Tutti i diritti riservati.
|
|