Posts Tagged ‘AEFAD’

Tuning AEFAD

When changing technologies, it’s all too easy to forget that those Asynchronous Daemon parameters that have been religiously tuned over the years need re-evaluating. This is especially true when changing database technology.

Take database connections, for example – each load module requires a connection to the database, but how long do those connections last, and how large are they – different load modules contain different numbers of open cursors, for example, leading to varying sizes of connections.

Does the -a parameter to AEFAD now hold true (this is the maximum number of load modules allowable per daemon) ?

The reason that this might be a bone of contention is that database connections require memory, and a change in technology will necessitate a recalculation of how much memory on the target database server is required. Reducing -a does indeed reduce the memory overhead, but at what cost ? Performance is usually the first thing to go here – additional paging and loading up of load modules as a result of a lower -a parameter.

Counteracting this may be a strategy to pre-load load modules into memory and lock them in, thus almost specifying the number of database connections required and thus the memory requried on the database server - but this also comes with an downside – if your application has more load modules than can be pre-loaded, then packaging needs to be changed to reduce the number of open connections – but again, at a development cost.

An invaluable tool in the tuner’s arsenal is aefc (see this post), but its no substitute for pre-thinking and performance and stress testing of a newly ported application.

Issues like re-planning the configuration of the Transaction Enabler are items on a porting project’s list that should probably come higher than they do, such that it is planned in from the start.

Gaining a DEEP understanding of the application and how it currently works is critical to the success of a porting project – allow time for this in any plan.