|
|
|
Los datos de las transacciones a menudo se recopilan para compararlos con determinados umbrales o para poder calcular el porcentaje periódico de éxito final. Por ejemplo, cada cinco minutos se registra una transacción virtual en un sistema y el resultado (tiempo de respuesta en milisegundos) se almacena como se indica a continuación:
[…] 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 […]
En otras situaciones, en lugar de utilizar transacciones virtuales, se puede tener acceso a transacciones reales en un sistema. En estos casos, se pueden realizar cientos o incluso miles de transacciones cada hora.
En los dos casos anteriores, debe evitarse cargar tal volumen de información en CA Business Service Insight, si se puede.
Agregar los datos por períodos de tiempo es la mejor forma de reducir la cantidad de datos. Cuando se fija el umbral de acuerdo al cual se va a medir el éxito, el proceso de agregación se puede llevar a cabo permitiendo al adaptador contar el número de transacciones dentro del período agregado que ha tenido éxito. Por ejemplo, si el umbral de éxito en el ejemplo anterior se establece en 500 milisegundos, solamente cinco de cada siete transacciones tuvieron éxito dentro del período mostrado. El problema con este enfoque es el umbral fijado: ¿qué pasaría si hubiera que cambiar el umbral más adelante? En este caso, el adaptador deberá releer y probar los datos sin procesar comparándolos con el nuevo umbral.
Por lo tanto, lo ideal sería que el adaptador agregase los datos de las transacciones de una manera flexible y sin perder datos significativos.
Una solución limitada es permitir al adaptador probar las transacciones comparándolas con varios umbrales. Hay muchas formas de hacerlo:
Las dos opciones tiene el mismo problema: los umbrales se podrán cambiar en el futuro solamente dentro de un conjunto pequeño de valores predefinidos.
Supongamos que todos los umbrales potenciales son múltiplo de cierto número. Por ejemplo, todos los umbrales (en milisegundos) son múltiplo de 250, de modo que 0, 250, 500, 1750 y 3000 milisegundos son todos umbrales potenciales.
De acuerdo con este supuesto, la solución sugerida es agregar transacciones redondeando todos los valores al múltiplo común, y contar cuántas transacciones se incluyen dentro de cada redondeado. Tipo de evento = {RangeFrom, RangeTo, TransactionCount}
Por ejemplo, se generarán los eventos siguientes para agregar los datos mostrados anteriormente, donde el múltiplo común es 250 milisegundos:
{1, 250, 2}
{251, 500, 3}
{501, 750, 1}
{751, 1000, 1}
Comentarios:
La marca de tiempo de esos eventos sería la misma. (Por ejemplo, todos los eventos agregados pueden ocurrir el 1/1/2007 00:00., y puede haber otro conjunto de eventos para la siguiente muestra de hora el 1/1/2007 01:00 en el supuesto de haya agregación cada hora).
RangeTo se calcula redondeando una transacción al múltiplo común (vea la información a continuación).
RangeFrom es RangeTo menos el múltiplo, más 1. Se especifica para proporcionar claridad solamente; se puede omitir.
Por ejemplo, una agregación por cada hora tendría un aspecto similar a lo siguiente (reemplace MULTIPLE por el valor del múltiplo):
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
En la lógica de negocios, se puede aplicar a los eventos la condición siguiente:
If eventDetails("RangeTo")<=Threshold Then
SuccessfulTransactions=SuccessfulTransactions+eventDetails("TransactionCount")
End If
Algunos datos decisivos:
| Copyright © 2012 CA. Todos los derechos reservados. | Enviar correo electrónico a CA Technologies acerca de este tema |