HUP handling: a thought
aland at deployingradius.com
Tue May 8 18:21:04 CEST 2007
Claudiu Filip wrote:
> That is a good idea, but on most applications where a "state machine"
> was critical, users solved the problem by using a database.
Which won't handle 100 DB lookups per packet. That's why main memory
is used: fast access to necessary configuration information.
> FR has the possibility to change those 1000 users without restarting
Because it queries a database for those users. Often only once per
request. Maybe 2-3 times, but definitely not 10-20. If all of the
configuration information was in a DB, it would do 100-200 DB lookups
per request. Even if they were cached, that's still a huge load.
> We can easily grow from 1000 users to 1M users.
> Imho, the next step is to have the possibility to change radius
> clients on the fly. Not only VoIP carriers or access providers want to
> manage/grow to 10k radius clients.
I know. That's the goal.
> If IP addresses are not so easy to compare when (re)building large lists, why
> not having a numeric ID for each client to seek faster the tree and
> change the IP address, secret, name?..
> This numeric ID can also be used for snmp requests and it will be
> natural for users running a database backend with a "serial" field.
2.0-pre already does that for SNMP requests.
Maybe the solution is to separate the server into multiple processes.
One can handle packets going in and out, but wouldn't connect to a DB.
Another would connect to the DB, but would only have the first program
as a listed as a client.
That separation would solve most of the reloading problems. The only
difficulty left would be fast sharing of packets between the programs.
But I suspect that for almost any real-world traffic, the extra overhead
of moving 20 packets/s between two processes would be negligible.
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Devel