>
> I'd normally just put users into SQL.
>
Yes - this was our default approach. It made the most sense to us initially.
rlm_sql
- highly dynamic
- need non-trivial skills to config "right" for performance
- need extra h/w to scale for white-hot performance
rlm_files
- not so dynamic (regular reloads provide a reasonable trade-off)
- trivial to config for performance
- unlikely to need extra h/w for white-hot performance
Our custom module
- highly dynamic
- trivial to config for performance
- unlikely to need extra h/w for white-hot performance
:)
>
> > FreeRADIUS core is very stable. But MySQL adds instability we have been
> unable to identify or reproduce in our environment.
>
> That's odd. While MySQL isn't perfect, I have successfully used it in
> systems with 100's of transactions/s. There was a VoIP provider ~8
> years ago using it with ~1K authentications/s.
>
I too am surprised that we had these stability issues. We use MySQL for pretty
much everything we do - web-sites, customer management, inventory, real-time
network analytics, usage accounting, etc. etc. Some of these systems have
significant load - possibly more than radius. And we have had no stability
problems.
>
> MySQL does have concurrency issues. But if you split it into
> auth/acct, most of those go away. i.e. use one SQL module for
> authentication queries. Use a *different* one for accounting inserts.
>
Yes, we did this. We have two authentication servers and two accounting
servers, with hash-based load-balancing proxies at the front.
This gave us a huge performance boost - and met our performance goals. But the
stability issue just never went away.
> If you also use the decoupled-accounting method (see
> raddb/sites-available), MySQL gets even faster. Having only one process
> doing inserts can speed up MySQL by 3-4x.
Yes, we did this too. Also helped, but it was getting too far behind in some
situations. We've replaced with batch-loading of batch files.
>
> Using a database WILL be faster than reading the file system.
>
Nah :)
Ignoring the effort to config the DB correctly, you still have most DBMS's
using a separate server process. This requires IPC (probably over a network)
and OS context-switching between processes.
In contrast, fopen, fgets, fclose only requires a switch into kernel mode and
back again. If the block-buffer pool has the data (it usually will) then the
process may not even go into a wait-state.
>
> You can do the same kind of thing with SQL. Simply create a table,
> and do:
>
> update request {
> My-Magic-Attr = "%{sql: SELECT .. from ..}"
> }
>
This is a very cool idea - I wish we had tried it! This would have allowed us
to put the rlm_sql processing into "postauth" and that may have made a huge
difference.
>
> That's just weird. SQL should be fine, *if* you design the system
> carefully. That's the key.
>
Yes. I contrast that with a trivial "C" module and some local files.
>
> It's not a race condition, it's lock contention.
>
I don't *know* if it was a race condition, but I know it wasn't lock
contention. As the threads gradually got lost we would look in the database to
find corresponding stalled queries. None would be present.
>
> If it works for you...
>
> But it's really just a re-implementation of a simple SQL table.
Functionally, yes. The benefits are more in simplicity of configuration, and
performance per server-dollar. Plus for us, a stability issue.
Thanks for all your help.
Cheers,
Claude.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
