[RADIATOR] Performance logging

Hugh Irvine hugh at open.com.au
Wed Mar 23 17:28:45 CDT 2016


Hi Alex -

I may have misunderstood your original question - %s is only the offset in the current second.

For what you want to do you should probably be using “LogMicroseconds” global parameter (requires “Time-Hires” from CPAN).

Otherwise you can add your own custom time attributes in the current request packet and post-process the logs to derive the deltas.

The AuthBy INTERNAL clause is very handy for this sort of thing if you add them into your processing sequence at the relevant places.

regards

Hugh


> On 23 Mar 2016, at 21:03, Hartmaier Alexander <Alexander.Hartmaier at t-systems.at> wrote:
> 
> Hi Hugh,
> is that a microsecond counter starting when the request is received?
> Imho the wording is confusing, will it wrap around when the request takes more than one second?
> How would I log the microseconds as integer for requests that take longer than one second?
> 
> Thanks, Alex
> 
> On 2016-03-23 10:33, Hugh Irvine wrote:
>> Hello Alex -
>> 
>> %s is the number of microseconds in the current second.
>> 
>> From section 5.2 of the Radiator 4.16 reference manual (“doc/ref.pdf”):
>> 
>> 	%s  Microseconds in the current second
>> 
>> Note that the RADIUS protocol only defines times in seconds.
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>>> On 23 Mar 2016, at 19:44, Hartmaier Alexander <alexander.hartmaier at t-systems.at> wrote:
>>> 
>>> Hi,
>>> I'd like to add the time it took to craft a response for each request to
>>> the logs.
>>> In the reference manual I only found %E which is 'The elapsed time in
>>> seconds since the packet was received. Can be used to log
>>> processing time for proxied packets etc.'.
>>> For this logging I'd need at least milli- or better microseconds.
>>> Did I overlook a placeholder for those or do they currently not exist?
>>> 
>>> How do you guys monitor response time to prevent clients marking a
>>> server as unresponsive because it takes it too long to send a response,
>>> most of the time because of a backend like LDAP, SQL database or proxied
>>> radius server being slow?
>>> 
>>> Thanks, Alex
>>> 
>>> 
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
>>> Handelsgericht Wien, FN 79340b
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> Notice: This e-mail contains information that is confidential and may be privileged.
>>> If you are not the intended recipient, please notify the sender and then
>>> delete this e-mail immediately.
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> --
>> 
>> Hugh Irvine
>> hugh at open.com.au
>> 
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>> DIAMETER, SIM, etc.
>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> 
> 


--

Hugh Irvine
hugh at open.com.au

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.



More information about the radiator mailing list