SQL usage ideas

Roy Walker rwalker at sensorlogic.com
Sun Jul 29 22:30:06 CEST 2007


Well if you understand server/client systems, no client request is INIFINATELY faster than a server cached request.  So when you get to the point where you need to handle several hundred requests a second, you do the math.

Roy

-----Original Message-----
From: freeradius-users-bounces+rwalker=sensorlogic.com at lists.freeradius.org [mailto:freeradius-users-bounces+rwalker=sensorlogic.com at lists.freeradius.org] On Behalf Of tnt at kalik.co.yu
Sent: Sunday, July 29, 2007 1:58 PM
To: FreeRadius users mailing list
Subject: Re: SQL usage ideas

How about you let SQL server deal with SQL queries:

http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

Ivan Kalik
Kalik Informatika ISP


Dana 29/7/2007, "Roy Walker" <rwalker at sensorlogic.com> piše:

>I think I have a pretty good idea of how the sql structure works for radius.  Here are some ideas I have:
> 
>It looks like the clients query is cached at startup (guessing this since I don't see thousands of queries to the nas table like I do to the other tables).  One really useful option would be to add an option to read some of the  database tables into the radius servers memory on startup.  This would be EXTREMELY useful for my case in that I am using groups and could set the radgroupcheck and radgrouprely tables (since they just about never change, and I would be willing to deal with a restart if they did need to change) to load into memory on the radius server and still allow me to dynamically add/remove users from groups.  Would be a good idea to offer this to every read only table (some like radpostauth just would not make sense), some may not be used often, but you never know.
> 
>Thoughts?
> 
>Roy
>
>

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html




More information about the Freeradius-Users mailing list