just two questions

[Chris Knipe]

On Thu, Jun 12, 2014 at 3:14 PM, Alan DeKok <aland at deployingradius.com> wrote:
> Chris Knipe wrote:
>> Now given my specific application that I use Radius for, the elapsed times
>> are OK for the majority of requests (the sub 100ms range is fine).
>
>   100ms for a request?  That's terrible.  It indicates something wrong
> with your configuration.
>
>   If you put an entry into the "users" file in the default config, the
> server can do ~5K auths/s.  That's 2 microseconds each, or 50K times faster.

Yes.  Unfortunately, I need to SSH/Telnet into a load balancer, and
set up certain parameters for each unique session.  This isn't
traditional PPP based authentication, this is actually application
level authentication and application load balancing. :-)  Sub 100ms is
great for what I authenticate and the process involved in terms of
authenticating.

Radius is and can be used for more than just traditional PPP
authentication, yes?



>> Under what circumstances will FR "drop" a request (i.e. dropped 3110).
>
>   When a request is blocked, and the NAS transmits a new request using
> the same src/dst IP/port and RADIUS ID.

Interesting, considering that the application wasn't programmed to do
ANY re-transmissions.  It does do re-transmissions now though, but
those stats were pulled prior to re-transmissions being introduced
inside the application.  Would a request not also be dropped if


>> Also, would it be possible to be able to get stats for the thread pool
>> through radmin as well?
>
>   Sure.  Send a patch. :)

If I was a C programmer, I would have.  Unfortunately I know diddly
squat about C.  See it then as a feature request :-)


>> I've been experiencing very weird, intermittent and seemingly random
>> timeouts from FR, and after increasing (doubling) the size of my thread
>> pool, most of my issues seemed to have gone away.  Surely, those kind of
>> stats in terms of the thread pool will not only be very helpful, but it will
>> be absolutely beneficial in terms of debugging performance issues?
>
>   Not really.  Increasing the size of the thread pool is putting a
> band-aid on the problem.  It won't fix anything.

It will fix allot if you KNOW your authentication process WILL be
slow.  Since I've put the 'band aid' on, I have not had one single
issue with either auth or acct, again, specific to my application per
say.  Unfortunately, in real world cases it is not always possible to
process authentication requests sub 2ms, or whatever the 'ideal'
number would be.  Sometimes you just have to work with what you have,
and make the best of it.

--
Chris.