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