[RADIATOR] Authorization delay problem SQL

Heikki Vatiainen hvn at open.com.au
Thu Nov 22 04:33:21 CST 2012

On 11/21/2012 04:00 PM, Ricardo Martinez wrote:

> 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.

What is the request rate you are using? Is it taking 2 to 3 seconds for
even single requests, are are you sending as fast as the client can.

Also, the DB looks quite good but I have seen responses in milliseconds
too. It depends on the DB, though.

> So I'm thinking that maybe Radiator and the queue could be causing
> the delay.

Did you check netstat output? What were the Recv-Q numbers?

Also, does Radiator log show anything unusual? Is it logging warnings
about duplicates?

Another thing you could try is radpwtst to see if it reports different

> 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?.

The queue is specific for socket. So the only packets in this particular
queue are the ones destined to Radiator. If it can not drain the queue
fast enough, then you could consider load balancing, FarmSize setting
(see ref.pdf) or other means to handle the load.


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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

More information about the radiator mailing list