Specific User Trace and multiple radiusd instant

[Alan DeKok]

Fajar A. Nugraha wrote:
> I can't speak for the Tom, but there are legitimate use cases for this.

  They're getting more rare.

> For example, currently FR does not have limit for a particular virtual
> server, port, or purpose (i.e. auth vs acct); everything uses the same
> server thread pool. There can be cases where acct packets flood the
> server and use up all available server threads, so that all further
> packets (including auth packets, which should need less resource
> compared to acct) is rejected. In this case it might be desirable to
> have separate instance for auth and acct.

  That usually happens when the same DB is used for accounting &&
authentication.  A high accounting load will cause starvation on
authentication.

  The solution is to split the DB into two pools.  One for accounting
(read/write), and another for authentication (read-only).  You can
provision 50 sockets for acct && auth, then 100 threads.  After that, a
blocked accounting DB will have *no* effect on authentication.

  On top of that, the server prioritizes authentication internally.  It
will preferentially process authentication packets over accounting
packets.  So that's one more way to avoid server meltdown.

  Alan DeKok.