Cannot control attribute ordering via "rlm_perl"

[Fajar A. Nugraha]

On Tue, Jan 24, 2012 at 9:53 AM, Claude Brown
<Claude.Brown at vividwireless.com.au> wrote:
> 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.

So to confirm, your new module is basically files module, but it does
NOT cache anything in directory, but re-read the files on disk for
every request, is that correct?

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

It's possible to work around that, but you need deep-enough knowledge
about sql performance tuning.

For example, in our setup the number of concurrent autentication
request that can go through and still leave mysql respond in timely
manner is about 128. So we limit the bumber of sql threads to that
number.

Using unlang, we then create a failsafe scenario, so if that a
concurrent request comes that exceed the number of max sql thread, it
would automatically accepted (i.e. basically Auth-Type=accept), but
with a low timeout (e.g. 1 hour). That way the user can connect, but
it'd reconnect and reauthenticate later when the system is (hopefuly)
not-so-busy.

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

Interesting. I wonder if we can hack a detail reader to behave similar, e.g.:
- send "start transaction"
- read lines from detail file
- every 10 seconds or before deleting the detail file, send a "commit"

-- 
Fajar