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