(RADIATOR) bad perfomance due slow DB??

Hugh Irvine hugh at open.com.au
Wed Apr 17 18:17:35 CDT 2002


Hello Slava -

Your analysis of the situation is quite correct, the session database is 
updated before the request is proxied, therefore if the database is slow, 
everything will be slow in consequence.

You can check the packet queues by using the "netstat" utility. 

You can enable the LogMicroseconds parameter in later versions of Radiator 
(requires the Time-HiRes module from CPAN), which will show you the time 
being taken for each operation in a trace 4.

If you send me a copy of the configuration file (no secrets) together with a 
trace 4 debug I will take a look.

regards

Hugh


On Thu, 18 Apr 2002 01:10, Rimdenok, Sviatoslav wrote:
>   Hello All,
>
>   I've got a question.. We have Radiator on our site that is proxying most
> of the auth/acct requests to the remote RADIUS servers. Also we use
> PostgreSQL database to keep  the RADONLINE database (for example to see the
> amount of the current connected users). That means for each new request
> from NASes Radiator updates RADONLINE table and resend (proxies) that
> request to remote RADIUS server.
>
>   Usually we receive a reply from remote RADIUS servers in 1 sec(max 2
> secs). But 3 days ago we have found that according to the Radiator log, the
> delay between sending and receiving the answer was up to 15-20 secs ( I
> checked "*** Sending to ...., "*** Receiving from ..." lines with
> corresponding Code and Identifier values).
>   These remote RADIUS servers belong to different companies, - so I don't
> think that suddenly all of them became "very slow". But at the same time we
> have seen that PostgreSQL DB was running very slow.
>
>    Here my question comes : how Radiator is working internally? For
> example, if the SQL DB backend is very slow - does it block/affect Radiator
> performance? My idea is that Radiator was running very slow during
> communication with PostgreSQL, perhaps (!? I know nothing about Radiator
> internals) it was waiting for finishing operations with DB before
> proceeding the RADIUS packets from the socket queue.. Is it possible to
> check the amount of packets waiting/staying in the queue?
>
>    Most probably I wrote something wrong above, but I'd appreciate to hear
> expert opinion about that case..
>
>    Thank you so much in advance!
>
>    sincerely yours,
>    Slava
>
>
> Sviatoslav Rimdenok
> System Administrator
> COLT Telecom AG
> Badenerstrasse 820
> CH-8048 Zürich
>
> t: 	+41 1 5 600 900
> f:	 	+41 1 5 600 910
> e:            mailto:sviatoslav.rimdenok at colt.ch
>                www.colt.ch
>
> we make business straight.forward
>
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list