Runtime database tuning parameters
To improve performance, you can configure the database tuning parameters for Advanced Access Control.
From the top menu, select Secure Access Control > Global Settings > Advanced Configuration to access these configuration parameters. Table 1 contains the key parameters that you can use to tune the runtime database.
For a full list of the available parameters, see Managing advanced configuration.
| Parameter | Description |
|---|---|
| attributeCollection.sessionTimeout | The appliance keeps the collected session data for context-based access in the
runtime database tables. In an environment with a high volume of transactions, the tables
build quickly. Consider the rate of transactions in your runtime environment to determine an appropriate timeout value. The default value of the
attributeCollection.sessionTimeout parameter is |
| deviceRegistration.maxRegisteredDevices | The device registration process creates entries across numerous tables in the
runtime database. This value limits the maximum number of devices that each user can
register. A user can continue to register new devices until this maximum is reached. In a dynamic environment where every user has multiple devices, set this value to a number that represents a reasonable number of devices per user. To limit the volume of data in the database, do not use an excessive number. The default value of the
deviceRegistration.maxRegisteredDevices parameter is
|
| deviceRegistration.maxUsageDataPerUser | The number of records each user can have in the runtime database table that
holds usage data. If a new usage transaction is received after a user reaches this limit, the
oldest record for the user is removed to accommodate the new data. That is, the system
retains the most recent usage records for each user. In a large deployment, set this value to a number that retains the necessary usage records without overloading the table with unnecessary data. The default value of the
deviceRegistration.maxUsageDataPerUser parameter is
|
| distributedMap.getRetryDelay | The amount of time, in milliseconds, to wait before the appliance does another retrieval against the distributed map. In a cluster environment with failover support, you can use this value to cater for failover time. For example, distributedMap.getRetryDelay = 500. Note: Increasing
this value might result in longer response times.
The default value of the distributedMap.getRetryDelay parameter is 0. |
| distributedMap.getRetryLimit | The number of retrievals that are done against the distributed map before the appliance returns that the retrieved data is not in the distributed map. The default value is zero, which means that the retry is disabled. You can use this value with the distributedMap.getRetryDelay value to control the behavior of the appliance when it tries to retrieve data from the distributed map. In a cluster environment with failover support, you might want to permit multiple retrievals by setting a value such as 5. If there is network latency in the environment between cluster members, you can increase this number of retries along with the retry delay. Note: Increasing
this value might result in longer response times.
The default value of the distributedMap.getRetryLimit parameter is 0. |
| session.dbCleanupInterval | Specifies the interval, in seconds, that the database cleanup thread
runs to remove expired data in the runtime database. The database cleanup thread removes
the following types of expired data:
The default value of the session.dbCleanupInterval parameter is 86400. The minimum value for this property is 3600. |