Snmp Query Configuration; Thread Pool Configuration; Table 50 Thread Pool Settings - Aruba Networks PowerConnect W Clearpass 100 Software Deployment Manual

Table 49 Proxy Configuration Settings (Continued) (Continued)
Value
proxy.dead_time = 120

SNMP Query Configuration

The SNMP query configuration value is snmp = no. To enable SNMP querying of the server, set this
directive to 'yes'. Allowed values are no and yes .

Thread Pool Configuration

Table 50 Thread Pool Settings

Value
thread.start_servers = 5
thread.max_servers = 32
thread.min_spare_servers = 3
thread.max_spare_servers = 10
Amigopod 3.7 | Deployment Guide
Description
If the home server does not respond to any of the multiple retries, then the RADIUS
server will stop sending it proxy requests, and mark it 'dead'. If there are multiple
entries configured for this realm, then the server will failover to the next one listed. If no
more are listed, then no requests will be proxied to that realm.
After a configurable 'dead_time', in seconds, the RADIUS server will speculatively
mark the home server active, and start sending requests to it again. If this dead time is
set too low, then you will lose requests, as the server will quickly switch back to the
home server, even if it isn't up again. If this dead time is set too high, then the server
may take too long to switch back to the primary home server.
Realistic values for this number are in the range of minutes to hours (60 to 3600).
Description
The thread pool is a long-lived group of threads which take turns (round-
robin) handling any incoming requests.
You probably want to have a few spare threads around, so that high-load
situations can be handled immediately. If you don't have any spare
threads, then the request handling will be delayed while a new thread is
created, and added to the pool.
You probably don't want too many spare threads around, otherwise they'll
be sitting there taking up resources, and not doing anything productive.
The default configuration should be adequate for most situations.
Limit on the total number of servers running. If this limit is ever reached,
clients will be locked out, so it should not be set too low. It is intended
mainly as a brake to keep a runaway server from taking the system with it
as it spirals down.
You may find that the server is regularly reaching the 'max_servers'
number of threads, and that increasing 'max_servers' doesn't seem to
make much difference. If this is the case, then the problem is most likely
that your back-end databases are taking too long to respond, and are
preventing the server from responding in a timely manner. The solution is
not to keep increasing the 'max_servers' value, but instead to fix the
underlying cause of the problem: slow database, or 'hostname_lookups'
set to 'yes'. For more information, see the 'max_request_time' server
option.
Server-pool size regulation. Rather than making you guess how many
servers you need, the RADIUS server dynamically adapts to the load it
sees. That is, it tries to maintain enough servers to handle the current
load, plus a few spare servers to handle transient load spikes.
It does this by periodically checking how many servers are waiting for a
request. If there are fewer than 'min_spare_servers', it creates a new
spare. If there are more than 'max_spare_servers', some of the spares die
off. The default values are probably OK for most sites.
Reference | 413