FreeBSD anyone?

[Dusty Doris]

> Thanks for the advice.

Didn't get a change to get good numbers for you today, but here is at 
least something.

I took a look at our records for today and we have about 70,000 
entries, with only 1500 of them without a stop yet.  I can't get a good 
estimate at packets right now because I'm not sure how many updates we 
receive.

But if I were to take a guess and say there is 1 update per user session 
(very rough guess), then that puts us at about 210,000 packets in 24 hours 
with 1 start, 1 update, and 1 stop.  That makes our average about 
2.5/second.

Now, there are probably at least a few more than 1 update, so that number 
could be a bit higher.  Also, our usage definately has big peaks during 
certain times of the day.  But, I'd guess that we don't hit much more than 
20-30/second during those peaks.

>
> I've found that the performance problem goes away when I test with interim 
> accounting records instead of start records.
>
> I haven't figured out why start records generate such a performance hit. Any 
> ideas?

That seems odd to me.  I don't have any ideas on that, looking at the 
queries in sql.conf it seems to me that the accounting start should be 
faster since it begins with just a plain insert vs the update starting 
with an update that contains a where clause.

Do you have a my.cnf file tuning that db?  I can't explain update vs 
insert, but it could help with performance.

Did you tweak sql.conf or radiusd.conf either?  Perhaps you could try 
adjusting the num_sql_socks and connection_failure_retry_delay numbers in 
sql.conf and the thread pool section of radiusd.conf.

Also, you can do many other things to help especially turning off radutmp. 
I'd also comment out any other modules that aren't used.  Actually read 
tuning_guide in the doc dir, there are some good comments there.

Also, remember that the sql performance is going to be primarily dependant 
on your configuration vs freeradius in general.  For example, the CPU, 
disk speed, ram, etc.. will have more of an influence than anything else.

> We're currently looking at radrelay. That sounds like a good idea.

Its been working great for us.

However, in the CVS head they now have sqlrelay which I'd definately 
considering taking a look at.  It does the same thing as radrelay, but 
sends over sql queries to your db instead of radius packets.  Might be 
nice to not have to worry about an additional process (radiusd) on your 
sql servers.  I'll test it out one of these days if I ever get some spare 
time.

-Dusty