On Sat, 17 Aug 2002, Torry Crass wrote:
> Here goes...
>
> PIII - more than enough really.
>
> 32MB of ram - fine for a smaller load but more is better.
That's only for RADIUS and only if you keep a few db connections open. MySQL
will need another 32-48MBs and you may need more if you keep a lot of open db
connections.
>
> MySQL - Here's how MySQL and most other SQL Databases work in regards to
> scalability. They're extremely much faster than flat text files in the
> short and medium term. Performance is excellent and does not begin to be
> compromised by user numbers until your user table begins to become
> exceedingly large (assuming you're not a HUGE national ISP and do decent SQL
> maintenance this should be little trouble) at this point performance will
> start going down hill, probably at roughly 100,000 or so it will be a little
> noticable. The reason being is that MySQL has to search through the entire
> table to find the exact entry that it's looking for, this takes time and
> uses processor cycles thus your performance 'could' go downhill.
That's why indexes are there. The freeradius tables definitions all contain
indexes for several variables. We don't maintain multi column indexes but that's
not really a big problem. Anyway, here's a small overview of the required
indexes per database query:
authorize_check: radcheck.UserName
authorize_reply: radreply.UserName
authorize_group_check: (usergroup.UserName,usergroup.GroupName),
groupcheck.GroupName
authorize_group_reply: (usergroup.UserName,usergroup.GroupName),
groupreply.GroupName
accounting_update: (AcctSessionId,UserName,NASIPAddress,AcctStopTime)
accounting_stop: (AcctSessionId,UserName,NASIPAddress,AcctStopTime)
The parentheses mean multi column indexes
The mysql table definitions contain the following usefull column indexes:
radcheck: UserName
radreply: UserName
usergroup: UserName
radgroupcheck: GroupName
radgroupreply: GroupName
radacct: AcctSesionId,UserName,NASIPAddress,AcctStopTime
As you can see most of the required indexes are there. We could create multi
column indexes for the usergroup and radacct tables but that's not really
necessary. MySQL will use the least rows index if there isn't any multi column
index and we can get a few rows by using the UserName index in usergroup
table and the AcctSessionId index in the radacct table.
Consequently, I don't think you will see any performance degradation with MySQL.
> At this
> point it's probably better to split the user table into separate sections,
> such as by location or dialin number or something of the sort for easy
> management and all of that things. I 'may' eventually submit a better table
> structure for radius since the current one when interfaced with dialup_admin
> is...well...seriously lacking from a database standpoint and fails to take
> into consideration a number of basic database design issues, but we'll see.
Could you give an overview of your thoughts here? Optimizing sql is really
important since even if someone does not use it for authentication/authorization
he will most certainly use it for accounting (which is usually X times larger
than the user database).
Also what do you mean by 'when interfaced with dialup_admin'? Do you see a
problem in the interface design or in the database design?
>
> Apache - This should not even remotely affect the performance of the server
> unless it's a dumpster box anyhow or/and you're using it for webhosting or
> whatever as well. Which would be really not very smart to do on you auth
> server anyhow, but hey, that's just my opinion.
>
> Anyhow that's my 2 cents, sorry about how long this took to compose but I
> just found it in my drafts as I am sitting in Perkins at 1a.m. - go
> figure...
>
> ~Torry Crass
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 10 7721861
'Go back to the shadow' Gandalf
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
