FreeRADIUS can't make progress under certain load

[rihad]

On 09/11/2011 04:58 PM, Alan DeKok wrote:
> rihad wrote:
>> On 09/11/2011 01:58 PM, Alan DeKok wrote:
>>>     Your Perl script is breaking the server.  Fix it.
>> I know that. The auth&  billing software we're using is admittedly slow.
>    Then stop your complaints about FreeRADIUS.  Don't change FreeRADIUS.
>   It's fine.
>
>> But see how easy it was to lower max_requests and allow FreeRADIUS to
>> make progress on its own during load spikes (like when a NAS reboots).
>    That is a bad solution, and one which makes the problem worse.
>
It's a working one. Just think of it: some of the new requests get 
dropped because the server thinks it can't handle them right now: it has 
already received max_requests req's during the past cleanup_delay seconds.
Doesn't my tweak do exactly this:

src/main/event.c can_handle_new_request():
         /*
          *      FUTURE: Add checks for system load.  If the system is
          *      busy, start dropping requests...
          *
          *      We can probably keep some statistics ourselves...  if
          *      there are more requests coming in than we can handle,
          *      start dropping some.
          */

?
>> PPPoE clients (most of which are ADSL modems) retry auth anyway. Noting
>> in radiusd.conf that max_clients shouldn't be set higher than the system
>> can process within cleanup_delay seconds might save some poor soul their
>> spare time in the future.
>    I doubt that.  Everyone else ensures that their system can handle the
> load.
>
>> Let me just quote Mr. Arran again:
>>> Your NAS is also behaving very strangely. FreeRADIUS only gives up on
>>> processing a request if a request with a duplicate ID, SRC IP, and SRC
>>> PORT but a different REQUEST AUTHENTICATOR is received.
>>>
>>> When a NAS retransmits it should use the same ID, SRC IP, SRC PORT and
>>> REQUEST AUTHENTICATOR.
>> By this it should be clear that it's not NAS resending unanswered auth
>> requests, but rather ADSL modems issuing _new_ requests.
>    That doesn't matter, even if it was true.
>
>    Pretty much every piece of equipment you have is horribly broken.
> Your solution is to break FreeRADIUS rather than the fix the equipment.
>
>    Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>
>