#19 Stats tracking bugs/improvements

[The Master]

I've made some improvements to the Ganimede server to
get a better feel of the usage patterns from my IIS
application.

First, the average number tends to become garbage
after a long run period (in our case, 2 days and about
30,000 requests). I've modified the code as follows to
make a more accurate average available:

Add to tt_agents table:

FIELD f_exec_tot AS DECIMAL

Rewrote FreeAgent as follows:

PROCEDURE pFreeAgent : / Purpose: Free up agent
Notes: if agent is persistent will mark as
available
if non persistent it is shut down /
DEFINE INPUT PARAMETER pcAgentPort AS CHARACTER
NO-UNDO. / Port to free /
define variable tottime as integer no-undo.

FIND FIRST tt_agents WHERE tt_agents.f_port =

INTEGER(pcAgentPort)
EXCLUSIVE-LOCK NO-WAIT NO-ERROR.

IF AVAILABLE(tt_agents) THEN DO:
    fLogMsg(109,pcAgentPort, {&LogInfo}).
    lNoFreeAgent = FALSE.
    IF iStatistics = 1 THEN 
        ASSIGN tottime = ETIME - tt_agents.f_time
               tt_agents.f_exec_min = MINIMUM

(tt_agents.f_exec_min,tottime)
tt_agents.f_exec_max = MAXIMUM
(tt_agents.f_exec_max,tottime)
tt_agents.f_exec_tot =
tt_agents.f_exec_tot + tottime
tt_agents.f_exec_avr =
tt_agents.f_exec_tot /

tt_agents.f_exec_cnt NO-ERROR.
ASSIGN tt_agents.f_available = TRUE
tt_agents.f_time = ETIME NO-
ERROR.
END.
END.

Then I changed the showstat procedure to supply more
information back to the requester:

PROCEDURE pShowStat :
/*-----------------------------------------------------

---

Purpose: Show broker statistics
Parameters: in - broker admin pass

Comments: 02/24/06 KWS - Added additional stats
responses

---

-----------------------*/
DEFINE OUTPUT PARAMETER cStat AS CHARACTER NO-
UNDO.

DEFINE VARIABLE iAgtFree AS INTEGER    NO-UNDO.
DEFINE VARIABLE iAgtBusy AS INTEGER    NO-UNDO.
DEFINE VARIABLE iAgtTo   AS INTEGER    NO-UNDO.
DEFINE VARIABLE iTime    AS INTEGER    NO-UNDO.
DEFINE VARIABLE iDays    AS INTEGER    NO-UNDO.
define variable cAStat   as char no-undo.

/* Broker statistics */
ASSIGN iTime = INTEGER((ETIME - giStartTime) /

1000) / up time: seconds /
iDays = TRUNCATE(iTime / 86400,
0) / up time: days /
iTime = iTime - iDays *
86400 / this day seconds /
NO-ERROR.
IF iDays > 0 THEN
cStat = STRING(iDays) + ' day(s) and '.
cStat = cStat + STRING(iTime,'HH:MM:SS') + '&' +
STRING(giTotalReq) + '&' + STRING
(giSolveReq) + '&' +
STRING(giDenyReq) + '&' + STRING
(giErrReq).

/* Agent status */
FOR EACH tt_agents NO-LOCK:
    assign cAStat = cAStat + substitute

("&1|&2|&3|&4|&5|&6",

tt_agents.f_port,

tt_agents.f_available,

tt_agents.f_exec_cnt,

tt_agents.f_exec_min,

tt_agents.f_exec_max,

tt_agents.f_exec_avr) + "&".
IF tt_agents.f_available THEN
iAgtFree = iAgtFree + 1.
ELSE IF giExecTimeOut EQ 0 OR
(tt_agents.f_time + giExecTimeOut >
iTime) THEN
iAgtBusy = iAgtBusy + 1.
ELSE
iAgtTo = iAgtTo + 1.
END.

cStat = cStat + '&' + STRING(iAgtFree) + '&' + 
                      STRING(iAgtBusy) + '&' + 
                      STRING(iAgtTo) + '&' +
                      cAStat.

END PROCEDURE.

[Marian Edu]

Logged In: YES
user_id=486637

Hi there Master ;)

thanks for that... i didn't given too much attention to the
statistics thing lately, i was thinking it was a good thing
to put in place at the beginning but didn't heard to many
users asking for that nor using it... maybe it's the time
for me to get back on that and do a little bit of cleanup to
set things straight. Do you really think that the total time
an agent was serving can prove as a useful information, any
other candidates we might consider?

Regards,
Marian

[The Master]

Logged In: YES
user_id=1358187

Well, I picked the stats I did because I wanted to get a
feel fow how my call volume was spread across the ganimede
agents. Total time of execution is useful only in that it
gives you an idea of actual call volume. The
min/max/average numbers are more useful on a general basis.
Having the stats available via a call is VERY handy, but
I'm sure it adds some call time overhead.

I was considering adding a more robust logging system too,
but I haven't had the time to explore it. It would be kind
of nice to log errors to the syslog as well. I also want to
add another logging level to lower the number of "connect
disconnect" messages in the log files.