Cannot control attribute ordering via "rlm_perl"

[Alan DeKok]

Claude Brown wrote:
> We didn't try this.

  That would fix it.

> 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

  That should be fixed, too.  There is NO NEED to do 7 SQL queries.  You
can put pretty much everything into "post-auth".

> - one hour duration to get everyone sorted

  Which works out to ~70 auths/s.  That's trivial.

> 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.

  It's dead easy.  Create a custom table as I said before.  SELECT on
that.  Do the select in the post-auth section.  Separate auth from acct.

  70 queries/s is a small system.  I've built MySQL systems which do
sustained hundreds of queries per second, and hundreds of accounting
packets/s.  It's pretty simple.

> In any case, assuming MySQL can be configured appropriately, I believe the thread-loss stability issue we experienced with high authentication rates would remain.

  I don't see why.  I've never seen any "thread loss" issue.

  If you use the same SQL module for auth & acct, you WILL run into
contention, locks, and massive delays.  The solution for that is above.

> 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.

  Wild.

> 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.

  That can help, yes.

> 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.  

  Well... I've run MySQL systems with 100's of accounting inserts/s,
using pretty much a stock config.  It should be possible.

  Alan DeKok.