[RADIATOR] Authorization delay problem SQL

[Ricardo Martinez]

Thanks Heikki.
This is very useful information for us.  As I mention, we're trying to
track down a problem with delay in the Authorization process, and we're
investigating if Radiator could be the problem.  So far, the DB seems not
to be the problem, according to the statistics file in Radiator the answer
from database is very quick, from 0.03 secs to 0.07 secs, but the request
using the "simpleClient.pl" tool are taking near to 2 or 3 secs to be
answered. So I'm thinking that maybe Radiator and the queue could be
causing the delay.
So... a couple more questions.
The way to process the Access-Request packets is in FIFO order?
 Let's suppose the Radiator is running and listening , and for some reason
the UDP queue  starts to fill up, is there a way I can optimize or
prioritize the  handling of these packets in a way to avoid delay and
clear the queue?.

Hope you can help me here.
Thanks in advance,
Regards,
Ricardo Martinez.-

-----Mensaje original-----
De: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] En
nombre de Heikki Vatiainen
Enviado el: martes, 20 de noviembre de 2012 18:21
Para: radiator at open.com.au
Asunto: Re: [RADIATOR] Authorization delay problem SQL

On 11/20/2012 09:08 PM, Ricardo Martinez wrote:

> This make me think, is there any queque in Radiator for the
> Authorization packets?  Can I see this queque?, can I take measures?

The queue is UDP socket buffer the operating system maintains. Radiator
reads requests from the socket one by one. In other words, if there are
multiple incoming requests, it does not first read them all and then start
processing them.

You can try e.g., 'netstat -ulpn' on Linux to see socket buffer (Recv-Q)
usage. Try e.g. kill -STOP <radiusd pid> and then use radpwtst to send a
request. Since radiusd is stopped you will see how the Recv-Q count grows.
When you do kill -CONT <radiusd pid> radiusd will read the requests and
Recv-Q is empty again.

> For example, if 10 or 20 Access-Request packet arrives to Radiator,
> how are processed?

The are processed one by one from the incoming socket.

You should turn on 'LogMicroseconds' global option and then test with
radpwtst and other clients. With Trace 4 you will see exactly how long DB
query takes when you compare the debug log microsecond timestamps.

Thanks,
Heikki

--
Heikki Vatiainen <hvn 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
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator