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
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@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
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@lists.freeradius.org [mailto:freeradius-users-bounces+rwalker=sensorlogic.com@lists.freeradius.org] On Behalf Of tnt@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@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
Hi,
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.
depends on how the SQL tables are indexed, how the server is configured etc etc - certainly I've got some very complex queries that upon benchmarking against a million entries can run in less than 0.00 (ie MySQL basic counter in seconds isnt good enough to measure ;-) ) but if you want to take your data, then cache it in memory rather than query it.....well, that sounds much like having it in memory and not in a database at all - ie 'fastusers' and the such...rather than a database as we know it. alan
Maybe I am misunderstanding you, but are you saying there is already a method to pull the data from the database and cache it using 'fastusers'? I do not see anyway to do that... There are a lot reasons to keep the data in a database, look at the NAS table (I realize it is read-on-start for DOS reasons) but someone must be of the same mind set as me or there would be no client support in the SQL module. Roy ________________________________ From: freeradius-users-bounces+rwalker=sensorlogic.com@lists.freeradius.org on behalf of A.L.M.Buxey@lboro.ac.uk Sent: Sun 7/29/2007 3:42 PM To: FreeRadius users mailing list Subject: Re: SQL usage ideas Hi,
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.
depends on how the SQL tables are indexed, how the server is configured etc etc - certainly I've got some very complex queries that upon benchmarking against a million entries can run in less than 0.00 (ie MySQL basic counter in seconds isnt good enough to measure ;-) ) but if you want to take your data, then cache it in memory rather than query it.....well, that sounds much like having it in memory and not in a database at all - ie 'fastusers' and the such...rather than a database as we know it. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
No. Fastusers uses flat (users type) file. There is no "fastsql" module. Again, if you think that database stored on disk is too slow for you feel free to use heap (memory) tables. Ivan Kalik Kalik Informatika ISP Dana 30/7/2007, "Roy Walker" <rwalker@sensorlogic.com> piše:
Maybe I am misunderstanding you, but are you saying there is already a method to pull the data from the database and cache it using 'fastusers'? I do not see anyway to do that...
There are a lot reasons to keep the data in a database, look at the NAS table (I realize it is read-on-start for DOS reasons) but someone must be of the same mind set as me or there would be no client support in the SQL module.
Roy
________________________________
From: freeradius-users-bounces+rwalker=sensorlogic.com@lists.freeradius.org on behalf of A.L.M.Buxey@lboro.ac.uk Sent: Sun 7/29/2007 3:42 PM To: FreeRadius users mailing list Subject: Re: SQL usage ideas
Hi,
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.
depends on how the SQL tables are indexed, how the server is configured etc etc - certainly I've got some very complex queries that upon benchmarking against a million entries can run in less than 0.00 (ie MySQL basic counter in seconds isnt good enough to measure ;-) )
but if you want to take your data, then cache it in memory rather than query it.....well, that sounds much like having it in memory and not in a database at all - ie 'fastusers' and the such...rather than a database as we know it.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Phil Mayers -
Roy Walker -
tnt＠kalik.co.yu