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-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En nombre de Heikki Vatiainen Enviado el: martes, 20 de noviembre de 2012 18:21 Para: radiator@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 <h...@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@open.com.au http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
