Bjorn, Thanks.
> > You don't even need to be that careful. Just run a read-only mysql > slave instance locally on the radius server and all mysql-related > performance problems will vanish. > We didn't try this. Our design goal is: - 250K users all needing to get on the network at the same time - each user performing 7 authentications during EAP negotiation - one hour duration to get everyone sorted This is about 486 authentications per second. I'm sure that a MySQL configuration can be constructed to achieve this, but I'm not confident it would be a simple setup. In contrast, the "files" module easily does this with a trivial configuration. In any case, assuming MySQL can be configured appropriately, I believe the thread-loss stability issue we experienced with high authentication rates would remain. See my longer reply to Alan for more details. > > If you do mysql accounting: use buffered-sql aka decoupled-accounting. > It won't fix the performance issues on your accounting mysql-server, but > it will decouple the radius server from any such problems. > Yes, we did use this feature to move the accounting backlog from the radius clients into the on-disk buffer. However, as you note it doesn't solve the accounting performance issues on the database. This was a significant issue for us as we are only able to learn the customers IP address (needed for many business processed) from the "accounting start" request. If this is delayed due to an avalanche of requests it affects customers in certain business states. We were able to gain a significant performance improvement over and above "rlm_sql" accounting by writing the essential data to a flat-file and then batch-loading that into the SQL database. The improvement came down to SQL transactions - the batch load only created one transaction for 1000's of accounting events rather than one transaction per event. Cheers, Claude. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
