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.