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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
