ADF Application Module tuning

One of the important parameters when doing performance tuning is tuning of the Application Modules.
Below are some of the important ampool parameters to consider for tuning:

Name

Tuning recommendation

jbo.ampool.initpoolsize The recommendation is 10% more than estimated concurrent users divided by the number of WLS managed servers, is can be aggressive for some application.
jbo.ampool.maxpoolsize 20% more than the initial pool size
jbo.recyclethreshold -20% more than the max pool size
jbo.ampool.monitorsleepinterval The length of time in milliseconds between pool resource cleanup. Default value 600000 (10’).The proposal is minimum 5’ as not to stress memory.
jbo.ampool.maxavailablesize Maximum number of available AM instances.Same value as jbo.ampool.maxpoolsize
jbo.ampool.minavailablesize 25% of jbo.ampool.maxavailablesize
jbo.ampool.maxinactiveage Same value as jbo.ampool.monitorsleepinterval
jbo.ampool.timetolive The default value is sufficient for most applications. A higher value increases the time an application module instance can exist before it must be removed at the next cleanup.Double of jbo.ampool.maxinactiveage
jbo.dofailover TRUE for live (HA) environmentsFALSE for non live (NO HA) environments
jbo.doconnectionpooling The default setting for jbo.doconnectionpooling is false. This means the application module instance hangs onto its JDBC connection while it’s in the application module pool. This is the most efficient setting because the application module can keep its JDBC prepared statements open across application module checkouts/checkins.The application module instance will trigger its prepareSession() method each time a new user session begins using it.
jbo.ampool.doampooling TRUE for live environmentsFALSE for non live environments
jbo.txn.disconnect_level When used in conjunction with jbo.doconnectionpooling=true, specifies BC4J behavior for maintaining JDBC ResultSets. By default jbo.txn.disconnect_level is 0, and passivation can be used to close any open ResultSets when the database connection is disconnected from the AM instance. Configuring jbo.txn.disconnect_level to 1 can prevent this behavior to avoid the passivation costs for this situation.
jbo.locking.mode Default locking mode is pessimisticjbo.locking.mode to optimistic or optupdateOptimistic locking recommended for Web applicationsLock acquired just before posting changes to the database”
jbo.poolmaxinactiveage Same value as jbo.ampool.maxinactiveage
jbo.doconnectionpooling and jbo.txn.disconnect_level The default setting for jbo.doconnectionpooling is false. This means the application module instance hangs onto its JDBC connection while it’s in the application module pool. This is the most efficient setting because the application module can keep its JDBC prepared statements open across application module checkouts/checkins.The application module instance will trigger its prepareSession() method each time a new user session begins using it.If you set jbo.doconnectionpooling to true, then on each checkout of an application module from the pool, that application module pool will acquire a JDBC connection from the database connection pool and use it during the span of the current request. At the end of the request when the application module is released back to the application module pool, that application module pool releases the JDBC connection it was using back to the database connection pool.It follows that with jbo.doconnectionpooling set to true the application module instance in the pool may have a completely different JDBC connection each time you check it out of the pool. In this situation, the prepareSession() method will fire each time the application module is checked out of the pool to give you a chance to reinitialize the database state.Alternatively, you can set jbo.txn.disconnect_level=1 (default is 0) to ensure that all application modules, view objects and row sets remain in memory and stay valid after their corresponding references to JDBC connections are dropped. Upon activation, the framework reexecutes and synchronizes the cursor positions. When used in conjunction with jbo.doconnectionpooling=true, setting jbo.txn.disconnect_level=1 reduces the memory overhead associated with this situation.

Leave a Reply

Your email address will not be published. Required fields are marked *