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.

Table 1. Runtime database tuning parameters
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 1800 seconds.

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 10.

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 200.

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:
  • Session data
  • Device information
  • Obligation transaction data

The default value of the session.dbCleanupInterval parameter is 86400. The minimum value for this property is 3600.