Runtime database tuning parameters

Runtime database tuning parameters

To improve performance, we can configure the database tuning parameters for Advanced Access Control. To access these configuration parameters...
AAC > Global Settings > Advanced Configuration

For a full list of the available parameters, see Manage 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 the runtime environment to determine an appropriate timeout value. Default 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 representing a reasonable number of devices per user. To limit the volume of data in the database, do not use an excessive number. Default 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. Default 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, we can use this value to cater for failover time. For example, distributedMap.getRetryDelay = 500.Increasing this value might result in longer response times. Default is 0.

distributedMap.getRetryLimit The number of retrievals that are done against the distributed map before the appliance returns the retrieved data is not in the distributed map. Default is zero, which means the retry is disabled. We 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, we might want to permit multiple retrievals by setting a value such as 5. If there is network latency in the environment between cluster members, we can increase this number of retries along with the retry delay. Increasing this value might result in longer response times. Default is 0.

session.dbCleanupInterval Interval, in seconds, 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

Default value is 86400. Minimum value is 3600.

Parent topic: Runtime database

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 the runtime environment to determine an appropriate timeout value. Default 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 representing a reasonable number of devices per user. To limit the volume of data in the database, do not use an excessive number. Default 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. Default 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, we can use this value to cater for failover time. For example, distributedMap.getRetryDelay = 500.Increasing this value might result in longer response times. Default is 0.
distributedMap.getRetryLimit	The number of retrievals that are done against the distributed map before the appliance returns the retrieved data is not in the distributed map. Default is zero, which means the retry is disabled. We 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, we might want to permit multiple retrievals by setting a value such as 5. If there is network latency in the environment between cluster members, we can increase this number of retries along with the retry delay. Increasing this value might result in longer response times. Default is 0.
session.dbCleanupInterval	Interval, in seconds, 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 Default value is 86400. Minimum value is 3600.