Database Connections

Access Governance Suite is a multi-user, multi-threaded application, so depending on the use of a particular application instance, the number of database connections required can vary.

Access Governance Suite has been architected to limit the number of database connections required.  Each thread in the application can have at most one database connection, and connection pooling is used so that database connections can be shared without having to close and reconnect between each use.  Connection pooling is implemented directly in Access Governance Suite or Access Governance Suite can take advantage of pooling provided by the J2EE container's datasources.

Database use within Access Governance Suite can be classified into three categories of application components: web content, application tasks, application daemons.

To improve the usability and scalability of the web UI in Access Governance Suite, many pages will load the frame or body of the page initially and then load the data (e.g. rows of a table) with a subsequent AJAX request.  Because of this, a given web page can have multiple HTTP requests that independently require a connection to the database.  To avoid any contention for database connections, NetIQ suggests that the database pool be configured to allow three to five connections for each truly concurrent user.  Concurrent users in this context refer to users that will be loading a web page at exactly the same time.  There may be significantly more (by an order of magnitude) active application users than the number of truly concurrent users.

Application tasks are those that are managed through the Tasks page in Access Governance Suite and include things like account aggregation, identity refresh, certification generation, etc.  Most of these tasks are linear in their execution and will only use one database connection.

Some tasks have a small fixed number of parallel operations that are handled in a different thread to improve overall performance.  For example, multi-value identity and/or application attributes are persisted in a separate table from the identity and application account objects, and their persistence is handled in a separate helper thread that has its own database connection.

Some tasks have parallelization options available to allow multiple threads to handle the operations in parallel.  Identity Refresh and the certification finalization portion of the Perform Maintenance task are examples where the number of threads and therefore database connections that will be used are configurable, but default to one.  (Some of these parallelization features have been introduced in later versions of the product.)

In general the number of concurrent tasks that can be run in an Access Governance Suite instance should be configured to correlate to the number of available CPU cores (or threads if the CPU is hyper threaded).  Typically one and a half to three times the number of cores is appropriate.

A safe number of database connections would again be three to five connections for each concurrent task.  More often than not, it will only be one connection, but this may need to be increased if parallelization has been enabled (explicit configuration options) in any of the tasks.

Application daemons are those background operations in Access Governance Suite that start when the application launches and continue running for the life of the application.  The Task Scheduler is one of those components.  It continually checks to see if there are tasks available to execute and handles the starting and stopping of those tasks.  The Request Processor is another of those daemon tasks.  A safe number of connections here is in the three to five range.  The recommended number of connection pool entries for these daemons are typically accounted for in the "overhead margin".

If the application deployment architecture has divided application instances into a web tier and a task tier, then each application instance should be configured appropriately for its purpose.
In summary, our recommendations would be

• in the web tier, 3-5 connections per truly concurrent user
• in the task tier, 3-5 connections per concurrent task
• in both tiers, a 10% overhead margin

If an application instance is both serving web pages and executing tasks, then both totals would need to be taken into account.

These recommendations are intended to be safe numbers that provide a limit on resource usage, but do not create contention or the need to wait for an active connection to be available.  The numbers can be restricted below these recommendations if it is acceptable for delays to occur.  In the web tier, as long as the connection pool wait time is longer than the HTTP request processing time, starvation (no connections being available) will not occur.  In the task tier, connections are held for longer amounts of time as Access Governance Suite iterates over lists of objects, so there is less opportunity for overlapping use of the same connections.